[Nagiosplug-devel] Suggested alterations to the Performance Protocol

[Ben Clewett]

Andrea,

I agree with what you have written.  Thanks for the information on some 
common SI units.

I would like to comment on your comment that NULL is redundant.

You mention what NAN is a good indication of non available data. 
Technically NAN represents a bad number, eg, division by zero.  See:

http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html

The standard way of representing a nonexistent number in database theory 
is using NULL.  This is therefore unambiguous as 'no value to pass'. 
Personally I would be happier with NULL, but the decision is up to the 
authors of the document and not my self :)

Regards, Ben.


Andreas Ericsson wrote:
> 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.
>