[Nagiosplug-devel] Suggested alterations to the Performance Protocol

[Andreas Ericsson]

Ben Clewett wrote:
>> I like the idea of macros. I had proposed using some arcane 
>> characters  (such as ~ for negative infinity), but I think your macro 
>> idea is far  clearer. Any comments?
> 
> Maybe use both?  As long as it's clear and developers such as my self 
> can parse them exactly.  This would be good.
> 

Go for the humanly readable version. Anything to stay away from perl'ish 
line-noise in case more macros are needed later ($', $` $] and $[ aren't 
exactly crystal clear...)

INF for high enough for plugin not to bother measuring any more.
-INF for other end of above.
NAN for nonavailable data.

NULL is sort of redundant, so don't add it. Keep it simple, and keep it 
strict. It's pretty likely that someone someday will reimplement 
perfparse. They will be grateful for consistency restrictions.

>> The idea was that the label was free text to describe the thing being  
>> measured, while the UOM gives the graphing program enough data on how  
>> to graph (eg, RRD has a concept of graphing the difference between 
>> two  values for counters type data). Thus having an exhaustive list of 
>> UOM  units would make it extra coding. But there does seem to be 
>> confusion  as things like B (bytes) and s (seconds) are UOMs whereas 
>> it wouldn't  matter to the graphing program. Maybe we should be more 
>> like SI units?
> 
> 
> I would strongly support SI units.  I think this would be an excellent 
> idea.  Although some use Greek characters, but I am sure there is a 
> Latin character notation for these.  Anybody know ?  If not there can't 
> be too much harm in making them up.
> 
> You did talk about automatically comparing variables in a graph drawing 
> package.  It might be worth writing down some of the expected 
> conversions.  Eg 1B = 8b, 1MB = 1024KB etc...
> 

There's a standards document for this, but those rules are broken so 
often it's hard to remember what's real from time to time...

Anyways, for the more common ones;
M = Mega = 1000000
K = Kilo = 1000 (Kelvin (temperature) if printed alone)
Ki = binary Kilo = 1024
B = byte
b = bit
m = milli
u = micro
n = nano

>> I would prefer to use Unix time, only because of brevity. As long as 
>> it  gets translated later (and there are lots of common functions for 
>> it),  then the graphing would be okay.
>>
>> Would Unix time with a .ms make sense for more granularity? This 
>> would  presumably need a UOM defined too.
> 
> Ok.  Translating a SQL style data (Thanks Yves for the correction to my 
> format :) would be a pain anyway.  UNIX time is great.  As long as it's 
> written down so we can follow it, I'm very happy to use what ever people 
> think is best.
> 

Unix timestamp is computer standard. Use it where appopriate. Where 
execution time is applicable, simply use xx.xx ms.

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