As one who has previously used Puppet to drive Nagios configurations (and
attempted to contribute patches to Puppetlabs), allow me offer a somewhat
fabulous alternative: check_mk. check_mk is a package that can be used to
generate your Nagios configuration in a programmatic fashion. Here's how
it works for my site:
1) Puppet runs on every host export three files: ${hostname}.mk,
${hostname}.mk.wato, and ${hostname}.parents.mk as well as ensuring that
the check_mk agent is installed, along with our local extensions.
2) Those files are collected on the appropriate Nagios server using tags
and the spaceship operator in a no-replace operation.
3) If new files get written, an exec{} gets kicked off that runs the
check_mk inventory against the new hosts and regenerates the Nagios
configuration.
Step three is where most of the magic happens. As an example, our check_mk
configuration files specify that hosts named with "c2h" are Resin
application servers. check_mk will automatically assign the three
web-based checks (port 80 HTTP, port 443 HTTPS, and a /resin-status URL
that gets parsed for app server data).
The programmatic decision on checks makes lots of stuff easy. Inventory
makes some of the stuff even better. As an example, ever notice that every
time you use a different network configuration (1-2-3 NICs, bonding,
VLANs), you need to do separate checks and write extra rules? The
inventory catches all of the current network configuration and watches
that, and any changes will show up as an appropriate notification (in our
case, we chose to mark those as UNKNOWN). You can also choose to have
weighting on your disks, i.e. a 4GB disk alarms at ~75% utilization while a
30TB filesystem doesn't alarm until it hits ~98%. The weighting is done
with a strict formula, and isn't always appropriate, but for our
environment it works very well.
On Tue, Jun 12, 2012 at 4:34 PM, Jared Ballou <jbal...@jballou.com> wrote:
> Hi everyone,
>
> I am reconsidering how I am using the Puppet nagios functionality, at
> the moment I am creating one service for each check on each host. A
> lot of them are identical, and would be better tied to hostgroups to
> simplify my config. Namely, I have about 5,000 checks in there now
> which will go up to about 20K over the next month, and it's taking
> about 5-10 minutes for a Puppet agent run on the nagios server now.
> I've tried running through the spaceship operator to collect hostgroup
> members or assign groups to hosts at realization time, but I can't get
> it working. Does anyone have this sort of setup done for me to poke
> at, or am I stuck with making an object for each check?
>
> Thanks,
>
> -Jared
>
> --
> 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.
>
>
--
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.
