[Nagiosplug-devel] Suggested alterations to the Performance Protocol
Andreas Ericsson
ae at op5.se
Wed Sep 8 10:08:17 CEST 2004
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
More information about the Devel
mailing list