[Nagiosplug-devel] Suggested alterations to the Performance Protocoll
Yves Mettier
ymettier at libertysurf.fr
Fri Sep 10 02:52:35 CEST 2004
> 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 !
> I used "=" in my conceptual discussion this morning, but that obviously
> won't work because we alreadty use "=" in the guidelines.
>
> How about @NAN@, @NULL@, @+INF@, @-INF@
I like "@" (because I use autoconf/automake), but it won't work here because @ is the
keyword to invert a range.
> Or [NAN], [NULL], and so on.
[ and ] will be ambiguous in the documentation. They mean that the contents is optionnal
in the doc. I prefer no interaction with the doc, even if there should be no problem
here.
Any reason not to use $ like nagios does ? $TIMET$ :)
> Or is there a general reason why some sort of tokens won't work?
Back to the debate. For me, there are now 2 questions.
1/ Are NaN and INF macros ? I consider that they are values, and should be recognized as
values, like some strtod() implementations do. I also suggest to use the values that
glibc uses:
printf("%lf %lf\n", (0./0.), (1./0.));
I'm not sure (I have no glibc here), but the result is something like this:
NaN inf
If we consider them as values, there are only "NaN" and "inf" to recognize before using
strtod. We don't need an identifier.
2/ What macros do we need besides NaN and INF ? I read about "protocol_version",
"start_time", "end_time"... Those are not macros but keys. There is no need for a
protocol change here. The only thing that can be done if you want to reserve such keys
is to write it as a footnote in the doc. All parsers will be compatible with that, even
if they don't know that those are reserved keys. So here is my question: what keywords
do we need to consider them as macros, in other fields than the key field ?
>
> (I should not that if there is no range provided, it is genereally
> assumed to be infinite in the current plugin implementations - in other
> words, the philosohy has been to ry and be diligent in providing limts
> whenever they can be)
About inf, we already have the "~" reserved symbol. Here, we are talking about using
"inf" instead of "~" in the range field.
And NaN cannot be used in ranges. How can you define a range with "NaN" ? :)
On the opposite, inf cannot be used in values. You can't measure the infinite. If you
cannot measure something finite, the result is "NaN", not "inf".
Well, I already said that, but I feel important to write it again.
>
>> 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?)
>
> Right - programs that are built for graphing would be expected to ignore
> such data. But that does not give license to design the guideline such
> that nothing but graphing can ever be done with the data.
If I understand well, you are not against not-numerical data (i'm not against either).
If we do that, we need a separator between the value and the UOM. See my previous mails
about that (and about my suggestion to move "min;max" to a range if the protocol changes
and the compatibility is lost).
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