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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On 3/9/2010 10:52 AM, Al @ Lab42 wrote:> 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=HEADOh, sweet! Great idea :-) One quick nit on monitor::plugin: the current design would require having the same name for plugins in collectd and munin, which would preclude implementation-independent monitoring. The two solutions I see here is either create a implementation-specific name mapping (e.g. in defines/plugin.pp) or use monitor::plugin::{munin ,collectd} directly. The latter would be less flexible and require moving the "if $monitor_collectd == "yes" {" into the specific defines. I''ll try to take a deeper look later today. Best Regards, David Schmitt -- dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at Klosterneuburg UID: ATU64260999 FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Tue, Mar 9, 2010 at 5:57 AM, David Schmitt <david@dasz.at> wrote:> On 3/9/2010 10:52 AM, Al @ Lab42 wrote: >> >> 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 > > > Oh, sweet! Great idea :-) > > > One quick nit on monitor::plugin: the current design would require having > the same name for plugins in collectd and munin, which would preclude > implementation-independent monitoring. > > The two solutions I see here is either create a implementation-specific name > mapping (e.g. in defines/plugin.pp) or use monitor::plugin::{munin > ,collectd} directly. The latter would be less flexible and require moving > the "if $monitor_collectd == "yes" {" into the specific defines. > > > I''ll try to take a deeper look later today. > > > Best Regards, David Schmitt > --I''m wondering if this might be more seamless if done as a system of monitoring types and providers? i.e. we have the nagios stuff in core now, but if we had a generic ''monitor'' type with a nagios provider, other provider, etc... (We''ve been wanting to move some of the nagios stuff out of core anyway, so it could be rev''d seperately from Puppet) One catch is that it''s initially more effort, but might make things simpler on the end user side (no variables to set, etc). --Michael -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mar 9, 11:57 am, David Schmitt <da...@dasz.at> wrote:> On 3/9/2010 10:52 AM, Al @ Lab42 wrote: > > 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=monito... > > Oh, sweet! Great idea :-) > > One quick nit on monitor::plugin: the current design would require > having the same name for plugins in collectd and munin, which would > preclude implementation-independent monitoring. > > The two solutions I see here is either create a implementation-specific > name mapping (e.g. in defines/plugin.pp) or use monitor::plugin::{munin > ,collectd} directly. The latter would be less flexible and require > moving the "if $monitor_collectd == "yes" {" into the specific defines.Yep, good point. Actually I don''t even like a "monitor type" called plugin, since is not related to something to monitor (port, process, host or whatever). It''s intended as a shortcut to quickly include the relevant plugin, if any, of a monitoring software. And *generally* the name of the plugin is the name of the application. In any case, generally speaking I''d prefer to keep the monitor define as much independent as possible and abstract from the actual monitoring tool, so in this case I''d prefer the first solution, Ciao 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mar 9, 3:58 pm, Michael DeHaan <mich...@reductivelabs.com> wrote:> On Tue, Mar 9, 2010 at 5:57 AM, David Schmitt <da...@dasz.at> wrote: > > On 3/9/2010 10:52 AM, Al @ Lab42 wrote: > > >> 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=monito... > > > Oh, sweet! Great idea :-) > > > One quick nit on monitor::plugin: the current design would require having > > the same name for plugins in collectd and munin, which would preclude > > implementation-independent monitoring. > > > The two solutions I see here is either create a implementation-specific name > > mapping (e.g. in defines/plugin.pp) or use monitor::plugin::{munin > > ,collectd} directly. The latter would be less flexible and require moving > > the "if $monitor_collectd == "yes" {" into the specific defines. > > > I''ll try to take a deeper look later today. > > > Best Regards, David Schmitt > > -- > > I''m wondering if this might be more seamless if done as a system of > monitoring types and providers? > > i.e. we have the nagios stuff in core now, but if we had a generic > ''monitor'' type with a nagios provider, other provider, etc... > > (We''ve been wanting to move some of the nagios stuff out of core > anyway, so it could be rev''d seperately from Puppet) > > One catch is that it''s initially more effort, but might make things > simpler on the end user side (no variables to set, etc). > > --MichaelThat''s interesting. Probably something more integrated in Puppetland would manage better the flow and conversion of variables from general monitor definitions to specific calls for different monitoring software. And moreover it would be more easily integrated into users'' modules. I also think that it''s important to keep abstraction (in your own application XYZ module you define what to monitor, without the need to know or decide what you use for monitoring) and have the possibility of extending the base monitor defines (or whatever kind of meta- objects) to manage singularities and specific settings. Another important point IMHO is to keep the possibility of choosing different monitoring tools AND use different implementations (module, in this case) for the same tool (ie, manage Nagios with custom templates and static files, without using Nagios types). 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Le mardi 09 mars 2010 à 10:26 -0800, Al @ Lab42 a écrit :> In any case, generally speaking I''d prefer to keep the monitor define > as much independent as possible and abstract from the actual > monitoring tool, so in this case I''d prefer the first solution,I do agree this point. I''m not a puppet development ninja but I''d prefer to see something like a "meta property" added to types. Making this the more abstract from the monitoring is, to me, mandatory. My 2c Nico.