[Nagiosplug-devel] Suggested alterations to the Performance Protocoll

[Yves Mettier]

> Date: Fri, 10 Sep 2004 22:03:46 -0400
> From: Karl DeBisschop <karl at debisschop.net>
> To:  nagiosplug-devel at lists.sourceforge.net
> Subject: Re: [Nagiosplug-devel] Suggested alterations to the Performance P
>  rotocoll


> But I don't see how it in any way suggests we should require that all
> perfdata be numeric.
>
> Sometimes the data itself is a string (e.g., the current status of a
> printer - ONLINE/OFFLINE, or the DHCP-assigned IP address of an
> interface, or the hostname of a machine connected to a particular port
> on a Shiva terminal concentrator)

online/offline is a status, not perf data. For perf data, you would put NaN for an
offline device. And its value (meaning online).
If you want to draw something with offline/online, you cannot draw "online". You need to
convert to some numeric value like 1. And offline would either be NaN or 0., depending
on your needs.

For the DHCP-assigned IP address, this is a status again. How do you want to draw an IP
address ? You may want to draw something that show how often the IP address changes. But
if you want to draw it, you need to convert the change, not the IP address, as a value
that you can draw. Send 1. when the IP changes since the last check, and 0. it it still
the same.

You may also want to log the different IP addresses. This is an interesting case. Perf
data have a good key/value system that an external tool can use to log such data.
If we use perf data like that, I think that perf data are limited already. I prefer an
XML format where we have a tree instead of a key/value list. Do we move performance data
to the XML extra data ?
<xml>
  <log>
    <IPaddress time="1012345678">10.11.12.13</IPaddress>
  </log>
  <perf name='IPaddress' time='1012345715' range=...>0.</perf>
  <perf name='CPU' time='1012345715' unit='%' range=...>13.</perf>
</xml>

<xml>
  <log>
    <IPaddress time="1012345715">10.11.12.15</IPaddress>
  </log>
  <perf name='IPaddress' time='1012345715' range=...>1.</perf>
  <perf name='CPU' time='1012345715' unit='%' range=...>15.</perf>
</xml>

All this would be in one line of course (nagios plugin definition)
All this can be discussed.
This is just ideas, and I don't even want to have that. I prefer to have a perf data
field with only numeric values, and after a second |, extra data with maybe a specific
DTD for XML :)

I only wrote that to give you additionnal ideas, if this can give you ideas :)

> SNMP recognizes this - if has the capacity to return simple strings and
> other "interesting" data like IP addresses. Why should we assert that if
> someone monitors a string via SNMP, that they will not be able to use
> perfdata to create a long-term log of that data?
>
> Note that I'm not requiring anyone to actually handle that data - I'm
> only saying that we should not create a data specification that forces
> one view of perfdata utility (graphing) onto the world as a whole, when
> there may be other uses also.

We force graphing of perfdata, but we open any other use with allowing to have extra
data after the 2nd | :)

> And what is the cost of allowing strings? We use "$NAN$ instead of "NAN"
> and "$$" instead on "$". A small effort.

Seems that Ton and I agree with following POSIX spec. So that will be NAN and INF
without '$' around.
If any disagree with that, say it soon, because I will update my unfinised-yet parser
next week, and I don't want to change it too often :)

>
> I just do not see how the new guideline will benefit significantly by
> outlawing string data. If someone has explained the harm in allowing
> strings, I have just missed it, and could you repeat the argument?

If we allow strings, there is no way to distinguish a string from a number. Except that
we'll have NaN if we follow the POSIX spec. This is a new reason. So values have to be
considered all as strings, and we need some additionnal field to say if the value is
drawable or not (can be converted into number or not)

If we have values as strings, there is no way to see where the value finishes and where
the unit begins. We need a new separator.

In both cases, we need an additionnal field that will probably break the compatibility.


> --
> Karl

> --__--__--

> Date: Fri, 10 Sep 2004 22:31:46 -0400
> From: Karl DeBisschop <karl at debisschop.net>
> To: Yves Mettier <ymettier at libertysurf.fr>
> CC: Ben Clewett <ben at clewett.org.uk>,
>  nagiosplug-devel at lists.sourceforge.net
> Subject: Re: [Nagiosplug-devel] Suggested alterations to the Performance
>      Protocoll
>
> Yves Mettier wrote:
>
>>>Ben Clewett wrote:
>>>
>>>
>>>>Looking back at suggestions from my original email and discussion:
>>>>
>>>>4.  Addition of macro's.  NaN = No value.  -INF and +INF to be used in
>>>>range specification.  Agreed.  (?)
>>>
>>>I do still think some token to indicate it is a macro is appropriate
>>
>> For INF and NaN, I don't consider them as macros, but as values.
>> Look at the ethymology: macro stands for macro command. And INF and NaN are not
>> commands !
>
> Not my term. To me, it doesn't matter whether they are called macros or
> something else. Only that most programming languages will not scan the
> line and automatically create the corresponding value in a float variable.

OK. So we could have other macros like PI or E ? :)
Or we could have +small and -small that mean "nearly 0 but not null" ?
Well, I suggest that we don't support this for now, but keep in mind that one day,
somebody asks for it. That day, let's use $PI$, $E$, $SMALL$...
That day, $ alone becomes a syntax error.
And $$ is a macro for $ (from Karl's other mail, above)



> POSIX strtod is required to recognize NAN and INF, so I'm willing to
> follow POSIX and forgo any other indicators

Me too.
I will now check if Solaris has a POSIX-compliant strtod().
Linux probably has.
Does anybody have some non posix system where perfparse runs ? If yes, I need to take it
into account for my parser. If not, we'll find a solution one day :)

> If NAN and INF are the only tokens we are concerned with, my concerns
> can be put aside so long as the guideline we produce does not otherwise
> prohibit string data.

Same for me. Extra data, with XML format, should allow everything, even extra
performance data if the perf data we are talking about are too limited :)

Yves

> --
> Karl

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