[Nagiosplug-devel] Suggested alterations to the Performance Protocol
Ben Clewett
Ben at clewett.org.uk
Thu Sep 9 00:40:05 CEST 2004
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.
>
More information about the Devel
mailing list