> A Nagios server on each monitored host?
> And this should scale better than NRPE?
>
> I really cannot believe that this is the "intended" usage.
> This kind of seems to reverse the usual Nagios monitoring from a
> mainly polling to an entirely pushing scheme.
> I so far only monitor abt. 400 hosts from my Nagios server,
> and for a while had a very modest delegation to merely two other
> distributed Nagios servers (mainly owe to firewall impedances)
> for less than 50 hosts.
> But even in such a trivial setting I found that the nsca server on my
> central Nagios server was almost overburdened
> by the load of incoming passive check results (or rather the xinetd,
> which admittedly probably wasn't the best choice).
> Added to this came the configuration overhead, but ok, I understand
> you are letting Puppet handle this.
> As a complete Puppet novice I think for now this would be beyond my
> capabilities anyway.
The nsca solution can be problematic - we wrote our own receiver/
sender and shipped stuff via snmp instead. I seem to remember a skew
issue - where all nsca updates from all servers where sent on the
minute (ie. zero seconds past the minute) - can't recall how this was
solved exactly though.
With nrpe, we had processes blocking and the queue wasn't being
processed quickly enough on the main nagios host. The scheduler within
nagios can be complex when mixing active/passive services - so we
moved active checks away onto other servers and let the main server
only do passive.
> Nay, disk space isn't that expensive these days anymore.
> But I'm a supporter of the old virtue that what isn't required on a
> host
> shouldn't be installed on it.
Well - I guess it was a loaded question. My point was its kind of
going against the grain. Not that I don't think you have a point - RPM
kind of lacks the ability to handle optionals as far as I can see - so
dependencies are mandatory. *shrug*.
If you really do want to do this, I have in the past written my own
wrappers around package to extend functionality of the core one. This
example worked around added a 'disableexcludes' parameter for when you
want to install packages but don't want 'yum upgrade' picking them up
during upgrades - things like tomcat and kernel may fall into this
category.
define my_package(
$ensure,
$disableexcludes = false) {
# Normal package type cannot handle disableexcludes - so this
is a convenient
# wrapper around exec that tries to pretend its a package :-)
if $disableexcludes == true {
$cmd = "yum --disableexcludes=all -y install $name ;
rpm -q $name"
package {
$name:
noop => true,
ensure => $ensure,
require => Exec[$cmd];
}
exec {
$cmd:
command => $cmd,
timeout => 1800,
unless => "rpm -q $name";
}
} else {
package {
$name:
ensure => $ensure;
}
}
}
You could very easily adapt this to add a 'nodeps' option for yourself
- so when it is set dropping to using the yum command in an exec as I
have shown. This will avoid having to modify the core ruby code. I did
a bit of wrapping like this at my last job - for example I had my own
'foo_mount' resource which also turned on nagios monitoring
implicitly.
ken.
--
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.
