<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 4 Sep 2009, at 14:34, Alain Williams wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Fri, Sep 04, 2009 at 09:15:05AM -0400, Max wrote:<br><blockquote type="cite">On Fri, Sep 4, 2009 at 8:47 AM, Ton Voon<<a href="mailto:ton.voon@opsera.com">ton.voon@opsera.com</a>> wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">So I think we should have a nagios plugins library called<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">np_write_state_data() and np_read_state_data().<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">that sounds good.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">What's the interface? Please help flesh this out. I'm guessing on a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">write you would pass:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> * plugin name<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> * optional index name for the state data (eg, hostname)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> * time of invocation<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> * serialized data<br></blockquote></blockquote><br>We need a plugin_version number, since after upgrading a plugin the serialised<br>data might have changed. Perhaps this should be serialised_data_format_version.<br></div></blockquote><div><br></div>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.</div><div><br></div><div>So I agree with adding version in.</div><div><br></div><div><br><blockquote type="cite"><div><br>Hmmm, I thought that I understood what that meant until I wondered how to use it.<br>You might need to consider that a plugin might be run several times on the same<br>machine - so what does 'index name' mean ?<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><blockquote type="cite"><div>check_procs can want to store about a process:<br><span class="Apple-tab-span" style="white-space:pre"> </span>pid ppid name MS secs<br>where<span class="Apple-tab-span" style="white-space:pre"> </span>M is is the Metric (eg CPU%, virtual memory size, ...)<br><span class="Apple-tab-span" style="white-space:pre"> </span>S is the state (Critical or Warning)<br>It might have a Critical AND a Warning record for any particular process.<br><br>What I would like is to store/retrieve a blob (serialised string) that I can<br>then unserialise to my taste. It might be nice to provide serialisation routines,<br>this might be hard to generalise.<br></div></blockquote><div><br></div>I can picture how this works in perl, but I don't really know about C. (Can I get any arbitrary data structure back?)</div><div><br><blockquote type="cite"><div><br><blockquote type="cite">Should we pass in time or should the write_state do that for the user<br></blockquote><blockquote type="cite">so plugin developers do not have to repeat passing in time every time<br></blockquote><blockquote type="cite">this is called?<br></blockquote></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">On a read, you pass:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> * plugin name<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> * optional index name<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">You get returned (null for error):<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> * last time<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> * serialized data<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Would you return the last time or the number of seconds since the last<br></blockquote><blockquote type="cite">write call? Do I as a developer care about the real time or do I care<br></blockquote><blockquote type="cite">about the interval between calls to write and read? My personal<br></blockquote><blockquote type="cite">preference and experience with plugins is that it is the interval<br></blockquote><blockquote type="cite">between calls that matters, not the absolute timestamps.<br></blockquote><br>In the case of my patch to check_procs what I am interested is the absolute<br>timestamp -- I want to know how long a process has been in a particular state.<br>I suspect that what this shows is that different plugins will want different<br>things.<br></div></blockquote><div><br></div>I think we should have absolute timestamp, because you can then calculate the difference.</div><div><br></div><div>Ton</div><div><br></div></body></html>