[Nagiosplug-devel] New Threshold Syntax

William Leibzon william at leibzon.org
Sat Jun 29 13:11:21 CEST 2013

The current proposal for new syntax is at

I'd like to make some extensions to it before implementing this in the
library I'm working on
And it seems coordination is indeed needed as we have at least 3
different people willing to use this or alike syntax in entirely
independent implementations in different languages (C,Perl, Java).

The proposed additions I'd like to have discussed are:

1) Extending WARN and CRIT to have special specifiers so that multiple
types of thresholds for same metric could be specified together. One
use I'd have of this is "rate" of change which my library currently
implements as a "virtual" metric (name is suffixed as -rate). Also it'
be used at some distance future for check_netint to allow combined
thresholds based on traffic as percent as interface speed, based on
long average and based on total, etc. And I think there are many other
applications where one metric could have different types of

The proposed optional extended format would be:
Example would be:
  --threshold METRIC=evictions,WARN=rate:2..9,CRIT=rate:10..inf

2) Allow ":" to be used in place and equivalent to "'=" with
preference that both are supported by libraries. This character ":" is
what my library use to separate "CRIT" from numeric level. The reason
I chose is that long options to commands are often specified in unix
as "--option=data". This makes for a few issues when using external
libraries for processing options if the data were to have "=".

The proposal would therefore be to consider:
  --threshold METRIC:errors,WARN:2..5,CRIT:6..inf
  --threshold METRIC:evictions,WARN:rate:2..9,CRIT:rate:10..inf
as equivalent to
  --threshold METRIC=errors,WARN=2..5,CRIT=6..inf
  --threshold METRIC=evictions,WARN=rate:2..9,CRIT=rate:10..inf

3) As you probably noticed I prefer upper case for keywords like WARN,
CRIT. I want to make certain plugin writers know these are
case-insensitive and both lowercase and upper case are to be

4) I've used a few additional keywords in my implementation that I
think would be useful to make part of the spec:

  this specifies type of alert and exit code if metric is not
available at all on the device. often plugin writers chose to exist
with UNKNOWN but people maybe ok with it or want CRITICAL. this would
override default plugin behavior
  this specifies if metric and data should be added to plugiin status
output.  overrides default plugin behavior if any
  this specifies if metric data should be part of performance data.
overrides default plugin behavior if any

5) Currently CRIT and WARN threshold levels are added to perf output
so that these could be displayed on a graph. i.e.
   load_1_min=5.17;20;30 load_5_min=5.37;18;24 load_15_min=5.79;16;20

The problem is going to be how to add this for our new syntax that
allows multiple WARN and CRIT and complex ranges. My proposal is that
if it is possible to translate new threshold range to old format that
is to be done i.e warn=5..inf is just 5. For cases where translation
to something simple is not possible the syntax or perf output is
extended to be:
   'label'=value[UOM];[warn threshold if single value only];[crit
threshold if single value only];[min];[max];[warn ranges];[crit
ranges];[ok ranges]
where multiple WARN and CRIT ranges are to be specified as a list
and -inf and inf are just not specified i.e. -inf..5 becomes ..5 and
5..inf is 5.. or just 5

Additionally I'd like to reserve a special UOM string of NOGRAPH for
what is put in performance data but is not expected to be
automatically graphed. Graphing programs are to ignore everything
after that.

That is all for my proposed extensions. Hopefully we can have some
comments on this now.


More information about the Devel mailing list