[Nagiosplug-devel] Suggested alterations to the Performance Protocol

[Ben Clewett]

Dear Group,

I would like to discuss upgrading the performance protocol as defined in:

http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN185

I have noticed a few people making suggestions and it might be time to 
get a new version published.  Certainly to discuses whether it is time 
to do this.

Just to start things off:

1.

Patch a loop-hole in the document.  The Warn and Crit values should be 
of the same UOM as the value.  Second, all numbers, value, max, min, 
warn and crit, should be directly comparable.

Although this is common sense, I have seen some plugins (eg, check_disk) 
which certainly used to use a different number type for the warn & crit 
as to the value.  In this case, 'Disk Free' and 'Disk Used', which are 
not comparable.

2.

Suggested by Yves Mettier:  The addition of a special reserved variable, 
'check_time' which records the time at which the plugin completed the check.

I can't remember if units were suggested, but in line with Nagios, the 
time as seconds from 01-01-1970 00:00:00 UTC, or standard UNIX time, may 
make sense.  If Yves is reading this, he may be able to comment further.

3.

The addition of macro's to define special numbers.  Some mentioned are 
NULL to indicate no value or an invalid value.  INF and -INF to indicate 
an infinite value.  Possibly NAN to represent Not a Number, as with 
division by zero.  Not often used, but do have a place.

4.

To allow any UOM unit.  For instance, 'degc' for temperature, 'users' 
for a user count etc.

5.

There is no way of representing a date.  There may be some plugins, eg, 
recording user information, which do want to record a date.

I have suggested UNIX time above.  However another suggestion is to use 
the popular SQL syntax: '%Y-%m-%q %d:%M:%S.ms', eg, '2004-09-07 
16:10:15.123'.  Or a component of 'date', 'data time', 'time.ms'.  It 
works for SQL :)



I hope this meets with a friendly reception, and I look forward to 
seeing where we can take this.

Kind regards,

Ben Clewett.