[Nagiosplug-devel] Suggested alterations to the Performance P rotocoll
Karl DeBisschop
karl at debisschop.net
Mon Sep 13 18:11:11 CEST 2004
Ben Clewett wrote:
> Not to exclude textual data. There are I am sure valid places for this.
> But as Yves said. If we include text, there is no way of saying where
> the metric value ends and the metric unit begins.
If the data IS a string, then it is not a measure and there is no metric.
> Or break
> compatibility and insert new delimiters.
I don't believe representing stings breaks compatibility - I do believe
that precluding strings does change the interface in a non-compatible way.
Further, you are suggesting new mechanisms for handling string-type
perfdata in nagios when it is not required.
Perfdata is very simply the stuff after the "|" - nagios does not parse
it or care what it say - it simply returns the data following the "|" in
the perfdata macro. It is precisely this separation between plugin and
scheduling that give nagios its extensibility.
If it is not sufficient for a parser to pass on things that it cannot
parse as a number, we could do
DHclient OK - 192.168.1.1|eth0="192.168.1.1"
I don't see how that is ambiguous, and it preserves the existing
flexabilty in the interface.
Again, I would like to have someone give me a compelling reason why
string data will break things - unit of measure and everything after it
are and always have been optional, and were in fact not in the nagios
documentation - they are just a convention of the plugin developers.
Also from the nagios docs:
What you do with the performance data once its out of Nagios is
completely up to you. If you are simply writing performance
data to text files...
This is the sort of statement that suggests to me that the existing
standard should be considered as relating to more than only the process
of making a graph.
--
Karl
More information about the Devel
mailing list