[Nagiosplug-devel] Patch for persistent data on plugins

[Ton Voon]

On 17 Sep 2009, at 13:53, Jose Luis Martinez wrote:

> The thing is that you can be executing the same plugin with the same
> hostname 2 times on the same machine (with different params). One  
> plugin
> would pick up the data of the other plugin.
>
> As an example:
> check_disk --disk=sda -w=90 -c=95
> check_disk --disk=sdb -w=90 -c=95
>
> That gets reflected as the "instance" parameter in the proposed API.  
> The
> bad thing is that the developer has to be VERY aware of this  
> situation,
> and could lead to very hard to understand and hard to debug results  
> for
> the user of the plugin.
>
> If in the disk example, the developer chooses the --disk param as the
> instance id, and the plugin has a couple of extra params (to select
> blocks in and blocks out, for example), one possible use of the plugin
> would lead to problems:
>
> check_disk --disk=sda --blocksin -w=90 -c=95
> check_disk --disk=sda --blocksout -w=50 -c=95
>
> And the developer may have not been aware of this use case.
>
> IMHO, the instance id should not be selected by the developer, as he  
> is
> not capable of previewing all these situations. There should be a  
> way of
> automatically giving it to the plugin.

I think I'd rather the developer consider these options, than make it  
difficult for the nagios administrator to configure.

> The base case is: If you have a plugin that generates a piece of data,
> and recollects it later, and you have it defined N times in Nagios (be
> whatever you want it's parameters), you would exepect that every
> "instance" of the check gets back the data it stored. That would be  
> that
> the check is "bound to the service".

I think this actually shows that Nagios should interpret the perfdata.  
If nagios stored the previous values, then it can work out things like  
rate changes.

Ton