[Nagiosplug-devel] Suggested alterations to the Performance Protocoll

[Yves Mettier]

> Yves, your idea of a ntm "ntm[.xx]"  Was there a good reason why this
> should not be as a variable "ntm=ntm[.xx]", thus making this backwardly
> compatible?

Because it is syntaxly correct. But then you need to tell the parser that this is a
specific value.

Having the nagios timestamp in xxxxx[.xx] is also backwardly compatible (nagios does not
write the ms), and you also need to tell the parser about that new syntax.

So I prefer no additionnal value here (even if that was my initial idea :)

>> Well, for now, the only agreed changes are to allow INF (-INF, +INF) for the ranges,
>> and
>> NaN for the value. Is that right ?
>
> Looking back at suggestions from my original email and discussion:

[...]

> 3.  Time it took for plugin to run: Forgotten/Rejected?

For debugging purposes. You don't monitor a monitor tool, do you ? Or only to see if it
is working :)
This can be done with something like debug_time_being_running=xxxxx. This can already be
done and does not need any doc change, right ?

> 4.  Addition of macro's.  NaN = No value.  -INF and +INF to be used in
> range specification.  Agreed.  (?)


> 7.  Using milliseconds as fractional past of a UNIX time/date where user
> wants this accuracy: Agree.

No. Under discussion. See the beginning of this mail :)

> 8.  Including a protocol version number: Still in discussion.

> 9.  Limit protocol to just numerical data:  No.  But will not be
> supported by some storage programs.  (Yves performance parsing engine to
> allow such programs to do what they like with this data.  Hows this work
> going?)

The parser I'm writing is compatible with the current syntax. However, the value is
coded with type "double".
I found that this type can be a limitation (not for me yet) and the only way to get rid
of this limiation is to code that as a string. The parser returns a string, and the tool
converts it to what it likes (according to the label, the unit or anything, that is not
our point).
I don't agree with putting anything else than values that can be drawn. Perf data are
supposed to be drawn. But if I use a string as the returned value type, I implictely
allow anything. And I cannot find where the value ends and where the UOM begins.
I have 2 suggestions here. Pick the one you prefer and I code it.

1/ I detect if we have "NaN" as the value. Otherwise I find the 1st non-numeric value
myself (without strtod) and that value is either the beginning of the UOM or the ";"
separator. And I return a string with what is identified as the value. With this, we
cannot put anything else than numeric values (and NaN).

2/ The protocol is changed, and we have value;UOM instead of valueUOM. Then I check for
the ";" that mark the end of the value. And I return it as is. With this, we can have
any type of value.

I prefer 1/ for compatibility reasons, even if the parser becomes more complex to do.
If you think that putting other things than numeric values (and NaN) there is necessary,
there is no other way than 2/. 2/ breaks the compatibility.
If 2/ is chosen, don't forget my suggestion about using a range [@][min:][max] instead
of [min];[max]

What do you think ?


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