Custom plugin issue

[Stanley Hopcroft]

Dear Ladies and Gentlemen,

I am writing to thank you for your letter and say,

On Fri, May 13, 2005 at 09:23:31AM -0700, nagios-users-request at lists.sourceforge.net wrote:

> Message: 7
> Subject: RE: [Nagios-users] Custom plugin issue
> Date: Thu, 12 May 2005 23:31:24 -0500
> From: "Marc Powell" <marc at ena.com>
> To: <nagios-users at lists.sourceforge.net>
> 
> 
> 
> > -----Original Message-----
> > From: nagios-users-admin at lists.sourceforge.net [mailto:nagios-users-
> > admin at lists.sourceforge.net] On Behalf Of Jelle Smet
> > Sent: Thursday, May 12, 2005 6:47 PM
> > To: nagios-users at lists.sourceforge.net
> > Subject: [Nagios-users] Custom plugin issue
> >=20
> > Hi all,
> >=20
> > I made a plugin written in perl.
> >=20
> > It compiles OK with      " use strict; " in the code.
> >=20
> > Now i want to compile my script with "perlcc  -B"
> >=20
> > Which works.  The executable executes on the bash prompt without a
> > problem.
> >=20
> >=20
> > If I add my new checkcommand to nagios and use it, Nagios gets an
> error ;
> >=20
> >         **ePN 'check_temp' Missing right curly or square bracket at
> > (eval 3) line 11, at end of line
> >=20
> > It's not that the plugin receives parameters which are out of
> boundary.
> >=20
> > Anyone with a clue, advice?

(Yep. Avoid mailers that convert spaces into =20 will 'improve your IQ, 
help with everything you do, it's recommended, don't cost too much')

> 
> Mr. Hopcroft will probably be the definitive source on this but have you
> tried _not_ compiling your perl script?

My advice too, especially since I think the 5.8.x Perls broke perlcc: it 
doesn't even generate C for me.

(stan> cat x.pl
#!/usr/bin/perl -w

use strict ;

print "Hello Perl.\n" ;

exit 0 ;
stan> perlcc x.pl

--------------------------------------------------------------------------------
Compiling x.pl:
--------------------------------------------------------------------------------
Making C(x.pl.c) for x.pl!
/usr/local/bin/perl -I/usr/local/lib/perl5/site_perl/5.8.5/mach 
-I/usr/local/lib/perl5/site_perl/5.8.5 -I/usr/local/lib/perl5/site_perl 
-I/usr/local/lib/perl5/5.8.5/BSDPAN -I/usr/local/lib/perl5/5.8.5/mach 
-I/usr/local/lib/perl5/5.8.5 -I. -MO=CC,-ox.pl.c x.pl
Can't locate object method "fake_ppaddr" via package "B::FAKEOP" at 
/usr/local/lib/perl5/5.8.5/mach/B/C.pm line 365.
CHECK failed--call queue aborted.
ERROR: In generating code for x.pl!
stan> 
)

But in any case, embedded Perl Nagios scans the first line of the plugin 
text for '/bin/perl' and any plugins that are found are converted into 
the internal Perl op-code tree (by eval 
'your_plugin_wrapped_into_a_subroutine'. This is exactly the same 
process as used by Registry.pm in mod_perl)

Since ePN compiles your code and retains the Opcode tree in memory, 
there is no need to use the B modules to convert your plugin into a C 
program (and then compile it). Doing so would not help since 

1 you defeat the embedded Perl function

2 the B modules are intended for generating byte code (or for 
distributing binary code). No one has ever clamied that they 
generate more efficient code for any metric (faster, less memory etc)

> It looks like you built nagios
> (whatever version) with the embedded perl interpreter which I believe
> compiles and caches the perl code anyway. The documentation at
> http://nagios.sourceforge.net/docs/1_0/embeddedperl.html has some
> suggestions for creating a compatible Perl program and debugging the
> ePN. 

Yep. Don't use perlcc with embedded Perl Nagios (ePN).

(If the OP meant that the plugin wouldn't run even though perlcc would 
compile it, please keep reading).

You do have to be more careful with Perl coding when using ePN. The URL 
Mr Powell quotes lists some gotchas.

Also you can try the /contrib directory for an ePN simulator to give you 
some confidence that your plugin _will_ run under ePN (this isn't too 
hard, I write Perl plugins all the time and very few cause problems). 

There are also further (unpublished) tools that simulate some aspects of 
ePN Nag more completely, let one check large numbers of Perl plugins for 
compliance etc. Write me if interested.


> If you don't have a lot of perl based plugins or checks then it's
> probably more worthwhile to recompile nagios without embedded perl. You
> can then run the perl scripts as normal plugins and probably compile
> them as above too. I believe that ePN still has some memory management
> issues requiring a periodic reload but don't take my word on that.
> 

Depends eactly what you mean by 'memory management issues' and which 
Nag/Perl.

Embedding Perl trades off leaks and greater mem use against better 
plugin performance/less CPU utilisation. 

Even spohisticated implementations like mod_perl leak and require 
restarting. However embedded Perl Nagios has these specific issues

1.x   with _unthreaded Perl_,  no leaks known to me over the statement 
      above

2.x   prior to CVS of ~ 10 May 2005.

      (NB 2.x Nag _requires_ threaded Perl)

      Unacceptable leak rate much greater than for 1.x.

      Unusable without monitoring the Nagios process (check_procs) &
      restarting when the vsz gets over threshold

2.x  after 10 May 2005

     Leak rate comparable (to me & prob one tester) to those with 1.x

     What is the leak rate ?

     The leak rate is proportional to the number of Perl plugins and 
     the Nagios running time.

     For me (~ 55 Perl plugins, most requiring large OO Perl modules)
     and about 400 active service checks (not all Perl), the leak rate
     is about 576 kB/day. Note that this is the steady state leak rate.
     (initially Perl has to alloc a lot of memory to cache the plugins,
      so the Nag vsz quickly climbs to [this case] about 18 MB).

To the best of my knowledge significant sites (ie >= 1000 services) are 
using embedded Perl Nagios because of the better Perl plugin performance.

My advice concerning ePN 

1 Don't use it unless you _know_ you need it or can manage the trade 
offs

2 OTOH, if you have a lot of Perl plugins (especially custom plugins) 
and you can't get the performance you need out of plain Nagios, use 
embedded Perl.

Finally, the embedded Perl Nagios has suffered a bit because

1 there are no good Perl/C developers supporting it

2 there has not been a great deal of confidence in the embedded Perl
  support.

It would be good if people were to say, "What are you on, man ? 5k 
services, Perl 5.6.x, 200 Perl plugins and leak rate is ~ 0.5 GB/day 
_and_ performance sucks" or whatever is the case.

If enough people were to do that to convince me that I and the project 
were wasting their time, it would be pulled.


> --
> Marc
> 
>

Yours sincerely. 

-- 
Stanley Hopcroft

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: disclaimer.txt
URL: <https://www.monitoring-lists.org/archive/users/attachments/20050514/3e67daa7/attachment.txt>