[Nagiosplug-devel] New Threshold Syntax

[Jochen Bern]

On 21.08.2013 17:23, William Leibzon wrote:
> I have requested time at upcoming Nagios conference for 30 minute BoF
> session on this topic and to get feedback on any general features people
> may like to see in all the plugins. They have't got back to me yet (only
> sent email on Friday) but this is not a formal session and so I'd not
> expect an issue with holding it after normal sessions are over.
> 
> My own plugins library and several plugins will support the syntax at
> https://github.com/willixix/nagios-plugins/wiki/New-Threshold-Syntax by
> conference time (just committed most of the necessary code yesterday).

I'm afraid I haven't had much time to read up on the discussion ever
since my first reply on the topic (which I made from a cell phone with
an almost-depleted battery, so I'm sorry if I sounded a bit gruff), so
let me take this opportunity to comment on the version currently on that
page:

-------

I'm missing the possibility to supply *different* labels for the same
(numerical) data as presented in the output vs. in the performance data.
Cases where such a differentiation would be useful, off the top of my head:
-- Output (-> notifications) in local staff's primary language, but
   perfdata names shall be in English so as to permit *global*
   referencing (say, in a performance data backend system's graph
   templates)
   [Same goes for things like "Houston Interlink" vs. "Interface 4711",
   "upstream"/"downstream" vs. "ingress"/"egress", etc. ad nauseam]
-- Continuity of saved performance data, e.g., what the first version
   of the plugin reported as "rx pkts" should now be properly called
   "received unicast packets to a local MAC" in the output but still
   just "rx_pkts" in the performance data

Note 1:	It would be a possibility to use non-{yes_or_no} values for the
	"display" and/or "perf" keywords to achieve this.
Note 2:	There are performance data backends which rely on the *order*
	of performance data items, rather than their naming, to have
	performance data items produced by the current plugin run
	correlated to (hopefully) equivalent items of the previous
	runs. Do we want to provide a means, however contrived, to
	control that order?
Note 3:	Restricting the labels to [A-Za-z0-9_-]* means that we're
	actually dropping behind the current perfdata spec (which allows
	special chars inside quotes).

-------

rrdtool, as the most common basis for performance data backends, allows
you to provide a non-numerical value 'U' so that you can provide
complete data*sets* even in cases where single *values* are unknown /
cannot be determined. PNP4Nagios followed suit and now allows plugins to
return 'U' in the performance data (replacing the number, still allowing
the UOM etc.). I think this should make it into an updated perfdata spec
(which is likely to result from *this* activity sooner rather than later).

-------

Speaking of the UOM, your spec for the "uom" keyword mirrors the current
perfdata specs in only allowing UOMs from a given whitelist. [Yes, I'm
aware that the allowed values for your "uom" keyword do not necessarily
imply restrictions on the UOM spec for plugin output, but bear with me.]

This approach has, in my opinion, proven to be a failure because it is
virtually impossible to provide an all-encompassing list of UOMs that
may occur in the wild. (Off the top of my head, I have "ppm" from ntpd
drift files, several UOMs for bandwidth, "dBm" for GSM reception level,
"degC" for Temperatures, "RPM" for fans, "V" for Voltages, ...) One
consequence of that is that I do not know a *single* perfdata backend
that would try to split the perfdata UOM back into unit and prefix, and
*that* results in output (graphs) where UOMs like "kB" (as output by
"df", for example) get scaled into "MkB" and similar chimeras. Thus, my
first suggestion: Drop the ever-outdated base unit registry!

Second, if we want a chance to *ever* get proper automatic UOM scaling
back in working order, we need some sort of hint within the perfdata UOM
string that allows the backends to tell prefix from base unit, candela
from centidays, Ampere- from attohours, etc.. I'm thinking of a
separator character, preferably one that results in a small, unobtrusive
representation if *not* caught before Web-UI etc.. (U+00B7 looks like a
good candidate to me, but I'm not very experienced with charset
conversion and compatibility problems ...)

-------

The "prefix" keyword *badly* needs a clarification where it shall have
an effect and where not:
-- prefixed to string specified with "uom" keyword
-- causing the relevant number output to be rescaled
   -- *from* prefixed *to* prefixless UOM
      (i.e., "prefix:k" changes original result "3.14" to "3140",
      equivalent to the statement "the number obtained by the plugin
      up to output formatting *is in* thousands")
   -- *from* prefixless *to* prefixed UOM
      (i.e., when the plugin's original output is "4711 foo",
      "prefix:k" shall change it to "4.7 kfoo"
-- causing the *thresholds* to be rescaled accordingly
   -- again, *from* or *to* the given prefix
and most of this could potentially apply to a number's representation in
the output, the perfdata, or both ...

Kind regards,
								J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel