> On Mon, Mar 17, 2008 at 2:15 PM, Ton Voon <<a href="mailto:ton.voon@altinity.com">ton.voon@altinity.com</a>> wrote: > Hi! > > I tried to get this through last year, but I don't think a conclusion > was reached so I'm going to try again now! > > This is a proposal for a new threshold syntax. My motivation is that I > have to update check_procs based on a customer's requested use for it. > I'd like a generally applicable syntax, so that there is maximum code > reuse and consistency. > > The proposal is here: <a href="http://nagiosplugins.org/rfc/new_threshold_syntax" target="_blank">http://nagiosplugins.org/rfc/new_threshold_syntax</a> > > I've decided to use the website as this can be the master document. I > plan on updating it based on people's comments. Hopefully it will not > require too many alterations! > > Comments? I'm going to comment on it even if its a bit late... And quickly my personal "vote" would be NO, but I have mostly outsider perspective and NO does not mean I'm like existing threshold either and have not used it when developing my plugins until very recently. I probably will not participate in this thread as I have only limited time right now but will answer specific questions to me if there are any. First of I'd like to note that above proposal moves to the idea that each threshold is a separate parameter checked by plugin for which critical/warning/ok are to be specified. For such a case the syntax could work if the parameter to the plugin is stable and so can have its own command line parameter. But this is not all so in every case. It is especially not so for plugins that I write where parameters are called attributes and are specified on command line to the plugin and their numbers change depending on use. In such and similar cases it is a lot better to have --warning and --critical command-line parameter and spec on how to specify it. This is also what people are used to who used nagios for many years. Additionally in new syntax you now have "ok", "warn", "crit" and that I think would end up being confusing (and make code more difficult) especially if people start specifying all 3 together. I also think that people do not like it when you change plugin spec code too much/too often and with nagios plugins you want to be as backward-compatible from one release of the plugin to another (admins expect to be able to just drop in your new version of code as replacement for what they currently have and then they may look at use of new features and further changes). You maybe able to support both as you'd specific new syntax as "crit=.." where as old one did not have but supporting multiple syntax versions in same code makes it larger and more difficult to maintain. Now I'm not saying you should not do it and extend your current syntax if there is a legitimate need and problems reported, just be warned about consequences and difficulties... I also generally found you "range" based syntax to be somewhat counter-intuitive and as far as a:b specifying alert when OUTSIDE of the range. Perhaps this can be fixed fairly easily by adapting new separator (a..b is alert when >a and ------ Now I'll give personal perspective of what I have done in my plugins and custom spec I use (which I do not recommend you adapt but seeing it may help in some way). In most of my plugins there are many "attributes" that are checked as for example in: <a href="http://william.leibzon.org/nagios/plugins/check_mysqld.pl">http://william.leibzon.org/nagios/plugins/check_mysqld.pl</a> where attributes are variables from "SHOW STATUS" and you specify which ones to check (similar also for number of my other plugins at <a href="http://william.leibzon.org/nagios">http://william.leibzon.org/nagios</a> such as check_snmp_temperature, check_jboss and others; although code is older as far as thresholds parsing in them but that will slowly get updated). So I adapted system where list of Attributes are specified with one command line parameter (usually -a and then alphanumeric list separated by ','), warning threshold values with another (usually --warn with threshold spec values separated with ',' - empty/no value if there is no threshold) and similarly critical. This turns to work pretty well although you can argue that there are better ways to do it... I also wrote code that handles threshold spec in my plugins (which is largely same for every one) before I even knew there is "official threshold spec". So doing it independently I created threshold syntax of [prefix]value where prefix is one of "<",">",'=","!" specifying if alert (critical or warning depending on where that is in) is to be issued when plugin data is below, above or equal or not equal to value specified. Of the people I know that use my plugins they find it all fairly straight forward but the symbols are a bit of an issue because > and < are special symbols in bash, etc. so result is often enough that for proper call to plugin you have to quote it all in "" to work. At some point I came upon page about nagios plugins threshold syntax (can't immediately remember url) and while I found that syntax somewhat odd, when it came down to extending my syntax to support ranges (which are really very really needed) I decided to use that to be compatible with what others do and to support users who are familiar with that spec. So currently this is a full spec documented in plugin code: # Warning and critical thresholds are specified with '-w' and '-c' and each # one must have exact same number of values to be checked (separated by ',') # as number of variables specified with '-a'. Any values you dont want to # compare you specify as ~ (or just not specify a value, i.e. ',,'). # # There are also number of other one-letter modifiers that can be used # as prefix before actual data value to direct how data is to be checked. # These prefixes are as follows: # > : issue alert if data is above this value (default for numeric value) # < : issue alert if data is below this value (must be followed by number) # = : issue alert if data is equal to this value (default for non-numeric) # ! : issue alert if data is NOT equal to this value # # Additionally supported are two specifications of range formats: # number1:number2 issue alert if data is OUTSIDE of range [number1..number2] # i.e. alert if data<$number1 or data>$number2 # @number1:number2 issue alert if data is WITHIN range [number1..number2] # i.e. alert if data>=$number and $data<=$number2 Well ok, going back to your new spec question and again taking personal perspective, I can tell that if plugin syntax seriously changes, I probably would not be willing to rewrite my code (although adding support for ".." to work same as @a:b is easy enough and that I might do that) and I also have no near-term plans to start using Nagios::Plugins library either (I think its bloated and difficult but that is really issue for another discussion which I do not want to start here). William