Good morning all,
lately I've tested a bit the concept of generic modules used to manage
typical inter-node functions like Monitor, Backup and Firewall.
My point and goal is to able to use in a module a class like the
following that can manage the application monitoring indipendently of
the actual monitoring software used and even of the same module used
for the same software:
class apache::monitor {
monitor::port {
"apache_port":
proto => "tcp",
port => 80,
enable => true,
}
monitor::process {
"apache_process":
name => $operatingsystem ? {
ubuntu => "apache2",
debian => "apache2",
default => "httpd",
},
enable => false,
}
monitor::plugin {
"apache_plugin":
name => "apache",
enable => true,
}
}
In order to make the above possible, it's needed a meta-module like
what I've started to write here:
http://git.example42.com/git/?p=example42modules/.git;a=tree;f=monitor;hb=HEAD
:
Puppet abstraction module: monitor
# Written by Lab42 #
# http://www.example42.com
Licence: GPLv3
DESCRIPTION:
This modules abstracts the monitoring definitions for an host or
application, in order to add
and use different monitoring methods, without changes on the single
application modules.
It's a proof of concept that tries to provide:
- a common interface for different implementations of monitoring logic
tools
- an unified syntax for monitoring resources able to adapt to
monitoring modules from different authors
- a standard way to define what an application or an host needs to be
monitored
Everything in this module is under discussion and open to
redefinition,
the goal is to prove that the concept and the implementation work
seamlessly and
to define standards accepted by the Puppet community, that can make
things this work:
class apache::monitor {
monitor {
"$fqdn_apache_port":
type => "port",
proto => "tcp",
port => 80,
address => $ipaddress,
}
monitor {
"$fqdn_apache_process":
type => "process",
name => $operatingsystem ? {
ubuntu => "apache2",
debian => "apache2",
default => "httpd",
},
}
}
USAGE:
# On the HOST to be monitored:
# set the variable: $monitor=yes
# set the variable: $monitor_<tool>=yes
include monitor::target
# On the monitoring SERVER:
# set the variable: $monitor=yes
# set the variable: $monitor_<tool>=yes
include monitor::server
# If you have different monitoring servers:
# set the variable: $monitor_nagios=yes
include monitor::server::nagios
# On the APPLICATIONS module to be monitored:
include apache::monitor # Monitor apache Automatically included
if $monitor=yes
Where you can have something like the class apache::monitor seen
before.
DEPENDENCIES:
This is a meta-module that needs dependencies according to the modules
you use.
You must have storeconfigs enabled.
You generally need the "common" module and all the prerequites for the
modules related to monitoring
applications you decide to use.
--------------
I've tried to verify if this approach can effectively work with
different software (tried with munin, collectd and nagios) and
different modulesets (tried to integrate, for testing, DavidS',
Immerda, Camptocamp, RiseUp's modules) .
An example of the latter is here:
http://git.example42.com/git/?p=example42modules/.git;a=blob;f=monitor/manifests/nagios.pp
the POF works, even if I see many open issues that I would like to
discuss here, with module-sets writers and generally whoever is
interested is some form of interoperability between modules.
First of all for my is important to find agreement on the general
concept (an unified, standard, way to monitor applications in
different module sets).
The implementation, my "alpha" module class, the same syntax and
naming conventions (the arguments needed to monitor different
resources) and the collectors structure (how to convert a generic
monitor define to a specific monitoring module by a specific module-
sets), are completely development stage and under discussion.
And is also under discussion if this same approach can work seamlessly
and cleanly.
Since I think this matter can relate also to the module-forge topic,
for me it would be important to have opinions and feedback from module
writers like David S., the guys at Immerda, Camptocamp and Puzzle,
Volcane and whoever is more or less involved in the release of public
module-sets.
Best regards,
Al
Lab42
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
