[Nagiosplug-devel] Please can I have GIT access

[Ton Voon]

On 4 Sep 2009, at 14:34, Alain Williams wrote:

> On Fri, Sep 04, 2009 at 09:15:05AM -0400, Max wrote:
>> On Fri, Sep 4, 2009 at 8:47 AM, Ton Voon<ton.voon at opsera.com> wrote:
>>> So I think we should have a nagios plugins library called
>>> np_write_state_data() and np_read_state_data().
>>
>> that sounds good.
>>
>>> What's the interface? Please help flesh this out. I'm guessing on a
>>> write you would pass:
>>>   * plugin name
>>>   * optional index name for the state data (eg, hostname)
>>>   * time of invocation
>>>   * serialized data
>
> We need a plugin_version number, since after upgrading a plugin the  
> serialised
> data might have changed. Perhaps this should be  
> serialised_data_format_version.

I can see that. I've written something that caches data and that uses  
a version number. We found structural changes incurred a version  
difference, which means the old cache is considered unreliable.

So I agree with adding version in.


>
> Hmmm, I thought that I understood what that meant until I wondered  
> how to use it.
> You might need to consider that a plugin might be run several times  
> on the same
> machine - so what does 'index name' mean ?

The index allows configuration to be stored "alongside" other cache  
data. Consider this: you are running on a Nagios server and you want  
to save the last in/out bits for an interface. The cache data is not  
separated by plugin name (same plugin for different hosts), and these  
could be invoked simultaneously. So the index name is a separator  
where the data should not clash.


> check_procs can want to store about a process:
> 	pid ppid name MS secs
> where	M is is the Metric (eg CPU%, virtual memory size, ...)
> 	S is the state (Critical or Warning)
> It might have a Critical AND a Warning record for any particular  
> process.
>
> What I would like is to store/retrieve a blob (serialised string)  
> that I can
> then unserialise to my taste. It might be nice to provide  
> serialisation routines,
> this might be hard to generalise.

I can picture how this works in perl, but I don't really know about C.  
(Can I get any arbitrary data structure back?)

>
>> Should we pass in time or should the write_state do that for the user
>> so plugin developers do not have to repeat passing in time every time
>> this is called?

That's a fair point. There might be a difference between "plugin  
invoke time" and "write to cache file time", but if you are saying  
that is not necessary, then we'll remove that requirement.

>>
>>> On a read, you pass:
>>>   * plugin name
>>>   * optional index name
>>>
>>> You get returned (null for error):
>>>   * last time
>>>   * serialized data
>>
>> Would you return the last time or the number of seconds since the  
>> last
>> write call?  Do I as a developer care about the real time or do I  
>> care
>> about the interval between calls to write and read?  My personal
>> preference and experience with plugins is that it is the interval
>> between calls that matters, not the absolute timestamps.
>
> In the case of my patch to check_procs what I am interested is the  
> absolute
> timestamp -- I want to know how long a process has been in a  
> particular state.
> I suspect that what this shows is that different plugins will want  
> different
> things.

I think we should have absolute timestamp, because you can then  
calculate the difference.

Ton

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20090904/0c67b588/attachment.html>