[Nagiosplug-devel] Please can I have GIT access

Thomas Guyot-Sionnest dermoth at aei.ca
Fri Sep 4 18:32:09 CEST 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ton Voon wrote:
> On 4 Sep 2009, at 15:32, Thomas Guyot-Sionnest wrote:
> 
>>> If we can agree a design, I'll be looking for someone to volunteer to
>>> write this with appropriate tests to go into core plugins code. Then
>>> we can switch any particular plugins to use this if state info is
>>> required.
>> Let's not forget I also wrote the code for parsing performance data
>> strings... This method is valid and already working in my
>> snmp_counters_new branch. With Nagios v3 extended output could also be
>> used to extend performance data length beyond usual limits.
> 
> I think I was the one pushing you for this, but you can't pass the  
> Nagios envvars through NRPE (nor check_by_ssh). So I think local  
> storage is the best answer.

Arguments would work though... Would need NRPE to support safe ways of
passing them though! That seems like a trivial change but would disable
shell metachars in commands... I'd do it as a separate command type, and
I'd do the dame for Nagios too - it would make some things a lot simpler :)

Next-gen NRPE could proxy environment and/or FH too - just FYI since no
one like these methods so far :(

Also, one more thing to consider with local storage is when you have
multiple nagios instances - either part of distributed monitoring,
migrations of just for testing. In many case data accuracy rely on the
fact the the same data is relative to the last check. If you have two
nagios instances doing the same NRPE check, the scheduling may cause one
check to get a very small interval of data. For example, with cpu usage
check, that mean instead of getting the last 5 minutes, you may get only
the last few seconds. You can easily miss a CPU hog because at the
moment the check is executing the CPU was idle for the last few seconds,
even if it was full the rest of the time (because the test/backup/old
Nagios instancegot the rest of the interval data).

The fact that this method is nearly transparent make it even easier to
fall into this pitfall and pretty hard to figure out the problem without
knowing how the plugin actually work.

By comparison, when using performance data strings the stored data is
bound to a single Nagios service on a single Nagios instance. The same
check can run many times yet the plugins will *always* get it's last
performance data string.

I don't care how it's implemented in the end, but I'm favor any method
that can allow this kind of granularity without having to specifically
think about it.

- --
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqhQQkACgkQ6dZ+Kt5BchZrqQCfY4kf0cFzNVsNxepXhx2GetWU
3QcAn2ZGw9mJWqQM1JzoctqIHnvAwF2p
=gXAm
-----END PGP SIGNATURE-----




More information about the Devel mailing list