[Nagiosplug-devel] Re: Nagiosplug-devel digest, Vol 1 #654 - 7 msgs

[Yves Mettier]

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/                    -