[Nagiosplug-devel] Please can I have GIT access

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


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

Holger Weiß wrote:
> * Thomas Guyot-Sionnest <dermoth at aei.ca> [2009-09-01 15:15]:
>> Just for completeness the FD method uses files primarily, but it
>> actually gives that control to the caller. This means:
>>
>>  * Plugin only cares about FD numbers to use, caller decides where data
>> will go. No extra work, library or complex code required in the plugins.
>>  * If desired, caller can send FDs pointing to mmaped memory, and then
>> decide where to store it afterward (private RAM, SHM, memcached, SQL...)
>>  * Any custom wrapper can be used, for any desired retention method.
>>  * Nagios and NRPE could provide basic methods for simple setups and to
>> avoid an extra fork. Furthermore Nagios modules could be used to extend
>> Nagios functionality in an efficient manner on large sites.
>>
>> I believe this method is much closer to the Unix philosophy of having
>> multiple components doing simple tasks.
> 
> I'd associate passing file descriptors around between every process and
> his dog with DJB's philosophy rather than with the Unix philosophy :-P

Awww. I've been unmasked! ;)

Well, DJB's way it pretty much the same philosophy as UNIX.

> Personally, I'd prefer not to bother the caller with this stuff.  Of
> course, I'm fine with providing options, but I'd rather not _force_ the
> caller to setup storage for state retention and to play file descriptor
> games just to get this functionality.  It's simply not his job to hold

I don't see it as forcing the caller... It wouldn't be required unless
if the plugin have to store data. Moreover it can be done with a wrapper
program (or even directly trough the shell) so there's not absolute need
for supporting it in the caller.

> state information for the executed plugin, and I guess it would cause
> quite a bit of confusion (e.g., when users test plugins they use in
> Nagios on the command line).  In general, I'd like to keep the plugin
> interface as simple possible.

The plugin can easily detect if the FH isn't open and throw an helpful
error. Moreover, I believe nagios should be told explicitly to store
data for a command.


My though regarding this is the FH method gives a lot of flexibility
(the same flexibility as using the performance data method without its
downfalls), and considering that people have many different ways they
may want to store data (FILE, RAM, Memcached...) that flexibility would
be welcome.

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

iEYEARECAAYFAkqhHo0ACgkQ6dZ+Kt5BchYyfACgu4OSjeJavlQW5/WJZjRQVr33
CV8An3/ObGscsoA7f4ow9aWPWJzPq2qs
=UBvD
-----END PGP SIGNATURE-----




More information about the Devel mailing list