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

[Ben Clewett]

The only comment I have, apart from my desire to still use NULL, is that 
if we include time as UNIX time, we can't use float as the underlying 
data storage mechanism:

Time:           1094718313
Time -> Float:  1094718336.000000
Float -> Time:  1094718336
Time -> Double: 1094718313.000000
Double -> Time: 1094718313

Both PP and RRD will have to use double.  (I don't know what RRD 
currently uses.)

If we use double, then the fractional part of the time (ms) can also be 
supported.  As used by Microsoft for their time structure.  (I do hate 
to take a lead off Mictrsoft!)

However, It seems unlikely that this level of precision is needed. 
(Millisecond accurate data over 60+ years).  Especially as this doubles 
the space required to store these values.  I wonder if some form of date 
representation can be used which only requires the precision of float.

I don't like it much, but we might define a range of time formats:

Date accurate to the day, in UTF:

plugin_data = time(NULL) / (60 * 60 * 24);

Time as an offset accurate to 1 millisecond, this would be sufficient 
for a range of about 200 days:

Eg, 1am would be 3600.000

This can be simplified for the user by using SQL date format components:

value='2004-08-10'date
value='09:52:00'time
value='09:52:00.000'time

(Although this is not an argument to use this format :)

Where both are needed, use two variables, rectify this in the display 
application.

Or is this is just too nasty, we will have to use double and double the 
size of our storage :)

Regards, Ben.




Yves Mettier wrote:

> 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