[Nagiosplug-devel] Re: Nagiosplug-devel digest, Vol 1 #654 - 7 msgs
Yves Mettier
ymettier at libertysurf.fr
Thu Sep 9 01:01:02 CEST 2004
Again, sorry for breaking the thread. I will stop the digest mode if I have to give my
opinion too often :)
> Date: Wed, 08 Sep 2004 16:33:03 +0100
> From: Ben Clewett <Ben at clewett.org.uk>
> To: Ton Voon <tonvoon at mac.com>
> CC: nagiosplug-devel at lists.sourceforge.net,
> Yves Mettier <ymettier at libertysurf.fr>
> Subject: Re: [Nagiosplug-devel] Suggested alterations to the Performance Protocol
[...]
> The real one of interest now is the idea of a NULL value. For instance
> the latency of check_icmp when there is no reply. Using NULL to show a
> gap in the graph. Rather than joining the graph together round the
> missing value, or using some odd value to imply NULL.
NULL is a value, not a macro, and has no signification here.
NULL can mean anything, while NaN means that it is Not a Number, while INF means
INFinity... :)
Let's use NULL in our code, and NaN in the specification of the perf data.
> --__--__--
> Date: Wed, 08 Sep 2004 19:06:51 +0200
> From: Andreas Ericsson <ae at op5.se>
> To: nagiosplug-devel at lists.sourceforge.net
> Subject: Re: [Nagiosplug-devel] Suggested alterations to the Performance Protocol
>
> 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.
NULL is redundant with Nan, and can be ambiguous. In fact, NULL can mean anything and
nothing :)
I'm writing some new parser for perfparse. Nearly finished. Should I support "-INF",
"INF" (as +infinity), "+INF" and "NaN" ?
Should I remove support for "~" ?
[...]
>> 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.
No greek characters in SI units. Some, like micro, are usually written as µ (read the
greek letter "mu") when you are using some old-style tools like pen and paper. But when
using SI units, you write them with latin characters, like "u" for micro ("u" looks much
like the greek letter "µ" :)
>> 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
For mega and kilo, isn't it "m" and "k" ?
>
>>> 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.
Nothing specific to support here. Values can already be coded as float numbers. For
timestamps, nagios does not support them, and I think that it is not precise enough to
support it.
Yves
--
- Homepage - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key - http://ymettier.free.fr/gpg.txt -
- Maitretarot - http://www.nongnu.org/maitretarot/ -
- GTKtalog - http://www.nongnu.org/gtktalog/ -
More information about the Devel
mailing list