[Nagiosplug-devel] Suggested alterations to the Performance Protocoll

[Andreas Ericsson]

Ben Clewett wrote:
> Just a comment or two, I want to get this completed now :)
> 
> Andreas,
> 
>>> I suggest following the KISS rule. Please don't turn perfparse into
>>> something too complicated for users to use, and don't make it too
>>> monolithic to install.
> 
> 
> I totally agree with KISS.  Very easy to go on designing way beyond what 
> is needed or wanted.  Can I pick up your commend about making PerfParse 
> something 'too monolithic to install'.  I am not sure what you mean.  Do 
> you mean we should break the product into lots of libs?
> 

Brain-typo on my behalf. What I meant was "too monolithic to use". See 
below for details.


>> This was just a bad example. For now, I only see the following uses :
>> label1:string='any string'
>> label2:perf=valueUOM;range...
>> label3:log=timestamp;'log line'
> 
> 
> Have we agreed 1 and 2?  I think so.  Label 3 looks interesting, 
> although not much to separate from label 2.
> 

If the intention of perfparse is to gather data and display it in graphs 
(the number of strings occuring between certain time-intervals is one of 
those things that can be graphed, although in a very non-optimal way, 
code- and databasewise), I think it would be prudent to have it not 
gather anything else. Keep the abilities within the purpose, so to speak.

I know it's quite simple to have it pull whatever data anyone can 
possibly imagine and save to a plethora of different mediums. Code for 
parsing input isn't really all that difficult to write either. But 
remember, "because it's possible" is the worst reason ever to do 
anything at all.

I can imagine a lot of people using perfparse because its abilities are 
(currently) (properly) limited to something that appeals to a wide 
audience, while not being very difficult to set up. What I can NOT 
imagine is that people want to use perfparse like some additional 
logging module for various data they can already find somewhere else.

> Can I suggest with log lines, and other non-unique data, that the data 
> is written into the standard textual output of the plugin, with the 
> timestamp of the plugin.  This already does a very good job of storing 
> this kind of data.  An extension of '| timestamp=23432432432.123'  has 
> already been discusses as a correction if the plugin time is not 
> correct.

This is not a very good idea. If the Nagios timestamp isn't correct, 
there's very little chance for the plugin to obtain one that is (unless 
you want to incorporate NTP capabilities in all plugins). Also, I see 
very little real value (but a whole lot of work) in adding microsecond 
precision to plugins and I wonder when that timestamp should be 
collected? Invocation-time? Then it will differ greatly (micro-second 
wise) between perl and C plugins, and will be hard to get at all for 
shell-scripts. Exit-time? Then it will differ a lot based on how long 
the check took to execute. What about remotely executed plugins? Should 
they report the time on the system they're being run on, or should 
check_nrpe / check_by_ssh collect the timestamp?

The proper way of doing this is ofcourse to let perfparse auto-add 
timestamps when data arrives (or better yet, have the SQL server do it 
for you). That way plugin-authors won't have to think about it, and 
every plugin gets its time collected in an identical way. For 
synchronization issues between several different hosts, turn to NTP and 
inform the users that things won't optimally if time drifts a lot. I'm 
sure the users will think this is pretty obvious once they're informed 
of this.


>  Do we need anything more?  If so is it time to break into XML 
> rather than a large confusing collection of metric formats?  (Sorry Yves :)
> 

Using XML output in Nagios plugins will break something that has made 
Nagios very successful: The ability of the average user to concoct a 
plugin that works.
Those who use both Nagios and perfparse might add the output you're 
looking for (although I doubt it), but Nagios has a much wider userbase 
so most of them will just write "check this and return 
OK|WARNING|CRITICAL" plugins. The perfparse users will then complain to 
the perfparse devel team (or, *shudder*, to the nagiosplug-devel or 
nagios-users list) that some plugin they found somewhere doesn't work 
with perfparse. Don't put us through that.

>>> Use shell (backslash) escapes or die. ;)
>>
>>
>> I prefer the backslash too. Others said '' to escape a '
>> This is not too hard to code and I can change that in my parser. What 
>> should I do ?
> 
> 
> So I vote to scrap the '' in all cases and use \\ instead.  For what 
> it's worth...
> 

I guess we all agree then. Good thing, consensus. :)

> Ben
> 
> 

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