[Nagiosplug-devel] Please can I have GIT access

Thomas Guyot-Sionnest dermoth at aei.ca
Fri Sep 4 16:32:48 CEST 2009


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

Ton Voon wrote:
> Sorry, didn't read this thread earlier.
> 
> I also prefer the files option. My approach is to abstract the  
> plugin's interface to the actual implementation, and then get the  
> implementation working in the simplest way possible first. If it turns  
> out to be a bottleneck, we can enhance the implementation without  
> changes to the plugin.
> 
> So I think we should have a nagios plugins library called  
> np_write_state_data() and np_read_state_data().
> 
> 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
> 
> On a read, you pass:
>    * plugin name
>    * optional index name
> 
> You get returned (null for error):
>    * last time
>    * serialized data

That sounds pretty good, and so far you did not specify any storage
methos so it's totally abstracted from the plugin.

> We can implement this first as writing to files. If this is a problem,  
> we can always switch to memcache or sqllite or some other technique  
> later.

And that's where my view differs. If we implement the actual storage
method in the plugins library then any new storage method will require
modifying the code. It will also require to be coded in each of the
languages plugins are written in (perl, c...).

OTOH the functions above could read/write filehandles and a wrapper
would take care of the rest. We'd provide at least one of them (e.g.
files) and anyone could contribute other kind of wrappers. Nagios and
NRPE could also eventually provide directly the storage for simplicity.
Furthermore Nagios could allow modules to override plugin storage so
efficient methods could be plugged in directly.

My approach also allow writing wrappers in any language, even a few
lines of shell code can do the trick. If someone needs Yet Another
Storage Method(tm) he doesn't have to actually know C and perl, nor do
he has to modify any of the plugin code. He just has to place his own
wrapper in between and he's done.

> If we can agree a design, I'll be looking for someone to volunteer to  
> write this with appropriate tests to go into core plugins code. Then  
> we can switch any particular plugins to use this if state info is  
> required.

Let's not forget I also wrote the code for parsing performance data
strings... This method is valid and already working in my
snmp_counters_new branch. With Nagios v3 extended output could also be
used to extend performance data length beyond usual limits.

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

iEYEARECAAYFAkqhJRAACgkQ6dZ+Kt5BchYFBACgjBDhYxmVq+7tR8wCixjJHRr2
YLsAmgKDRM0X2v1Aw5w+hmPbiTm5CdO/
=+G3p
-----END PGP SIGNATURE-----




More information about the Devel mailing list