I've tried to achieve my overall goals with several different features
of Puppet, but I've hit a bit of a wall here. I think it's time for me
to explain what I'm trying to accomplish:
I want the enabling of a service in my manifests to configure
the monitoring of that service by a nagios server, without
needless repetition.
Let me explain how my non-automated nagios3 server is configured:
Each service is declared once per type (or type+role, but there
are very few types distinguished by role, so we'll ignore that
for now). Services are members of hostgroups and servicegroups,
and hosts join hostgroups in order to activate monitoring.
Servicegroups are mostly used for sorting in the Web UI.
Now let's look at how Puppet "wants" to configure Nagios:
Each host exports a unique service for each of the checks it
should be subject to.
Holy cow! So if I have 25 checks per machine, and a thousand nodes,
that's 25,000 entries! We're talking about a nagios_services.cfg
measured in the tens of *megabytes*! I'm a little stunned by this
pattern.
I had created a system whereby nodes exported concat::fragments
expressing desired membership in a hostgroup, and defines that created
services, hostgroups, and servicegroups only if they hadn't already been
made. All this ground to a halt and with only 50 test nodes the
compilation of the nagios server's catalog took 3 minutes on a
reasonably spec'd machine. I have to assume that the AST's mass of
defines-of-defines was partly to blame.
I'd like to make it as simple as possible for my module writers: "Just
use the nagios::nrpe_check define. That'll make the nrpe config locally
and export everything needed to ensure this host is checked for your
module's behaviors!" Forcing them to make a service check *here* and a
hostgroup *there* and don't forget to add the hostgroup to the node that
used the class *there*… well it just opens up too many opportunities for
human fallibility.
So what are my options here? I don't want to probe the hosts to
determine what should be monitored, because the whole *point* of
monitoring is to alert you when your live system state isn't what you
asked for. I also worry that this Cartesian product of everything by
everyone will not scale acceptably into the future.
Fingers crossed that I'm just being dense and missed something big!
--
"Ill-informed qmail-bashing is better than no
qmail-bashing at all."
--Don Marti
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
