[Nagiosplug-devel] Re: Hooray - 1.4 is out! What next?

[Stanley Hopcroft]

Dear Folks,

Le Vendredi 4 Février 2005 12:17, Benoit Mortier a écrit :
> Ton Voon wrote:
> > Well, we've finally got to 1.4. Thanks to everyone who has helped 
> > this release out and helped make this software better.
>
> Splendid news. Nice work, fellas.
>
> > What's next? 


> > For 1.5;
> > * aim to get rid of output parsing plugins completely. Implement 
> > system calls to get disk/memory/swap/load status instead (the ISC 
> > dhcp suite of
> > programs have excellent ways of determining system type and 
> > version).

> that's the way to go ..

> > * rewrite commonly used perl/shell/python/whatever plugins in C. 
> > (this will in time allow Nagios to load plugins as shared modules, 
> > which can only be a good thing).

> Yes, i wanted to do that for a long time.

> > * minimize the perl module dependencies.

> That would be agood thing


Why ?

You may wish to do this because you are reselling Nagios and the Nagios 
plugins, and want to conceal the fact, or it reduces your installation 
costs. This is not necessarily a bad thing; a slicker install is good.

However, in 1.4 there have been two attempts at this in check_icmp and 
check_dhcp.

At least one attempt - check_dhcp - is not a happy plugin in all 
enterprise environments. And I am quite clear about whose fault that is: 
mine (and in any case, someone will make it better).

However, if it where implemented in Perl for example, multi-platform 
comes at the cost of either 

1 fork tax (Perl load, compile and execution) if your code uses 
_only_ built in functions (ie no modules)

2 the expense of installing a module (FWIW, I think CPAN can be 
programmed to automate installation).

Again, people should ask themselves why are they doing this ?

I may be able to write write faster code in C but I can certainly code 
faster in other languages.

Also, what one gets is basically a limited function plugin that is less 
likely to distinguish Nagios from its competitors.

The next most obvious disappointment of Tivoli and HPOV (after the cost) 
is the extremely low function. Both products seem to provide highly 
scalable employment opportunities for either consulting, or 
administering giant pollers. Apart from the GUI configuration and the 
self discovery these products have little more to commend them 
(excepting the Tivoli rules engine).

(& both of these features are _useless_ to network owners/admins, 
because people are hired to setup Tivoli or HPOV, and no one is brave 
enough to ever ever change things after).

In my view, plugins should do cool things (or check hot boxes if you 
will); how they do so may be  best left up to the imagination and best 
efforts of those who conceive of how to do the cool things.

Here is an example, my employer checks multi-page web transactions 
requiring any and all of

1 proxying HTTP and SSL

2 authorisation (by proxy and origin)

3 scraping content out of one page to pass onto the next

4 timing

5 HTMl/XML parsing

6 GET/POST to web forms

The service checks to do this are built in Perl (or could be Ruby, 
Python) on a custom Perl class (although there are standard ways of 
doing this now).

And in case this is not compelling, another Perl service check does a 
complete site specific simulation of Win 9x client logon to an NT 
domain: locate Domain controllers, connect to the IPC$ share, read the 
LANMAN.INI script, parse it and connect to shares. This one is built on 
top of a Perl XS class that interfaces Perl to some of the Samba library 
functions and other _C functions_ written specially for this class 
(produce the plugin ? the XS class is not good enough to maintain & the 
LANMAN.INI parsing is not general enough. Also it doesn't test a 2k/XP 
client logon)

The idea of providing this general function in C alone is silly. If it 
weren't, there would be _no_ Java, C++ etc.

The fact that my implementation skills are lacking does not invalidate 
the cross language approach.

Also, most contemporary scripting language Interpreters can be embedded 
in C providing all the power of the script language to do stuff far more 
concisely than in C.

Have a look at perldoc perlembed for examples of functions to

1 match character strings

2 substitute character strings

If examples of their application don't come to mind, look at the huge 
amount of duplicated code in Nagios (eg utils.c) that does things like 
substitute macro values for the macro names, crump illegal characters, 
find things in strings.

So sure, perfect the check_dns plugin by using the resolver libraries, but remember, you're still only getting RRs.

The way to decide between implementation alternatives is to have an 
adequate view of our objectives and businesses. 


[ lot's of other good things snipped ]

> That's all i have in my mind for now ;-)

> -- 
> Benoit Mortier
> Linux Engineer
> www.opensides.be

Yours sincerely.

-- 
Stanley Hopcroft

IP Australia
Ph: (02) 6283 3189  Fax: (02) 6281 1353
PO Box 200 Woden  ACT 2606
http://www.ipaustralia.gov.au
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: disclaimer.txt
URL: <http://nagios-plugins.org/archive/devel/attachments/20050204/c456b5e0/attachment.txt>