[Nagiosplug-devel] Please can I have GIT access

[Thomas Guyot-Sionnest]

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

Jose Luis Martinez wrote:
> Thomas Guyot-Sionnest escribió:
>> 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
> 
> Another con: you may be outputting perfdata in a format that is not 
> "usable" the next time the check is executed. Suppose an incrementing 
> counter. I normally read the counter, but output "things since last 
> check" or "things since last check / second" in the performance data, so 
> getting that perfdata back doesn't help me do the next calculation.
> 
> I see this method as too limiting :S

I still don't see where you have an issue. Performance data has a very
specific format and this method doesn't break it (hence the "Only small
numeric values can be passed" Cons. I've been using this method
successfully for some time now.

>> - - 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
> 
> I don't understand how the wrapper will be bound to the service. Isn't 
> the wrapper just another plugin? If so, can't the wrapper and the "self 
> contained storage" use the same method for binding to the service?

Well, either you have Nagios provide the FDs or have a properly
ocnfigured wrapper doing it; that's why I say "Bound to service *in
recommended setup*" It sure is easier to fuck up than the performance
data method, but guarding applications against user stupidity will
*always* be a tricky game ;)

> I would be open to adapting Nagios::Plugin::Differences to also support 
> the use of FD's as a pluggable storage mechanism, it shouldn't be too 
> complex (was already planning for pluggable storage)

As you wish... though IMHO I think we should settle on a single method.
and use it. Even if we go file-based, the advantage with a perl module
is that you can allow using different modules for storage given a
specific API. In other words, anyone could write it's own data storage
module and plug it in directly. You could use some sort of "connection
string" (referring to the perl DB API since It has similar purpose) that
would allow selecting the storage method using a parameter from
command-line options.

Similar thing could be possible in C but it's harder and would require
writing the storage engine in C as well.

>> - - 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
> 
> But it's always good to give people a choice, and if you give me that 
> unique ID, the two solutions would be usable.
> 
> And thinking about this further... there is another way to bind to a 
> service (mixing and matching tecniques). It's based on generating a 
> token if one hasn't been passed, and then getting it back (via the last 
> check (maybe via $SERVICEOUTPUT$, maybe via perfdata)?
> 
> if ($SERVICEOUTPUT$ contains tk=UUID){
>     read /tmp/UUID;
>     do_stuff();
>     write /tmp/UUID;
>     output "$output tk=UUID";
>     exit $status;
> } else {
>     UUID = gen_UUID();
>     write to /tmp/UUID;
>     output "UNKNOWN tk=UUID";
>     exit with UNKNOWN
> }
> 
> Of course, this is a poor man way of getting a unique ID passed back to 
> you :D

Or another option, write a brand new plugin API which is much more
extensible and allow passing specific values (besides output and
performance data) back to Nagios. Most people think of XML though I
believe it's up for debate - there are simpler and smaller solutions
IMHO, and I believe Andreas agrees with me on this ;)

Obviously that's a big change; It won't be done quickly nor easily so
there mucg be strong incentives and community support for this to happen.

Before someone yells about it, backwards-compatibility to the hundred of
plugins out there can easily be achieved with a wrapper that runs them
and return new-format output...

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

iEYEARECAAYFAkqmfeAACgkQ6dZ+Kt5BchZJvQCfaN6FrRci85iHQOEf7f8gYhTm
/fEAn0mVM2uMbW4DrddD8+JMp0Bz3goA
=AA4h
-----END PGP SIGNATURE-----