[Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins

Florian Gleixner flo at bier.homeip.net
Tue Jan 2 00:14:22 CET 2007


True, leaks and crashes could make nagios more unstable. dl-plugins
should be used with care. "Worker threads" could isolate some of the risk.

The performance gain is simply the time a C plugin needs to create a
process. You could say, that this is not very much time, but some nagios
setups make thousands of checks per minute. Here is a very simple test:
The bash has the echo command build in. On most linux systems you will
find a /bin/echo program with same functionality too. So compare:

time for ((i=0 ; i< 10000 ; i++)) ; do echo bla ; done
real    0m1.536s
user    0m0.172s
sys     0m0.020s

time for ((i=0 ; i< 10000 ; i++)) ; do /bin/echo bla ; done
real    0m34.047s
user    0m8.761s
sys     0m15.365s

I think some default plugins like ping or tcp-check could be made as dl
module, the more complicated or the plugins that are usually executed at
the monitored nodes should be "normal" plugins.

I never had a look at the nagios code, it was just a idea popping up.

Flo

Thomas Guyot-Sionnest wrote:
> If I understand it correctly, it could also make Nagios crash and leak
> memory much more easily.
> 
> C plugins are very fast already and can behave pretty badly without
> affecting the main process. What performance gain could we expect going
> from C to dynamically loaded plugins?
> 
> Thomas
> 
> On 31/12/06 07:07 PM, Florian Gleixner wrote:
>> Hi,
>>
>> is there or is it planned to support some time plugins that are compiled
>> as dynamic libraries and can be loaded with dlopen()?
>> The embedded perl is very nice and makes plugin development fast, but a
>> C/C++ api with dynamically loaded plugins could make nagios much faster.
>>
>> Flo
>>
>> Ethan Galstad wrote:
>>> Hi Everyone -
>>>
>>> One of the things that Nagios 3 will support is the ability to use the 
>>> embedded Perl interpreter for specific perl plugins only, instead of all 
>>> or nothing. The Nagios 3 development code currently support the 
>>> following...
>>>
>>> Line 2 of a Perl plugin may start with one of the following:
>>>
>>> #USE_EPN
>>>
>>> -or-
>>>
>>> #NO_EPN
>>>
>>> If the #USE_EPN statement is found, Nagios will use the embedded Perl 
>>> interpreter to run the plugin.  If #NO_EPN is found, it will not be used 
>>> (even if epn is compiled in and enabled in the Nagios daemon).  If 
>>> neither directive is found, Nagios will default to the behavior 
>>> specified by a new 'use_embedded_perl_implicitly' variable in the main 
>>> Nagios config file.
>>>
>>> Plugin devs - would you prefer different statements other than #USE_EPN 
>>> / #NO_EPN, or are they okay?  Any other comments or suggestions?
>>>
>>>
>>> Ethan Galstad,
>>> Nagios Developer
>>> ---
>>> Email: nagios at nagios.org
>>> Website: http://www.nagios.org
>>>




More information about the Devel mailing list