From ryan.marsh at mac.com Tue Mar 4 18:53:46 2008 From: ryan.marsh at mac.com (Ryan Marsh) Date: Tue, 4 Mar 2008 11:53:46 -0600 Subject: [Nagiosplug-devel] check_ping and interfaces Message-ID: <3277296A-B2A3-4303-A6D1-1F1CAD62AF2C@mac.com> I'd like to force check_ping to use a specific network interface. How could I do this? Thanks, -ryan 713.430.6946 From holger at CIS.FU-Berlin.DE Fri Mar 7 19:13:46 2008 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Fri, 7 Mar 2008 19:13:46 +0100 Subject: [Nagiosplug-devel] check_ping and interfaces In-Reply-To: <3277296A-B2A3-4303-A6D1-1F1CAD62AF2C@mac.com> References: <3277296A-B2A3-4303-A6D1-1F1CAD62AF2C@mac.com> Message-ID: <20080307181346.GA47905149@CIS.FU-Berlin.DE> * Ryan Marsh [2008-03-04 11:53]: > I'd like to force check_ping to use a specific network interface. How > could I do this? check_ping currently has no such option. The SVN version of check_icmp can do that using the new "-s" flag, you could download the current snapshot if you're interested: http://nagiosplug.sf.net/snapshot/nagios-plugins-HEAD.tar.gz Holger From noreply at sourceforge.net Mon Mar 10 18:12:55 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2008 10:12:55 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1911239 ] check_smtp only says "Invalid SMTP response received from.." Message-ID: Bugs item #1911239, was opened at 2008-03-10 18:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1911239&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_smtp only says "Invalid SMTP response received from.." Initial Comment: Hi there, we got a bugreport against our (debian-)package: check_smtp.c around line 239 says: if (!strstr (buffer, server_expect)) { if (server_port == SMTP_PORT) printf (_("Invalid SMTP response received from host\n")); In such a case, it makes sense to actually *print* what the server said (different from SMTP_EXPECT, "220"), because this error message is pretty much useless for later debugging. Including the 'buffer' variable in that output seems like a no-brainer. The original bugreport can be found at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467493 and was filled against 1.4.5, but it also applies for latest cvs. Thanks and with kind regards, Jan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1911239&group_id=29880 From noreply at sourceforge.net Tue Mar 11 18:01:23 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2008 10:01:23 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1912023 ] check_http segfaults with "-a x" option Message-ID: Bugs item #1912023, was opened at 2008-03-11 13:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1912023&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Buchbinder (gdrago23) Assigned to: Nobody/Anonymous (nobody) Summary: check_http segfaults with "-a x" option Initial Comment: Plugin Version (-V output): check_http v1861 (nagios-plugins 1.4.11) Plugin Name: check_http Plugin Commandline showing issues: ./check_http -a x google.com Operating System: Ubuntu Gutsy Architecture: i686 Compiler: gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Backtrace: (gdb) run -a x google.com Starting program: /home/abuchbinder/src/nagiosplug/nagios-plugins-1.4.11/plugins/check_http -a x google.com Program received signal SIGSEGV, Segmentation fault. 0x08050b73 in base64 (bin=0x806bf04 'A' ..., len=1) at base64.c:23 23 buf[i++] = base64_table[bin[j] >> 2]; (gdb) bt #0 0x08050b73 in base64 (bin=0x806bf04 'A' ..., len=1) at base64.c:23 #1 0x0804b164 in check_http () at check_http.c:764 #2 0x0804e344 in main (argc=1094795585, argv=0x41414141) at check_http.c:166 (gdb) The argument specified isn't valid, but it still shouldn't segfault. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1912023&group_id=29880 From noreply at sourceforge.net Tue Mar 11 18:04:40 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2008 10:04:40 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1912023 ] check_http segfaults with "-a x" option Message-ID: Bugs item #1912023, was opened at 2008-03-11 13:01 Message generated for change (Settings changed) made by gdrago23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1912023&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing >Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Buchbinder (gdrago23) Assigned to: Nobody/Anonymous (nobody) Summary: check_http segfaults with "-a x" option Initial Comment: Plugin Version (-V output): check_http v1861 (nagios-plugins 1.4.11) Plugin Name: check_http Plugin Commandline showing issues: ./check_http -a x google.com Operating System: Ubuntu Gutsy Architecture: i686 Compiler: gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Backtrace: (gdb) run -a x google.com Starting program: /home/abuchbinder/src/nagiosplug/nagios-plugins-1.4.11/plugins/check_http -a x google.com Program received signal SIGSEGV, Segmentation fault. 0x08050b73 in base64 (bin=0x806bf04 'A' ..., len=1) at base64.c:23 23 buf[i++] = base64_table[bin[j] >> 2]; (gdb) bt #0 0x08050b73 in base64 (bin=0x806bf04 'A' ..., len=1) at base64.c:23 #1 0x0804b164 in check_http () at check_http.c:764 #2 0x0804e344 in main (argc=1094795585, argv=0x41414141) at check_http.c:166 (gdb) The argument specified isn't valid, but it still shouldn't segfault. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1912023&group_id=29880 From noreply at sourceforge.net Tue Mar 11 18:05:36 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2008 10:05:36 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1912023 ] check_http segfaults with "-a x" option Message-ID: Bugs item #1912023, was opened at 2008-03-11 13:01 Message generated for change (Comment added) made by gdrago23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1912023&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Buchbinder (gdrago23) Assigned to: Nobody/Anonymous (nobody) Summary: check_http segfaults with "-a x" option Initial Comment: Plugin Version (-V output): check_http v1861 (nagios-plugins 1.4.11) Plugin Name: check_http Plugin Commandline showing issues: ./check_http -a x google.com Operating System: Ubuntu Gutsy Architecture: i686 Compiler: gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Backtrace: (gdb) run -a x google.com Starting program: /home/abuchbinder/src/nagiosplug/nagios-plugins-1.4.11/plugins/check_http -a x google.com Program received signal SIGSEGV, Segmentation fault. 0x08050b73 in base64 (bin=0x806bf04 'A' ..., len=1) at base64.c:23 23 buf[i++] = base64_table[bin[j] >> 2]; (gdb) bt #0 0x08050b73 in base64 (bin=0x806bf04 'A' ..., len=1) at base64.c:23 #1 0x0804b164 in check_http () at check_http.c:764 #2 0x0804e344 in main (argc=1094795585, argv=0x41414141) at check_http.c:166 (gdb) The argument specified isn't valid, but it still shouldn't segfault. ---------------------------------------------------------------------- >Comment By: Adam Buchbinder (gdrago23) Date: 2008-03-11 13:05 Message: Logged In: YES user_id=20994 Originator: YES This has also been reported on the Ubuntu bug tracker: https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/201054 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1912023&group_id=29880 From noreply at sourceforge.net Tue Mar 11 18:26:59 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2008 10:26:59 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1912023 ] check_http segfaults with "-a x" option Message-ID: Bugs item #1912023, was opened at 2008-03-11 18:01 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1912023&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Adam Buchbinder (gdrago23) Assigned to: Nobody/Anonymous (nobody) Summary: check_http segfaults with "-a x" option Initial Comment: Plugin Version (-V output): check_http v1861 (nagios-plugins 1.4.11) Plugin Name: check_http Plugin Commandline showing issues: ./check_http -a x google.com Operating System: Ubuntu Gutsy Architecture: i686 Compiler: gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Backtrace: (gdb) run -a x google.com Starting program: /home/abuchbinder/src/nagiosplug/nagios-plugins-1.4.11/plugins/check_http -a x google.com Program received signal SIGSEGV, Segmentation fault. 0x08050b73 in base64 (bin=0x806bf04 'A' ..., len=1) at base64.c:23 23 buf[i++] = base64_table[bin[j] >> 2]; (gdb) bt #0 0x08050b73 in base64 (bin=0x806bf04 'A' ..., len=1) at base64.c:23 #1 0x0804b164 in check_http () at check_http.c:764 #2 0x0804e344 in main (argc=1094795585, argv=0x41414141) at check_http.c:166 (gdb) The argument specified isn't valid, but it still shouldn't segfault. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2008-03-11 18:26 Message: Logged In: YES user_id=759506 Originator: NO As far as I can see, this is fixed in SVN (we now use Gnulib for Base64 encoding), see the latest snapshot at: http://nagiosplug.sourceforge.net/snapshot/nagios-plugins-HEAD.tar.gz ---------------------------------------------------------------------- Comment By: Adam Buchbinder (gdrago23) Date: 2008-03-11 18:05 Message: Logged In: YES user_id=20994 Originator: YES This has also been reported on the Ubuntu bug tracker: https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/201054 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1912023&group_id=29880 From noreply at sourceforge.net Wed Mar 12 15:26:51 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Mar 2008 07:26:51 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1595450 ] check_procs bus error, segmentation fault or ... Message-ID: Patches item #1595450, was opened at 2006-11-13 09:24 Message generated for change (Comment added) made by zxr750 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1595450&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Peeters (zxr750) Assigned to: Ton Voon (tonvoon) Summary: check_procs bus error, segmentation fault or ... Initial Comment: check_procs bus error, segmentation fault or wrong output on Solaris 8, 9 & 10 Do first the next configure! ---------------------------- ./configure --with-ps_command="/usr/bin/ps -eo 's uid pid ppid vsz rss pcpu etime comm args'" --with-ps_format='%s %d %d %d %d %d %f %s %s %n' --with-ps_cols=10 --with-ps_varlist='procstat,&procuid,&procpid,&procppid,&procvsz,&procrss,&procpcpu,procetime,procprog,&pos' --with-trusted-path=/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin To solve the bus error and /or segmentation fault on Solaris 8: -------------------------------------------------- replace into check_procs.c if ( cols >= expected_cols ) { resultsum = 0; - asprintf (&procargs, "%s", input_line + pos); strip (procargs); with if ( cols >= expected_cols ) { resultsum = 0; + asprintf (&procargs, "%s", input_line); strip (procargs); To solve the wrong output on Solaris 8, 9 & 10: ----------------------------------------------- change into common.h MAX_INPUT_BUFFER 1024 to MAX_INPUT_BUFFER 4096 ---------------------------------------------------------------------- >Comment By: Alex Peeters (zxr750) Date: 2008-03-12 15:26 Message: Logged In: YES user_id=590764 Originator: YES > Can you see if this is still a problem with the snapshot? Tested with 5000 running process and no problems anymore Thanks -- Alex Peeters ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2008-02-29 11:52 Message: Logged In: YES user_id=664364 Originator: NO Alex, Can you see if this is still a problem with the snapshot? Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1595450&group_id=29880 From G.Tudan at gmx.de Thu Mar 13 15:18:05 2008 From: G.Tudan at gmx.de (Gregor Tudan) Date: Thu, 13 Mar 2008 15:18:05 +0100 Subject: [Nagiosplug-devel] Bug in mrtg_traf Message-ID: <47D9379D.8070206@gmx.de> Hi, there seems to be a bug in the mrtg_traf plugin. Line 206 reads "fperfdata(*"in"*, adjusted_outgoing_rate, outgoing_speed_rating," but it should be "fperfdata(*"out"*, adjusted_outgoing_rate, outgoing_speed_rating," Hope that helps, Gregor! From nathan.vonnahme at bannerhealth.com Thu Mar 13 18:19:39 2008 From: nathan.vonnahme at bannerhealth.com (Vonnahme, Nathan) Date: Thu, 13 Mar 2008 09:19:39 -0800 Subject: [Nagiosplug-devel] Nagios::Plugin with scientific notation In-Reply-To: References: Message-ID: <077F1B782014ED48A58E7927914D36A00457683A@fai01500.bhs.bannerhealth.com> Sorry, I have been negelecting the Nagios lists for a long time, but I don't see any replies to your question from Feb 1. Larry Wall said in one of his State of the Onion speeches that it's better for programs (and also community members) to be "generous in what you accept for input and strict in what you produce as output". So I think the sprintf solution is better, and the test that catches it, a good test! -n > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- > devel-bounces at lists.sourceforge.net] On Behalf Of Ton Voon > Sent: Friday, February 01, 2008 12:45 AM > To: Nagios Plugin Development Mailing List > Subject: [Nagiosplug-devel] Nagios::Plugin with scientific notation > > Hi! > > I've been looking at some of the test failures that CPAN is reporting > about the Nagios::Plugin module and I think I've fixed most of them > now. However, this one still occurs: > http://www.nntp.perl.org/group/perl.cpan.testers/2007/12/msg887150.html > > It looks like on some systems, perl returns the scientific notation > for the value part of the performance data. > > You can see this on any system by running: > > perl -e '$a = 0.000053; print $a,$/' > > I get 5.3e-05 on my MacOSX 10.5 and Debian 4.0. For some reason, the > test on darwin is giving this scientific notation when other systems > are not. > > So the question is: Is scientific notation a problem? If not, I'll > amend the test so that it doesn't fail. But if it is, should we > specifically state a sprintf output so that you get a consistent > output of the value? > > Ton > > http://www.altinity.com > UK: +44 (0)870 787 9243 > US: +1 866 879 9184 > Fax: +44 (0)845 280 1725 > Skype: tonvoon > > > ------------------------------------------------------------------------ - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > 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 From noreply at sourceforge.net Fri Mar 14 23:38:03 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Mar 2008 15:38:03 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1911239 ] check_smtp only says "Invalid SMTP response received from.." Message-ID: Bugs item #1911239, was opened at 2008-03-10 18:12 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1911239&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: CVS >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) >Assigned to: Matthias Eble (psychotrahe) Summary: check_smtp only says "Invalid SMTP response received from.." Initial Comment: Hi there, we got a bugreport against our (debian-)package: check_smtp.c around line 239 says: if (!strstr (buffer, server_expect)) { if (server_port == SMTP_PORT) printf (_("Invalid SMTP response received from host\n")); In such a case, it makes sense to actually *print* what the server said (different from SMTP_EXPECT, "220"), because this error message is pretty much useless for later debugging. Including the 'buffer' variable in that output seems like a no-brainer. The original bugreport can be found at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467493 and was filled against 1.4.5, but it also applies for latest cvs. Thanks and with kind regards, Jan. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-03-14 23:38 Message: Logged In: YES user_id=1694341 Originator: NO this problem is now fixed in svn. thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1911239&group_id=29880 From noreply at sourceforge.net Sat Mar 15 00:03:07 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Mar 2008 16:03:07 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1904673 ] Unknown Status Message-ID: Bugs item #1904673, was opened at 2008-02-29 14:07 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1904673&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eugene Dubovski (eugene_dubovski) Assigned to: Nobody/Anonymous (nobody) Summary: Unknown Status Initial Comment: nagios-plugins-1.4.11 check_apache nagios plugin version 0.01 Issue: Unknown Status Gentoo arch: amd64 gcc version 4.1.2 Patch attached. Eugene dea1983 at inbox.ru ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2008-03-15 00:03 Message: Logged In: YES user_id=1694341 Originator: NO Hi Eugene, this plugin is located in the contrib directory, which means that we do not maintain it actively. It looks like your patch doesn't necessarily work on all versions of apache. However - having a quality mod_status plugin in the official plugin distribution would be great IMO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1904673&group_id=29880 From noreply at sourceforge.net Sat Mar 15 00:03:32 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Mar 2008 16:03:32 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1904673 ] check_apache.pl Unknown Status Message-ID: Bugs item #1904673, was opened at 2008-02-29 14:07 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1904673&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eugene Dubovski (eugene_dubovski) Assigned to: Nobody/Anonymous (nobody) >Summary: check_apache.pl Unknown Status Initial Comment: nagios-plugins-1.4.11 check_apache nagios plugin version 0.01 Issue: Unknown Status Gentoo arch: amd64 gcc version 4.1.2 Patch attached. Eugene dea1983 at inbox.ru ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-03-15 00:03 Message: Logged In: YES user_id=1694341 Originator: NO Hi Eugene, this plugin is located in the contrib directory, which means that we do not maintain it actively. It looks like your patch doesn't necessarily work on all versions of apache. However - having a quality mod_status plugin in the official plugin distribution would be great IMO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1904673&group_id=29880 From noreply at sourceforge.net Sat Mar 15 00:58:02 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Mar 2008 16:58:02 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1874041 ] check_dig does not parse timeout value Message-ID: Bugs item #1874041, was opened at 2008-01-17 20:31 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1874041&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: LoOoD (loood) >Assigned to: Matthias Eble (psychotrahe) Summary: check_dig does not parse timeout value Initial Comment: When I try to specifiy a timeout value for check_dig, it doesn't send that value to the actual dig command. I'm using version 1.4.11 of the plugins and its running on centos4 $ ~/libexec/check_dig -H localhost -l host.domain.com -t 1300 -v /usr/bin/dig @localhost -p 53 host.domain.com -t A Looking for: 'host.domain.com' DNS WARNING - 10.010 seconds response time (dig returned an error status)|time=10.010081s;;;0.000000 $ ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2008-03-15 00:58 Message: Logged In: YES user_id=1694341 Originator: NO -t only handles the timeout for the plugin itself. it seems that dig times out here. I've just committed an enhancement to svn. With that you can pass a timeout argument to dig by adding -A '+time=WHATEVER' to check_dig. Does this solve your issue? ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-03-15 00:58 Message: Logged In: YES user_id=1694341 Originator: NO this problem is now fixed in svn. thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1874041&group_id=29880 From noreply at sourceforge.net Sat Mar 15 01:00:05 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Mar 2008 17:00:05 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1889453 ] check_dig should support TCP Message-ID: Bugs item #1889453, was opened at 2008-02-08 09:30 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1889453&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Giannis Stoilis (stoilis) >Assigned to: Matthias Eble (psychotrahe) Summary: check_dig should support TCP Initial Comment: I want to check DNS services for both UDP and TCP connectivity. dig has the +tcp parameter that enables TCP querying insted of UDP but it is not accessible because check_dig doesn't support it. While enabling this through check_dig would be a nice thing, maybe a better idea would be to pass parameters starting with "+" to dig directly, thus making it a little more transparent, giving it the ability to support future needed features. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2008-03-15 01:00 Message: Logged In: YES user_id=1694341 Originator: NO I've just committed an enhancement to svn. With that you can pass any argument to dig. Using tcp can now be switched on by adding -A '+tcp' to check_dig. Thanks for your proposal ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-03-15 01:00 Message: Logged In: YES user_id=1694341 Originator: NO this problem is now fixed in svn. thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1889453&group_id=29880 From dermoth at aei.ca Sat Mar 15 01:01:16 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 14 Mar 2008 20:01:16 -0400 Subject: [Nagiosplug-devel] nagios-plugins.ini & argument parsing Message-ID: <47DB11CC.6040501@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This morning I was looking at the work needed to add ini parsing to the C Nagios plugins. While looking at the C and Perl code I was stumbled to see that is can pass the argument list back to the argument parser as a straight space-separated list (I believe the perl module pass it as an array with the arguments already cleaned-up in case the caller wants a string, while the C library always returns a string). It wasn't hard to write arguments that showed differently depending on whenever they were specified in the ini file or in the command line and I personally believe trying to fix that will be a never-ending fight. Is there any reason not to always use an array? So my suggestion is: 1. Make Nagios::Plugin::Getopt::_cmdline always return an array and stop cleaning up the arguments (maybe renaming that internal function for clarity would be good too). 2. Do something similar for parse_ini.c. I'm not an expert, but I guess the best way would be to pass a linked list from the ini parser to the argument parser (not yet written), and then the argument parser can build a replacement array that can be processed by process_arguments. Ideally the C plugins should have a library that do all the work behind the scenes like Nagios::Plugins, but in the mean time it would be nice to have ini file support. Any objection / suggestion / comment? Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2xHM6dZ+Kt5BchYRAsj5AKDTEs07+o6uMjwwYwKOmceBZfGwDgCgqD9R 2eqzKubI1w2UkJlag6XP4M4= =Ouns -----END PGP SIGNATURE----- From noreply at sourceforge.net Sat Mar 15 01:01:42 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Mar 2008 17:01:42 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1889453 ] check_dig should support TCP Message-ID: Bugs item #1889453, was opened at 2008-02-08 09:30 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1889453&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Giannis Stoilis (stoilis) Assigned to: Matthias Eble (psychotrahe) Summary: check_dig should support TCP Initial Comment: I want to check DNS services for both UDP and TCP connectivity. dig has the +tcp parameter that enables TCP querying insted of UDP but it is not accessible because check_dig doesn't support it. While enabling this through check_dig would be a nice thing, maybe a better idea would be to pass parameters starting with "+" to dig directly, thus making it a little more transparent, giving it the ability to support future needed features. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-03-15 01:00 Message: Logged In: YES user_id=1694341 Originator: NO I've just committed an enhancement to svn. With that you can pass any argument to dig. Using tcp can now be switched on by adding -A '+tcp' to check_dig. Thanks for your proposal ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-03-15 01:00 Message: Logged In: YES user_id=1694341 Originator: NO this problem is now fixed in svn. thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1889453&group_id=29880 From noreply at sourceforge.net Sat Mar 15 01:16:37 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Mar 2008 17:16:37 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1881898 ] Fix 'Host:' header to include port Message-ID: Patches item #1881898, was opened at 2008-01-29 17:14 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1881898&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Christophe Dupre (duprec) >Assigned to: Matthias Eble (psychotrahe) Summary: Fix 'Host:' header to include port Initial Comment: RFC-2616 (HTTP/1.1 protocol) states that the lack of the port information in the "Host: " header supplied by the client implies the default value (80 for http, 443 for https). This means that if we override the port with the '-p' option, the plugin must provide that information in the "Host: " header. This patch fixes that oversight by always supplying the port, which is accepted practice and makes it a one-liner. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-03-15 01:16 Message: Logged In: YES user_id=1694341 Originator: NO this patch has been committed to the nagiosplug SVN repository. thank you for your contribution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1881898&group_id=29880 From noreply at sourceforge.net Sat Mar 15 21:11:36 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Mar 2008 13:11:36 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1250967 ] broken awk script subst.in Message-ID: Bugs item #1250967, was opened at 2005-08-03 13:53 Message generated for change (Comment added) made by nsturm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250967&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: None >Status: Open Resolution: None Priority: 5 Private: No Submitted By: nsturm (nsturm) Assigned to: Nobody/Anonymous (nobody) Summary: broken awk script subst.in Initial Comment: The script plugins-scripts/subst.in does things in the wrong order resulting in broken pathnames. As an example look at check_rpc.pl. First "use lib utils.pm;" is substituted by the full path name to utils.pm, but then the first name component is stripped off again (at least on OpenBSD where /usr/local/libexec/nagios/utils.pm becomes just nagios/utils.pm) This is on OpenBSD-current with plugins 1.4 and 1.4.1. Diff attached. ---------------------------------------------------------------------- >Comment By: nsturm (nsturm) Date: 2008-03-15 21:11 Message: Logged In: YES user_id=1323236 Originator: YES I was able to reproduce the problem, the cause is the last substitution in plugins-scripts/subst.in (lines 65-68). If you build nagios-plugins on OpenBSD, the substitution in line 48 will replace "use lib utils.pm" with 'use lib "/usr/local/libexec/nagios"'. If this directory does not exist however, lines 65-68 will strip /usr/local/libexec/ from this line (the directory does not exist when building the port on a clean system). I suggest not using which() in that script or at least returning an unchanged c in case the alleged binary is not found anywhere. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2007-06-26 04:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 10:13 Message: Logged In: YES user_id=1694341 Originator: NO Announced pending state by sending emails to the participants. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 14:07 Message: Logged In: YES user_id=1694341 Originator: NO Hi all, I have tried to reproduce this case on freebsd 6.2. But the lines were substituted correctly. use lib PREFIX/libexec use utils (... I tried 1.4.1, 1.4.3 and 1.4.5. Could you please test if this issue perstists with the latest version (1.4.9 or cvs snapshot)? Matthias ---------------------------------------------------------------------- Comment By: Olexandr Davydenko (blackraven1977) Date: 2006-12-08 20:48 Message: Logged In: YES user_id=1526665 Originator: NO Similar problem on FreeBSD 6.2-RC1 and nagios-plugins-1.4.5 . For example: in nagios-plugins-1.4.3 string in check_mailq.pl "use lib utils.pm;" substituted with full path in installed check_mailq "use lib "/usr/local/libexec/nagios";", but in nagios-plugins-1.4.5 it substituted as "use lib "nagios";" and check_mailq plugin cannot find utils.pm . Patch patch-plugins-scripts_subst_in fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250967&group_id=29880 From dermoth at aei.ca Sat Mar 15 21:17:51 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sat, 15 Mar 2008 16:17:51 -0400 Subject: [Nagiosplug-devel] nagios-plugins.ini & argument parsing In-Reply-To: <47DB11CC.6040501@aei.ca> References: <47DB11CC.6040501@aei.ca> Message-ID: <47DC2EEF.6070208@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/03/08 08:01 PM, Thomas Guyot-Sionnest wrote: > > 2. Do something similar for parse_ini.c. I'm not an expert, but I guess > the best way would be to pass a linked list from the ini parser to the > argument parser (not yet written), and then the argument parser can > build a replacement array that can be processed by process_arguments. > > Ideally the C plugins should have a library that do all the work behind > the scenes like Nagios::Plugins, but in the mean time it would be nice > to have ini file support. I started implementing this part and fixing bugs in parse_ini.c, and so far I went across two big differences in ini handling: 1. N::P allows '#' to be part of the argument, while parse_ini treat them as comments. Since it's a one-line change I left the original behavior in parse_ini (mainly because the ini/tests have to be changed too) but I really think '#' should be allowed. 2. N::P seems do do some smart parsing based on getopts... in either case it doesn't allow parameters without values (no '=' sign on the line) while parse_ini does, and append the '=' is there's one. While I'd be tempted to follow N::P's behavior for #2, this raises one question: N::P is able to make the difference between parameters that requires arguments and those that don't and could smartly insert an empty arg if there's nothing after the '='. This means we wouldn't be able to emulate empty arguments in the c plugins as long as we don't implement N::P-like argument parsing routines. Alternatively, I could append an empty argument when there's a '=' and keep allowing empty arguments, but for consistency I guess we should also allow it in N::P (Moth may want to use the config. This also seems to be a violation of the ini standard. In a perfect world we could just always add empty arguments but it seems that some backward-compatibility stuff fail with that. I could also reject lines missing a '=' and never add an argument since there aren't many plugins that require empty args... So for now I'll follow N::P behavior and never add an empty argument. The code isn't even used yet so this is still open for comments. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH3C7v6dZ+Kt5BchYRAtODAJ4yQXbjBrOsTaY8HsobvVeeJ81UqACgwBt4 awXBnM0FWO8SH8TlRWsYPK4= =ZAYP -----END PGP SIGNATURE----- From ton.voon at altinity.com Mon Mar 17 10:39:33 2008 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 17 Mar 2008 09:39:33 +0000 Subject: [Nagiosplug-devel] Nagios::Plugin with scientific notation In-Reply-To: <077F1B782014ED48A58E7927914D36A00457683A@fai01500.bhs.bannerhealth.com> References: <077F1B782014ED48A58E7927914D36A00457683A@fai01500.bhs.bannerhealth.com> Message-ID: <42CE1B1C-A524-4DB5-AAD1-D77356D1C0E8@altinity.com> Hi Nathan! Long time no hear! On 13 Mar 2008, at 17:19, Vonnahme, Nathan wrote: > Larry Wall said in one of his State of the Onion speeches that it's > better for programs (and also community members) to be "generous in > what > you accept for input and strict in what you produce as output". That's a good principle. I guess that means anything parsing the perf data should cater for scientific notation, but the plugins should only return a certain format. In which case, what is the precision? Can we say at the time of printing the value, it is something like: $value_as_text = sprintf("%.5f", $value); $value_as_text =~ s/0+$/; # Remove trailing zeros $value_as_text =~ s/\.$/; # Remove trailing separator Hmmm, different languages have different separators, so do we state that the value will come from the POSIX locale? (decimal point is a dot, no 'thousands' grouping). I'm thinking that the performance data doesn't need to be much more precise than this - Nagios plugin performance data is guidance, not exact. Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From ton.voon at altinity.com Mon Mar 17 11:39:00 2008 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 17 Mar 2008 10:39:00 +0000 Subject: [Nagiosplug-devel] nagios-plugins.ini & argument parsing In-Reply-To: <47DC2EEF.6070208@aei.ca> References: <47DB11CC.6040501@aei.ca> <47DC2EEF.6070208@aei.ca> Message-ID: On 15 Mar 2008, at 20:17, Thomas Guyot-Sionnest wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 14/03/08 08:01 PM, Thomas Guyot-Sionnest wrote: > I started implementing this part and fixing bugs in parse_ini.c, and > so > far I went across two big differences in ini handling: > > 1. N::P allows '#' to be part of the argument, while parse_ini treat > them as comments. Since it's a one-line change I left the original > behavior in parse_ini (mainly because the ini/tests have to be changed > too) but I really think '#' should be allowed. So comments can only be entered if # is the first character on a line? That sounds like a reasonable restriction. > 2. N::P seems do do some smart parsing based on getopts... in either > case it doesn't allow parameters without values (no '=' sign on the > line) while parse_ini does, and append the '=' is there's one. > > > While I'd be tempted to follow N::P's behavior for #2, this raises one > question: N::P is able to make the difference between parameters that > requires arguments and those that don't and could smartly insert an > empty arg if there's nothing after the '='. This means we wouldn't be > able to emulate empty arguments in the c plugins as long as we don't > implement N::P-like argument parsing routines. > > Alternatively, I could append an empty argument when there's a '=' and > keep allowing empty arguments, but for consistency I guess we should > also allow it in N::P (Moth may want to use the config. This also > seems > to be a violation of the ini standard. In a perfect world we could > just > always add empty arguments but it seems that some backward- > compatibility > stuff fail with that. I could also reject lines missing a '=' and > never > add an argument since there aren't many plugins that require empty > args... > > So for now I'll follow N::P behavior and never add an empty argument. > The code isn't even used yet so this is still open for comments. I'm not following the problem here. Can you provide examples? Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From dermoth at aei.ca Mon Mar 17 13:08:40 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 17 Mar 2008 08:08:40 -0400 Subject: [Nagiosplug-devel] nagios-plugins.ini & argument parsing In-Reply-To: References: <47DB11CC.6040501@aei.ca> <47DC2EEF.6070208@aei.ca> Message-ID: <47DE5F48.8010603@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/03/08 06:39 AM, Ton Voon wrote: > On 15 Mar 2008, at 20:17, Thomas Guyot-Sionnest wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 14/03/08 08:01 PM, Thomas Guyot-Sionnest wrote: > >> I started implementing this part and fixing bugs in parse_ini.c, and >> so >> far I went across two big differences in ini handling: >> >> 1. N::P allows '#' to be part of the argument, while parse_ini treat >> them as comments. Since it's a one-line change I left the original >> behavior in parse_ini (mainly because the ini/tests have to be changed >> too) but I really think '#' should be allowed. > > So comments can only be entered if # is the first character on a line? > That sounds like a reasonable restriction. There can be spaces before a comment (and probably comments after a section header too), but not a comment after a = line. i.e. right now the following lines: foo = bar # this is a comment foobar = some_data_containing_a_#_in_the_middle will result in: - --foo=bar - --foobar-some_data_containing_a_ Once I disable comments there it will change to (ps: I didn't quoted the value part here, but in the prugins it will be passed as only one argument): - --foo=bar # this is a comment - --foobar-some_data_containing_a_#_in_the_middle To be able to pass a # in the value we'll have to forbid comments there. This is really easy to change, but I'll have to change the tests too. >> 2. N::P seems do do some smart parsing based on getopts... in either >> case it doesn't allow parameters without values (no '=' sign on the >> line) while parse_ini does, and append the '=' is there's one. >> >> >> While I'd be tempted to follow N::P's behavior for #2, this raises one >> question: N::P is able to make the difference between parameters that >> requires arguments and those that don't and could smartly insert an >> empty arg if there's nothing after the '='. This means we wouldn't be >> able to emulate empty arguments in the c plugins as long as we don't >> implement N::P-like argument parsing routines. >> >> Alternatively, I could append an empty argument when there's a '=' and >> keep allowing empty arguments, but for consistency I guess we should >> also allow it in N::P (Moth may want to use the config. This also >> seems >> to be a violation of the ini standard. In a perfect world we could >> just >> always add empty arguments but it seems that some backward- >> compatibility >> stuff fail with that. I could also reject lines missing a '=' and >> never >> add an argument since there aren't many plugins that require empty >> args... >> >> So for now I'll follow N::P behavior and never add an empty argument. >> The code isn't even used yet so this is still open for comments. > > I'm not following the problem here. Can you provide examples? This is a problem only if you wish to provide an empty string as a parameter. I believe the original idea of whoever wrote parse_ini was that a parameter without = sign would be a parameter without argument, and a parameter with an = sign and to value would be an empty argument. N::P forbid parameters without = sign so the config file would be incompatible. The way I understand it, N::P detects if there's an required argument and sets an empty string as the argument if needed. so the following line: label= would either set a flag parameter to true or set the label to an empty string depending on the way it is defined. Now I realize this still leaves one issue, so the only option is to avoid these cases in our plugins. Let's say you have a --label option that takes an optional argument. without argument, the label is determined automatically so ion your command line you can write: - --label --other-args => label determined automatically - --label=something --label something => you define the label - --label '' => you want an empty label so the third case wouldn't work with ini files. In other words we shouldn't allow optional arguments with empty argument (either make the argument required, or make the default to an empty string). There might be ways to work around this in our plugins too... As i convert them I will look for special cases and see what I can do. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH3l9I6dZ+Kt5BchYRAuZ8AKDLUHNFR3oODNL1c/hMgFVmLNVD2gCdEKV3 5dCqiHmIvd1ffYd1fdcYtJw= =rWsB -----END PGP SIGNATURE----- From ton.voon at altinity.com Mon Mar 17 22:15:32 2008 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 17 Mar 2008 21:15:32 +0000 Subject: [Nagiosplug-devel] RFC: New threshold syntax Message-ID: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> 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: http://nagiosplugins.org/rfc/new_threshold_syntax 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? Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From perldork at webwizarddesign.com Tue Mar 18 05:36:04 2008 From: perldork at webwizarddesign.com (Max) Date: Tue, 18 Mar 2008 00:36:04 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> Message-ID: Hi, I think your idea to extend the syntax is a good one :), I personally have found myself more and more using a syntax in this format -w 'metricnumber:metric2number' e.g. -w '1min>15:5min>5' -c '15min>15:5min>10' "Warn if 1 minute load is greater than 15 or 5 minute is greater than 5, critical if 15 minute is greater than 15 or 5 minute is greater than 10' this lets a user specify a fairly complex or'd syntax for complex thresholds .. the separator could determine or vs. and. I too find that just using simple single numbers does not do well for 'check all' types of plugins .. plugins that check multiple metrics at once, it is a limitation that forces inefficiencies when adding service checks for Nagios .. if an element type, for example, CPU utilization, has 3 metrics associated with it (1 min, 5 min, 15 min), I want to check those all at once with one plugin, not have Nagios make 3 calls to the same plugin just to check all 3 ... I really like that plugins have guidelines and that Nagios takes a keep things simple approach but I also think we need as a community to have guidelines that allow developers to create efficient checks, more and more we see 'check all' types of checks that could really benefit from specifying multiple metric thresholds per warning and critical ranges .. - Max From dermoth at aei.ca Tue Mar 18 07:13:00 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 18 Mar 2008 02:13:00 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> Message-ID: <47DF5D6C.1000708@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/03/08 05:15 PM, Ton Voon 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: http://nagiosplugins.org/rfc/new_threshold_syntax > > 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! Thanks Ton, It looks great, but I have a few comments: The threshold format should possibly include a separator (I vote for the comma, ",", the usual separator for arguments) since some plugins expects multiple successive thresholds (like check_snmp). Those would be only accepted by a 2nd function that would return an array of thresholds struct. Omitting thresholds would be allowed the usual way (if I get it properly) with a slash and optional uom (ex: "/,20:/30:k,/M"). If the regular function is used the thresholds would be rejected. *** Added after reading some more *** I thought the / was always required. Your check_http example isn't very clear if you specify warning or critical thresholds. I believe uom/prefix for controlling the unit used for printing is a good idea but: 1. we should define what is allowed. Should probably be a subset of this: http://physics.nist.gov/cuu/Units/prefixes.html 2. Do we allow base8 units (Ki, Mi, etc)? 3. Do we allow a unit after the prefix? I think it's metric-specific, so I wouldn't think so (despite your examples). If yes and 2, how do we specify a 'i' unit? what if the unit you want is a valid prefix? 4. I believe uom should only affect the plugin output. The performance data should be as precise as possible, ideally in scientific notation. I also think it shouldn't change, because parsers would then need to find the uom to properly See my check_memory plugin in nagiosexchange for example. It would be nice to have another prefix (that goes before, after or without the caret) to specify whenever the specified values should be alerted on or not (inclusive vs exclusive)... Maybe a pound (#). Just I suggestion - I'd personally use that sometimes. I dislike the choice of inf or colons to denote infinity. I'd prefer we stick on either one of them. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH311s6dZ+Kt5BchYRArNsAKDidboi2KGjj5sleCQoWD1AohEnrQCfSPzv aNPt1xhkHO+VKK24Fa9ZLXM= =O5r6 -----END PGP SIGNATURE----- From ton.voon at altinity.com Tue Mar 18 10:04:27 2008 From: ton.voon at altinity.com (Ton Voon) Date: Tue, 18 Mar 2008 09:04:27 +0000 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> Message-ID: <25F7CA25-4416-4F3D-BEFD-55730ACF259A@altinity.com> On 18 Mar 2008, at 04:36, Max wrote: > I think your idea to extend the syntax is a good one :), I personally > have found myself more and more using a syntax in this format > > -w 'metricnumber:metric2number' > > e.g. > > -w '1min>15:5min>5' -c '15min>15:5min>10' > > "Warn if 1 minute load is greater than 15 or 5 minute is greater than > 5, critical if 15 minute is greater than 15 or 5 minute is greater > than 10' > > this lets a user specify a fairly complex or'd syntax for complex > thresholds .. the separator could determine or vs. and. So I guess in the proposed format, this would be: --load1=/15: --load5=10:/5: --load15=15: Is that easier to read? I guess for me it is :) I like the > symbol, but it is overloading an existing shell meaning, which is why I avoided it. Currently, my proposal only supports an OR of the threshold checks, but I guess we could easily add a flag to change to AND instead. > I too find that just using simple single numbers does not do well for > 'check all' types of plugins .. plugins that check multiple metrics at > once, it is a limitation that forces inefficiencies when adding > service checks for Nagios .. if an element type, for example, CPU > utilization, has 3 metrics associated with it (1 min, 5 min, 15 min), > I want to check those all at once with one plugin, not have Nagios > make 3 calls to the same plugin just to check all 3 ... Agreed. For one customer, they want to check that there is a single process and alert if vsz > 100MB OR cpu > 30%. They currently have to run this as 3 checks: ./check_procs -u user -C command -c 1:1 ./check_procs -u user -C command --metric=VSZ -c 100000 ./check_procs -u user -C command --metric=CPU -c 30 So I'm trying to get check_procs to allow the following: ./check_procs -u user -C command --number=^1:1 --vsz=100000 --cpu=30 > I really like that plugins have guidelines and that Nagios takes a > keep things simple approach but I also think we need as a community to > have guidelines that allow developers to create efficient checks, more > and more we see 'check all' types of checks that could really benefit > from specifying multiple metric thresholds per warning and critical > ranges .. What ideas do you have? I see the plugins team mission is to create a great set of re-usable frameworks (the C library functions and Nagios::Plugin for perl) and some of the most commonly used plugins that showcase the frameworks. Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From ton.voon at altinity.com Tue Mar 18 10:39:37 2008 From: ton.voon at altinity.com (Ton Voon) Date: Tue, 18 Mar 2008 09:39:37 +0000 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <47DF5D6C.1000708@aei.ca> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47DF5D6C.1000708@aei.ca> Message-ID: <62BFCC67-13AC-456D-A3DC-25C21EA026C4@altinity.com> On 18 Mar 2008, at 06:13, Thomas Guyot-Sionnest wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 17/03/08 05:15 PM, Ton Voon 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: http://nagiosplugins.org/rfc/new_threshold_syntax >> >> 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! > > Thanks Ton, > > It looks great, but I have a few comments: > > The threshold format should possibly include a separator (I vote for > the > comma, ",", the usual separator for arguments) since some plugins > expects multiple successive thresholds (like check_snmp). Those > would be > only accepted by a 2nd function that would return an array of > thresholds > struct. Omitting thresholds would be allowed the usual way (if I get > it > properly) with a slash and optional uom (ex: "/,20:/30:k,/M"). If the > regular function is used the thresholds would be rejected. I agree about the use of a comma separator. I was deliberately not trying to overcomplicate this, but I've added a note in for future. > *** Added after reading some more *** > I thought the / was always required. Your check_http example isn't > very > clear if you specify warning or critical thresholds. Good point. I've added a sentence that says that the / can be missed out if you are specifying criticals only. > I believe uom/prefix for controlling the unit used for printing is a > good idea but: > > 1. we should define what is allowed. Should probably be a subset of > this: > http://physics.nist.gov/cuu/Units/prefixes.html > 2. Do we allow base8 units (Ki, Mi, etc)? > 3. Do we allow a unit after the prefix? I think it's metric- > specific, so > I wouldn't think so (despite your examples). If yes and 2, how do we > specify a 'i' unit? what if the unit you want is a valid prefix? > 4. I believe uom should only affect the plugin output. The performance > data should be as precise as possible, ideally in scientific > notation. I > also think it shouldn't change, because parsers would then need to > find > the uom to properly See my check_memory plugin in nagiosexchange for > example. I thought about the uom late yesterday, so I guess it could be half- baked :) I'm thinking that there would a strict list of uoms for conversion. The physics link looks like a decent list. I think there's something in the gnulib too for "human readable" values. I don't think this needs to be nailed at the moment. However, whether the perf data is altered or not does need to be agreed. I guess you are saying that the perfdata should always be in a specific unit (say, bytes for disk space), whereas I was thinking that the units could change to what a person thought was more readable (though changing would affect existing data stores). So what do you think the guideline should be? A plugin should have a base unit for all its perfdata? (bytes? seconds?) > It would be nice to have another prefix (that goes before, after or > without the caret) to specify whenever the specified values should be > alerted on or not (inclusive vs exclusive)... Maybe a pound (#). > Just I > suggestion - I'd personally use that sometimes. That screams "next phase" to me! > I dislike the choice of inf or colons to denote infinity. I'd prefer > we > stick on either one of them. There was a need in the current range definition to have infinity because ":5" was assumed to be "0:5". However, since we are now defining the range "all the way to the left" and "all the way to the right", we can drop +-inf. I'm keen on delivering something based on this, so I'll remove with a note. Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From dermoth at aei.ca Tue Mar 18 14:30:40 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 18 Mar 2008 09:30:40 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <62BFCC67-13AC-456D-A3DC-25C21EA026C4@altinity.com> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47DF5D6C.1000708@aei.ca> <62BFCC67-13AC-456D-A3DC-25C21EA026C4@altinity.com> Message-ID: <47DFC400.3070204@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/03/08 05:39 AM, Ton Voon wrote: > On 18 Mar 2008, at 06:13, Thomas Guyot-Sionnest wrote: > >> The threshold format should possibly include a separator (I vote for >> the >> comma, ",", the usual separator for arguments) since some plugins >> expects multiple successive thresholds (like check_snmp). Those >> would be >> only accepted by a 2nd function that would return an array of >> thresholds >> struct. Omitting thresholds would be allowed the usual way (if I get >> it >> properly) with a slash and optional uom (ex: "/,20:/30:k,/M"). If the >> regular function is used the thresholds would be rejected. > > I agree about the use of a comma separator. I was deliberately not > trying to overcomplicate this, but I've added a note in for future. Thanks. I believe it shouldn't be in the actual specs (or maybe just a note about it), but we should provide that facility to plugins and it would be documented in their --help output. >> *** Added after reading some more *** >> I thought the / was always required. Your check_http example isn't >> very >> clear if you specify warning or critical thresholds. > > Good point. I've added a sentence that says that the / can be missed > out if you are specifying criticals only. Can it be missed out when we're not specifying thresholds too? >> I believe uom/prefix for controlling the unit used for printing is a >> good idea but: >> >> 1. we should define what is allowed. Should probably be a subset of >> this: >> http://physics.nist.gov/cuu/Units/prefixes.html >> 2. Do we allow base8 units (Ki, Mi, etc)? >> 3. Do we allow a unit after the prefix? I think it's metric- >> specific, so >> I wouldn't think so (despite your examples). If yes and 2, how do we >> specify a 'i' unit? what if the unit you want is a valid prefix? >> 4. I believe uom should only affect the plugin output. The performance >> data should be as precise as possible, ideally in scientific >> notation. I >> also think it shouldn't change, because parsers would then need to >> find >> the uom to properly See my check_memory plugin in nagiosexchange for >> example. > > I thought about the uom late yesterday, so I guess it could be half- > baked :) > > I'm thinking that there would a strict list of uoms for conversion. > The physics link looks like a decent list. I think there's something > in the gnulib too for "human readable" values. I don't think this > needs to be nailed at the moment. > > However, whether the perf data is altered or not does need to be > agreed. I guess you are saying that the perfdata should always be in a > specific unit (say, bytes for disk space), whereas I was thinking that > the units could change to what a person thought was more readable > (though changing would affect existing data stores). Moving to scientific notation would require making sure everyone will be able to cope with that, so even if we want that I'd say 2.0, and even then possibly a compile-time option. OTOH the advantage is that you get consistent output; if could likely fix some problems we've had so far... So I think we should keep them like they are for now (ms, bytes, etc.). Arguably, with scientific notation you don't loose precision when you change units, but why should the perfdata unit change? Let's say I have disk ckecks showing space in megs. One day I decide to print them in Gigs for clarity, will I have to reset all my graph that stored data in megs so far? On the graphing side the conversion is done automatically so it doesn't matter what units they're in. BTW check_disk is a counter-example of what we should do. It rounds the result to megs, so when you look at your graph it's very ugly: flat lines and big jumps. > So what do you think the guideline should be? A plugin should have a > base unit for all its perfdata? (bytes? seconds?) The base-unit should be provided by the plugin istelf. There could be some exceptions like check_snmp and check_nt but I think it's best to let individual plugins deal with that. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH38QA6dZ+Kt5BchYRApnRAJ9BUQXDKBfHaCWwbspHpB+a2+ucJgCggYQT gTDGyc5eGRcZ1dKVTh108Bc= =WZi0 -----END PGP SIGNATURE----- From ae at op5.se Tue Mar 18 14:41:21 2008 From: ae at op5.se (Andreas Ericsson) Date: Tue, 18 Mar 2008 14:41:21 +0100 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <25F7CA25-4416-4F3D-BEFD-55730ACF259A@altinity.com> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <25F7CA25-4416-4F3D-BEFD-55730ACF259A@altinity.com> Message-ID: <47DFC681.7060009@op5.se> Ton Voon wrote: > On 18 Mar 2008, at 04:36, Max wrote: > >> I think your idea to extend the syntax is a good one :), I personally >> have found myself more and more using a syntax in this format >> >> -w 'metricnumber:metric2number' >> >> e.g. >> >> -w '1min>15:5min>5' -c '15min>15:5min>10' >> >> "Warn if 1 minute load is greater than 15 or 5 minute is greater than >> 5, critical if 15 minute is greater than 15 or 5 minute is greater >> than 10' >> >> this lets a user specify a fairly complex or'd syntax for complex >> thresholds .. the separator could determine or vs. and. > > So I guess in the proposed format, this would be: > > --load1=/15: --load5=10:/5: --load15=15: > > Is that easier to read? I guess for me it is :) > I absolutely loathe it, as it looks far too arcane. I have no better suggestion though, but imagine the command line going something like --load1=^10:15/^15:19 --load10=5:8/^12:16 --load15=^10:15/19:25 You have 5 seconds to spot the error. Anything more and the user debugging this line will have moved on already, thinking there are bugs in a) The plugins b) Nagios c) Both (no, it's not in the totally insane but perfectly legal thresholds). Besides, sometimes it's sensible to have the range specify the invalid states, and sometimes it's sensible to have them specify the OK range. It shouldn't be up to the arg parser to decide which one should be the default, and when a user sends a single number to the machinery, it needs to handle it properly and let the plugin decide for itself if it's the upper or lower boundary. > I like the > symbol, but it is overloading an existing shell meaning, > which is why I avoided it. > Sensible. With '>' in arguments every argument needs to be escaped, which is just plain stupid. > Currently, my proposal only supports an OR of the threshold checks, > but I guess we could easily add a flag to change to AND instead. > Why? I imagine OR would be more useful, or perhaps 'OR' and 'AND' at the same time. Perhaps you want either of 5 thresholds to match but only if not this other one matches too, since in that case you want only *this* or *that* to trigger an alert. Perhaps it'd be easier to just rip an SQL-parsing implementation directly, with subquery support tucked right in. Or perhaps 5 triggered warnings from a single plugin should escalate to a critical? I'd imagine quite a lot of users would want that. >> I too find that just using simple single numbers does not do well for >> 'check all' types of plugins .. plugins that check multiple metrics at >> once, it is a limitation that forces inefficiencies when adding >> service checks for Nagios .. if an element type, for example, CPU >> utilization, has 3 metrics associated with it (1 min, 5 min, 15 min), >> I want to check those all at once with one plugin, not have Nagios >> make 3 calls to the same plugin just to check all 3 ... > > Agreed. For one customer, they want to check that there is a single > process and alert if vsz > 100MB OR cpu > 30%. They currently have to > run this as 3 checks: > > ./check_procs -u user -C command -c 1:1 > ./check_procs -u user -C command --metric=VSZ -c 100000 > ./check_procs -u user -C command --metric=CPU -c 30 > Ordered arguments could solve this quite easily, with a command-line looking like this: ./check_procs -u user -C command -c 1:1 --metric=VSZ -c 100000 --metric=CPU -c 30 although that's 11 chars longer than what you have below. > So I'm trying to get check_procs to allow the following: > > ./check_procs -u user -C command --number=^1:1 --vsz=100000 --cpu=30 > You could achieve the exact same thing by just adding support for the new long arguments instead. Whoever invented the --metric thing should be shot. Wrappers are good things for accomplishing complex tasks with simple tools. One of the things that has given Nagios such a great spread is that it's really, really simple to write plugins for it. Creating a new check is as easy as hacking up 5 lines of shell-script, or 40 lines of C, or whatever. Taking the simple tools and making them more complex excludes a lot of nice usage one could get out of them. >> I really like that plugins have guidelines and that Nagios takes a >> keep things simple approach but I also think we need as a community to >> have guidelines that allow developers to create efficient checks, more >> and more we see 'check all' types of checks that could really benefit >> from specifying multiple metric thresholds per warning and critical >> ranges .. > > What ideas do you have? I see the plugins team mission is to create a > great set of re-usable frameworks (the C library functions and > Nagios::Plugin for perl) and some of the most commonly used plugins > that showcase the frameworks. > Frameworks? Umm... A framework is what you create when you have a task to create several similar pieces of software that for some reason look a bit different. The plugins are by their very definition unique in the tasks they have to complete. Sure, they do a couple of things in common, such as parsing arguments and sending some data over a network. For the argument parsing, you have getopt() (which is shipped with the plugins), for the network communication stuff you have the bsd socket layer, which is so portable that even VMS has it. Anyways, I have no strong opinion either way, except that I feel the current way of specifying arguments need to be retained, since quite a lot of people's configurations depend on it. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From perldork at webwizarddesign.com Tue Mar 18 16:01:06 2008 From: perldork at webwizarddesign.com (Max) Date: Tue, 18 Mar 2008 11:01:06 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <47DFC681.7060009@op5.se> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <25F7CA25-4416-4F3D-BEFD-55730ACF259A@altinity.com> <47DFC681.7060009@op5.se> Message-ID: On Tue, Mar 18, 2008 at 9:41 AM, Andreas Ericsson wrote: > Sensible. With '>' in arguments every argument needs to be escaped, > which is just plain stupid. Having operators match normal math vs. learning a different syntax just to indicate normal operators with a trade off of having to quote arguments is stupid? Interesting opinion, especially since command definitions are codified in configuration files that don't change much, in my (to you, stupid) mind making the warning and critical conditional syntax more readable and maintainable for more complex thresholds is more important than saving a plugin writer a few quote key strokes here and there. We all test and test plugins from the command line before we codify them in command definitions, not like most Nagios admins are doing tons of new checks a day for configurations where missing a quote is a huge risk. > just rip an SQL-parsing implementation directly, with subquery support > tucked right in. This I really like. This would let the syntax for threshold specifications get as complex as needed for people who want to do complex thresholds, use a paradigm for syntax that is very well understood, while the specifications at the same time could maintain as well the very simple integer specifications that are documented now for people who don't want to go that path. - Max From ton.voon at altinity.com Wed Mar 19 10:10:48 2008 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 19 Mar 2008 09:10:48 +0000 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <47DFC400.3070204@aei.ca> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47DF5D6C.1000708@aei.ca> <62BFCC67-13AC-456D-A3DC-25C21EA026C4@altinity.com> <47DFC400.3070204@aei.ca> Message-ID: <9EFC67C1-A221-4CF1-8E48-E5FEBBABA04E@altinity.com> On 18 Mar 2008, at 13:30, Thomas Guyot-Sionnest wrote: > > Can it be missed out when we're not specifying thresholds too? Good point. Added. > Moving to scientific notation would require making sure everyone > will be > able to cope with that, so even if we want that I'd say 2.0, and even > then possibly a compile-time option. OTOH the advantage is that you > get > consistent output; if could likely fix some problems we've had so > far... > So I think we should keep them like they are for now (ms, bytes, > etc.). We are already passing scientific notation in N::P (see separate thread subject "Nagios::Plugin with scientific notation"), and that is not in the spec. But I agree that this is not the time to consider this, so I'll remove the part about the perf data based on uom in the threshold. Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From ivibration at hotmail.com Wed Mar 19 10:18:21 2008 From: ivibration at hotmail.com (Erwan Boulard) Date: Wed, 19 Mar 2008 09:18:21 +0000 Subject: [Nagiosplug-devel] (No output error in Centreon) // no problem in console mode Message-ID: Hi list I have a problem with my plugin nagios => check http connexion login/passd and check the presence of a word in the next page. In console mode , i have no problem my plugin work well , but in Centreon i have the answer => (no output!). It's possible that in Centreon process the plugin d'ont work because of the use of a specific library (WWW:mechanize)?? I join the code of the plugin : #! /usr/bin/perl -w################################################# TEST CONNEXION HTTPS ITIM## Description : Script perl Verifiant l etat de disponibilite # de l application ITIM en testant une URL en # saisissant un user/password et verifiant la # page de retour## Author : Erwan Boulard################################################ use utils qw(%ERRORS $TIMEOUT);use Getopt::Long;use strict;use WWW::Mechanize;use vars qw($o_uri $o_login $o_passwd $o_host $o_port $o_vers $o_help); # Sortie Verbose#sub verb { my $t = shift; print $t, "\n" if defined($o_verb); } # parse command line options Getopt::Long::Configure("bundling"); GetOptions( 'h' => \$o_help, 'help' => \$o_help, #'v' => \$o_verb, #'verbose' => \$o_verb, 'H:s' => \$o_host, 'hostaddress:s' => \$o_host, 'u:s' => \$o_uri, 'uri:s' => \$o_uri, 'i:s' => \$o_login, 'identifiant:s' => \$o_login, 'm:s' => \$o_passwd, 'motdepasse:s' => \$o_passwd, 'p:i' => \$o_port, 'port:i' => \$o_port, );if ( defined($o_help) ) { &help(); exit $ERRORS{"UNKNOWN"} } my $output;my $statut; # URL/identifiant/motdepasse obligatoireif ( !defined($o_uri) || !defined($o_login) || !defined($o_passwd) || !defined($o_host)) { &print_usage; print "\nErreur : Une variable n a pas ete definie \n"; exit $ERRORS{'UNKNOWN'};} ########## MENU PRINCIPAL ####### { my $m = WWW::Mechanize->new; my $url; if(defined($o_port)){ $url = 'http://'.$o_host.':'.$o_port.$o_uri; } else { $url = 'http://'.$o_host.$o_uri; } # formulaire de login #print $url; $m->get($url); if($m->success){ # remplissage et validation $m->set_fields( useralias => $o_login, password => $o_passwd, ); $m->click; die $m->res->status_line unless $m->success; if($m->content =~ m/Host Stats/) { $output="OK - Test de connexion"; $statut='OK'; } else { $output="KO - Test de connexion"; $statut='CRITICAL'; } } else { $output="KO - Test de connexion"; $statut='CRITICAL'; }print $output;exit $ERRORS{$statut};}sub print_usage {print "Usage : ./check_itim_testconnexion.pl -H[--hostaddress]HostAddress -u[--uri]URI -i[--identifiant]IDENTIFIANT -m[--motdepasse]MOT DE PASSE -p[--port]Port \n";} sub help {print < From ivibration at hotmail.com Wed Mar 19 10:19:02 2008 From: ivibration at hotmail.com (boulard erwan) Date: Wed, 19 Mar 2008 10:19:02 +0100 (CET) Subject: [Nagiosplug-devel] (No output error in Centreon) // no problem in console mode Message-ID: <20080319091902.812B3580023@desire.netways.de> Hi list I have a problem with my plugin nagios => check http connexion login/passd and check the presence of a word in the next page. In console mode , i have no problem my plugin work well , but in Centreon i have the answer => (no output!). It's possible that in Centreon process the plugin d'ont work because of the use of a specific library (WWW:mechanize)?? I join the code of the plugin : #! /usr/bin/perl -w ############################################### # # TEST CONNEXION HTTPS ITIM # # Description : Script perl Verifiant l etat de disponibilite # de l application ITIM en testant une URL en # saisissant un user/password et verifiant la # page de retour # # Author : Erwan Boulard # ############################################### use utils qw(%ERRORS $TIMEOUT); use Getopt::Long; use strict; use WWW::Mechanize; use vars qw($o_uri $o_login $o_passwd $o_host $o_port $o_vers $o_help); # Sortie Verbose #sub verb { my $t = shift; print $t, "\n" if defined($o_verb); } # parse command line options Getopt::Long::Configure("bundling"); GetOptions( 'h' => \$o_help, 'help' => \$o_help, #'v' => \$o_verb, #'verbose' => \$o_verb, 'H:s' => \$o_host, 'hostaddress:s' => \$o_host, 'u:s' => \$o_uri, 'uri:s' => \$o_uri, 'i:s' => \$o_login, 'identifiant:s' => \$o_login, 'm:s' => \$o_passwd, 'motdepasse:s' => \$o_passwd, 'p:i' => \$o_port, 'port:i' => \$o_port, ); if ( defined($o_help) ) { &help(); exit $ERRORS{"UNKNOWN"} } my $output; my $statut; # URL/identifiant/motdepasse obligatoire if ( !defined($o_uri) || !defined($o_login) || !defined($o_passwd) || !defined($o_host)) { &print_usage; print "\nErreur : Une variable n a pas ete definie \n"; exit $ERRORS{'UNKNOWN'}; } ########## MENU PRINCIPAL ####### { my $m = WWW::Mechanize->new; my $url; if(defined($o_port)){ $url = 'http://'.$o_host.':'.$o_port.$o_uri; } else { $url = 'http://'.$o_host.$o_uri; } # formulaire de login #print $url; $m->get($url); if($m->success){ # remplissage et validation $m->set_fields( useralias => $o_login, password => $o_passwd, ); $m->click; die $m->res->status_line unless $m->success; if($m->content =~ m/Host Stats/) { $output="OK - Test de connexion"; $statut='OK'; } else { $output="KO - Test de connexion"; $statut='CRITICAL'; } } else { $output="KO - Test de connexion"; $statut='CRITICAL'; } print $output; exit $ERRORS{$statut}; } sub print_usage { print "Usage : ./check_itim_testconnexion.pl -H[--hostaddress]HostAddress -u[--uri]URI -i[--identifiant]IDENTIFIANT -m[--motdepasse]MOT DE PASSE -p[--port]Port \n"; } sub help { print < References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <25F7CA25-4416-4F3D-BEFD-55730ACF259A@altinity.com> <47DFC681.7060009@op5.se> Message-ID: <0AC471B9-F76A-4290-8BF2-9A549E92497A@altinity.com> On 18 Mar 2008, at 13:41, Andreas Ericsson wrote: > Ton Voon wrote: >> >> I absolutely loathe it, as it looks far too arcane. I have no > better suggestion though, but imagine the command line going > something like > > --load1=^10:15/^15:19 --load10=5:8/^12:16 --load15=^10:15/19:25 > > You have 5 seconds to spot the error. Anything more and the user > debugging this line will have moved on already, thinking there are > bugs in > a) The plugins > b) Nagios > c) Both Nope, I can't see the error, and I stared at it for 15 mins. I agree it looks arcane. But I bet, with any other plausible way of defining on the command line, that what you intend to do above will not be any clearer. The driver for this is not to invent Yet-Another-Custom-Way-Of- Defining-Thresholds. The driver is to get a standard/consistent/ dependable way of stating what your thresholds are, with some library functions to make it simple to add into plugins. I can imagine some helper functions (cmdline, web pages, google calculator) that, with more fields and example values, will tell you if your threshold is defined "as you expect". Or maybe do the reverse - enter in a specification like above, put in a few load1, load10 and load15 values - and tell you which metrics the plugin would alert on or not. You can only do this with a standard way of defining the threshold. > Besides, sometimes it's sensible to have the range specify the > invalid states, and sometimes it's sensible to have them specify the > OK range. It shouldn't be up to the arg parser to decide which one > should be the default, and when a user sends a single number to the > machinery, it needs to handle it properly and let the plugin decide > for itself if it's the upper or lower boundary. I think that's an interesting possibility - that a single digit is contextually defined by the plugin. This breaks the conventions above (unless the plugin gave data to say what its default behaviour is). I've note it for future consideration. >> Agreed. For one customer, they want to check that there is a single >> process and alert if vsz > 100MB OR cpu > 30%. They currently have to >> run this as 3 checks: >> >> ./check_procs -u user -C command -c 1:1 >> ./check_procs -u user -C command --metric=VSZ -c 100000 >> ./check_procs -u user -C command --metric=CPU -c 30 >> > > Ordered arguments could solve this quite easily, with a command-line > looking like this: > > ./check_procs -u user -C command -c 1:1 --metric=VSZ -c 100000 -- > metric=CPU -c 30 I hadn't considered ordered command line options. check_disk had such a painful way of specifying the thresholds, that I probably subconsciously blocked that out. Would you like to flesh out what the rules are, how backward compatibility can be maintained, what defaults are (looks like the default metric is "number of processes"), how the range values are processed (1:1 looks like it is treated differently to 100000 and 30 - contextually based on metric?). There needs more consideration, but I think there's merit here. > Whoever invented the --metric thing should be > shot. [hands up] My only excuse is that the aim was to merge check_rss, check_vsz and check_cpu into check_procs, which it has done :) > >> What ideas do you have? I see the plugins team mission is to create a >> great set of re-usable frameworks (the C library functions and >> Nagios::Plugin for perl) and some of the most commonly used plugins >> that showcase the frameworks. >> > > Frameworks? Umm... A framework is what you create when you have a > task to create several similar pieces of software that for some > reason look a bit different. The plugins are by their very definition > unique in the tasks they have to complete. Sure, they do a couple of > things in common, such as parsing arguments and sending some data over > a network. For the argument parsing, you have getopt() (which is > shipped > with the plugins), for the network communication stuff you have the > bsd > socket layer, which is so portable that even VMS has it. OK, "framework" is a bit marketing-speak. But in your list of "common tasks" I would add "calculation of thresholds", which is precisely what I'm trying to do here. > Anyways, I have no strong opinion either way, except that I feel the > current way of specifying arguments need to be retained, since quite > a lot of people's configurations depend on it. Absolutely. Which is why I spent 2 hours writing tests to make sure I get exactly the expected results using a fixed ps output and a set of command line options: http://nagiosplug.svn.sourceforge.net/viewvc/nagiosplug/nagiosplug/trunk/plugins/tests/check_procs.t?view=log If you'd like to add in your favourite options, patches welcome. Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From dermoth at aei.ca Wed Mar 19 10:56:44 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 19 Mar 2008 05:56:44 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <9EFC67C1-A221-4CF1-8E48-E5FEBBABA04E@altinity.com> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47DF5D6C.1000708@aei.ca> <62BFCC67-13AC-456D-A3DC-25C21EA026C4@altinity.com> <47DFC400.3070204@aei.ca> <9EFC67C1-A221-4CF1-8E48-E5FEBBABA04E@altinity.com> Message-ID: <47E0E35C.7080407@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/03/08 05:10 AM, Ton Voon wrote: > On 18 Mar 2008, at 13:30, Thomas Guyot-Sionnest wrote: >> Can it be missed out when we're not specifying thresholds too? > > Good point. Added. > >> Moving to scientific notation would require making sure everyone >> will be >> able to cope with that, so even if we want that I'd say 2.0, and even >> then possibly a compile-time option. OTOH the advantage is that you >> get >> consistent output; if could likely fix some problems we've had so >> far... >> So I think we should keep them like they are for now (ms, bytes, >> etc.). > > We are already passing scientific notation in N::P (see separate > thread subject "Nagios::Plugin with scientific notation"), and that is > not in the spec. > > But I agree that this is not the time to consider this, so I'll remove > the part about the perf data based on uom in the threshold. Hi Ton, It's not that I want to add fire on the subject, but given Andreas's input and a discussion between Matthias and Holger on IRC, is seems like you proposal is far from reaching consensus... So I just got a totally different idea: what if we make the thresholds a set of parameters that can be processes by getsubopt? I haven't developed much this idea, but I'm thinking something like: check_stuff --metric min=2,warn_max=5,crit_max=7,outside,uom_prefix=Ki,uom=b p.s.: here I'm thinking max/min alone would set both warn and crit thresholds (Hey, BTW there's also the binary prefixes: http://physics.nist.gov/cuu/Units/binary.html) To address Angreas's concern that people may want to alert critical if the number of triggered warnings exceed something, we could even add global (probably needs a better name, whatever) parameters: check_stuff --metric1 warn_min=2,warn_max=5 --metric2 warn_max=8,warn_min=1 --metric3 warn_max=1500,warn_min=inf,outside - --global max_warn=1 the global settings could also be used to set defaults for all other metrics. So for example if I want all metrics to have min=0,outside I just set them once and can optionally override them in individual metrics. With this scheme we're not limited by the number of parameters either because it doesn't really add complexity. We can even add new parameters in the future without breaking backward-compatibility... On a side note, maybe we could recruit users from the mailing lists and make them test our thresholds using different methods. We prepare a full, final specification for each method we want to test, give them real-world situation (i.e. service x - needs to send an email (warning) if metrix x goes higher than x, etc...) and ask them to write the correct thresholds. Then we can look which error they made, what they missed out and get their comments about the complexity and clearness if the specifications. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH4ONb6dZ+Kt5BchYRAt+/AJ9Q8Y2noguqsl3vNR+Okivv8QEnMQCgvXBL hkXiXGniDlj4y5v1Lst3gx0= =xOmb -----END PGP SIGNATURE----- From ton.voon at altinity.com Wed Mar 19 10:58:13 2008 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 19 Mar 2008 09:58:13 +0000 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <25F7CA25-4416-4F3D-BEFD-55730ACF259A@altinity.com> <47DFC681.7060009@op5.se> Message-ID: On 18 Mar 2008, at 15:01, Max wrote: > On Tue, Mar 18, 2008 at 9:41 AM, Andreas Ericsson wrote: >> Sensible. With '>' in arguments every argument needs to be escaped, >> which is just plain stupid. > > Having operators match normal math vs. learning a different syntax > just to indicate normal operators with a trade off of having to quote > arguments is stupid? Interesting opinion, especially since command > definitions are codified in configuration files that don't change > much, in my (to you, stupid) mind making the warning and critical > conditional syntax more readable and maintainable for more complex > thresholds is more important than saving a plugin writer a few quote > key strokes here and there. We all test and test plugins from the > command line before we codify them in command definitions, not like > most Nagios admins are doing tons of new checks a day for > configurations where missing a quote is a huge risk. Decent argument. Using "<" is more clear. Using "<=" will also sort out the inclusion/ exclusion issue too. Your example uses the -w and -c flags, rather than using the metric. How would we say "show me time, but I don't want thresholds set against it"? Maybe this in combination with the ordered command line options? --threshold=number -w '>5' -c '>7' --threshold=cpu -c '40<=x<=60' I can see this being much harder to parse. There's merit in this, but needs fleshing out. >> just rip an SQL-parsing implementation directly, with subquery >> support >> tucked right in. > > This I really like. This would let the syntax for threshold > specifications get as complex as needed for people who want to do > complex thresholds, use a paradigm for syntax that is very well > understood, while the specifications at the same time could maintain > as well the very simple integer specifications that are documented now > for people who don't want to go that path. As lovely as that sounds, what would it look like in practise? Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From bohara at gmail.com Wed Mar 19 12:13:01 2008 From: bohara at gmail.com (Ben O'Hara) Date: Wed, 19 Mar 2008 11:13:01 +0000 Subject: [Nagiosplug-devel] Fwd: Perfdata for check_mysql In-Reply-To: <2b36e660709060202l7d75c0dh3e0fe8d6ed40dbc9@mail.gmail.com> References: <2b36e660709060202l7d75c0dh3e0fe8d6ed40dbc9@mail.gmail.com> Message-ID: <2b36e660803190413gf9de77at7bb50733c2654f75@mail.gmail.com> Hi, I sent this to the list back last year, just deployed the latest CVS snapshot of nagios-plugins and there is still no perfdata returned from check_mysql Attached is a patch against CVS HEAD from today to fix this Can we please get this merged into CVS? Cheers Ben ---------- Forwarded message ---------- From: Ben O'Hara Date: Thu, Sep 6, 2007 at 9:02 AM Subject: Perfdata for check_mysql To: Nagios Plugin Development Mailing List Attached is a patch against the latest 1.4.9 release of the plugins for check_mysql to add performance data. Took it from this old entry and fixed to work with latest release... https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1150826&group_id=29880 Seems to do the job, ive not given it any thorough testing but seems to work....any chance of getting this merged into CVS/SVN as im sure people are after this data and save repatching after upgrades ;-) Cheers Ben -- "A Scientist will earn a living by taking a really difficult problem and spends many years solving it, an engineer earns a living by finding really difficult problems and side stepping them" -- If voting changed anything, they'd make it illegal -------------- next part -------------- A non-text attachment was scrubbed... Name: check_mysql.diff Type: application/octet-stream Size: 3124 bytes Desc: not available URL: From ae at op5.se Wed Mar 19 12:17:32 2008 From: ae at op5.se (Andreas Ericsson) Date: Wed, 19 Mar 2008 12:17:32 +0100 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <25F7CA25-4416-4F3D-BEFD-55730ACF259A@altinity.com> <47DFC681.7060009@op5.se> Message-ID: <47E0F64C.20102@op5.se> Ton Voon wrote: > On 18 Mar 2008, at 15:01, Max wrote: > >> On Tue, Mar 18, 2008 at 9:41 AM, Andreas Ericsson wrote: >>> Sensible. With '>' in arguments every argument needs to be escaped, >>> which is just plain stupid. >> Having operators match normal math vs. learning a different syntax >> just to indicate normal operators with a trade off of having to quote >> arguments is stupid? Yes, because many people will forget the quotes lots and lots of times. Syntaxes that so obviously will lead to irritation is stupid. > Interesting opinion, especially since command >> definitions are codified in configuration files that don't change >> much, in my (to you, stupid) mind making the warning and critical >> conditional syntax more readable and maintainable for more complex >> thresholds is more important than saving a plugin writer a few quote >> key strokes here and there. We all test and test plugins from the >> command line before we Well, the huge grey mass is infinitely more important than the singular individual here, I think, and you can't possibly mean "we, the entire community" when you say "we", so the argument is moot without a clearer definition. I know from personal experience that people will almost always omit quoting the first time a program is run if they're not a) 100% alert b) very used to Unix c) the developer who wrote the app d) previously bitten numerous times by the same issue The problem with overloading a shell operator is that the plugin author gets zero chance of giving decent feedback to the user what he did wrong, because he can't see the entire commandline the user gave, and someone not savvy enough with unix but still wishing to run Nagios won't have any idea what so ever that <> are input/output redirection commands for the shell to interpret. So yes, the idea of using shell operators in command arguments is clearly bogus. As an example, can you tell me which one of these works, and why, with a reasonable current version of, oh, let's say bash: if ! test -d /etc; then echo "no such dir /etc"; fi if test ! -d /etc; then echo "no such dir /etc"; fi goodie. Now do the test again, but with zsh, and then with tcsh. Then try it on Solaris, and then with korn shell. Now do the same exercise with your syntax. For some (ancient) shells, <> will override quoting (yes, retarded, isn't it?), but you will never know, and the user will have no way out except from upgrading both his login shell *and* his /bin/sh (as that's what popen(3) uses to run commands with). Now, hands up everyone who knew that popen(3) can use a different shell than you do when you're logged in, and that that shell can parse a command line totally different from your login shell. Then tell the user to "be more careful when creating his command definitions" and you'll just have made one HP openview sales rep very happy. > codify them in command definitions, not like >> most Nagios admins are doing tons of new checks a day for >> configurations where missing a quote is a huge risk. > > Decent argument. > > Using "<" is more clear. Using "<=" will also sort out the inclusion/ > exclusion issue too. > Except that '<' is *also* bogus, and will break horribly for any program running a script that can accept input on stdin. > Your example uses the -w and -c flags, rather than using the metric. > How would we say "show me time, but I don't want thresholds set > against it"? > > Maybe this in combination with the ordered command line options? > > --threshold=number -w '>5' -c '>7' --threshold=cpu -c '40<=x<=60' > > I can see this being much harder to parse. There's merit in this, but > needs fleshing out. > >>> just rip an SQL-parsing implementation directly, with subquery >>> support >>> tucked right in. >> This I really like. This would let the syntax for threshold >> specifications get as complex as needed for people who want to do >> complex thresholds, use a paradigm for syntax that is very well >> understood, while the specifications at the same time could maintain >> as well the very simple integer specifications that are documented now >> for people who don't want to go that path. > > As lovely as that sounds, what would it look like in practise? > Ugly, since SQL has different quoting / escape rules than shell, so you have to mix the two in order to be able to utilize it fully. Iow, same can of worms that Max wants to open, but opened from underneath and only powerusers will get bitten, as opposed to everyone. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From perldork at webwizarddesign.com Wed Mar 19 13:50:42 2008 From: perldork at webwizarddesign.com (Max) Date: Wed, 19 Mar 2008 08:50:42 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <47E0F64C.20102@op5.se> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <25F7CA25-4416-4F3D-BEFD-55730ACF259A@altinity.com> <47DFC681.7060009@op5.se> <47E0F64C.20102@op5.se> Message-ID: On Wed, Mar 19, 2008 at 7:17 AM, Andreas Ericsson wrote: > Yes, because many people will forget the quotes lots and lots of > times. Syntaxes that so obviously will lead to irritation is stupid. > definition. I know from personal experience that people will almost > always omit quoting the first time a program is run if they're not > a) 100% alert > b) very used to Unix > c) the developer who wrote the app > d) previously bitten numerous times by the same issue > The problem with overloading a shell operator is that the plugin > author gets zero chance of giving decent feedback to the user what > he did wrong, because he can't see the entire commandline the user > gave, and someone not savvy enough with unix but still wishing to > run Nagios won't have any idea what so ever that <> are input/output > redirection commands for the shell to interpret. > > So yes, the idea of using shell operators in command arguments is > clearly bogus. > user to "be more careful when creating his command definitions" and > you'll just have made one HP openview sales rep very happy. Ok, so you are a pessimist about the ability of normal users to be competent with shell syntax and I am an optimist. I don't agree that most users will forget to quote arguments, that hasn't been my experience with people new to Linux or Unix, but I certainly can't talk to your experience. > Except that '<' is *also* bogus, and will break horribly for any program > running a script that can accept input on stdin. Again works fine if quotes are used and the person is not on some ancient shell as you clearly pointed out that will break things even with quoting. > >>> just rip an SQL-parsing implementation directly, with subquery > >>> support > >>> tucked right in. > Ugly, since SQL has different quoting / escape rules than shell, so > you have to mix the two in order to be able to utilize it fully. Iow, > same can of worms that Max wants to open, but opened from underneath > and only powerusers will get bitten, as opposed to everyone. Then why did you bring the idea to the table? That was your idea in your earlier email. I don't want to 'open a can of worms', I want syntax that is easy to maintain and understand for new users and syntax that is rich enough to model complex conditionals for advanced users that still maintains some form of readability, to me it seems like this will all be going down the road of not having the holy grail of argument standards but instead continuing the lines of having best practices, maybe just having best practices for those less experienced with plugin writing and Linux/Unix and another set for those who are more experienced with the two. Appreciate the lengthy explanation of why you thought my idea was stupid, bogus, idiotic, whatever other insults you wish to add. Would have been nice if you explained that up front and substituted your obviously knowledgeable understanding of the problems that might cause for some users on some systems instead of just insulting me without any explanation. Sorry to the others on this conversation for the sidetrack, I will contribute to the thread again only if I have something productive to add, and I am very glad this topic is being discussed :), good stuff. - Max From perldork at webwizarddesign.com Wed Mar 19 14:04:28 2008 From: perldork at webwizarddesign.com (Max) Date: Wed, 19 Mar 2008 09:04:28 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <0AC471B9-F76A-4290-8BF2-9A549E92497A@altinity.com> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <25F7CA25-4416-4F3D-BEFD-55730ACF259A@altinity.com> <47DFC681.7060009@op5.se> <0AC471B9-F76A-4290-8BF2-9A549E92497A@altinity.com> Message-ID: On Wed, Mar 19, 2008 at 5:41 AM, Ton Voon wrote: > I agree it looks arcane. But I bet, with any other plausible way of > defining on the command line, that what you intend to do above will > not be any clearer. I agree with this, the balance between being verbose and easy to read vs compact and arcane will be an interesting one to strike. > The driver for this is not to invent Yet-Another-Custom-Way-Of- > Defining-Thresholds. The driver is to get a standard/consistent/ > dependable way of stating what your thresholds are, with some library > functions to make it simple to add into plugins. And I agree that this is excellent and can let the Nagios user community have a choice between libraries if needed. > I can imagine some helper functions (cmdline, web pages, google > calculator) that, with more fields and example values, will tell you > if your threshold is defined "as you expect". Nice idea. > Or maybe do the reverse - enter in a specification like above, put in > a few load1, load10 and load15 values - and tell you which metrics the > plugin would alert on or not. Not to go back to a sore topic that is just closing, but kind of the equivalent of an explain plan in SQL? This would be nice. > You can only do this with a standard way of defining the threshold. My worry is that trying to have just one standard will leave the less experienced and more experienced both less than content .. are people on this thread adverse to having more than one way of specifying thresholds to meet the needs of both groups? > > Ordered arguments could solve this quite easily, with a command-line > > looking like this: > > > > ./check_procs -u user -C command -c 1:1 --metric=VSZ -c 100000 -- > > metric=CPU -c 30 > > I hadn't considered ordered command line options. check_disk had such > a painful way of specifying the thresholds, that I probably > subconsciously blocked that out. I agree that forcing order on the threshold arguments from the command line will frustrate some users and completely goes against the grain of how 99% of Unix CLI tools work. > OK, "framework" is a bit marketing-speak. But in your list of "common > tasks" I would add "calculation of thresholds", which is precisely > what I'm trying to do here. Agreed. > Absolutely. Which is why I spent 2 hours writing tests to make sure I > get exactly the expected results using a fixed ps output and a set of > command line options: http://nagiosplug.svn.sourceforge.net/viewvc/nagiosplug/nagiosplug/trunk/plugins/tests/check_procs.t?view=log > > If you'd like to add in your favourite options, patches welcome. So is this heading the direction of developing maybe two separate libraries that would meet the needs of people who just want simple thresholds and those who want complex thresholds or am I being 'stupid' again? As with Unix having the getopt and long getopt libraries from GNU, I personally would really like being able to choose between two families of option parsers to make the plugins I write as easy to read and maintain as possible. - Max From ae at op5.se Wed Mar 19 14:21:51 2008 From: ae at op5.se (Andreas Ericsson) Date: Wed, 19 Mar 2008 14:21:51 +0100 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <25F7CA25-4416-4F3D-BEFD-55730ACF259A@altinity.com> <47DFC681.7060009@op5.se> <47E0F64C.20102@op5.se> Message-ID: <47E1136F.7000903@op5.se> Max wrote: > On Wed, Mar 19, 2008 at 7:17 AM, Andreas Ericsson wrote: >> Yes, because many people will forget the quotes lots and lots of >> times. Syntaxes that so obviously will lead to irritation is stupid. >> definition. I know from personal experience that people will almost >> always omit quoting the first time a program is run if they're not >> a) 100% alert >> b) very used to Unix >> c) the developer who wrote the app >> d) previously bitten numerous times by the same issue > >> The problem with overloading a shell operator is that the plugin >> author gets zero chance of giving decent feedback to the user what >> he did wrong, because he can't see the entire commandline the user >> gave, and someone not savvy enough with unix but still wishing to >> run Nagios won't have any idea what so ever that <> are input/output >> redirection commands for the shell to interpret. >> >> So yes, the idea of using shell operators in command arguments is >> clearly bogus. > >> user to "be more careful when creating his command definitions" and >> you'll just have made one HP openview sales rep very happy. > > Ok, so you are a pessimist about the ability of normal users to be > competent with shell syntax and I am an optimist. > > I don't agree that most users will forget to quote arguments, that > hasn't been my experience with people new to Linux or Unix, but I > certainly can't talk to your experience. > >> Except that '<' is *also* bogus, and will break horribly for any program >> running a script that can accept input on stdin. > > Again works fine if quotes are used and the person is not on some > ancient shell as you clearly pointed out that will break things even > with quoting. > So what do we do with users running Nagios on AIX? Tell them to go screw themselves, because "oh look, we've thought up this wonderful new way of specifying critical and warning ranges at the same time"? Or they could ofcourse just not upgrade the plugins package, but that doesn't work in the long run. >> >>> just rip an SQL-parsing implementation directly, with subquery >> >>> support >> >>> tucked right in. >> Ugly, since SQL has different quoting / escape rules than shell, so >> you have to mix the two in order to be able to utilize it fully. Iow, >> same can of worms that Max wants to open, but opened from underneath >> and only powerusers will get bitten, as opposed to everyone. > > Then why did you bring the idea to the table? That was your idea in > your earlier email. > I was being ironic. An SQL parser that handles the standard only is far too complex to parse arguments with. > I don't want to 'open a can of worms', I want syntax that is easy to > maintain and understand for new users and syntax that is rich enough > to model complex conditionals for advanced users that still maintains > some form of readability, to me it seems like this will all be going > down the road of not having the holy grail of argument standards but > instead continuing the lines of having best practices, maybe just > having best practices for those less experienced with plugin writing > and Linux/Unix and another set for those who are more experienced with > the two. > So two sets of arguments to maintain? Maintenance nightmare, imo. > Appreciate the lengthy explanation of why you thought my idea was > stupid, bogus, idiotic, whatever other insults you wish to add. I never said idiotic. I said "<" is also bogus, because it leads to bogus error messages when users forget to add the quotes. And they will, trust me on that. Not to mention that it's horrible to write parsers for shell-specific chars in shell, and I imagine the perl parser will look quite funny too (which, going by your email, you'll half-volunteer to write). I did say stupid though, and I stand by it. Note that I didn't call you stupid, but your idea, which is a different matter entirely. Even brilliant people sometimes have dumb ideas because they don't see all the consequences of it, or perhaps they just don't have to deal with them, which, for practical purposes, equates to roughly the same thing. > Would > have been nice if you explained that up front and substituted your > obviously knowledgeable understanding of the problems that might cause > for some users on some systems instead of just insulting me without > any explanation. > What gain is there for either of us if I spoonfeed you the answers? I was hoping you'd start thinking a bit further than "this looks neat and almost like perl. I *like* it!". That way you could have learned something. For the future; it's a good idea to see what other semi-similar programs are doing. For the record, I can't think of a single cli program that requires shell characters in its command line. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ae at op5.se Wed Mar 19 15:59:20 2008 From: ae at op5.se (Andreas Ericsson) Date: Wed, 19 Mar 2008 15:59:20 +0100 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <25F7CA25-4416-4F3D-BEFD-55730ACF259A@altinity.com> <47DFC681.7060009@op5.se> <0AC471B9-F76A-4290-8BF2-9A549E92497A@altinity.com> Message-ID: <47E12A48.7070100@op5.se> Max wrote: > On Wed, Mar 19, 2008 at 5:41 AM, Ton Voon wrote: >> I agree it looks arcane. But I bet, with any other plausible way of >> defining on the command line, that what you intend to do above will >> not be any clearer. > > I agree with this, the balance between being verbose and easy to read > vs compact and arcane will be an interesting one to strike. > Not really. Verbose and easy to read should win out any time, as the syntax isn't supposed to be used daily. It's much more important that it's accurate and that the user is comfortable with the thresholds he/she has specified than that it's possible to cram as many args as possible into an 80 char wide screen. >> The driver for this is not to invent Yet-Another-Custom-Way-Of- >> Defining-Thresholds. The driver is to get a standard/consistent/ >> dependable way of stating what your thresholds are, with some library >> functions to make it simple to add into plugins. > > And I agree that this is excellent and can let the Nagios user > community have a choice between libraries if needed. > No, that's really, really bad, because everyone will come to the same place and ask for help, so if you get 9 different libraries you'll have 8 of them which no developer knows how to handle. Although I expect that will be a small issue, since 99% of all users will just go with what's default anyway. >> I can imagine some helper functions (cmdline, web pages, google >> calculator) that, with more fields and example values, will tell you >> if your threshold is defined "as you expect". > > Nice idea. > man pages > all that, for the same reason that the help output is restricted to an 80 char wide screen (no, I'm not being inconsistent). >> Or maybe do the reverse - enter in a specification like above, put in >> a few load1, load10 and load15 values - and tell you which metrics the >> plugin would alert on or not. > > Not to go back to a sore topic that is just closing, but kind of the > equivalent of an explain plan in SQL? This would be nice. > >> You can only do this with a standard way of defining the threshold. > > My worry is that trying to have just one standard will leave the less > experienced and more experienced both less than content .. are people > on this thread adverse to having more than one way of specifying > thresholds to meet the needs of both groups? > I am, in the strongest possible terms. For one simple reason: Bitrot. >> > Ordered arguments could solve this quite easily, with a command-line >> > looking like this: >> > >> > ./check_procs -u user -C command -c 1:1 --metric=VSZ -c 100000 -- >> > metric=CPU -c 30 >> >> I hadn't considered ordered command line options. check_disk had such >> a painful way of specifying the thresholds, that I probably >> subconsciously blocked that out. > > I agree that forcing order on the threshold arguments from the command > line will frustrate some users and completely goes against the grain > of how 99% of Unix CLI tools work. > Not really. find does it that way. >> OK, "framework" is a bit marketing-speak. But in your list of "common >> tasks" I would add "calculation of thresholds", which is precisely >> what I'm trying to do here. > > Agreed. > >> Absolutely. Which is why I spent 2 hours writing tests to make sure I >> get exactly the expected results using a fixed ps output and a set of >> command line options: http://nagiosplug.svn.sourceforge.net/viewvc/nagiosplug/nagiosplug/trunk/plugins/tests/check_procs.t?view=log >> >> If you'd like to add in your favourite options, patches welcome. > > So is this heading the direction of developing maybe two separate > libraries that would meet the needs of people who just want simple > thresholds and those who want complex thresholds or am I being > 'stupid' again? > Not stupid, but naive if you think that both of them will be kept up to date, along with the documentation for both of them. Like I said, it's maintenance nightmare to support two different ways of saying the same thing, and doubly so if you want users to know about it. > As with Unix having the getopt and long getopt libraries from GNU, I > personally would really like being able to choose between two families > of option parsers to make the plugins I write as easy to read and > maintain as possible. > What about use? -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From perldork at webwizarddesign.com Wed Mar 19 16:35:19 2008 From: perldork at webwizarddesign.com (Max) Date: Wed, 19 Mar 2008 11:35:19 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <47E12A48.7070100@op5.se> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <25F7CA25-4416-4F3D-BEFD-55730ACF259A@altinity.com> <47DFC681.7060009@op5.se> <0AC471B9-F76A-4290-8BF2-9A549E92497A@altinity.com> <47E12A48.7070100@op5.se> Message-ID: On Wed, Mar 19, 2008 at 10:59 AM, Andreas Ericsson wrote: > Not really. Verbose and easy to read should win out any time, as the > syntax isn't supposed to be used daily. It's much more important that > it's accurate and that the user is comfortable with the thresholds > he/she has specified than that it's possible to cram as many args as > possible into an 80 char wide screen. What are your suggestions, Andreas? You have given a lot of feedback on what you like and do not like, what syntax do you suggest? > No, that's really, really bad, because everyone will come to the same > place and ask for help, so if you get 9 different libraries you'll > have 8 of them which no developer knows how to handle. Although I > expect that will be a small issue, since 99% of all users will just > go with what's default anyway. Fair enough. > I am, in the strongest possible terms. For one simple reason: Bitrot. Let usage show who wins, provide a few parsing options, see which gets used the most and then drop the others as officially supported and let people from the Nagios user community support them if they are wanted. > > I agree that forcing order on the threshold arguments from the command > > line will frustrate some users and completely goes against the grain > > of how 99% of Unix CLI tools work. > > > > Not really. find does it that way. 99%, yes, I knew about find. > Not stupid, but naive if you think that both of them will be kept up > to date, along with the documentation for both of them. Like I said, > it's maintenance nightmare to support two different ways of saying the > same thing, and doubly so if you want users to know about it. I do think that if their is enthusiasm among Nagios users to keep them up, they will be kept up and Nagios is all about choice - flexible syntax, loads of add-ons and enhancements and points of integration. No one would expect you to maintain them, you do not think there are enough Nagios plugin writers available to support two parsers? > What about use? I agree, present a few options and let 'use' decide which wins in the long term - Max From perldork at webwizarddesign.com Wed Mar 19 16:49:59 2008 From: perldork at webwizarddesign.com (Max) Date: Wed, 19 Mar 2008 11:49:59 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <47E1136F.7000903@op5.se> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <25F7CA25-4416-4F3D-BEFD-55730ACF259A@altinity.com> <47DFC681.7060009@op5.se> <47E0F64C.20102@op5.se> <47E1136F.7000903@op5.se> Message-ID: On Wed, Mar 19, 2008 at 9:21 AM, Andreas Ericsson wrote: > So what do we do with users running Nagios on AIX? Tell them to go > screw themselves, because "oh look, we've thought up this wonderful > new way of specifying critical and warning ranges at the same time"? Ok, of course not, thanks for sharing, would be nice to drop the constant sarcasm, it gets in the way of your points. So we can't use these characters then either: ^ - old shells use this as pipe ~ - some shells use this for regexp matching = - forget to quote and doh, we are setting shell variables now ; | & So are we left with an RPN style notation to ensure that this works across all OSes .. like RRD, with multiple warn and critical switches accepted to help with readability, maybe? --warning 15min,15.00,gt --warning 1min,5.00,gte --critical 15min,30,gt,10min,5,gt ?? That would at least be something many users (no Andreas, not all, not beginners either) have used and something that is well documented. > For the future; it's a good idea to see what other semi-similar programs > are doing. For the record, I can't think of a single cli program that > requires shell characters in its command line. sed awk Yes, not for options, but they often are pipelined and have syntax that requires quotes. - Max From holger at CIS.FU-Berlin.DE Wed Mar 19 17:10:27 2008 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Wed, 19 Mar 2008 17:10:27 +0100 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <47DFC681.7060009@op5.se> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <25F7CA25-4416-4F3D-BEFD-55730ACF259A@altinity.com> <47DFC681.7060009@op5.se> Message-ID: <20080319161027.GV49216870@CIS.FU-Berlin.DE> * Andreas Ericsson [2008-03-18 14:41]: > Ton Voon wrote: > > ./check_procs -u user -C command -c 1:1 > > ./check_procs -u user -C command --metric=VSZ -c 100000 > > ./check_procs -u user -C command --metric=CPU -c 30 > > Ordered arguments could solve this quite easily, with a command-line > looking like this: > > ./check_procs -u user -C command -c 1:1 --metric=VSZ -c 100000 --metric=CPU -c 30 > > although that's 11 chars longer than what you have below. 11 chars longer and less readable and more confusing, in my opinion. So: > Whoever invented the --metric thing should be shot. What's the problem with it? Holger From ton.voon at altinity.com Wed Mar 19 18:28:39 2008 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 19 Mar 2008 17:28:39 +0000 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <47E0E35C.7080407@aei.ca> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47DF5D6C.1000708@aei.ca> <62BFCC67-13AC-456D-A3DC-25C21EA026C4@altinity.com> <47DFC400.3070204@aei.ca> <9EFC67C1-A221-4CF1-8E48-E5FEBBABA04E@altinity.com> <47E0E35C.7080407@aei.ca> Message-ID: On 19 Mar 2008, at 09:56, Thomas Guyot-Sionnest wrote: > So I just got a totally different idea: what if we make the > thresholds a > set of parameters that can be processes by getsubopt? > > I haven't developed much this idea, but I'm thinking something like: > > check_stuff --metric > min=2,warn_max=5,crit_max=7,outside,uom_prefix=Ki,uom=b One way of looking at this problem is this: how can I fill in the data structure? Currently ranges and thresholds are defined as such (lib/utils_base.h): typedef struct range_struct { double start; int start_infinity; double end; int end_infinity; int alert_on; /* OUTSIDE (default) or INSIDE */ } range; typedef struct thresholds_struct { range *warning; range *critical; } thresholds; We'd need to add in a uom into the thresholds struct. Maybe add a char *name to thresholds as well. Range might need an "include_endpoints" field. With a slight amendment to your idea, we get: check_stuff --threshold name=time,warn=5:,crit=10:,uom=b So --threshold is the "standard" option to set thresholds. The name= sets which threshold. However, I can't see a simpler way of defining the range. Your example of 'outside' doesn't specify for warning or critical (I guess you could do outside=warn, but then that doesn't scale with the (future) list of ranges idea). In other words, we still need a concise way of specifying range. So this problem can be broken down into: - how to specify ranges - how to specify thresholds I'd argue that the range is best done as [^][start]:[end] (with maybe a change of the "outside" character, maybe a character to signify inclusion of endpoints). The other option for ranges is Max's mathematical notation: (I'm assuming the following rules: - the following operators are fine: <, <=, >, >= - the following syntax is fine (where Z is some number): {operator}Z - if you are defining a range of values (where Y and Z are numbers): Y{operator}x{operator}Z - a comma acts as a list in an AND fashion ) So: <=5 equates to :5 1<=x<=3 equates to 1:3 1=10 equates to 10: My feeling is that whatever is chosen, (1) there's an education issue that needs to happen, (2) someone is going to hate it. I actually think we might be able to support both these syntaxes, because as long as the parser breaks it down into the range struct, code at the plugin level should just work. Then the options for defining threshold are (ignoring uom for the moment): 1) --threshold-time=crit_range/warn_range 2) --threshold name=time,warn=range,crit=range 3) --threshold=time -w range -c range I like (1) and (2) because it is all stored in "the same place" - ie, one parameter defines 1 threshold. (1) is a bit more consise than (2), but (2) has benefit of extensibility. However, I actually like the look of (3), though it is harder to parse in the options handling code. Is it voting time yet? Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From dermoth at aei.ca Wed Mar 19 19:06:59 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 19 Mar 2008 14:06:59 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47DF5D6C.1000708@aei.ca> <62BFCC67-13AC-456D-A3DC-25C21EA026C4@altinity.com> <47DFC400.3070204@aei.ca> <9EFC67C1-A221-4CF1-8E48-E5FEBBABA04E@altinity.com> <47E0E35C.7080407@aei.ca> Message-ID: <47E15643.7020707@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/03/08 01:28 PM, Ton Voon wrote: > On 19 Mar 2008, at 09:56, Thomas Guyot-Sionnest wrote: > >> So I just got a totally different idea: what if we make the >> thresholds a >> set of parameters that can be processes by getsubopt? >> >> I haven't developed much this idea, but I'm thinking something like: >> >> check_stuff --metric >> min=2,warn_max=5,crit_max=7,outside,uom_prefix=Ki,uom=b > > [...] > > With a slight amendment to your idea, we get: > > check_stuff --threshold name=time,warn=5:,crit=10:,uom=b > > So --threshold is the "standard" option to set thresholds. The name= > sets which threshold. > > However, I can't see a simpler way of defining the range. Your example > of 'outside' doesn't specify for warning or critical (I guess you > could do outside=warn, but then that doesn't scale with the (future) > list of ranges idea). Is there's a real needs for a mix of inside and outside ranges in the same thresholds? If so then fine, but keep in mind that this feature alone make things much more complex. I see you didn't like my min/max specifications... It's quite simple though, and personally the only reason I'd avoid that would be to allow multiple warning/critical ranges for the dame metric. Another way to make is simple and possibly allow all the wanted feature so far would be to separate the warn and crit ranges: - --threshold name=cpu,type=warn,min=0,max=80,inside >> here inside would be useless unless there's also a default inside defined in in the same command and if (and only if) we want to allow multiple ranges, then the same metric could be repeated - --threshold name=strange-metric,type=warn,min=20,max=40,outside - --threshold name=strange-metric,type=warn,min=50,max=60,outside so here strange-metric is only valid if within 20 to 40 or 50 to 60 - --threshold name=strange-metric,type=warn,min=inf,max=20,inside - --threshold name=strange-metric,type=warn,min=40,max=50,inside - --threshold name=strange-metric,type=warn,min=60,max=inf,inside Here it would be similar but the actual exact values (20, 40, 50 and 60) would be critical as well, right? And if type= is omitted, default to crit. Again a name=defaults could set defaults. Also, the plugins that used to allow a list of thresholds could instead expect a list on consecutive names, like name=1,[...] name=2,[...] or name=oid1,[...] name=oid2,[...] Final suggestion, to avoid having to type --threshold multiple times, we could also allow [fill-in-word]-separated threshold parameter lists. imho good candidates for the separator would be space and semicolon (since we can't use the comma anymore). Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH4VZD6dZ+Kt5BchYRAoeXAJ9DpTU6k4WNapZUZVav0DSyvGk09wCgjAtI 9lcbMkqoZjrvlg9AqHElLs0= =p7qi -----END PGP SIGNATURE----- From perldork at webwizarddesign.com Wed Mar 19 22:48:54 2008 From: perldork at webwizarddesign.com (Max) Date: Wed, 19 Mar 2008 17:48:54 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <47E15643.7020707@aei.ca> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47DF5D6C.1000708@aei.ca> <62BFCC67-13AC-456D-A3DC-25C21EA026C4@altinity.com> <47DFC400.3070204@aei.ca> <9EFC67C1-A221-4CF1-8E48-E5FEBBABA04E@altinity.com> <47E0E35C.7080407@aei.ca> <47E15643.7020707@aei.ca> Message-ID: Thomas, Ton, Do both of you think that using RPN-style notation would be too burdensome on users? It resolves a lot of the issues you are discussing and meets Andreas' request to have argument parsing done in a fashion that doesn't cause compatibility issues with buggy / problematic shells ... CPU check ... --warning 'kernel,80%,gte,system,90%,gte' --critical 'system,99%,gt' Range check --warning 'bpm,60,120,notwithin' where order is metric,number[,number]?,operator Something along those lines? - Max From noreply at sourceforge.net Thu Mar 20 07:02:19 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Mar 2008 23:02:19 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1920671 ] check_dig incorrect cmdline help info Message-ID: Bugs item #1920671, was opened at 2008-03-20 08:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1920671&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: snapshot tarball Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ville Mattila (vmattila) Assigned to: Nobody/Anonymous (nobody) Summary: check_dig incorrect cmdline help info Initial Comment: Problem description: Current version of check_dig prints incorrect long argument name '--lookup' for the option '-l'. Correct one the plugin recognizes is '--query_address'. A patch for fixing this in plugins/check_dig.c is attached. Plugin Version (-V output): v1943 (nagios-plugins 1.4.11) Plugin Name: check_dig Plugin Commandline showing issues: check_dig -h ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1920671&group_id=29880 From dermoth at aei.ca Thu Mar 20 12:09:45 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 20 Mar 2008 07:09:45 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47DF5D6C.1000708@aei.ca> <62BFCC67-13AC-456D-A3DC-25C21EA026C4@altinity.com> <47DFC400.3070204@aei.ca> <9EFC67C1-A221-4CF1-8E48-E5FEBBABA04E@altinity.com> <47E0E35C.7080407@aei.ca> <47E15643.7020707@aei.ca> Message-ID: <47E245F9.1090507@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/03/08 05:48 PM, Max wrote: > Thomas, Ton, > > Do both of you think that using RPN-style notation would be too > burdensome on users? It resolves a lot of the issues you are > discussing and meets Andreas' request to have argument parsing done in > a fashion that doesn't cause compatibility issues with buggy / > problematic shells ... > > CPU check ... > > --warning 'kernel,80%,gte,system,90%,gte' --critical 'system,99%,gt' > > Range check > > --warning 'bpm,60,120,notwithin' > > where order is > > metric,number[,number]?,operator > > Something along those lines? Well, if you want something like that why not making it like my suggestion which: 1. is a bit clearer: just like your example but using name=value pairs instead of values alone 2. Is a standard way of specifying parameters, and is parseable using standard libraries. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH4kX56dZ+Kt5BchYRAkpQAKCdTYzNDqxoKPwW0EOcNvQ3Dv3dSwCffPqf DK2t0Nv5r0vp7aKkyYHgRc0= =7nJO -----END PGP SIGNATURE----- From noreply at sourceforge.net Thu Mar 20 12:54:54 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Mar 2008 04:54:54 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1920671 ] check_dig incorrect cmdline help info Message-ID: Bugs item #1920671, was opened at 2008-03-20 02:02 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1920671&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: snapshot tarball >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Ville Mattila (vmattila) Assigned to: Nobody/Anonymous (nobody) Summary: check_dig incorrect cmdline help info Initial Comment: Problem description: Current version of check_dig prints incorrect long argument name '--lookup' for the option '-l'. Correct one the plugin recognizes is '--query_address'. A patch for fixing this in plugins/check_dig.c is attached. Plugin Version (-V output): v1943 (nagios-plugins 1.4.11) Plugin Name: check_dig Plugin Commandline showing issues: check_dig -h ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-03-20 07:54 Message: Logged In: YES user_id=375623 Originator: NO this problem is now fixed in svn. thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1920671&group_id=29880 From noreply at sourceforge.net Thu Mar 20 13:13:17 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Mar 2008 05:13:17 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1920973 ] check_disk is not using statvfs64 structure (patch inc) Message-ID: Bugs item #1920973, was opened at 2008-03-20 13:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1920973&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Vincent Alloo (valloo99) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk is not using statvfs64 structure (patch inc) Initial Comment: --SSH-- > ./check_disk --version check_disk v1793 (nagios-plugins 1.4.10) --SSH-- > uname -a SunOS xxx 5.10 Generic_127112-07 i86pc i386 i86pc check_disk is failing on file system > 1TB. --SSH-- > ./check_disk -w 10 -c 5 -p /pooldbnbu DISK OK - free space: /pooldbnbu 4332308954993 MB (0% inode=-208438065308%);| /pooldbnbu=-2147483648MB;-2147483648;-2147483648;0;-2147483648 This can be solved by modifying gl/fusage.c (using statvfs64 type): get_fs_usage (char const *file, char const *disk, struct fs_usage *fsp) { #if defined STAT_STATVFS /* POSIX */ struct statvfs64 fsd; if (statvfs64 (file, &fsd) < 0) return -1; /* f_frsize isn't guaranteed to be supported. */ fsp->fsu_blocksize = (fsd.f_frsize ? PROPAGATE_ALL_ONES (fsd.f_frsize) : PROPAGATE_ALL_ONES (fsd.f_bsize)); Result is now: --SSH-- > ./check_disk -w 10 -c 5 -p /pooldbnbu DISK OK - free space: /pooldbnbu 1239417 MB (57% inode=99%);| /pooldbnbu=921731MB;2161139;2161144;0;2161149 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1920973&group_id=29880 From perldork at webwizarddesign.com Thu Mar 20 13:31:54 2008 From: perldork at webwizarddesign.com (Max) Date: Thu, 20 Mar 2008 08:31:54 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <47E245F9.1090507@aei.ca> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47DF5D6C.1000708@aei.ca> <62BFCC67-13AC-456D-A3DC-25C21EA026C4@altinity.com> <47DFC400.3070204@aei.ca> <9EFC67C1-A221-4CF1-8E48-E5FEBBABA04E@altinity.com> <47E0E35C.7080407@aei.ca> <47E15643.7020707@aei.ca> <47E245F9.1090507@aei.ca> Message-ID: > Well, if you want something like that why not making it like my > suggestion which: > > 1. is a bit clearer: just like your example but using name=value pairs > instead of values alone > 2. Is a standard way of specifying parameters, and is parseable using > standard libraries. > Well, if you want something like that why not making it like my > suggestion which: > > 1. is a bit clearer: just like your example but using name=value pairs > instead of values alone > 2. Is a standard way of specifying parameters, and is parseable using > standard libraries. --threshold name=cpu,type=warn,min=0,max=80,inside uom_prefix=Ki,uom=b This certainly is very readable, is there a need for uom or uom_prefix? Isn't it as maintainable to use suffixes on min and max to ask for types and a little less typing Instead of --threshold name=cpu,type=warn,min=0,max=80,oum_prefix=Ki,uom=b We get --threshold name=cpu,type=warn,min=0KB,max=80,gt If min or max specifies a suffix, that becomes the type .. if both specify suffixes that don't match, throw an error The thing I like about using --warning and --critical still is that the focus of a threshold is what kind of alert it will trigger as that is the focus of a threshold, yes? :) using that and integrating your style we would get --warning name=system,max=90 --warning name=nice,max=99 --critical name=system,max=100 and if we use the threshold type as the argument then we can eliminate the name= part and get --warning system,max=90 --critical user,max=95 which can then lead to complex conditionals if needed, still easy to parse --warning system,max=80,min=0,range=inside,AND,user,max=80 --critical system,max=98,OR,user,max=98 If UOM is assumed to be at the end of a min or max (if both are specified and do not match, the library would throw an error) then we reduce the fields needed. and this way the only time a condition type has to be specified is when a min and max are present this is all still much more verbose than just using RPN :), parsing RPN is a simple matter and there are lots of libraries available to do that --warning system,90,gt,nice,90,gt,AND To me the RPN style is easy to read and minimizes typing and the specification is simple SPEC = THRESHOLD1,THRESHOLDN,boolean THRESHOLD = metric,number[uom],[number[uom]],conditional Another idea is to not use RPN but a similar style --warning system,gt,90 --warning system,gt,90,AND,user,gt,90 Similar style and gets rid of the RPN while avoiding special characters that could be misinterpreted by shells, including spaces - Max From noreply at sourceforge.net Thu Mar 20 13:59:57 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Mar 2008 05:59:57 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1920973 ] check_disk is not using statvfs64 structure (patch inc) Message-ID: Bugs item #1920973, was opened at 2008-03-20 12:13 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1920973&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Vincent Alloo (valloo99) >Assigned to: Ton Voon (tonvoon) Summary: check_disk is not using statvfs64 structure (patch inc) Initial Comment: --SSH-- > ./check_disk --version check_disk v1793 (nagios-plugins 1.4.10) --SSH-- > uname -a SunOS xxx 5.10 Generic_127112-07 i86pc i386 i86pc check_disk is failing on file system > 1TB. --SSH-- > ./check_disk -w 10 -c 5 -p /pooldbnbu DISK OK - free space: /pooldbnbu 4332308954993 MB (0% inode=-208438065308%);| /pooldbnbu=-2147483648MB;-2147483648;-2147483648;0;-2147483648 This can be solved by modifying gl/fusage.c (using statvfs64 type): get_fs_usage (char const *file, char const *disk, struct fs_usage *fsp) { #if defined STAT_STATVFS /* POSIX */ struct statvfs64 fsd; if (statvfs64 (file, &fsd) < 0) return -1; /* f_frsize isn't guaranteed to be supported. */ fsp->fsu_blocksize = (fsd.f_frsize ? PROPAGATE_ALL_ONES (fsd.f_frsize) : PROPAGATE_ALL_ONES (fsd.f_bsize)); Result is now: --SSH-- > ./check_disk -w 10 -c 5 -p /pooldbnbu DISK OK - free space: /pooldbnbu 1239417 MB (57% inode=99%);| /pooldbnbu=921731MB;2161139;2161144;0;2161149 ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2008-03-20 12:59 Message: Logged In: YES user_id=664364 Originator: NO Hi Vincent, I think has been fixed already. Can you try the snapshot at http://nagiosplug.sf.net/snapshot? This will be in the upcoming 1.4.12 release. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1920973&group_id=29880 From noreply at sourceforge.net Thu Mar 20 14:13:11 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Mar 2008 06:13:11 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1920973 ] check_disk is not using statvfs64 structure (patch inc) Message-ID: Bugs item #1920973, was opened at 2008-03-20 13:13 Message generated for change (Comment added) made by valloo99 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1920973&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Vincent Alloo (valloo99) Assigned to: Ton Voon (tonvoon) Summary: check_disk is not using statvfs64 structure (patch inc) Initial Comment: --SSH-- > ./check_disk --version check_disk v1793 (nagios-plugins 1.4.10) --SSH-- > uname -a SunOS xxx 5.10 Generic_127112-07 i86pc i386 i86pc check_disk is failing on file system > 1TB. --SSH-- > ./check_disk -w 10 -c 5 -p /pooldbnbu DISK OK - free space: /pooldbnbu 4332308954993 MB (0% inode=-208438065308%);| /pooldbnbu=-2147483648MB;-2147483648;-2147483648;0;-2147483648 This can be solved by modifying gl/fusage.c (using statvfs64 type): get_fs_usage (char const *file, char const *disk, struct fs_usage *fsp) { #if defined STAT_STATVFS /* POSIX */ struct statvfs64 fsd; if (statvfs64 (file, &fsd) < 0) return -1; /* f_frsize isn't guaranteed to be supported. */ fsp->fsu_blocksize = (fsd.f_frsize ? PROPAGATE_ALL_ONES (fsd.f_frsize) : PROPAGATE_ALL_ONES (fsd.f_bsize)); Result is now: --SSH-- > ./check_disk -w 10 -c 5 -p /pooldbnbu DISK OK - free space: /pooldbnbu 1239417 MB (57% inode=99%);| /pooldbnbu=921731MB;2161139;2161144;0;2161149 ---------------------------------------------------------------------- >Comment By: Vincent Alloo (valloo99) Date: 2008-03-20 14:13 Message: Logged In: YES user_id=1977333 Originator: YES You're correct, it is fixed. Sorry for duplicate bug :) --SSH-- > pwd /home/valloo/nagios/nagios-plugins-trunk-200803201300/plugins --SSH-- > ././check_disk --version check_disk v1933 (nagios-plugins 1.4.11) --SSH-- > ./check_disk -w 10 -c 5 -p /pooldbnbu DISK OK - free space: /pooldbnbu 1239417 MB (57% inode=99%);| /pooldbnbu=921731MB;2161139;2161144;0;2161149 ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2008-03-20 13:59 Message: Logged In: YES user_id=664364 Originator: NO Hi Vincent, I think has been fixed already. Can you try the snapshot at http://nagiosplug.sf.net/snapshot? This will be in the upcoming 1.4.12 release. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1920973&group_id=29880 From ae at op5.se Thu Mar 20 14:14:59 2008 From: ae at op5.se (Andreas Ericsson) Date: Thu, 20 Mar 2008 14:14:59 +0100 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <25F7CA25-4416-4F3D-BEFD-55730ACF259A@altinity.com> <47DFC681.7060009@op5.se> <47E0F64C.20102@op5.se> <47E1136F.7000903@op5.se> Message-ID: <47E26353.9040907@op5.se> Max wrote: > On Wed, Mar 19, 2008 at 9:21 AM, Andreas Ericsson wrote: >> So what do we do with users running Nagios on AIX? Tell them to go >> screw themselves, because "oh look, we've thought up this wonderful >> new way of specifying critical and warning ranges at the same time"? > > Ok, of course not, thanks for sharing, would be nice to drop the > constant sarcasm, it gets in the way of your points. > > So we can't use these characters then either: > ^ - old shells use this as pipe > ~ - some shells use this for regexp matching True. > = - forget to quote and doh, we are setting shell variables now Only if it appears immediately after the first shell-word with no whitespace in between. Iow, it would be stupid to name a plugin check=foo, but it's quite alright to let it take = as an argument. > ; > | > & > True. > So are we left with an RPN style notation to ensure that this works > across all OSes .. like RRD, with multiple warn and critical switches > accepted to help with readability, maybe? > > --warning 15min,15.00,gt --warning 1min,5.00,gte --critical > 15min,30,gt,10min,5,gt > Something like that, yes, although I could imagine it being something like check_proc --cpu w=60%,c=80% for the non-ranged case. Note that --disk w=20%,c=10% will probably want its arguments to mean the exact inverse (ie, alert when below), so the API needs to be flexible enough to let it specify a preference, or possibly figure it out on its own (if C < W, low values are bad). > > That would at least be something many users (no Andreas, not all, not > beginners either) have used and something that is well documented. > >> For the future; it's a good idea to see what other semi-similar programs >> are doing. For the record, I can't think of a single cli program that >> requires shell characters in its command line. > > sed > awk > sed and awk are script languages. Not Turing-complete, but still languages. Perl uses pretty much every shell-character in the world too (come to think of it, it probably imports shell-chars from the entire galaxy), but neither you nor me mentioned that. Besides that, neither sed nor awk *requires* shell characters in its command line. > Yes, not for options, but they often are pipelined and have syntax > that requires quotes. > Pipelines are set up by the shell, so this argument just proves my point. Thanks. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ae at op5.se Thu Mar 20 14:23:50 2008 From: ae at op5.se (Andreas Ericsson) Date: Thu, 20 Mar 2008 14:23:50 +0100 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <25F7CA25-4416-4F3D-BEFD-55730ACF259A@altinity.com> <47DFC681.7060009@op5.se> <0AC471B9-F76A-4290-8BF2-9A549E92497A@altinity.com> <47E12A48.7070100@op5.se> Message-ID: <47E26566.5020607@op5.se> Max wrote: > On Wed, Mar 19, 2008 at 10:59 AM, Andreas Ericsson wrote: >> Not really. Verbose and easy to read should win out any time, as the >> syntax isn't supposed to be used daily. It's much more important that >> it's accurate and that the user is comfortable with the thresholds >> he/she has specified than that it's possible to cram as many args as >> possible into an 80 char wide screen. > > What are your suggestions, Andreas? You have given a lot of feedback > on what you like and do not like, what syntax do you suggest? > See the other fork in this thread. > >> I am, in the strongest possible terms. For one simple reason: Bitrot. > > Let usage show who wins, provide a few parsing options, see which gets > used the most and then drop the others as officially supported and let > people from the Nagios user community support them if they are wanted. > Except for one rather large problem there; Content users usually keep their voices down, while the angry ones voice their complaints. So we go with two sets of options, then remove one because we guess (or even do it properly and set up a user-survey) to see which one is most popular. Then we remove the other and find that there were thousands of users who now got bitten because their configurations stopped working all of a sudden. They'll all come to nagiosplug-help@ (or nagios-users@) to ask/complain/spew gaul/whatever, and someone will have to deal with that. > >> Not stupid, but naive if you think that both of them will be kept up >> to date, along with the documentation for both of them. Like I said, >> it's maintenance nightmare to support two different ways of saying the >> same thing, and doubly so if you want users to know about it. > > I do think that if their is enthusiasm among Nagios users to keep them > up, they will be kept up and Nagios is all about choice - flexible > syntax, loads of add-ons and enhancements and points of integration. > Perhaps there is enthusiasm, but most of the plugin users are admins, not programmers. If we were catering to kernel hackers, I wouldn't be worried at all, but we're not. > No one would expect you to maintain them, you do not think there are > enough Nagios plugin writers available to support two parsers? > That's exactly what I think, because you can't even add options to a plugin then without having to know both parsers enough to add a way to set those options for the plugins in either way. I believe this raises the itch-to-contribution barrier significantly, and as such it will only do the plugins project harm. >> What about use? > > I agree, present a few options and let 'use' decide which wins in the long term > *sigh* There will still have to be flag-days for when we deprecate the old syntax (in plugins-2.0, I expect, as it will no longer be backwards compatible), and then it'll have to be a new major release when we drop support for whichever way of specifying arguments happened to not win. Ton, are you up for doing 2 flagdays in one year, or even half a year, with all the user-hassle it usually means? op5 will probably help writing conversion scripts for peoples configurations, but if we're the only ones that do that, we'll effectively end up picking the "most popular syntax", so that's an entirely new dilemma right there. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From noreply at sourceforge.net Thu Mar 20 14:25:15 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Mar 2008 06:25:15 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1920973 ] check_disk is not using statvfs64 structure (patch inc) Message-ID: Bugs item #1920973, was opened at 2008-03-20 12:13 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1920973&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Vincent Alloo (valloo99) Assigned to: Ton Voon (tonvoon) Summary: check_disk is not using statvfs64 structure (patch inc) Initial Comment: --SSH-- > ./check_disk --version check_disk v1793 (nagios-plugins 1.4.10) --SSH-- > uname -a SunOS xxx 5.10 Generic_127112-07 i86pc i386 i86pc check_disk is failing on file system > 1TB. --SSH-- > ./check_disk -w 10 -c 5 -p /pooldbnbu DISK OK - free space: /pooldbnbu 4332308954993 MB (0% inode=-208438065308%);| /pooldbnbu=-2147483648MB;-2147483648;-2147483648;0;-2147483648 This can be solved by modifying gl/fusage.c (using statvfs64 type): get_fs_usage (char const *file, char const *disk, struct fs_usage *fsp) { #if defined STAT_STATVFS /* POSIX */ struct statvfs64 fsd; if (statvfs64 (file, &fsd) < 0) return -1; /* f_frsize isn't guaranteed to be supported. */ fsp->fsu_blocksize = (fsd.f_frsize ? PROPAGATE_ALL_ONES (fsd.f_frsize) : PROPAGATE_ALL_ONES (fsd.f_bsize)); Result is now: --SSH-- > ./check_disk -w 10 -c 5 -p /pooldbnbu DISK OK - free space: /pooldbnbu 1239417 MB (57% inode=99%);| /pooldbnbu=921731MB;2161139;2161144;0;2161149 ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2008-03-20 13:25 Message: Logged In: YES user_id=664364 Originator: NO No problem. Thanks for reporting. Closing this call. ---------------------------------------------------------------------- Comment By: Vincent Alloo (valloo99) Date: 2008-03-20 13:13 Message: Logged In: YES user_id=1977333 Originator: YES You're correct, it is fixed. Sorry for duplicate bug :) --SSH-- > pwd /home/valloo/nagios/nagios-plugins-trunk-200803201300/plugins --SSH-- > ././check_disk --version check_disk v1933 (nagios-plugins 1.4.11) --SSH-- > ./check_disk -w 10 -c 5 -p /pooldbnbu DISK OK - free space: /pooldbnbu 1239417 MB (57% inode=99%);| /pooldbnbu=921731MB;2161139;2161144;0;2161149 ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2008-03-20 12:59 Message: Logged In: YES user_id=664364 Originator: NO Hi Vincent, I think has been fixed already. Can you try the snapshot at http://nagiosplug.sf.net/snapshot? This will be in the upcoming 1.4.12 release. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1920973&group_id=29880 From dermoth at aei.ca Thu Mar 20 14:47:09 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 20 Mar 2008 09:47:09 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47DF5D6C.1000708@aei.ca> <62BFCC67-13AC-456D-A3DC-25C21EA026C4@altinity.com> <47DFC400.3070204@aei.ca> <9EFC67C1-A221-4CF1-8E48-E5FEBBABA04E@altinity.com> <47E0E35C.7080407@aei.ca> <47E15643.7020707@aei.ca> <47E245F9.1090507@aei.ca> Message-ID: <47E26ADD.4040909@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20/03/08 08:31 AM, Max wrote: >> Well, if you want something like that why not making it like my >> suggestion which: >> >> 1. is a bit clearer: just like your example but using name=value pairs >> instead of values alone >> 2. Is a standard way of specifying parameters, and is parseable using >> standard libraries. > >> Well, if you want something like that why not making it like my >> suggestion which: >> >> 1. is a bit clearer: just like your example but using name=value pairs >> instead of values alone >> 2. Is a standard way of specifying parameters, and is parseable using >> standard libraries. > > --threshold name=cpu,type=warn,min=0,max=80,inside > > uom_prefix=Ki,uom=b > > This certainly is very readable, is there a need for uom or > uom_prefix? Isn't it as maintainable to use suffixes on min and max > to ask for types and a little less typing > > Instead of > > --threshold name=cpu,type=warn,min=0,max=80,oum_prefix=Ki,uom=b > > We get > > --threshold name=cpu,type=warn,min=0KB,max=80,gt The former is easier to parse. uom shouldn't be needed in most cases because the plugin knows what it gets, and uom_prefix is optional, letting the plugin choose what prefix is best. Also mixing uom and uom_prefix it risky because you could end up with corner cases where there's no way to determine what is uom and what is uom_prefix (this is especially true with 2-byte prefixes like Ki (kibibytes) and the fact that uom_prefix is optionnal). > If min or max specifies a suffix, that becomes the type .. if both > specify suffixes that don't match, throw an error > > The thing I like about using --warning and --critical still is that > the focus of a threshold is what kind of alert it will trigger as that > is the focus of a threshold, yes? :) using that and integrating your > style we would get > > --warning name=system,max=90 --warning name=nice,max=99 --critical > name=system,max=100 > > and if we use the threshold type as the argument then we can eliminate > the name= part and get > > --warning system,max=90 --critical user,max=95 > > which can then lead to complex conditionals if needed, still easy to parse > > --warning system,max=80,min=0,range=inside,AND,user,max=80 --critical > system,max=98,OR,user,max=98 I agree that would be great, but there's no easy way to keep backwards compatibility if we re-use -w and -c. Ideally in two different big release we should first add support for the new thresholds format so that people could change their config to the new format, then remove support for the old one. Considering that the transitional release will fill in the same threshold structs, we could possibly write a "reverse thresholds" function that allow printing thresholds in verbose mode, so that users could just run their plugin in verbose mode to find the new argument format. > If UOM is assumed to be at the end of a min or max (if both are > specified and do not match, the library would throw an error) then we > reduce the fields needed. > > and this way the only time a condition type has to be specified is > when a min and max are present > > this is all still much more verbose than just using RPN :), parsing > RPN is a simple matter and there are lots of libraries available to do > that > > --warning system,90,gt,nice,90,gt,AND > > To me the RPN style is easy to read and minimizes typing and the > specification is simple I came across this format with RRDTools, but I don't know many people who actually know it. Even after having built a few RPNs I'm still confused when I come across complex ones. IMHO using RPNs will only increase the gap between "power-users" and normal users. I believe there's many people that are very comfortable with RPN because they learned it at school, while for all the others it's something they'll likely never fully understand. > SPEC = THRESHOLD1,THRESHOLDN,boolean > THRESHOLD = metric,number[uom],[number[uom]],conditional > > Another idea is to not use RPN but a similar style > > --warning system,gt,90 > > --warning system,gt,90,AND,user,gt,90 > > Similar style and gets rid of the RPN while avoiding special > characters that could be misinterpreted by shells, including spaces Then again you miss out the point of using RPNs or option-strings. I believe a better approach would be the obviousness threshold ranges. Any range can trigger an alert and multiple non-overlapping ranges can be made. An alternative to the min and max could be a simple range too. I.e.: name=cpu,warn=0:90,outside or(since cpu % can't be under 0 anyways): name=cpu,warn=:90,outside Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH4mrc6dZ+Kt5BchYRAob7AJ45oxuaZFnE998v1F+BTcDq61MoZQCgtSh3 I3QDZKSuGKXkSdSvqWJpemU= =3odp -----END PGP SIGNATURE----- From ton.voon at altinity.com Thu Mar 20 15:46:54 2008 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 20 Mar 2008 14:46:54 +0000 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> Message-ID: <69B57AD2-4841-47BA-872E-E56ECA2FF8BB@altinity.com> Hi! I've committed a branch of nagiosplug with check_procs taking --rss- threshold=[warn_range]/[crit_range] style threshold values. The --help output is reflected (as whatever new style thresholds should be the recommended approach). This is backwards compatible - the test suite for existing functionality works as expected, although the output is slightly different. An interesting thing I've observed is that it is possible to get 3 alerts for only 1 process: ./check_procs -C cron --number=^1:1 --rss-threshold=0: --vsz- threshold=0: --cpu-threshold=-1: I can't decide what is the best way of summarising the problem (was it the vsz or the cpu that alerted?). It means that the way of looking at a plugin is to consider the thresholds as the most important thing, rather than the things being measured - I don't know, I haven't quite got my head around it yet. You can use -v -v to get info about which thresholds were crossed (multi-line - needs Nagios 3!). Also, I've been thinking about the specification of ranges and I've come to the conclusion that my concise notation is arcane. But regular expressions are arcane too - yet you have to learn it if you want to use them. But I think, for the most common cases, my proposed range definition is suitable. Snapshot of this branch is here: http://resources.opsview.org/ton/nagios-plugins-branch-200803191456.tar.gz Comments? Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From ae at op5.se Thu Mar 20 16:35:17 2008 From: ae at op5.se (Andreas Ericsson) Date: Thu, 20 Mar 2008 16:35:17 +0100 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <47E26ADD.4040909@aei.ca> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47DF5D6C.1000708@aei.ca> <62BFCC67-13AC-456D-A3DC-25C21EA026C4@altinity.com> <47DFC400.3070204@aei.ca> <9EFC67C1-A221-4CF1-8E48-E5FEBBABA04E@altinity.com> <47E0E35C.7080407@aei.ca> <47E15643.7020707@aei.ca> <47E245F9.1090507@aei.ca> <47E26ADD.4040909@aei.ca> Message-ID: <47E28435.4090304@op5.se> Thomas Guyot-Sionnest wrote: > there's no way to determine what is uom and what is uom_prefix (this is > especially true with 2-byte prefixes like Ki (kibibytes) and the fact > that uom_prefix is optionnal). > Actually, Ki is short for "binary kilo". Bytes (B) or bits (b) is still the uom. I'm really, really against forcing users to have to learn about the difference between Kb (kilobit, used to measure network bandwidth), KiB (binary kilobyte, used to measure HDD's from the 80's), and KB (non-binary kilobyte, used to measure disk capacity when talking to disk vendors.....) Otoh, It can probably be gleaned from context in most of the cases. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From nathan.vonnahme at bannerhealth.com Thu Mar 20 18:29:06 2008 From: nathan.vonnahme at bannerhealth.com (Vonnahme, Nathan) Date: Thu, 20 Mar 2008 09:29:06 -0800 Subject: [Nagiosplug-devel] Nagios::Plugin with scientific notation In-Reply-To: <42CE1B1C-A524-4DB5-AAD1-D77356D1C0E8@altinity.com> References: <077F1B782014ED48A58E7927914D36A00457683A@fai01500.bhs.bannerhealth.com> <42CE1B1C-A524-4DB5-AAD1-D77356D1C0E8@altinity.com> Message-ID: <077F1B782014ED48A58E7927914D36A004601B17@fai01500.bhs.bannerhealth.com> > On 13 Mar 2008, at 17:19, Vonnahme, Nathan wrote: > > > Larry Wall said in one of his State of the Onion speeches that it's > > better for programs (and also community members) to be "generous in > > what > > you accept for input and strict in what you produce as output". > > That's a good principle. I guess that means anything parsing the perf > data should cater for scientific notation, but the plugins should only > return a certain format. That sounds like too much work for a small set of cases. I think it would suffice for parsers to produce a polite error message when they detect scientific notation (or anything else they can't handle). > > In which case, what is the precision? Can we say at the time of > printing the value, it is something like: > > $value_as_text = sprintf("%.5f", $value); > $value_as_text =~ s/0+$/; # Remove trailing zeros > $value_as_text =~ s/\.$/; # Remove trailing separator > > Hmmm, different languages have different separators, so do we state > that the value will come from the POSIX locale? (decimal point is a > dot, no 'thousands' grouping). > > I'm thinking that the performance data doesn't need to be much more > precise than this - Nagios plugin performance data is guidance, not > exact. That should be plenty of precision, but I'd suggest deferring localization to somewhere closer to the user interface layer (in this case, the web CGIs and the notification scripts). I doubt if any of the existing plugins produce localized output, and in a way, producing differently punctuated output in different environments is the opposite of being "strict". -n From nathan.vonnahme at bannerhealth.com Thu Mar 20 20:39:19 2008 From: nathan.vonnahme at bannerhealth.com (Vonnahme, Nathan) Date: Thu, 20 Mar 2008 11:39:19 -0800 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47DF5D6C.1000708@aei.ca> <62BFCC67-13AC-456D-A3DC-25C21EA026C4@altinity.com> <47DFC400.3070204@aei.ca><9EFC67C1-A221-4CF1-8E48-E5FEBBABA04E@altinity.com><47E0E35C.7080407@aei.ca> Message-ID: <077F1B782014ED48A58E7927914D36A004601B94@fai01500.bhs.bannerhealth.com> Even in 2008, Outlook badly quotes: > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- > devel-bounces at lists.sourceforge.net] On Behalf Of Ton Voon > Sent: Wednesday, March 19, 2008 9:29 AM > So this problem can be broken down into: > - how to specify ranges > - how to specify thresholds I like Ton's proposal (and the fact that he has written code to implement it!), but I think it's still a little confusing. When I first started working with plugins (especially trying to write my own with N::P), I was confused about 2 things, which correspond to the two parts of the problem: First, many of the plugins assume the numbers you're giving them are maximums (x), but secretly they are always translated into ranges (-infinity .. x). Ton's range syntax (min:max) does as well as any at expressing the ranges, and it would be good to replace the implicit ranges (x secretly means -infinity..x) with explicit ones to keep readers and writers of plugin args straight. But the second, and most ambiguous part of the old (and still the new) syntax is whether the range you're defining constitutes "normal" or "abnormal". If you're looking at one of the above definitions for the first time, is that clear? When I first started messing with plugins, the inside/outside and OK/warning/critical meanings of the ranges kept flipflopping in my brain, and I ended up writing a bunch of tests in Perl to figure it out. Part of it is that it's natural to think sometimes in terms of the normal range, and sometimes in terms of the abnormal range(s). What you might mean, in English, is something like: Get this URL. Warn me if it's over 1 day old or too big. But it's critical if it is too small or produces an HTTP error code or the check fails, or it takes over 5 seconds to get the response. You could also express it like this: Get this URL. It's OK for it to return a HTTP 200 code (it's CRITICAL otherwise) and be less than 1 day old (just WARN me if it's over 1 day old; it's never CRITICAL) and be between 300 and 500 bytes (I mean, WARN me if it's over 500 but it's CRITICAL if it's under 300) and take less than 5 seconds to respond (otherwise it's CRITICAL) How do we clearly communicate that to the plugin we're running? It looks like, under Ton's RFC, in the interest of "convention over configuration", the plugins assume: * you're giving it the abnormal range for each check ["alert is raised if value is inside start and end range (inclusive of endpoints)"] * but you can specify the OK range by negating the range with ^. The ^ flips whether you're defining the normal or abnormal range. so if I've got Ton's RFC right, I could express the above this way: check_http -H $HOSTADDRESS$ --size=:300/500:b --age=/1:d --time=5:s or alternatively, check_http -H $HOSTADDRESS$ --size=^300:500/500:b --age=/^0:1d --time=^0:5s Maybe I'm warped by using the ok() style test functions in Perl, but the first way seems backwards. The second way (defining "normal") makes more sense, so when reading or writing the arguments I keep forgetting whether I'm telling it "normal" or "abnormal". Also, it is usually better to enumerate the "good" results and flag abnormal exceptions than to try to enumerate badness (See `perldoc perlsec` or http://www.ranum.com/security/computer_security/editorials/dumb/). So I'd like to suggest less ambiguous option names and three more conventions: 1. we start by defining "normal" (OK), and assume everything else is CRITICAL 2. we have to explicitly differentiate between CRITICAL and "just" WARNING 3. we always explicitly write both sides of the range so it looks like a range (x:y) instead of a number with weird punctuation (x: or :y) So a sample syntax would be: check_http -H $HOSTADDRESS$ \ --size_ok=300:500b --size_warn=500b:inf \ # (but infb seems problematic) --age_ok=0:1d --age_warn=1d:inf \ # (same with infd) --time_ok=0:5s That seems more readable to me; does anyone else think so? The location of "ok"/"warn" is negotiable; it would also work to do --size=ok(300:500b),warn(500b:inf) or maybe --size=ok(300:500),warn(500:inf),bytes or --size=ok(300:500,bytes),warn(500:inf,bytes) --time=ok(0:5,seconds) Which is getting quite languageish actually. Even though these suggestions would mean a few more characters to type, I would be more likely to write it correctly the first time, which is the real time saver :) I guess a side effect is that inversion (which could still use ^ or how about "not" or "outside", e.g. --size=ok(not 3:5) ) would be rare, and the critical threshold would not ever need to be explicitly defined but would be secretly calculated by inverting the OK definition, and then the warning threshold defined independently. -n From ton.voon at altinity.com Thu Mar 20 22:07:18 2008 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 20 Mar 2008 21:07:18 +0000 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <077F1B782014ED48A58E7927914D36A004601B94@fai01500.bhs.bannerhealth.com> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47DF5D6C.1000708@aei.ca> <62BFCC67-13AC-456D-A3DC-25C21EA026C4@altinity.com> <47DFC400.3070204@aei.ca><9EFC67C1-A221-4CF1-8E48-E5FEBBABA04E@altinity.com><47E0E35C.7080407@aei.ca> <077F1B782014ED48A58E7927914D36A004601B94@fai01500.bhs.bannerhealth.com> Message-ID: On 20 Mar 2008, at 19:39, Vonnahme, Nathan wrote: > 1. we start by defining "normal" (OK), and assume everything > else is CRITICAL I'm still digesting what you've written, but I just had to say: brilliant. Defining OK ranges is going to be the biggest thing to aid comprehension. Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From perldork at webwizarddesign.com Fri Mar 21 13:05:30 2008 From: perldork at webwizarddesign.com (Max) Date: Fri, 21 Mar 2008 08:05:30 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47DF5D6C.1000708@aei.ca> <62BFCC67-13AC-456D-A3DC-25C21EA026C4@altinity.com> <47DFC400.3070204@aei.ca> <9EFC67C1-A221-4CF1-8E48-E5FEBBABA04E@altinity.com> <47E0E35C.7080407@aei.ca> <077F1B782014ED48A58E7927914D36A004601B94@fai01500.bhs.bannerhealth.com> Message-ID: On Thu, Mar 20, 2008 at 5:07 PM, Ton Voon wrote: > > On 20 Mar 2008, at 19:39, Vonnahme, Nathan wrote: > > > 1. we start by defining "normal" (OK), and assume everything > > else is CRITICAL > > I'm still digesting what you've written, but I just had to say: > brilliant. > > Defining OK ranges is going to be the biggest thing to aid > comprehension I agree with the usefulness of this and readability of this, very nice. I am not sold on the value of having ranges have to state negative or positive infinity explicitly. I think that should be optional but not required. I understand from an implementation standpoint that having it manditory makes parsing arguments easier, though only slightly. >From a readability standpoint, I think fewer people are used to seeing infinity explicitly stated and represented as a token than they are having it be assumed by an expression. I do really like the readability of warn(), ok(), critical() and I like having UOM as a suffix; I would not see any developer or plugin writer, regardless of skill, getting confused about whether he or she has to put a UOM on infinity :). I would also make ok() optional as there are plenty of use cases for plugins where just defining exceptions and having what is normal implied by the exceptions is more intuitive. Your suggestion does use characters that would be interpreted by the shell if not quoted. How about using '-' instead and using UOM suffixes? --result_size=ok-300:500b,warn-:300,critical-500: --free_space=warn-inf:300KB,critical-inf:100KB Using suffixes to identify UOM and - instead of () Would avoid the extra parentheses and eliminate that potential problem and is still very readable in my opinion. Suffixes would be optional, but if someone wants to use them I think it is perfectly reasonable to have the user then understand the difference between bits and bytes, KB vs kb, MB vs Mb when dealing with orders of magnitude. --free_space=ok:300-500b,warn:-300b,critical:500b+ this is another alternate punctuation still that could be used that still keeps to your idea ... - for less than, + for greater than, num - num for range, and use : as the state:spec separator. That to me is more readable than the '-' version I just suggested as an alternative and still avoids using the shell sub-shell parens. People are very used to seeing label ':' value. - Max From ae at op5.se Fri Mar 21 17:40:54 2008 From: ae at op5.se (Andreas Ericsson) Date: Fri, 21 Mar 2008 17:40:54 +0100 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47DF5D6C.1000708@aei.ca> <62BFCC67-13AC-456D-A3DC-25C21EA026C4@altinity.com> <47DFC400.3070204@aei.ca> <9EFC67C1-A221-4CF1-8E48-E5FEBBABA04E@altinity.com> <47E0E35C.7080407@aei.ca> <077F1B782014ED48A58E7927914D36A004601B94@fai01500.bhs.bannerhealth.com> Message-ID: <47E3E516.30506@op5.se> Max wrote: > On Thu, Mar 20, 2008 at 5:07 PM, Ton Voon wrote: >> On 20 Mar 2008, at 19:39, Vonnahme, Nathan wrote: >> >> > 1. we start by defining "normal" (OK), and assume everything >> > else is CRITICAL >> >> I'm still digesting what you've written, but I just had to say: >> brilliant. >> >> Defining OK ranges is going to be the biggest thing to aid >> comprehension > > I agree with the usefulness of this and readability of this, very nice. > > I am not sold on the value of having ranges have to state negative or > positive infinity explicitly. I think that should be optional but not > required. I understand from an implementation standpoint that having > it manditory makes parsing arguments easier, though only slightly. >>From a readability standpoint, I think fewer people are used to seeing > infinity explicitly stated and represented as a token than they are > having it be assumed by an expression. > > I do really like the readability of warn(), ok(), critical() and I > like having UOM as a suffix; I would not see any developer or plugin > writer, regardless of skill, getting confused about whether he or she > has to put a UOM on infinity :). > > I would also make ok() optional as there are plenty of use cases for > plugins where just defining exceptions and having what is normal > implied by the exceptions is more intuitive. > > Your suggestion does use characters that would be interpreted by the > shell if not quoted. How about using '-' instead and using UOM > suffixes? > > --result_size=ok-300:500b,warn-:300,critical-500: > > --free_space=warn-inf:300KB,critical-inf:100KB > For negative infinity, this would be "warn--inf:300KB" which looks kinda ugly and is hard to debug. I'd go with equal-sign and recommend disjointed parameter/argument in all docs, like this --freespace warn=inf:300KB,critical=inf:100KB (yes, I detest underscores in argument names, primarily because many keyboard setups requires the user to press shift to get an underscore) And let "warn", "critical" and "ok" be specified by their shortest non-ambiguous string, for brevity, so that really long command-lines can be shortened to --freespace w=inf:2GB,c=inf:200MB uom must be specifiable along with the numerical option, otherwise the above thresholds would feel unnatural to specify. Note that 0.2GiB != 200MiB, while 0.2GB == 200MB. Since we're talking disks here, both KiB and KB are valid and both kinds are used. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From nathan.vonnahme at bannerhealth.com Fri Mar 21 19:48:36 2008 From: nathan.vonnahme at bannerhealth.com (Vonnahme, Nathan) Date: Fri, 21 Mar 2008 10:48:36 -0800 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <47E3E516.30506@op5.se> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47DF5D6C.1000708@aei.ca> <62BFCC67-13AC-456D-A3DC-25C21EA026C4@altinity.com> <47DFC400.3070204@aei.ca> <9EFC67C1-A221-4CF1-8E48-E5FEBBABA04E@altinity.com> <47E0E35C.7080407@aei.ca> <077F1B782014ED48A58E7927914D36A004601B94@fai01500.bhs.bannerhealth.com> <47E3E516.30506@op5.se> Message-ID: <077F1B782014ED48A58E7927914D36A004601D7F@fai01500.bhs.bannerhealth.com> > Max wrote: > > On Thu, Mar 20, 2008 at 5:07 PM, Ton Voon wrote: > >> On 20 Mar 2008, at 19:39, Vonnahme, Nathan wrote: > >> > >> > 1. we start by defining "normal" (OK), and assume everything > >> > else is CRITICAL > >> > >> I'm still digesting what you've written, but I just had to say: > >> brilliant. > >> > >> Defining OK ranges is going to be the biggest thing to aid > >> comprehension > > > > I agree with the usefulness of this and readability of this, very nice. *blush* gee, thanks. > > I am not sold on the value of having ranges have to state negative or > > positive infinity explicitly. I think that should be optional but not > > required. I understand from an implementation standpoint that having > > it manditory makes parsing arguments easier, though only slightly. > >>From a readability standpoint, I think fewer people are used to seeing > > infinity explicitly stated and represented as a token than they are > > having it be assumed by an expression. I think in most cases 0 will be the obvious lower limit, rather than negative infinity. I was not really thinking of ease of parsing though, but of mapping what the user assumes to the way the plugin actually uses the value. I think x:y looks like a range at first (and 100th) glance, even when it's surrounded by other stuff, but (ignoring the shell-breaking parentheses for the moment), compare the readability: ok(10,bytes) ok(10:10, bytes) # the first only makes sense for a range of 1 value, which is almost never what we want, so it wouldn't hurt to require the explicit 10:10 ok(10:,bytes) ok(10:inf,bytes) ok(:10,bytes) ok(0:10,bytes) when it gets more complex, having both sides of the range also reminds you what's happening, rather than looking like some sort of operator or marker: load=ok(2,1.5,1.2) # ok but the (implicitly -inf) lower limit is ambiguous load=ok(:2,:1.5,:1.2) # better (implicit minimums) load=ok(0:2,0:1.5,0:1.2) # best (explicit max and min) > > > > I do really like the readability of warn(), ok(), critical() and I > > like having UOM as a suffix; I would not see any developer or plugin > > writer, regardless of skill, getting confused about whether he or she > > has to put a UOM on infinity :). > > > > I would also make ok() optional as there are plenty of use cases for > > plugins where just defining exceptions and having what is normal > > implied by the exceptions is more intuitive. > > > > Your suggestion does use characters that would be interpreted by the > > shell if not quoted. How about using '-' instead and using UOM > > suffixes? > > > > --result_size=ok-300:500b,warn-:300,critical-500: > > > > --free_space=warn-inf:300KB,critical-inf:100KB > > > > For negative infinity, this would be "warn--inf:300KB" which looks > kinda ugly and is hard to debug. You could leave off the minus sign and assume that "inf" means negative infinity if it's on the left side of the colon. But, as you said, Max, the parentheses are a shell problem. It's too bad all the nice matching tokens you'd normally use to express a set-- ()[]{}<> -- would require escaping or quoting. > > I'd go with equal-sign and recommend disjointed parameter/argument > in all docs, like this > > --freespace warn=inf:300KB,critical=inf:100KB --metric warn=min:maxunit since you don't have a separator between the range and the unit, it still runs into the infinity units thing, which I don't like: --usedspace warn=300:infGB what about //, which is used for grouping regexps? --time=ok/0:3/seconds --freespace=ok/300:inf/KB,warn/100:300/KB --load=ok/0:2,0:1.5,0:1.2/ but in those I feel the colon and slash visually compete when you're trying to divide up the units, so what if we used .. instead of : for ranges? --time=ok/0..3/seconds --freespace=ok/300..inf/KB,warn/100..300/KB --load=ok/0..2,0..1.5,0..1.2/ I like --metric=ok/min..max/unit,warn/min..max/unit,critical/min..max/unit the best so far. It seems readable, writable and is pretty isomorphic with the data structure, it's simple for the simple cases: --time=ok/0..2/ and capable of the complex ones: --load=ok/0.7..2,0.7..1.5,0.7..1.2/,warn/0..0.7,0..0.7,0..0.7/ and for the rare case where you'd need to invert the range (rather than specifying the OK range), you could add 'outside' inside the range defining slashes: --metric=critical/outside,min..max/units OTOH, biting the bullet and quoting the argument would allow a lot more flexibility... --metric='critical(outside,min..max)units, warning(min..max)units' --metric='critical outside (min:max) units, warning (min:max) units' --metric=ok(min:max) --metric='ok outside min..max units, warning min..max units' # especially good for haters of the shift key > And let "warn", "critical" and "ok" be specified by their shortest > non-ambiguous string, for brevity, so that really long command-lines > can be shortened to > > --freespace w=inf:2GB,c=inf:200MB > > uom must be specifiable along with the numerical option, otherwise > the above thresholds would feel unnatural to specify. Note that I think allowing uom on every ok/warn/critical definition is good, but I don't think abbreviating them gains much-- in most cases if you use 'ok', you wouldn't need 'critical', and you're only saving 1 and 3 chars on 'ok' and 'warn'. BTW, I'll be on vacation next week so won't be able to answer. I hope your discussion (and/or coding) is fruitful though. -n From noreply at sourceforge.net Fri Mar 21 22:44:15 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 21 Mar 2008 14:44:15 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1922579 ] check_ldap: ldap_init implicitly converted Message-ID: Bugs item #1922579, was opened at 2008-03-21 22:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1922579&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_ldap: ldap_init implicitly converted Initial Comment: We have detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. This is often due to a missing function prototype definition. For more information, see [1]. Function `ldap_init' implicitly converted to pointer at check_ldap.c:124 The libldap API has been updated and many functions used by the ldap plugin are now deprecated. This package should either update to the new API or define LDAP_DEPRECATED to continue using the deprecated interfaces. For more infos see our bug{2] in the Debian BTS. Thanks and with kind regards, Jan. [1] http://wiki.debian.org/ImplicitPointerConversions [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463322 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1922579&group_id=29880 From noreply at sourceforge.net Wed Mar 26 03:20:30 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Mar 2008 19:20:30 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1912023 ] check_http segfaults with "-a x" option Message-ID: Bugs item #1912023, was opened at 2008-03-11 10:01 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1912023&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Adam Buchbinder (gdrago23) Assigned to: Nobody/Anonymous (nobody) Summary: check_http segfaults with "-a x" option Initial Comment: Plugin Version (-V output): check_http v1861 (nagios-plugins 1.4.11) Plugin Name: check_http Plugin Commandline showing issues: ./check_http -a x google.com Operating System: Ubuntu Gutsy Architecture: i686 Compiler: gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Backtrace: (gdb) run -a x google.com Starting program: /home/abuchbinder/src/nagiosplug/nagios-plugins-1.4.11/plugins/check_http -a x google.com Program received signal SIGSEGV, Segmentation fault. 0x08050b73 in base64 (bin=0x806bf04 'A' ..., len=1) at base64.c:23 23 buf[i++] = base64_table[bin[j] >> 2]; (gdb) bt #0 0x08050b73 in base64 (bin=0x806bf04 'A' ..., len=1) at base64.c:23 #1 0x0804b164 in check_http () at check_http.c:764 #2 0x0804e344 in main (argc=1094795585, argv=0x41414141) at check_http.c:166 (gdb) The argument specified isn't valid, but it still shouldn't segfault. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2008-03-25 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2008-03-11 10:26 Message: Logged In: YES user_id=759506 Originator: NO As far as I can see, this is fixed in SVN (we now use Gnulib for Base64 encoding), see the latest snapshot at: http://nagiosplug.sourceforge.net/snapshot/nagios-plugins-HEAD.tar.gz ---------------------------------------------------------------------- Comment By: Adam Buchbinder (gdrago23) Date: 2008-03-11 10:05 Message: Logged In: YES user_id=20994 Originator: YES This has also been reported on the Ubuntu bug tracker: https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/201054 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1912023&group_id=29880 From marc at ena.com Wed Mar 26 15:16:32 2008 From: marc at ena.com (Marc Powell) Date: Wed, 26 Mar 2008 09:16:32 -0500 Subject: [Nagiosplug-devel] plugins spec file patch for command.cfg Message-ID: Hi all, In this thread on nagios-users - http://thread.gmane.org/gmane.network.nagios.user/53370, Robert Dodier experienced that the command.cfg from the plugins became his /etc/nagios/command.cfg after building the RPM from the spec file. I suspect that this was caused by an order-of-installation issue since the spec properly dictates noreplace for the file. The core problem, however, is that this file is still in Netsaint format. I personally see no reason why this file should be installed any longer outside of the documentation directory given that nagios itself ships with sufficient sample config files. The attached patch file removes the installation of the file to /etc/nagios. -- Marc p.s. http://nagiosplugins.org/support link to subscribe to nagiosplug-devel points to nagiosplug-help subscription page. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: plugins-spec.patch.txt URL: From ton.voon at altinity.com Wed Mar 26 15:43:36 2008 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 26 Mar 2008 14:43:36 +0000 Subject: [Nagiosplug-devel] plugins spec file patch for command.cfg In-Reply-To: References: Message-ID: <8B5560DB-3C26-414F-BBCE-99D3FABB50BB@altinity.com> Marc, On 26 Mar 2008, at 14:16, Marc Powell wrote: > I personally see no reason why this file should be installed any > longer > outside of the documentation directory given that nagios itself ships > with sufficient sample config files. The attached patch file removes > the > installation of the file to /etc/nagios. I've removed the file altogether, since it is an extra point of maintenance when the documentation of the plugins themselves should have sufficient examples. However, that maybe a bit extreme. > p.s. http://nagiosplugins.org/support link to subscribe to > nagiosplug-devel points to nagiosplug-help subscription page. Thanks - sorted that too. Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From thomas at zango.com Wed Mar 26 15:53:39 2008 From: thomas at zango.com (Thomas Guyot-Sionnest) Date: Wed, 26 Mar 2008 10:53:39 -0400 Subject: [Nagiosplug-devel] plugins spec file patch for command.cfg In-Reply-To: References: Message-ID: <47EA6373.803@zango.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marc Powell wrote: | Hi all, | | In this thread on nagios-users - | http://thread.gmane.org/gmane.network.nagios.user/53370, Robert Dodier | experienced that the command.cfg from the plugins became his | /etc/nagios/command.cfg after building the RPM from the spec file. I | suspect that this was caused by an order-of-installation issue since the | spec properly dictates noreplace for the file. The core problem, | however, is that this file is still in Netsaint format. | | I personally see no reason why this file should be installed any longer | outside of the documentation directory given that nagios itself ships | with sufficient sample config files. The attached patch file removes the | installation of the file to /etc/nagios. Thanks. I have no RPM-based systems to test with and haven't played with spec files for long... do you mind testing and/or confirming this patch is correct? I kept the line as we'll likely want to ship a sample plugins.ini file in a near future... I will also update or delete the sample config file as well... - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6mNz6dZ+Kt5BchYRAjQnAJ95S2yw1wbfEJXuCO7mEJSm9Nln+QCeLVI6 G7v5/rBYxLIkwEG4oQTmRM8= =9nTB -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: nagiosplug_spec_file.patch URL: From marc at ena.com Wed Mar 26 15:57:01 2008 From: marc at ena.com (Marc Powell) Date: Wed, 26 Mar 2008 09:57:01 -0500 Subject: [Nagiosplug-devel] plugins spec file patch for command.cfg In-Reply-To: <8B5560DB-3C26-414F-BBCE-99D3FABB50BB@altinity.com> Message-ID: > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug-devel- > bounces at lists.sourceforge.net] On Behalf Of Ton Voon > Sent: Wednesday, March 26, 2008 9:44 AM > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] plugins spec file patch for command.cfg > > I've removed the file altogether, since it is an extra point of > maintenance when the documentation of the plugins themselves should > have sufficient examples. However, that maybe a bit extreme. Thanks Ton, definitely a better solution. -- Marc From matthias.eble at mailing.kaufland-informationssysteme.com Fri Mar 28 16:19:18 2008 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Fri, 28 Mar 2008 16:19:18 +0100 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> Message-ID: <47ED0C76.1050700@mailing.kaufland-informationssysteme.com> Hi all, after reading and thinking about this thread for hours, now, I want to summarize the discussion up to now. I hope I got the most important statements and met the participants' intentions. So here, we go: Max suggested:syntax like -w '1min>15:5min>5' -c '15min>15:5min>10' Which has downsides: - thresholds need to be quoted properly (no problem for the people on this list, but annoying anyway) - it's much harder to read than using longopts: --load1=/15: --load5=10:/5: --load15=15: One general aim is that the threshold specification should be as flexible as possible also to prevent the need to run the same plugin multiple times to get one job done (like Ton's example for three check_procs services for testing one process) Thomas posted links to http://physics.nist.gov/cuu/Units/prefixes.html http://physics.nist.gov/cuu/Units/binary.html containing a list of metrics. He claims that there should be a list of legal UOMs/prefixes and that allowing base8 units should be discussed. Maybe some gnulib code can be used for conversion (Ton). Andreas later noted that 0.2GiB != 200MiB, while 0.2GB == 200MB which should be kept in mind. Ton and Thomas agree that Perfdata should be in a fixed UOM and not the one specified in the thresholds (at least for now). - changing the threshold UOM will destroy old graphs - Defining a base unit should be up to the respective plugins and be as small as possible (sec,bytes,...) - Thus uom is optional even when no thresholds are defined (like --load1 to just graph load1) Using scientific notation is omitted for now. Ton and Thomas agree on dropping +-inf since the colon implies them. But Nathan also thinks that ranges should always explicitly write both sides of the range meaning 10:inf rather than 10: Andreas could imagine that commandlines could become very complex confusing users, but he has no better idea either. Ton could imagine some helper functions (cmdline, web pages, google calculator) to verify complex thresholds and Andreas likes to see a possibility to shorten --freespace warn=inf:300KB to --freespace w=inf:300KB. Andreas also thinks that taking the simplicity off the plugins/specs will take off one important advantage of nagios and that Ton should be shot :D Additionaly Ton (who should now fear the next nagios conference :) and Andreas state that compatibility should and will be retained. At least for versions prior 2.0. Thomas dropped in to use getsubopt style arguments like --metric min=2,uom_prefix=Ki,uom=b,.. which makes it easier to keep backward compatibility when introducing new values. Ton summarized that it all comes down to two things: - range definition - threshold definition When it comes to ranges, there are two options: keeping existing ranges using ':' or some math style 1<=x<=3 containing "quote me" characters (like Max proposed). But, however multiple styles *might* be possible and could be supported parallely. Thus the options for defining a threshold are (ignoring uom for the moment): 1) --threshold-time=crit_range/warn_range 2) --threshold name=time,warn=range,crit=range 3) --threshold=time -w range -c range Thomas thinks about something like --threshold name=cpu,type=warn,min=0,max=80,inside which would lead to another seperator if multiple ranges per metric should (possibly) be supported. Andreas also noted that the warn/crit sanity check needs to be different depending on plugin. Sometimes w < c sometimes w > c Ton implemented a showcase for the a possible approach into check_procs: ./check_procs -C cron --number=^1:1 --rss-threshold=0: --vsz- threshold=0: --cpu-threshold=-1: But currently the non OK output doesn't state which threshold is actually exceeded. Nathan pointed out that it is more intuitive to specify only ok and warning ranges. Everything outside them is critical, which Ton thinks is "brilliant". Something like: --size_ok=300:500b --size_warn=500b:inf or --size=ok(300:500b),warn(500b:inf) Nathan added that ':' could be replaced by '..' and using '/' as a range seperator: --time=ok/0..3/seconds --freespace=ok/300..inf/KB,warn/100..300/KB --load=ok/0..2,0..1.5,0..1.2/ --End of summary So to me there are multiple open questions Key questions: - Must the threshold specification argument be valid without quoting? - Is it necessary to allow multiple ranges per thresh warn=10:20,50:60? - Should thresholds be defined ok/warn rather than warn/crit? - Should plugins only print perfdata for explicitly selected metrics or should there be a base set? - Should there be an explicit range limit (10:inf over 10:) - Is it favorable to have multiple range styles like 1 Hello, Suggestion for plugin improvements: Add a section on the --help output that provides an explicit description of the performance information. For instance: Running: check_disk -k -w20% -c10% -p /local produces this output: DISK WARNING - free space: /local 3964552 kB (17% inode=98%);| /local=18917352kB;19285164;21695810;0;24106456 I use rrdtool to track the output of our Nagios checks, but I don't know how the numbers above relate to the partition below: [nagios at USUS007]/usr/local/nagios/libexec$ df -v /local Filesystem 1K-blocks Used Available Use% Mounted on /dev/cciss/c0d0p8 24106456 18917512 3964392 83% /local I see the 17%, 18917352kB, and 24106456; but where does 19285164;21695810;0 come in? It would be helpful if this was described clearly. I'm sure that you include it because it has value, but I can only guess right now. Thanks for your valuable work. ddk Don Knapp *********************************************************************** This e-mail and any attachments may contain information which is confidential, privileged, proprietary or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer. *********************************************************************** From bohara at gmail.com Fri Mar 28 16:37:28 2008 From: bohara at gmail.com (Ben O'Hara) Date: Fri, 28 Mar 2008 15:37:28 +0000 Subject: [Nagiosplug-devel] Suggestion In-Reply-To: References: Message-ID: <2b36e660803280837s29800afu11f0769a96283bfe@mail.gmail.com> There the warning and critical value AFAIK Ben On Fri, Mar 28, 2008 at 2:05 PM, Don Knapp wrote: > > Hello, > > Suggestion for plugin improvements: > > Add a section on the --help output that provides an explicit description > of > the performance information. > > For instance: > > Running: > check_disk -k -w20% -c10% -p /local > > produces this output: > DISK WARNING - free space: /local 3964552 kB (17% inode=98%);| > /local=18917352kB;19285164;21695810;0;24106456 > > I use rrdtool to track the output of our Nagios checks, but I don't know > how the numbers above relate to the partition below: > > [nagios at USUS007]/usr/local/nagios/libexec$ df -v /local > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/cciss/c0d0p8 24106456 18917512 3964392 83% /local > > I see the 17%, 18917352kB, and 24106456; but where does > 19285164;21695810;0 > come in? It would be helpful if this was described clearly. I'm sure > that > you include it because it has value, but I can only guess right now. > > Thanks for your valuable work. > > ddk > > Don Knapp > > > *********************************************************************** > This e-mail and any attachments may contain information which is > confidential, privileged, proprietary or otherwise protected by law. > The information is solely intended for the named addressee (or a person > responsible for delivering it to the addressee). If you are not the > intended recipient of this message, you are not authorized to read, > print, retain, copy or disseminate this message or any part of it. > If you have received this e-mail in error, please notify the sender > immediately by return e-mail and delete it from your computer. > *********************************************************************** > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________________ > Nagios Plugin Development Mailing List > Nagiosplug-devel at lists.sourceforge.net > 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 > -- If voting changed anything, they'd make it illegal -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.eble at mailing.kaufland-informationssysteme.com Fri Mar 28 16:41:54 2008 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Fri, 28 Mar 2008 16:41:54 +0100 Subject: [Nagiosplug-devel] Suggestion In-Reply-To: References: Message-ID: <47ED11C2.50607@mailing.kaufland-informationssysteme.com> Hi Don, > Add a section on the --help output that provides an explicit description of > the performance information. see http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN203 > Running: > check_disk -k -w20% -c10% -p /local > > produces this output: > DISK WARNING - free space: /local 3964552 kB (17% inode=98%);| > /local=18917352kB;19285164;21695810;0;24106456 'label'=value[UOM];[warn];[crit];[min];[max] Matthias From s.urbanovski at ac-nancy-metz.fr Fri Mar 28 16:46:08 2008 From: s.urbanovski at ac-nancy-metz.fr (=?UTF-8?B?U3TDqXBoYW5lIFVyYmFub3Zza2k=?=) Date: Fri, 28 Mar 2008 16:46:08 +0100 Subject: [Nagiosplug-devel] Suggestion In-Reply-To: References: Message-ID: <47ED12C0.4070006@ac-nancy-metz.fr> Don Knapp a ?crit : > Hello, > > Suggestion for plugin improvements: > > Add a section on the --help output that provides an explicit description of > the performance information. > > For instance: > > Running: > check_disk -k -w20% -c10% -p /local > > produces this output: > DISK WARNING - free space: /local 3964552 kB (17% inode=98%);| > /local=18917352kB;19285164;21695810;0;24106456 > > I use rrdtool to track the output of our Nagios checks, but I don't know > how the numbers above relate to the partition below: > > [nagios at USUS007]/usr/local/nagios/libexec$ df -v /local > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/cciss/c0d0p8 24106456 18917512 3964392 83% /local > > I see the 17%, 18917352kB, and 24106456; but where does 19285164;21695810;0 > come in? It would be helpful if this was described clearly. I'm sure that > you include it because it has value, but I can only guess right now. You will find informations about perf data here : http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN203 -- St?phane Urbanovski From matthias.eble at mailing.kaufland-informationssysteme.com Fri Mar 28 17:50:53 2008 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Fri, 28 Mar 2008 17:50:53 +0100 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <47ED0C76.1050700@mailing.kaufland-informationssysteme.com> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47ED0C76.1050700@mailing.kaufland-informationssysteme.com> Message-ID: <47ED21ED.60204@mailing.kaufland-informationssysteme.com> > Ton and Thomas agree that Perfdata should be in a fixed UOM and > not the one specified in the thresholds (at least for now). > - changing the threshold UOM will destroy old graphs > - Defining a base unit should be up to the respective plugins and be > as small as possible (sec,bytes,...) > - Thus uom is optional even when no thresholds are defined (like > --load1 to just graph load1) When changing perfdata uom(-prefix) rrd will show up something like 1k MB. Taking bytes is the most precise offer we can pass to the graphers. They can then define how to handle/display them. > Ton could imagine some helper functions (cmdline, web pages, google > calculator) to verify complex thresholds That could also be part of the library so every plugin could have a dryrun option to print which values would cause what. Based on the defined thresholds, (for example x:y) one could test/print what rc the values x,y,x+1,x-1,y+1,y-1 would cause. > and Andreas likes to see a > possibility to shorten --freespace warn=inf:300KB > to --freespace w=inf:300KB Me too. > Andreas also thinks that taking the simplicity off the plugins/specs > will take off one important advantage of nagios yes > and that > Ton should be shot :D noooo! > Thomas dropped in to use getsubopt style arguments like --metric > min=2,uom_prefix=Ki,uom=b,.. which makes it easier > to keep backward compatibility when introducing new values. I think getsubopt style is a real improvement in this discussion. > Thus the options for defining a threshold are (ignoring uom for the > moment): > 1) --threshold-time=crit_range/warn_range > 2) --threshold name=time,warn=range,crit=range > 3) --threshold=time -w range -c range > Thomas thinks about something like > 4) --threshold name=cpu,type=warn,min=0,max=80,inside I'd prefer to see some kind of range since it's shorter than min=,max= > Nathan pointed out that it is more intuitive to specify only ok and > warning ranges. > Everything outside them is critical, which Ton thinks is "brilliant". > ... > Nathan added that ':' could be replaced by '..' and using '/' as a range > seperator: > --time=ok/0..3/seconds > --freespace=ok/300..inf/KB,warn/100..300/KB > --load=ok/0..2,0..1.5,0..1.2/ --freespace ok/300..inf/KB,warn/100..300/KB or --freespace ok=300..inf/KB,warn=100..300/KB looks good to me but should we seperate prefix and uom? > > --End of summary > > So to me there are multiple open questions > > Key questions: > - Must the threshold specification argument be valid without quoting? To me: yes (for numeric values/ranges). Required quoting opens a brider range of syntax though. > - Is it necessary to allow multiple ranges per thresh warn=10:20,50:60? The Performance data definition doesn't permit this up to now but I could imagine some people would like to see this. > - Should thresholds be defined ok/warn rather than warn/crit? I like the approach but this means not only the syntax is changed. People need to start thinking when converting. > - Should plugins only print perfdata for explicitly selected metrics > or should there be a base set? I'd vote for a base set, to get some values (beside the alert ones) for free. Having to look what all the plugins offer is exhausting. I'd thus say printing as much as perfdata as possible would be best. Also most rrd based perfdata tools will run in severe problems with new/changing metric labels after creation. > - Should there be an explicit range limit (10:inf over 10:) 10:inf or 10::inf looks cleaner to me. > - Is it favorable to have multiple range styles like > 1 Further questions: > - should perfdata inherit threshold's uom/prefix? No. See above > - replace range seperator ':' with '..'? I guess that depends on some other factors, but I like Nathans suggestions > - Which component is responsible for sanity checking of thresholds? > - Should base8 UOM-prefixes be allowed? No opinion for now. > I'll post my thoughts later on. I've some hints, too: Since it looks like the default alerting mechanism will be "inside", default range behaviour for plain numbers (X gets 0:X) should be reversed, too. So X will result in X:inf instead of 0:X Or should we drop those plain thresholds completely? What about mixing uom-prefix in one range? Might this be needed in the future? One more thing which has been in my head for a couple of weeks, now is that we need to strengthen percent support in our library. This could be done by adding an optional(?) base value to get_status so that this can calculate percentage. At the moment, my favourite threshold/range definition is following: --throughput ok=1..5/M,warn=1..300/M/B Where ok takes the default UOM (here bit) and warn uses an own UOM (byte). But this is also invalid with our perfdata specs. with ranges like [^]start..end Matthias From thomas at zango.com Fri Mar 28 19:26:26 2008 From: thomas at zango.com (Thomas Guyot-Sionnest) Date: Fri, 28 Mar 2008 14:26:26 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <47ED21ED.60204@mailing.kaufland-informationssysteme.com> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47ED0C76.1050700@mailing.kaufland-informationssysteme.com> <47ED21ED.60204@mailing.kaufland-informationssysteme.com> Message-ID: <47ED3852.2010205@zango.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey Matthias! First of all thanks for the summary! It's awesome and will definitely help to see where we should head. Matthias Eble wrote: |> Ton and Thomas agree that Perfdata should be in a fixed UOM and |> not the one specified in the thresholds (at least for now). |> - changing the threshold UOM will destroy old graphs |> - Defining a base unit should be up to the respective plugins and be |> as small as possible (sec,bytes,...) |> - Thus uom is optional even when no thresholds are defined (like |> --load1 to just graph load1) | | When changing perfdata uom(-prefix) rrd will show up something like | 1k MB. Taking bytes is the most precise offer we can pass to the | graphers. They can then define how to handle/display them. I somewhat agree, though when you set up your graph you should divide/multiply appropriately the values. If your data is in E or p it's probably not an option to print: label=183000000000000000000;200000000000000000000;250000000000000000000;0;300000000000000000000 or label=0.000000000018;0.000000000100;0.000000000200;;; ... Unless you use scientific notation. Although I agree in most cases perfdata should have no prefix. For that reason I'd leave the perfdata unit prefix up to each plugin and have prefixes defined in the thresholds only apply to the thresholds themselves and the status line. |> Ton could imagine some helper functions (cmdline, web pages, google |> calculator) to verify complex thresholds | | That could also be part of the library so every plugin could have a | dryrun option to print which values would cause what. Based on the | defined thresholds, (for example x:y) one could test/print what rc the | values x,y,x+1,x-1,y+1,y-1 would cause. +1 | > and Andreas likes to see a |> possibility to shorten --freespace warn=inf:300KB |> to --freespace w=inf:300KB | | Me too. +1 For the rest I'd leave that to getsubopt which, I believe, will allow you to shorten any non-conflicting name (like -- options). | |> Thomas thinks about something like |> 4) --threshold name=cpu,type=warn,min=0,max=80,inside | | I'd prefer to see some kind of range since it's shorter than min=,max= I totally agree... |> Nathan pointed out that it is more intuitive to specify only ok and |> warning ranges. |> Everything outside them is critical, which Ton thinks is "brilliant". | > ... |> Nathan added that ':' could be replaced by '..' and using '/' as a range |> seperator: |> --time=ok/0..3/seconds |> --freespace=ok/300..inf/KB,warn/100..300/KB |> --load=ok/0..2,0..1.5,0..1.2/ | | --freespace ok/300..inf/KB,warn/100..300/KB | or | --freespace ok=300..inf/KB,warn=100..300/KB | | looks good to me but should we seperate prefix and uom? First, you shouldn't mix ranges and UOM; that's the idea of subopts. As I said gluing together the UOM and prefix is totally hopeless. so: - --freespace ok=300..inf,warn=100..300,uom_prefix=Ki,uom=B or (uning single argument for all thresholds): - --threshold=metric=freespace,ok=300..inf,warn=100..300,uom_prefix=Ki,uom=B Or (if you can abbreviate to --th): - --th metric=freespace,ok=300..inf,warn=100..300,uom_prefix=Ki,uom=B On a side note, I'm totally confused with the above thresholds and for me the OK-suggestion just lost its purpose. Keep in mind that people always used warn/crit, and it's the same in any other monitoring product I came across. |> --End of summary |> |> So to me there are multiple open questions |> |> Key questions: |> - Must the threshold specification argument be valid without quoting? | | To me: yes (for numeric values/ranges). Required quoting opens a brider | range of syntax though. +1 |> - Is it necessary to allow multiple ranges per thresh warn=10:20,50:60? | | The Performance data definition doesn't permit this up to now but I | could imagine some people would like to see this. Indeed. If we ever allow that it can be done simply by allowing multiple warn/crit ranges... |> - Should thresholds be defined ok/warn rather than warn/crit? | | I like the approach but this means not only the syntax is changed. | People need to start thinking when converting. Yes. See my comment above. People with huge setups will fear upgrading! |> - Should plugins only print perfdata for explicitly selected metrics |> or should there be a base set? | | I'd vote for a base set, to get some values (beside the alert ones) for | free. Having to look what all the plugins offer is exhausting. | I'd thus say printing as much as perfdata as possible would be best. It's probably best to leave that to the plugins... In many cases base set + defined special ones will probably be the best. You can always define them with no thresholds ("print it but don't alert on it"). | Also most rrd based perfdata tools will run in severe problems with | new/changing metric labels after creation. We should always leave a "compatible" mode... At the very least least for one minor release (By minor I mean 2nd number changing) |> - Should there be an explicit range limit (10:inf over 10:) | | 10:inf or 10::inf looks cleaner to me. Either way if fine for me as long as there's only one way to explicitly define infinite ;) |> - Is it favorable to have multiple range styles like |> 1 - Which component is responsible for sanity checking of thresholds? |> - Should base8 UOM-prefixes be allowed? If the prefix is separated from the uom, we can easily support any SI prefixes. I'd allow this for correctness and because this is a standard. http://physics.nist.gov/cuu/Units/prefixes.html http://physics.nist.gov/cuu/Units/binary.html |> I'll post my thoughts later on. | | I've some hints, too: | | Since it looks like the default alerting mechanism will be "inside", | default range behaviour for plain numbers (X gets 0:X) should be | reversed, too. So X will result in X:inf instead of 0:X | Or should we drop those plain thresholds completely? I don't really have an opinion there... Although with the ".." in ranges you gave me an idea... You could use ":" or ".." to differentiate between inside and outside ranges. ":" would be outside, just as it is right now, and ".." would be inside like in Perl. | What about mixing uom-prefix in one range? Might this be needed in the | future? IMHO it's much clearer to have it separated, and it's also the original idea of using getsubopt. | One more thing which has been in my head for a couple of weeks, now is | that we need to strengthen percent support in our library. This could be | done by adding an optional(?) base value to get_status so that this can | calculate percentage. | | At the moment, my favourite threshold/range definition is following: | --throughput ok=1..5/M,warn=1..300/M/B | | Where ok takes the default UOM (here bit) and warn uses an own UOM | (byte). But this is also invalid with our perfdata specs. Why different prefixes for ok and warn? Can you easily tell if 18430KiB is more or less than 18874368MiB ???? What about critical UOM? I believe it should be consistent for easy comparison. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH7ThS6dZ+Kt5BchYRArysAJ9oFhJqgINhzh/lVW7uKOVn9E6ZkgCfaRyL zCKffcnG0h/LB7dfHBZYdho= =game -----END PGP SIGNATURE----- From noreply at sourceforge.net Sat Mar 29 03:29:48 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Mar 2008 19:29:48 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1928399 ] check_procs METRIC_CPU should ignore kernel processes Message-ID: Bugs item #1928399, was opened at 2008-03-28 22:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1928399&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steve Wills (stevewills) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs METRIC_CPU should ignore kernel processes Initial Comment: I'm using check_procs to check for processes which stopped living and become crazy mixed up zombies which eat all the CPU. This works fine on Linux, but on FreeBSD, the check_procs module detects the idle thread(s) as using 100% CPU. Of course the idle thread(s) aren't the ones I want to alarm about. On FreeBSD I can detect kernel threads by finding the processes whose parent process ID is 0 (except PID 1 which is always init). I've attached a patch which makes check_procs skip kernel threads. I'm not sure if this patch is appropriate for other platforms, but it might be a start. A better approach might be to provide an option to ignore kernel threads (I tried to look at how to do this on Linux and gave up, and I have no idea bout other platforms) and/or an option that is the opposite of the -p flag (ignore processes of particular ppid). But for now, the attached patch makes check_procs CPU metric much more useful on FreeBSD, although an #ifdef FREEBSD or something similar might be warranted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1928399&group_id=29880