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

[Andreas Ericsson]

Stanley Hopcroft wrote:
> 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 ?
> 

So as to simplify for end users. When I say minimize, I mean get rid of 
dependencies for modules that are used once in rarely used plugins for 
which a routine can be somewhat easily coded in-line.

And remember, I said minimize, not remove altogether. What I meant was 
that plugins that use a single sub from a module and that sub can be 
brought inline without too much work should have those subs brought inline.

> 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.
> 

No. We don't conceal that fact at all. Quite the contrary, we're riding 
the opensource hype. We've written a new GUI and some other things, but 
we never hide that we're using opensource projects (and which) as our base.

As for reducing our install costs, creating a perlmodule RPM takes about 
10 minutes (with testing) and is a one-time penalty as the same .spec 
can usually be used with upgrades as well. We have the knowledge and 
resources to do that, but many end first time users don't.

> 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 ?
> 

Yes. I wrote check_icmp in pure C because it is quite often used 
configured_hosts or even configured_hosts*2 times in a nagios setup. The 
speed/scalability gain of writing it in C and implementing tighter 
scheduling and timings are multiplied ad nauseum, and faster down 
detection makes nagios' serialized host checks less of an awkward issue.

For check_dhcp which wouldn't be used quite so often an execution speed 
tradeoff for implementation speedup is certainly acceptable. I vote C 
for check_dhcp because we could then use the already ported code in 
ISC's dhcp suite programs and get a complete protocol documentation at 
the same time, but I wouldn't want it written in C if that would take 6 
months vs a perl implementation in a week or two.

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

As can most, with exception of assembly code. Let's agree here and now 
to never write plugins in asm. ;)

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

How so? C is a complete language so adding new features once the 
protocol is implemented shouldn't be too hard.

> 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.
> 

I agree. This sort of highly specialized plugins should be written in 
perl. What I meant was that plugins that parse the output of commands 
should be reimplemented in C, using the libraries of the command in 
question, or implement the appropriate system calls themselves (this can 
be done fairly easy, using the ISC ./configure approach).

> 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.
> 

Yes, but that adds a lot of complexity to the nagios core and doesn't 
necessarily work as planned (embedded perl). It also often require users 
to make modifications to their scripts, which consumes resources on a 
running basis for contributed plugins or, worse, prevents people from 
contributing their clever script plugins. Adding instability to the 
daemon is unacceptable in pretty much all environments.

> 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.
> 

I agree. It should be done differently, but for now that's not the issue 
unless you intend to rewrite nagios in perl (*shudder*) which would be a 
fairly useless effort.

> So sure, perfect the check_dns plugin by using the resolver libraries,

I intend to start hacking on that next. More as an exercise in 
intellectual masturbation, but still.

> but remember, you're still only getting RRs.
> 

The check_{dig,dns} plugins parse output of programs that use resolver 
libs, so whatever they can do, check_nameserver will be able to.

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

Indeed. C should be used where plugins parse output of programs written 
in C (from perldoc perlembed manpage; Use C from C? Rethink your 
design.). New implementations that do things there are no programs for 
(or combine the features of several advanced programs) are best left 
written in a script language as they will most likely be advanced enough 
without adding memory management and the requirement for several -devel 
packages at ./configure time.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer