New Threshold Syntax
William Leibzon <[email protected]>
| Newsgroups | gmane.network.nagios.plugins.devel |
|---|---|
| Message-ID | <CAFCy1Bgb6ipOiaa7a8hUbFZjdvgZ0tYLqXiySHeEtpbb46Mg7Q@mail.gmail.com> |
The current proposal for new syntax is at http://nagiosplugins.org/rfc/new_threshold_syntax I'd like to make some extensions to it before implementing this in the library I'm working on (https://github.com/willixix/WL-NagiosPlugins/blob/master/Naglio.pm). 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 thresholds. The proposed optional extended format would be: WARN=[specifier:]threshold 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 supported. 4) I've used a few additional keywords in my implementation that I think would be useful to make part of the spec: ABSENT=OK|WARNING|CRITICAL|UNKNOWN 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 DISPLAY=YES|NO or STATUS=YES|NO this specifies if metric and data should be added to plugiin status output. overrides default plugin behavior if any PERF=YES|NO 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 start..end,start..end 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. William ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________________ Nagios Plugin Development Mailing List Nagiosplug-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel ::: Please include plugins version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null