[Nagiosplug-devel] Please can I have GIT access

[Thomas Guyot-Sionnest]

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

Jose Luis Martinez wrote:
>> 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.
> 
> The problem, in my opinion, is that a plugin has no idea about what 
> service check definition it is bound to, so it can't determine reliably 
> the state of it's last execution.

I'm not sure if you understand well how this works. Basically the plugin
requires you to pass the performance data string and possibly the last
check time (It can also get them from Nagios macros if they're enabled).
The data is either present or not, and if it's not the neck populates
the performance data and return UNKNOWN so next run will hopefully has
the performance data.

So the data comes from Nagios, and the result of a check *always* comes
from a computation based on the same service's data since it was passed
by Nagios from the same check.

I have some examples (check_perfmon - a check runing against windows
performance logs in CSV format, and a branch of nagios-plugins with
similar feature to check_snmp), unfortunately I had to take my server
down and hasn't had time to move the repositories, so no code right now :(

Since both are meant to run from the central nagios server (unless in
cases where checks are distributed to satellites which isn't supported
unless arguments can be passed around) this work well. The downside of
this method is that performance data can only contain numbers and NRPE
currently doesn't support safe argument passing (this should be fairly
easy to fix though).

>> 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.
> 
> If Nagios / NRPE could just pass a unique ID for each service check 
> definition, the plugins could use that by default to generate the 
> tempfile name for their local storage. The unique ID could be a GUID, so 
> that different Nagios instances would not generate the same IDs, thus 
> solving the "multiple Nagios instances" problem too...

Same problem with remote checks, that ID has to be passed around,
although that would be a viable solution to the problem I'm trying to solve.

So far we have:

- - Performance data
  * Pros:
    - Bound to service - no cross-service data overlap
    - No Nagios modifications needed
  * Cons:
    - Only small numeric values can be passed
    - Requires remote executor to pass arguments

- - File-descriptor passing
  * Pros:
    - Bound to service in recommended setup
    - Large/binary storage possible
    - Allow flexibility in how data is stored regardless of plugin language
  * Cons:
    - Requires wrapper or Nagios/remote-executor modifications
    - Less intuitive - users are not familiar with this
    - May require remote executor to pass FDs or implement storage

- - Plugin-bases with unique service ID
  * Pros:
    - Simple
    - Bound to service in recommended setup
    - Large/binary storage possible
  * Cons:
    - May requires Nagios modifications(*)
    - Requires remote executor to pass arguments
    - Different data storage requires modifications to the plugin

(*) It is easy using a well-templated config to use a unique Nagios
identifier + hostname + servicedescription as a unique ID, however I
don't expect many setups to be able to do that off-hands as it require
every services to use or include a single template...

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

iEYEARECAAYFAkqmWX4ACgkQ6dZ+Kt5BchZHUwCg+JShyKRi++AJnByYV8qNCXan
8wEAoOS63GlniC4pxdX4QVXQ0tRbtks+
=cf/9
-----END PGP SIGNATURE-----