[Nagiosplug-devel] Please can I have GIT access

[Jose Luis Martinez]

Thomas Guyot-Sionnest escribió:
> 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.

OK, I didn't realize that this was possible now! (I'm supposing via 
$SERVICEPERFDATA$ and $LASTSERVICECHECK$).

> 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

> - - 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?

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)

> - - 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


Jose Luis Martinez
jlmartinez at capside.com