From nathan.vonnahme at bannerhealth.com Tue Apr 1 00:55:57 2008 From: nathan.vonnahme at bannerhealth.com (Vonnahme, Nathan) Date: Mon, 31 Mar 2008 14:55:57 -0800 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: <077F1B782014ED48A58E7927914D36A0046B99A6@fai01500.bhs.bannerhealth.com> > From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- > devel-bounces at lists.sourceforge.net] On Behalf Of Matthias Eble > > 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. > I *really* like that idea, Matthias! It might be tricky for plugins like check_procs or check_http that are checking multiple parts of another program's output. > > - 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. I'd say "not necessary" -- there are workarounds (like using inversion, or two checks) for the few cases where you'd want this, and supporting it would be complex. > > - 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. We don't need to abandon or break the warn/critical options, although at some distant point it might be good to move away from the -W and -C syntax. Specifying "normal" and flagging exceptions instead of trying to "enumerate badness" is a good practice in many areas (testing, security, quality control). I think it's also how sysadmins think about their systems, right? "On this machine, the disk is normally 50-80% full." If you only think in terms of warn/critical, you might only think about the upper boundary, and have alerts when usage goes over 80%. But if you specify "OK", you may get an unexpectedly valid alert one day when your disk is suddenly, mysteriously, 1% full :) (actually that's also why check_disk's "free space" (instead of used space) approach has often confused me, though I can see several good reasons for it) > > - Should there be an explicit range limit (10:inf over 10:) > > 10:inf or 10::inf looks cleaner to me. I am always in favor of explicit (10:inf or 10..inf), because it optimizes reading, which you do more often than writing, and because newcomers read examples before they write. > > - Is it favorable to have multiple range styles like > > 1 > Not if you ask me. Agreed! And Thomas is right-- if you hate the supported syntax you can always write a script or utility to run the plugins or generate the options for you. The extremely lazy typists out there can also probably use various macro-like utilities to overcome any gratuitously explicit characters :) > 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'd like to see plain thresholds go away eventually, because in some existing cases X means 0:X or -inf:X and in others it means X:inf. Also, I think it's important to get users thinking in terms of ranges rather than single numbers. > What about mixing uom-prefix in one range? Might this be needed in the > future? -1 > At the moment, my favourite threshold/range definition is following: > --throughput ok=1..5/M,warn=1..300/M/B Let's check the readability of some examples: check_http https://foo.com --time ok=0..5/s,warn=5..10/s \ --size ok=3..5/kB \ --ssl-expiry ok=28..inf/d,warn=14..28/d old: check_procs -w 8096 -c 16182 -C httpd --metric VSZ new: check_procs -C httpd --vsize ok=0..8096,warn=8096..16182 old: check_procs -w 6:13 -c 4:18 -u mqm -a AKBLD new: check_procs -u mqm -a AKBLD --count ok=6..13,warn=4..18 (I'm not sure whether that overlapping warn range would work) old: check_procs -w 1:1 -c 1:1 -C tnslsnr new: check_procs -C tnslsnr --count ok=1..1 From perldork at webwizarddesign.com Tue Apr 1 05:09:31 2008 From: perldork at webwizarddesign.com (Max) Date: Mon, 31 Mar 2008 23:09:31 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <077F1B782014ED48A58E7927914D36A0046B99A6@fai01500.bhs.bannerhealth.com> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47ED0C76.1050700@mailing.kaufland-informationssysteme.com> <47ED21ED.60204@mailing.kaufland-informationssysteme.com> <077F1B782014ED48A58E7927914D36A0046B99A6@fai01500.bhs.bannerhealth.com> Message-ID: On Mon, Mar 31, 2008 at 6:55 PM, Vonnahme, Nathan wrote: > check_http https://foo.com > --time ok=0..5/s,warn=5..10/s \ > --size ok=3..5/kB \ > --ssl-expiry ok=28..inf/d,warn=14..28/d > > > old: check_procs -w 8096 -c 16182 -C httpd --metric VSZ > new: check_procs -C httpd --vsize ok=0..8096,warn=8096..16182 > > old: check_procs -w 6:13 -c 4:18 -u mqm -a AKBLD > new: check_procs -u mqm -a AKBLD --count ok=6..13,warn=4..18 > (I'm not sure whether that overlapping warn range would work) > > old: check_procs -w 1:1 -c 1:1 -C tnslsnr > new: check_procs -C tnslsnr --count ok=1..1 I am sold on the readability of this :), very nice, huge improvement over current syntax, the 'ok' range will be a huge win, would the standard then also support the inclusive ... range operator as well as suggested earlier or is it getting too 'chicken scratch-like' having both .. and .... ? Also, are we going to standardize on multiple metrics being or'd as they currently are (which I think is the way intuitively think about threshold tests of metrics) or will there be value in also providing a switch to change from an 'or all' to an 'and all' threshold check mode? check_tcp_states --finwait2 ok=0..50 --synreceived ok=0..100 --or-conditions check_tcp_states --established ok=30...500 --timewait ok=0..200 --and-conditions - Max From nathan.vonnahme at bannerhealth.com Tue Apr 1 20:57:02 2008 From: nathan.vonnahme at bannerhealth.com (Vonnahme, Nathan) Date: Tue, 1 Apr 2008 10:57:02 -0800 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com><47ED0C76.1050700@mailing.kaufland-informationssysteme.com><47ED21ED.60204@mailing.kaufland-informationssysteme.com><077F1B782014ED48A58E7927914D36A0046B99A6@fai01500.bhs.bannerhealth.com> Message-ID: <077F1B782014ED48A58E7927914D36A0046B9ADD@fai01500.bhs.bannerhealth.com> > I am sold on the readability of this :), very nice, huge improvement > over current syntax, the 'ok' range will be a huge win, would the > standard then also support the inclusive ... range operator as well as > suggested earlier or is it getting too 'chicken scratch-like' having > both .. and .... ? I think one inclusive range operator (..), a negation operator (^), and 3 possible ranges (ok,warn,crit) can handle at least 99% of uses. At least in N::P, that's as complex as the data structures for the thresholds. > Also, are we going to standardize on multiple metrics being or'd as > they currently are (which I think is the way intuitively think about > threshold tests of metrics) or will there be value in also providing a > switch to change from an 'or all' to an 'and all' threshold check > mode? > > check_tcp_states --finwait2 ok=0..50 --synreceived ok=0..100 --or-conditions > > check_tcp_states --established ok=30...500 --timewait ok=0..200 --and- > conditions I think it's intuitive when checking multiple values in one plugin that the "worst" failure gets reported. A mixed result of 9 OK, 1 warning and 1 critical should return CRITICAL. If someone wants other behavior I think it should be split into multiple plugin invocations. From perldork at webwizarddesign.com Tue Apr 1 21:16:57 2008 From: perldork at webwizarddesign.com (Max) Date: Tue, 1 Apr 2008 15:16:57 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <077F1B782014ED48A58E7927914D36A0046B9ADD@fai01500.bhs.bannerhealth.com> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> <47ED0C76.1050700@mailing.kaufland-informationssysteme.com> <47ED21ED.60204@mailing.kaufland-informationssysteme.com> <077F1B782014ED48A58E7927914D36A0046B99A6@fai01500.bhs.bannerhealth.com> <077F1B782014ED48A58E7927914D36A0046B9ADD@fai01500.bhs.bannerhealth.com> Message-ID: > I think one inclusive range operator (..), a negation operator (^), and > 3 possible ranges (ok,warn,crit) can handle at least 99% of uses. At > least in N::P, that's as complex as the data structures for the > thresholds. Ok, so that is a 'no' on you thinking we need inclusive and exclusive ranges. > > check_tcp_states --finwait2 ok=0..50 --synreceived ok=0..100 > --or-conditions > > > > check_tcp_states --established ok=30...500 --timewait ok=0..200 --and- > > conditions > > I think it's intuitive when checking multiple values in one plugin that > the "worst" failure gets reported. A mixed result of 9 OK, 1 warning > and 1 critical should return CRITICAL. If someone wants other behavior > I think it should be split into multiple plugin invocations. I think I didn't explain myself clearly :). Yes, the worst state always bubbles up as the plugin status, that is intuitive, I agree. My point was that with the "OR" case either finwait or synreceived (in the example above) would trigger an alert if either went out of ok() range whereas with an 'and' they would both have to be out of range to trigger an alert. - Max From jimmy.mathew1 at wipro.com Wed Apr 2 14:28:54 2008 From: jimmy.mathew1 at wipro.com (jimmy.mathew1 at wipro.com) Date: Wed, 2 Apr 2008 17:58:54 +0530 Subject: [Nagiosplug-devel] plugins in java Message-ID: Hi Is it possible to write nagios pugin in java I tried to execute a shell script as nagios pugin that executes a java program That script can be executed successfully in a particularly directory(/home/jj/slof/release/slomonitor) But when i try to execute that script as a nagios plugin it gives java exception (java.lang.NoClassDefFoundError). I have defined the command for this plugin in commands.cfg with command_line as /home/jj/slof/release/slomonitor/xen_availb.sh where xen_availb.sh is the name of the script please help Thanks Jimmy Mathew ------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dermoth at aei.ca Wed Apr 2 14:46:40 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 02 Apr 2008 08:46:40 -0400 Subject: [Nagiosplug-devel] plugins in java In-Reply-To: References: Message-ID: <47F38030.5000608@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/04/08 08:28 AM, jimmy.mathew1 at wipro.com wrote: > > Hi > > Is it possible to write nagios pugin in java > > I tried to execute a shell script as nagios pugin that executes a java > program > > That script can be executed successfully in a particularly > directory(/home/jj/slof/release/slomonitor) > > But when i try to execute that script as a nagios plugin it gives java > exception (java.lang.NoClassDefFoundError). > > I have defined the command for this plugin in commands.cfg with > command_line as > /home/jj/slof/release/slomonitor/xen_availb.sh where xen_availb.sh is > the name of the script You should be able to make it working... Make sure you don't rely on environment variables or being started in a specific directory. Also make sure the process doesn't require special privileges... check if you can run it as your Nagios user... Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH84Aw6dZ+Kt5BchYRApdQAKCBpyzg92iLm1iJRjRLD9yTvYT60ACfaNsP MNqGLKmZORAWZY+wMuv7YTE= =DIix -----END PGP SIGNATURE----- From nathan.vonnahme at bannerhealth.com Wed Apr 2 19:46:46 2008 From: nathan.vonnahme at bannerhealth.com (Vonnahme, Nathan) Date: Wed, 2 Apr 2008 09:46:46 -0800 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com><47ED0C76.1050700@mailing.kaufland-informationssysteme.com><47ED21ED.60204@mailing.kaufland-informationssysteme.com><077F1B782014ED48A58E7927914D36A0046B99A6@fai01500.bhs.bannerhealth.com><077F1B782014ED48A58E7927914D36A0046B9ADD@fai01500.bhs.bannerhealth.com> Message-ID: <077F1B782014ED48A58E7927914D36A0046B9C7D@fai01500.bhs.bannerhealth.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- > devel-bounces at lists.sourceforge.net] On Behalf Of Max > > > check_tcp_states --finwait2 ok=0..50 --synreceived ok=0..100 > > --or-conditions > > > > > > check_tcp_states --established ok=30...500 --timewait ok=0..200 --and- > > > conditions > > > > I think it's intuitive when checking multiple values in one plugin that > > the "worst" failure gets reported. A mixed result of 9 OK, 1 warning > > and 1 critical should return CRITICAL. If someone wants other behavior > > I think it should be split into multiple plugin invocations. > > I think I didn't explain myself clearly :). Yes, the worst state > always bubbles up as the plugin status, that is intuitive, I agree. > > My point was that with the "OR" case either finwait or synreceived (in > the example above) would trigger an alert if either went out of ok() > range whereas with an 'and' they would both have to be out of range to > trigger an alert. > I guess I can't imagine why you would ever really want "AND"... if any of the metrics are outside of the OK range you should get an alert. But I'm not really familiar with check_tcp_states so maybe I'm missing the point of your example. There's no reason a particular plugin couldn't implement an option to AND things (or XOR) instead of OR them, but I don't think that's a normal requirement so it wouldn't need to go in the default arg/threshold handling routines or syntax definition. -n From israel at frontierflying.com Wed Apr 2 22:28:05 2008 From: israel at frontierflying.com (Israel Brewster) Date: Wed, 2 Apr 2008 12:28:05 -0800 Subject: [Nagiosplug-devel] Plugins OS X 10.4 build on 10.5 Message-ID: <1E05059A-A83E-43C7-8E75-09B1A1FEBB6A@frontierflying.com> I am running Mac OS X 10.5.2 on my development machine, but I need to build a copy of the check_ping plugin to deploy to a machine running 10.4. Unfortunately, a plugin (or, at least, that plugin) built under 10.5 will not run under 10.4, simply giving a "bus error" when attempting to run. I got around this problem in the past (when building other things) by giving the "-isysroot /Developer/SDKs/ MacOSX10.4u.sdk" flag to gcc, but when I try that with the nagios plugins package, I get the following errors (on running make): gcc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -o check_apt check_apt.o utils.o runcmd.o -L/Users/israel/Downloads/nagios-plugins-1.4.11/ plugins ../lib/libnagiosplug.a ../gl/libgnu.a Undefined symbols: "_getrlimit$UNIX2003", referenced from: _np_runcmd_open in runcmd.o "_kill$UNIX2003", referenced from: _popen_timeout_alarm_handler in runcmd.o "_read$UNIX2003", referenced from: ... There are several more lines similar to those above. Configure was run as CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk" ./configure, and completed with no problem, as does the entire build process without the -isysroot flag. Can anyone tell me what I am doing wrong, and how to make this work? Thanks! ----------------------------------------------- Israel Brewster Computer Support Technician Frontier Flying Service Inc. 5245 Airport Industrial Rd Fairbanks, AK 99709 (907) 450-7250 x293 ----------------------------------------------- From ton.voon at altinity.com Thu Apr 3 02:01:37 2008 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 3 Apr 2008 01:01:37 +0100 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <077F1B782014ED48A58E7927914D36A0046B9C7D@fai01500.bhs.bannerhealth.com> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com><47ED0C76.1050700@mailing.kaufland-informationssysteme.com><47ED21ED.60204@mailing.kaufland-informationssysteme.com><077F1B782014ED48A58E7927914D36A0046B99A6@fai01500.bhs.bannerhealth.com><077F1B782014ED48A58E7927914D36A0046B9ADD@fai01500.bhs.bannerhealth.com> <077F1B782014ED48A58E7927914D36A0046B9C7D@fai01500.bhs.bannerhealth.com> Message-ID: Hi! Great thread! I've updated the RFC with the main points from this discussion. I've chosen the format of the range as start..end - this looks to be the most popular choice. I agree that the range definition should be definable without quoting if possible, but I also think we need negation and explicit inclusion/ exclusion, so I've added in a "complex range" definition, which does require quoting. It uses the mathematical symbols of () for exclusion, [] for inclusion and the programming symbol of ! for negation. However, I think most uses of the new thresholds will just be via the simple method. The complex range doesn't need to be implemented immediately. Also, I've stated that you can have non-continuous ranges by specifying ok,warn or critical again - this doesn't need to be implemented straight away either. I think the rules to calculate the state of the threshold is important to publish - I'm sure someone will let me know if the logic is missing something. The only thing I don't like is that uom is in a different subgetopt - I think it reads better to be after the end value (I think Nathan's principle of optimising for read, rather than write, is a good principle). http://nagiosplugins.org/rfc/new_threshold_syntax Next set of 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 nathan.vonnahme at bannerhealth.com Thu Apr 3 20:04:55 2008 From: nathan.vonnahme at bannerhealth.com (Vonnahme, Nathan) Date: Thu, 3 Apr 2008 10:04:55 -0800 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com><47ED0C76.1050700@mailing.kaufland-informationssysteme.com><47ED21ED.60204@mailing.kaufland-informationssysteme.com><077F1B782014ED48A58E7927914D36A0046B99A6@fai01500.bhs.bannerhealth.com><077F1B782014ED48A58E7927914D36A0046B9ADD@fai01500.bhs.bannerhealth.com><077F1B782014ED48A58E7927914D36A0046B9C7D@fai01500.bhs.bannerhealth.com> Message-ID: <077F1B782014ED48A58E7927914D36A0046B9E59@fai01500.bhs.bannerhealth.com> The updated RFC looks good, Ton. I especially like the clarification and definition of the term 'level', and the published state calculation rules. I think the simple I think you should add a section of other examples, because they demonstrate the readability and consistency which you're trying to solve. Here are some based on our Nagios conf (The first one is your HTTP example.)... I don't know if we need to include the old examples? Also, I suppose the last one is how it would apply to check_load, right? # check the host's HTTP response time, size and age are within "normal" ranges (it will be CRITICAL otherwise) check_http -H $HOSTADDRESS$ \ --time=ok=0..5,uom=s \ --size=ok=10..inf,uom=kb \ --age=ok=0..1,uom=d ### BTW, I like that this makes you think, "hrm, maybe infinity size would be a Bad Thing", unlike the old -m 10000 # httpd processes are OK if the virtual size is under 8096 bytes. WARN until they reach 16182, but bigger than that is CRITICAL. # old: check_procs -w 8096 -c 16182 -C httpd --metric VSZ # new: check_procs -C httpd \ --vsize ok=0..8096,warn=8097..16182 # there should always be one and only one 'tnslsnr' process. Otherwise it's CRITICAL. # old: check_procs -w 1:1 -c 1:1 -C tnslsnr # new: check_procs -C tnslsnr --count ok=1..1 # load averages (1,5,15 minute) should be within reasonable ranges. # old: check_load -w 1.0,0.8,0.7 -c 1.5,1.3,1.0 # new: check_load \ --1min=ok=0..1.0,warn=1.0..1.5 \ --5min=ok=0..0.8,warn=0.8..1.3 \ --15min=ok=0..0.7,warn=0.7..1.0 That makes me think also about endpoints. On that check_load example we should test that a 1 minute load of 1.000 is OK but 1.01 means WARNING... Do we maybe expect that a simple "OK" definition is inclusive of endpoints, but the warn/critical is exclusive? Or is it that overlapping ranges should be evaluated from better to worse, so that ok=3..5,warn=2..6 works as expected ? That is, given this overlapping threshold definition: ok=3..5,warn=2..6 we expect these values to give these results 0: CRITICAL 1: CRITICAL 2: WARN 3: OK 4: OK 5: OK 6: WARN 7: CRITICAL 8: CRITICAL I think if you swap rules #3 and #4 it would evaluate that example as expected, and it also solves the overlapping endpoints above. I think you also should change rule #1 (no levels specified) to return UNKNOWN -n From ae at op5.se Fri Apr 4 16:57:50 2008 From: ae at op5.se (Andreas Ericsson) Date: Fri, 04 Apr 2008 16:57:50 +0200 Subject: [Nagiosplug-devel] plugins in java In-Reply-To: References: Message-ID: <47F641EE.5050202@op5.se> jimmy.mathew1 at wipro.com wrote: > Hi > > Is it possible to write nagios pugin in java > It is, but it sucks. The reason being that java processes requires a virtual machine to run, which means the plugins require astonishing amounts of system resources to even say "Hello, world!". If it was a one-shot program, that would be just fine, but plugins are meant to be run over and over again, with quite short intervals, and they aren't meant to live very long. The start-up overhead of the virtual machine just doesn't make java plugins a very attractive option. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ton.voon at altinity.com Fri Apr 4 23:38:04 2008 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 4 Apr 2008 22:38:04 +0100 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: <077F1B782014ED48A58E7927914D36A0046B9E59@fai01500.bhs.bannerhealth.com> References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com><47ED0C76.1050700@mailing.kaufland-informationssysteme.com><47ED21ED.60204@mailing.kaufland-informationssysteme.com><077F1B782014ED48A58E7927914D36A0046B99A6@fai01500.bhs.bannerhealth.com><077F1B782014ED48A58E7927914D36A0046B9ADD@fai01500.bhs.bannerhealth.com><077F1B782014ED48A58E7927914D36A0046B9C7D@fai01500.bhs.bannerhealth.com> <077F1B782014ED48A58E7927914D36A0046B9E59@fai01500.bhs.bannerhealth.com> Message-ID: <92C7FAE3-6468-4964-9B5F-7593796DAF97@altinity.com> On 3 Apr 2008, at 19:04, Vonnahme, Nathan wrote: > I think you should add a section of other examples, because they > demonstrate the readability and consistency which you're trying to > solve. Good idea. Added: http://nagiosplugins.org/rfc/new_threshold_syntax > Do we maybe expect that a simple "OK" definition is inclusive of > endpoints, but the warn/critical is exclusive? For simplicity, I'd say all simple ranges are inclusive. > Or is it that overlapping ranges should be evaluated from better to > worse, so that ok=3..5,warn=2..6 works as expected ? It is the rules that define the priority of the range calculation and hence alert level for overlapping ranges: http://nagiosplugins.org/rfc/new_threshold_syntax#state_rules > That is, given > this overlapping threshold definition: > > ok=3..5,warn=2..6 > > we expect these values to give these results > > 0: CRITICAL > 1: CRITICAL > 2: WARN > 3: OK > 4: OK > 5: OK > 6: WARN > 7: CRITICAL > 8: CRITICAL > > I think if you swap rules #3 and #4 it would evaluate that example as > expected, and it also solves the overlapping endpoints above. I think the rules already give those exact results. When I first thought about the rules, it seemed weird to have rule #3 as critical, when you'd expect warning. But think of it this way: you are interested in defining success or failure; a shade of grey is when you're not too sure. BTW, I added an extra "if an ok level is defined, return critical" because Thomas pointed out otherwise you can never get an ok status without an ok level defined. > I think you also should change rule #1 (no levels specified) to return > UNKNOWN No - that should be OK, because I'm using that as the mechanism to decide that I want performance data to be graphed. Maybe I shouldn't be overloading the threshold definition, but having no levels doesn't really make sense in any other context. 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 Sat Apr 5 10:45:58 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sat, 05 Apr 2008 04:45:58 -0400 Subject: [Nagiosplug-devel] New threshold syntax (New thread) Message-ID: <47F73C46.1040305@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, My intent is to provide my suggestion on the latest RFC specification (dated 17 March 2008 - 5:07pm) so to make thing clear I'm starting a new thread. These suggestion have been discussed a bit on the #nagios-devel irc channel and this email will formalize them. Everithing in thes imail relates to the "Thresholds" section, although the proposed changes will reflect in many of the subsequent sections. http://nagiosplugins.org/rfc/new_threshold_syntax#thresholds Issue #1: The current specification of thresholds says the new system will use "--{metric} {definition}" to define new thresholds. The definition is a getsubopt(3) list . In regard to this method the new specification will cause conflicts because some plugins already us similar longopt names for thresholds that will be converted to the new format. Instead, I suggest using "--threshold" (or the shorter "--thresh" if it's too long) to specify the threshold string, and add the suboption "metric" to define which metric we're setting the threshold against. For example, to check the SSL certificate using check_tcp (that already has "--certificate") I could use: check_tcp -H myhst -S --thresh metric=certificate,warn=<...>,crit=<...> The plugin --help output would print a table of all supported metrics, descriptions, etc. Issue #2: The specs should clearly state what uom is and also add uom_prefix (or just prefix if it's preferred). The current meaning of uom should actually be uom_prefix. Both would be optionnal. uom shouldn't be needed in almost all plugins because the plugin already know that the thresholds is. It would be useful for checks that are more generic like check_snmp and check_nt as they can retrieve value they have no knowledge about. uom is generally a single character (although it can be more than one) that defines the type of value. It is used in printing the plugin output _and_ the performance data. Some example of uom units: http://physics.nist.gov/cuu/Units/units.html http://physics.nist.gov/cuu/Units/outside.html uom_prefix (or prefix) defined a multiplier for: a. defining the threshold level (the value are multiplied/divided by the prefix) b. printing the retrived value in the _plugin_ output. No matter what prefix is used the performance data should remain the same. Plugins may define a default prefix fro any threshold. Prefixes are strictly defined by the prefix tables found on these pages: http://physics.nist.gov/cuu/Units/prefixes.html http://physics.nist.gov/cuu/Units/binary.html One cannot "invent" new prefixes as the plugin needs to know what the multiplier/divider is. For example, to send a warning when a page size isn't between 60KiB and 80KiB with check_http, one could use: - --threshold metric=size,ok=60..80,warn=inf..inf,uom_prefix=Ki Note that uom is not defined - check_http know it's in bytes (B) The plugin would return the data in KiB. ex.: HTTP OK HTTP/1.1 - 70.99KiB in 0.018 seconds However the perfdata will stay in bytes: time=0.18082s;;;0.000000 size=72694B;61440;81920;0 This new specs seems very good to me and outside the aforementioned issues I fully support the latest RFC. I also wish to give special thanks to everyone who participated in the discussion and helped make the new syntax better and simpler. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH9zxG6dZ+Kt5BchYRAjqdAJ9fVQ6A7SvgzvY+eai8Qwj+jKZoBwCg72xy cuV6cs6l6/6kAS5zEgTujR4= =c6tc -----END PGP SIGNATURE----- From william at leibzon.org Sat Apr 5 16:23:08 2008 From: william at leibzon.org (William Leibzon) Date: Sat, 5 Apr 2008 07:23:08 -0700 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: > On Mon, Mar 17, 2008 at 2: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! > > Comments? I'm going to comment on it even if its a bit late... And quickly my personal "vote" would be NO, but I have mostly outsider perspective and NO does not mean I'm like existing threshold either and have not used it when developing my plugins until very recently. I probably will not participate in this thread as I have only limited time right now but will answer specific questions to me if there are any. First of I'd like to note that above proposal moves to the idea that each threshold is a separate parameter checked by plugin for which critical/warning/ok are to be specified. For such a case the syntax could work if the parameter to the plugin is stable and so can have its own command line parameter. But this is not all so in every case. It is especially not so for plugins that I write where parameters are called attributes and are specified on command line to the plugin and their numbers change depending on use. In such and similar cases it is a lot better to have --warning and --critical command-line parameter and spec on how to specify it. This is also what people are used to who used nagios for many years. Additionally in new syntax you now have "ok", "warn", "crit" and that I think would end up being confusing (and make code more difficult) especially if people start specifying all 3 together. I also think that people do not like it when you change plugin spec code too much/too often and with nagios plugins you want to be as backward-compatible from one release of the plugin to another (admins expect to be able to just drop in your new version of code as replacement for what they currently have and then they may look at use of new features and further changes). You maybe able to support both as you'd specific new syntax as "crit=.." where as old one did not have but supporting multiple syntax versions in same code makes it larger and more difficult to maintain. Now I'm not saying you should not do it and extend your current syntax if there is a legitimate need and problems reported, just be warned about consequences and difficulties... I also generally found you "range" based syntax to be somewhat counter-intuitive and as far as a:b specifying alert when OUTSIDE of the range. Perhaps this can be fixed fairly easily by adapting new separator (a..b is alert when >a and ",'=","!" specifying if alert (critical or warning depending on where that is in) is to be issued when plugin data is below, above or equal or not equal to value specified. Of the people I know that use my plugins they find it all fairly straight forward but the symbols are a bit of an issue because > and < are special symbols in bash, etc. so result is often enough that for proper call to plugin you have to quote it all in "" to work. At some point I came upon page about nagios plugins threshold syntax (can't immediately remember url) and while I found that syntax somewhat odd, when it came down to extending my syntax to support ranges (which are really very really needed) I decided to use that to be compatible with what others do and to support users who are familiar with that spec. So currently this is a full spec documented in plugin code: # Warning and critical thresholds are specified with '-w' and '-c' and each # one must have exact same number of values to be checked (separated by ',') # as number of variables specified with '-a'. Any values you dont want to # compare you specify as ~ (or just not specify a value, i.e. ',,'). # # There are also number of other one-letter modifiers that can be used # as prefix before actual data value to direct how data is to be checked. # These prefixes are as follows: # > : issue alert if data is above this value (default for numeric value) # < : issue alert if data is below this value (must be followed by number) # = : issue alert if data is equal to this value (default for non-numeric) # ! : issue alert if data is NOT equal to this value # # Additionally supported are two specifications of range formats: # number1:number2 issue alert if data is OUTSIDE of range [number1..number2] # i.e. alert if data<$number1 or data>$number2 # @number1:number2 issue alert if data is WITHIN range [number1..number2] # i.e. alert if data>=$number and $data<=$number2 Well ok, going back to your new spec question and again taking personal perspective, I can tell that if plugin syntax seriously changes, I probably would not be willing to rewrite my code (although adding support for ".." to work same as @a:b is easy enough and that I might do that) and I also have no near-term plans to start using Nagios::Plugins library either (I think its bloated and difficult but that is really issue for another discussion which I do not want to start here). William -------------- next part -------------- An HTML attachment was scrubbed... URL: From dermoth at aei.ca Sat Apr 5 16:53:29 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sat, 05 Apr 2008 10:53:29 -0400 Subject: [Nagiosplug-devel] New threshold syntax (New thread) In-Reply-To: <47F73C46.1040305@aei.ca> References: <47F73C46.1040305@aei.ca> Message-ID: <47F79269.3040901@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/04/08 04:45 AM, Thomas Guyot-Sionnest wrote: > Hi, > > My intent is to provide my suggestion on the latest RFC specification > (dated 17 March 2008 - 5:07pm) so to make thing clear I'm starting a new Correction: The revision date was: 4 Apr 2008 - 5:26pm I just copied the date without realizing it was the original posting date... Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH95Jp6dZ+Kt5BchYRAoJaAKCA95GRUL9NGNODaZeFdDBYxvrBqACfdGHf TGMRB4AAQ6AyQL52qQqXFoI= =PfwX -----END PGP SIGNATURE----- From dermoth at aei.ca Sun Apr 6 05:27:37 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sat, 05 Apr 2008 23:27:37 -0400 Subject: [Nagiosplug-devel] RFC: New threshold syntax In-Reply-To: References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com> Message-ID: <47F84329.9070004@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/04/08 10:23 AM, William Leibzon wrote: >> On Mon, Mar 17, 2008 at 2: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! >> >> Comments? > > I'm going to comment on it even if its a bit late... And quickly my > personal "vote" would be NO, but I have mostly outsider perspective and > NO does not mean I'm like existing threshold either and have not used it > when developing my plugins until very recently. I probably will not > participate in this thread as I have only limited time right now but > will answer specific questions to me if there are any. > > First of I'd like to note that above proposal moves to the idea that > each threshold is a separate parameter checked by plugin for which > critical/warning/ok are to be specified. For such a case the syntax > could work if the parameter to the plugin is stable and so can have its > own command line parameter. But this is not all so in every case. It is > especially not so for plugins that I write where parameters are called > attributes and are specified on command line to the plugin and their > numbers change depending on use. In such and similar cases it is a lot > better to have --warning and --critical command-line parameter and spec > on how to specify it. This is also what people are used to who used I have to disagree with this, although it's an interesting point that could be taken into account when writing the new lib. There's nothing that prevent us to let the plugin receive unparsed threholds and deal with them, or provide a way for on-demand thresholds. So you could have "metric=var:VAR1,..." and then the plugin yould use what'S after the first colon as the custom variable you're checking against. > nagios for many years. Additionally in new syntax you now have "ok", > "warn", "crit" and that I think would end up being confusing (and make > code more difficult) especially if people start specifying all 3 You don't have to specify all, so it's up to you to decide what you want to so. ok-range has been thought as a special range that takes precedence over the others so it makes an easy way to specifi only the accepted range. IMHO it make things easier for users. Regarding the code, it should also be just as simple as before. We're also thinking about providing a C library (and obviously include them in N::P). > together. I also think that people do not like it when you change plugin > spec code too much/too often and with nagios plugins you want to be as > backward-compatible from one release of the plugin to another (admins > expect to be able to just drop in your new version of code as > replacement for what they currently have and then they may look at use > of new features and further changes). You maybe able to support both as > you'd specific new syntax as "crit=.." where as old one did not have but > supporting multiple syntax versions in same code makes it larger and > more difficult to maintain. It will be backward compatible. We want to make this transition as seamless as possible and therefore we'll make sure that in the next minor release (which doesn't happen that ofter btw - we're at out first major and last minor change was a few years ago). The new thresholds will be a huge enhancement and will allow some plugins that still doesn't use the official threshold formats due to limitation to finally provide them. It will also be much easier to add all plugin metrics as real thresholds (many only allow criticals or warnings) without having many new and confusing switches. Any new metric added will not clobber the current option section of --help which is, in some plugins, very long and disorganized. Finally it will open the door for multi-range thresholds. > Now I'm not saying you should not do it and extend your current syntax > if there is a legitimate need and problems reported, just be warned > about consequences and difficulties... I also generally found you > "range" based syntax to be somewhat counter-intuitive and as far as a:b > specifying alert when OUTSIDE of the range. Perhaps this can be fixed > fairly easily by adapting new separator We're fully warned, and we'll do our best to use the community feedback to make them as intuitive and simple as possible while getting rid of previous limitations and opening new possibilities. This task is as hard as my last sentence was hard to read, but this is something that must get done. > (a..b is alert when >a and single value (no 'a:b" just a) be understood as single upper threshold > to be compatible with how existing people have used nagios for years. Compatibility will be held with the original switches. There is no reason to make the specs harder for backward compatibility as the command line will have to be changed to use new thresholds anyways. On the other hand, we willll definitely look into helper tools, switch or something else to get new thresholds out of legacy ones. > Now I'll give personal perspective of what I have done in my plugins and > custom spec I use (which I do not recommend you adapt but seeing it may > help in some way). In most of my plugins there are many "attributes" > that are checked as for example in: > http://william.leibzon.org/nagios/plugins/check_mysqld.pl > where attributes are variables from "SHOW STATUS" and you specify which > ones to check (similar also for number of my other plugins at > http://william.leibzon.org/nagios such as check_snmp_temperature, > check_jboss and others; although code is older as far as thresholds > parsing in them but that will slowly get updated). So I adapted system > where list of Attributes are specified with one command line parameter > (usually -a and then alphanumeric list separated by ','), warning > threshold values with another (usually --warn with threshold spec values > separated with ',' - empty/no value if there is no threshold) and > similarly critical. This turns to work pretty well although you can > argue that there are better ways to do it... I also wrote code that > handles threshold spec in my plugins (which is largely same for every > one) before I even knew there is "official threshold spec". So doing it > independently I created threshold syntax of [prefix]value where prefix > is one of "<",">",'=","!" specifying if alert (critical or warning > depending on where that is in) is to be issued when plugin data is > below, above or equal or not equal to value specified. Of the people I > know that use my plugins they find it all fairly straight forward but > the symbols are a bit of an issue because > and < are special symbols in > bash, etc. so result is often enough that for proper call to plugin you > have to quote it all in "" to work. At some point I came upon page about > nagios plugins threshold syntax (can't immediately remember url) and > while I found that syntax somewhat odd, when it came down to extending > my syntax to support ranges (which are really very really needed) I > decided to use that to be compatible with what others do and to support > users who are familiar with that spec. So currently this is a full spec > documented in plugin code: > > # Warning and critical thresholds are specified with '-w' and '-c' and each > # one must have exact same number of values to be checked (separated by ',') > # as number of variables specified with '-a'. Any values you dont want to > # compare you specify as ~ (or just not specify a value, i.e. ',,'). > # > # There are also number of other one-letter modifiers that can be used > # as prefix before actual data value to direct how data is to be checked. > # These prefixes are as follows: > # > : issue alert if data is above this value (default for numeric value) > # < : issue alert if data is below this value (must be followed by number) > # = : issue alert if data is equal to this value (default for non-numeric) > # ! : issue alert if data is NOT equal to this value > # > # Additionally supported are two specifications of range formats: > # number1:number2 issue alert if data is OUTSIDE of range [number1..number2] > # i.e. alert if data<$number1 or data>$number2 > # @number1:number2 issue alert if data is WITHIN range [number1..number2] > # i.e. alert if data>=$number and $data<=$number2 Care was taken to provide as much capabilities without having to escape the threshold definition. User questions regarding improperly escaped characters if something that can be seen on a regular basis on all the public Nagios/nagios-plugins mailing lists. This therefore was a big priority in defining the format. > Well ok, going back to your new spec question and again taking personal > perspective, I can tell that if plugin syntax seriously changes, I > probably would not be willing to rewrite my code (although adding > support for ".." to work same as @a:b is easy enough and that I might do > that) and I also have no near-term plans to start using Nagios::Plugins > library either (I think its bloated and difficult but that is really > issue for another discussion which I do not want to start here). The ides is that you shouldn't have to do much in your plugin. You'll definitely won't have to deal with threshold definition characters but rather with threshold objects. - - On a side note, I had a quick look at your plugin and there was something in the TODO about retaining data... There's a much better way to reuse last check data than using a file. Just write the last unix timestamp and your data in the perfdata line, and then retrieve it on the next check by passing it on the command line. I wrote a plugin that does it (not released yet). I just pasted the code in a pastebin... It reads CSV performance logs written by Windows. It might look a bit complex for what it does but it's based on a cacti script (there are no embedded Perl in cacti) and therefore was coded for optimal performance no matter how large the log file is. http://nagios.pastebin.com/m352a3dd8 getlog.pl (I can send it too if you want) doesn't use a single Perl module, although I activate warnings and strict for development. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+EMp6dZ+Kt5BchYRAmW5AJ9L+qXrjWqO9saP4H4dMw7F6ImFlgCdExuo rlNA9miWqyf5qKllya6GFio= =oQQl -----END PGP SIGNATURE----- From noreply at sourceforge.net Thu Apr 10 01:56:07 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Apr 2008 16:56:07 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1939022 ] SSL/TLS hostname extension support (SNI) Message-ID: Patches item #1939022, was opened at 2008-04-09 19:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1939022&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: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joe Presbrey (presbrey) Assigned to: Nobody/Anonymous (nobody) Summary: SSL/TLS hostname extension support (SNI) Initial Comment: Patch against Plugin Version (-V output): SVN trunk Plugin Name: sslutils/check_http Example Plugin Commandline: check_http -H wildcard.scripts.mit.edu -S -C 14 Tested on operating system: debian/4.0 Tested on architecture: i686 Tested with compiler: gcc-4.1.2-20061115 A TLS extension called "Server Name Indication" allows name-based HTTPS virtual hosting. (From Gentoo: http://gentoo-wiki.com/HOWTO_Apache_with_Name_Based_Hosting_and_SSL). This is especially common when serving HTTPS requests with a wildcard certificate (*.domain.tld). This patch adds a call to SSL_set_tlsext_host_name (OpenSSL 0.9.8f and higher) in the certificate check section of sslutils to allow certificate verification of HTTPS virtual-host domains. This patch also corrects the expiration check to escalate to 'critical' when the certificate is expired but for less than 1 day (currently emits 'warning') and displays the time-zone with the expiration time. Joe Presbrey ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1939022&group_id=29880 From noreply at sourceforge.net Thu Apr 10 18:10:54 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Apr 2008 09:10:54 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1939529 ] check_tcp: Message-ID: Bugs item #1939529, was opened at 2008-04-10 12:10 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=1939529&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: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Buchbinder (gdrago23) Assigned to: Nobody/Anonymous (nobody) Summary: check_tcp: Initial Comment: I am running nagios-plugins 1.4.11, the version from Ubuntu Hardy, backported to Feisty. $ /usr/lib/nagios/plugins/check_tcp -S -H www.google.com -p 443 -D 10; echo $? OK - Certificate will expire on 05/14/2008 23:18. TCP OK - 0.084 second response time on port 443|time=0.083917s;;;0.000000;10.000000 0 $ /usr/lib/nagios/plugins/check_tcp -S -H www.google.com -p 443 -D 295; echo $? WARNING - Certificate expires in 34 day(s) (05/14/2008 23:18). CRITICAL - Cannot retrieve server certificate. 1 The plugin only returns WARNING, as it should, but the second result line is wrong--the server certificate is indeed being retrieved, and the plugin isn't returning CRITICAL. Looking through the check_tcp.c source, it appears that np_net_ssl_check_cert is returning CRITICAL when the certificate can't be retrieved or parsed, or when it's expired, and WARNING when it's going to expire within the interval specified by the "-D" option. check_tcp interprets any answer other than STATE_OK as a failure to retrieve the cert. The root problem seems to be a conflation of Nagios return codes with function return codes; a plugin may interpret a failure to retrieve the certificate at all quite differently from the retrieval of an expired or soon-to-expire certificate. Perhaps it would be a better idea to have np_net_ssl_check_cert return STATE_UNKNOWN when it can't retrieve the SSL cert information, and STATE_WARNING/STATE_CRITICAL when there's a problem with it, so that the calling program can differentiate between the two types of event. Failing that, check_tcp should check for (result != STATE_OK && result != STATE_WARNING) rather than just (result != STATE_OK). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1939529&group_id=29880 From noreply at sourceforge.net Thu Apr 10 18:11:49 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Apr 2008 09:11:49 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1939529 ] check_tcp: Expiring SSL certs produce confusing messages. Message-ID: Bugs item #1939529, was opened at 2008-04-10 12:10 Message generated for change (Settings changed) made by gdrago23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1939529&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: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Buchbinder (gdrago23) Assigned to: Nobody/Anonymous (nobody) >Summary: check_tcp: Expiring SSL certs produce confusing messages. Initial Comment: I am running nagios-plugins 1.4.11, the version from Ubuntu Hardy, backported to Feisty. $ /usr/lib/nagios/plugins/check_tcp -S -H www.google.com -p 443 -D 10; echo $? OK - Certificate will expire on 05/14/2008 23:18. TCP OK - 0.084 second response time on port 443|time=0.083917s;;;0.000000;10.000000 0 $ /usr/lib/nagios/plugins/check_tcp -S -H www.google.com -p 443 -D 295; echo $? WARNING - Certificate expires in 34 day(s) (05/14/2008 23:18). CRITICAL - Cannot retrieve server certificate. 1 The plugin only returns WARNING, as it should, but the second result line is wrong--the server certificate is indeed being retrieved, and the plugin isn't returning CRITICAL. Looking through the check_tcp.c source, it appears that np_net_ssl_check_cert is returning CRITICAL when the certificate can't be retrieved or parsed, or when it's expired, and WARNING when it's going to expire within the interval specified by the "-D" option. check_tcp interprets any answer other than STATE_OK as a failure to retrieve the cert. The root problem seems to be a conflation of Nagios return codes with function return codes; a plugin may interpret a failure to retrieve the certificate at all quite differently from the retrieval of an expired or soon-to-expire certificate. Perhaps it would be a better idea to have np_net_ssl_check_cert return STATE_UNKNOWN when it can't retrieve the SSL cert information, and STATE_WARNING/STATE_CRITICAL when there's a problem with it, so that the calling program can differentiate between the two types of event. Failing that, check_tcp should check for (result != STATE_OK && result != STATE_WARNING) rather than just (result != STATE_OK). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1939529&group_id=29880 From noreply at sourceforge.net Thu Apr 10 19:20:46 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Apr 2008 10:20:46 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1939578 ] check_jabber: Always returns WARNING with Openfire server. Message-ID: Bugs item #1939578, was opened at 2008-04-10 13:20 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=1939578&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: Adam Buchbinder (gdrago23) Assigned to: Nobody/Anonymous (nobody) Summary: check_jabber: Always returns WARNING with Openfire server. Initial Comment: check_jabber always returns WARNING when run against an Openfire Jabber server. It may do so against other servers, but I have no way of checking that. Running check_jabber -v with no -e, -A or -a arguments shows that it expects the string " Bugs item #1939578, was opened at 2008-04-10 13:20 Message generated for change (Settings changed) made by gdrago23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1939578&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: Adam Buchbinder (gdrago23) Assigned to: Nobody/Anonymous (nobody) Summary: check_jabber: Always returns WARNING with Openfire server. Initial Comment: check_jabber always returns WARNING when run against an Openfire Jabber server. It may do so against other servers, but I have no way of checking that. Running check_jabber -v with no -e, -A or -a arguments shows that it expects the string " References: <2E06A674-4DD0-4B43-B561-E79DB2A00980@altinity.com><47ED0C76.1050700@mailing.kaufland-informationssysteme.com><47ED21ED.60204@mailing.kaufland-informationssysteme.com><077F1B782014ED48A58E7927914D36A0046B99A6@fai01500.bhs.bannerhealth.com><077F1B782014ED48A58E7927914D36A0046B9ADD@fai01500.bhs.bannerhealth.com><077F1B782014ED48A58E7927914D36A0046B9C7D@fai01500.bhs.bannerhealth.com><077F1B782014ED48A58E7927914D36A0046B9E59@fai01500.bhs.bannerhealth.com> <92C7FAE3-6468-4964-9B5F-7593796DAF97@altinity.com> Message-ID: <077F1B782014ED48A58E7927914D36A001D06FD9@fai01500.bhs.bannerhealth.com> > -----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, April 04, 2008 1:38 PM > > I think if you swap rules #3 and #4 it would evaluate that example as > > expected, and it also solves the overlapping endpoints above. > > I think the rules already give those exact results. > > When I first thought about the rules, it seemed weird to have rule #3 > as critical, when you'd expect warning. But think of it this way: you > are interested in defining success or failure; a shade of grey is > when > you're not too sure. You are correct... in my example there was no explicit critical so it would fall through. Thanks! From akamatsu at kic.ac.jp Wed Apr 9 02:50:26 2008 From: akamatsu at kic.ac.jp (akamatsu at kic.ac.jp) Date: Wed, 09 Apr 2008 09:50:26 +0900 Subject: [Nagiosplug-devel] BUG report of check_by_ssh.c Message-ID: Thank you for developing Nagios Plugins. I am a teacher of KIC(Kobe Institute of Computing graduate). I have read check_by_ssh.c of latist version nagios-plugins-1.4.11. I have checked -O output-file option. But I can not find messages in the output-file. Please correct source code of line-number of 137,138 in the check_by_ssh.c as follows. 126 /* process output */ 136 if (status_text == NULL) { 137 // printf ("%s", chld_out.line[i]); correct printf(?%s\n?, chld_out.line[i]); 138 // return result; correct continue 139 } Please check, and happy to your replay. From presbrey at gmail.com Thu Apr 10 02:08:57 2008 From: presbrey at gmail.com (Joe) Date: Wed, 9 Apr 2008 20:08:57 -0400 Subject: [Nagiosplug-devel] SSL/TLS hostname extension support (SNI) In-Reply-To: References: Message-ID: <173a8c250804091708q29d4dde2gf2aeb2bc647b8eae@mail.gmail.com> Hey all, the patch I submitted on sourceforge (and inline below) is rather verbose so I'll limit myself to adding just a few other things here. I've been using this patch with nagios plugins 1.4.10 and recently regenerated it for the current subversion trunk (r1977). Correct functioning looks something like this: # ./check_http -H scripts.mit.edu -S -C 14 OK - Certificate will expire on 07/29/2008 16:00 GMT. # ./check_http -H wildcard.scripts.mit.edu -S -C 14 OK - Certificate will expire on 04/08/2009 16:00 GMT. # ./check_http -H presbrey.scripts.mit.edu -S -C 14 OK - Certificate will expire on 04/08/2009 16:00 GMT. Before this patch is applied, check_http can only verify the certificate from the first instantiation shown above; the second and third end up verifying the wrong (non-SNI) certificate. The SNI extension is officially supported in OpenSSL 0.9.8f in the testing branch of several distributions and may become common relatively common soon. Thanks! Joe Presbrey ---------- Forwarded message ---------- From: SourceForge.net Date: Wed, Apr 9, 2008 at 7:56 PM Subject: [ nagiosplug-Patches-1939022 ] SSL/TLS hostname extension support (SNI) To: noreply at sourceforge.net Patches item #1939022, was opened at 2008-04-09 19:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1939022&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: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joe Presbrey (presbrey) Assigned to: Nobody/Anonymous (nobody) Summary: SSL/TLS hostname extension support (SNI) Initial Comment: Patch against Plugin Version (-V output): SVN trunk Plugin Name: sslutils/check_http Example Plugin Commandline: check_http -H wildcard.scripts.mit.edu -S -C 14 Tested on operating system: debian/4.0 Tested on architecture: i686 Tested with compiler: gcc-4.1.2-20061115 A TLS extension called "Server Name Indication" allows name-based HTTPS virtual hosting. (From Gentoo: http://gentoo-wiki.com/HOWTO_Apache_with_Name_Based_Hosting_and_SSL). This is especially common when serving HTTPS requests with a wildcard certificate (*.domain.tld). This patch adds a call to SSL_set_tlsext_host_name (OpenSSL 0.9.8f and higher) in the certificate check section of sslutils to allow certificate verification of HTTPS virtual-host domains. This patch also corrects the expiration check to escalate to 'critical' when the certificate is expired but for less than 1 day (currently emits 'warning') and displays the time-zone with the expiration time. Joe Presbrey ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1939022&group_id=29880 -------------- next part -------------- A non-text attachment was scrubbed... Name: nagiosplug-sni-trunk.patch Type: application/octet-stream Size: 2442 bytes Desc: not available URL: From nathan.vonnahme at bannerhealth.com Fri Apr 11 19:53:27 2008 From: nathan.vonnahme at bannerhealth.com (Vonnahme, Nathan) Date: Fri, 11 Apr 2008 09:53:27 -0800 Subject: [Nagiosplug-devel] New threshold syntax (New thread) In-Reply-To: <47F73C46.1040305@aei.ca> References: <47F73C46.1040305@aei.ca> Message-ID: <077F1B782014ED48A58E7927914D36A001D06FDA@fai01500.bhs.bannerhealth.com> > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On Behalf Of > Thomas Guyot-Sionnest > Sent: Saturday, April 05, 2008 12:46 AM > Issue #1: > > The current specification of thresholds says the new system will use > "--{metric} {definition}" to define new thresholds. The definition is > a > getsubopt(3) list . In regard to this method the new specification > will > cause conflicts because some plugins already us similar longopt names > for thresholds that will be converted to the new format. > > Instead, I suggest using "--threshold" (or the shorter "--thresh" if > it's too long) to specify the threshold string, and add the suboption > "metric" to define which metric we're setting the threshold against. > > For example, to check the SSL certificate using check_tcp (that > already > has "--certificate") I could use: > > check_tcp -H myhst -S > --thresh metric=certificate,warn=<...>,crit=<...> That is not as concise as --certificate=ok=28..inf,warn=14..28 But I guess it will be necessary in most cases and will simplify backwards compatibility. It is still easy to read. > Issue #2: > > The specs should clearly state what uom is and also add uom_prefix > (or > just prefix if it's preferred). The current meaning of uom should > actually be uom_prefix. Both would be optionnal. The SI units lists seems adequate, though probably it would be good to have a shorter list in the plugin documentation, since we don't need most of the physics units. I think the number of bits and abbreviation of binary units (gigabyte etc) should agree with `df -h` and `ls -lh` and other utilities. NIST is defining KB, MB, and GB differently from how they are usually used in practice on most OSes, and I think that would confuse users, because they'll be comparing plugin results with the results from those tools. I'm also guessing that beyond recommending a syntax and a list of valid uom values, the threshold parsing library we're talking about won't do much with the units, but it would be left to each plugin. A widget assembly line plugin might need a weird unit of measure like "thousands of widgets per hour" or KWpH :) From gquigs at gmail.com Tue Apr 15 19:08:15 2008 From: gquigs at gmail.com (Bryan Quigley) Date: Tue, 15 Apr 2008 13:08:15 -0400 Subject: [Nagiosplug-devel] LinuxPowertop nagios plug-in Message-ID: <2e117fdb0804151008r7e27586es19adbcf9e2a2018b@mail.gmail.com> Dear Nagios Plugin developers, I'm about to start work on a Nagios powertop plug-in. Just wanted to check and see if anyone already started working on this. Thanks, Bryan Quigley -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at zango.com Tue Apr 15 20:37:08 2008 From: thomas at zango.com (Thomas Guyot-Sionnest) Date: Tue, 15 Apr 2008 14:37:08 -0400 Subject: [Nagiosplug-devel] LinuxPowertop nagios plug-in In-Reply-To: <2e117fdb0804151008r7e27586es19adbcf9e2a2018b@mail.gmail.com> References: <2e117fdb0804151008r7e27586es19adbcf9e2a2018b@mail.gmail.com> Message-ID: <4804F5D4.6050001@zango.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bryan Quigley wrote: | Dear Nagios Plugin developers, | I'm about to start work on a Nagios powertop plug-in. Just wanted to | check and see if anyone already started working on this. Hi Bryan, http://nagiosexchange.org is the place to look for similar plugins. It is also where you should publish any plugin you write. Thanks - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFIBPXU6dZ+Kt5BchYRAjELAJiJ+BONWXVg7XIVvLYk1AUWP3WtAKCCPAjP nCNZ1IwgRO/fkIXVp8bETw== =ifwE -----END PGP SIGNATURE----- From pgarcia at mcw.edu Tue Apr 15 23:54:06 2008 From: pgarcia at mcw.edu (Garcia, Phillip) Date: Tue, 15 Apr 2008 16:54:06 -0500 Subject: [Nagiosplug-devel] development guidelines pdf? Message-ID: Hi, Are the plug-in development guidelines available as a pdf? Thank you, Phil Garcia From dermoth at aei.ca Wed Apr 16 05:25:37 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 15 Apr 2008 23:25:37 -0400 Subject: [Nagiosplug-devel] development guidelines pdf? In-Reply-To: References: Message-ID: <480571B1.4030009@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/04/08 05:54 PM, Garcia, Phillip wrote: > Hi, > > Are the plug-in development guidelines available as a pdf? They can be compiled to pdf with linuxdoc. The source file (SGML) is in the NAgios-plugins distribution. I believe the command would look like this (although I'm not even trying it): $ linuxdoc --backend=latex --output=pdf input_file.sgml I think it wouldn't be a bad idea to add various file formats for the developer guidelines. I'll eventually look into adding some more... Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIBXGx6dZ+Kt5BchYRAim5AKDDNpZEt5o60idhkMIZMrOiSJhl9wCeMJaV OQef7vPvlGShrUPktfMpfRY= =25Li -----END PGP SIGNATURE----- From pstehlik at sophics.cz Wed Apr 16 12:44:26 2008 From: pstehlik at sophics.cz (Petr Stehlik) Date: Wed, 16 Apr 2008 12:44:26 +0200 Subject: [Nagiosplug-devel] check_overcr patch Message-ID: <4805D88A.80008@sophics.cz> Hi there, (I am not subscribed so please CC: me, thanks) the attached patch fixes parsing of the "LOADx" command line parameter (it never worked, did it?), adds the QUIT to all commands and removes incorrect UT_VERBOSE line from --help usage. Thanks. Petr -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: check_overcr.c.diff URL: From hpsekhon at googlemail.com Thu Apr 17 17:02:00 2008 From: hpsekhon at googlemail.com (Hari Sekhon) Date: Thu, 17 Apr 2008 16:02:00 +0100 Subject: [Nagiosplug-devel] check_apt feature request: No Warning on Non-Security upgrades Message-ID: <48076668.9010003@googlemail.com> Hi, I'm using check_apt v1590 (nagios-plugins 1.4.11) and I'd like to make a feature request to not go in to a warning state when there are non-critical package upgrades available. I tend to only patch on security updates, otherwise you just end up upgrading lots of servers all the time unnecessarily. Perhaps this could be implemented as a switch to enable/disable warning on non critical package updates? I did a similar thing for my check_gentoo_portage check, which seems to make sense, as this way the administrator can choose which he/she prefers depending on the situation. Personally, I don't see the point in having a warning state if the package is not a security risk and there is no new feature you require, it just increases admin workload and the chances of a breakage or incompatibility with the older config. I just don't want to have permanent warnings in nagios until I upgrade packages just for the sake of it. Perhaps somebody has already made this obvious request or it's implemented in a more recent version or in the svn copy or something? Seems so obvious I surely can't be the first to ask...? Thanks -h -- Hari Sekhon From noreply at sourceforge.net Thu Apr 17 22:18:25 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Apr 2008 13:18:25 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1945210 ] Easy Connect support for check_oracle Message-ID: Patches item #1945210, was opened at 2008-04-17 16:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1945210&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: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: richardjq (richardjq) Assigned to: Nobody/Anonymous (nobody) Summary: Easy Connect support for check_oracle Initial Comment: Add in Oracle's new Easy Connect option for check_oracle --login. Original method is maintained. Now you can do: check_oracle --login SID or check_oracle --login hostname SID Note: Easy Connect option requires Oracle 10g or greater. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1945210&group_id=29880 From seanius at seanius.net Tue Apr 22 00:44:17 2008 From: seanius at seanius.net (sean finney) Date: Tue, 22 Apr 2008 00:44:17 +0200 Subject: [Nagiosplug-devel] check_apt feature request: No Warning on Non-Security upgrades In-Reply-To: <48076668.9010003@googlemail.com> References: <48076668.9010003@googlemail.com> Message-ID: <200804220044.24031.seanius@seanius.net> hiya, On Thursday 17 April 2008 05:02:00 pm Hari Sekhon wrote: > Perhaps this could be implemented as a switch to enable/disable warning > on non critical package updates? I did a similar thing for my seems reasonable. i guess an option would be like -C, --critical-only only check for critical updates (will not warn if non-critical packages are available for upgrade) > Perhaps somebody has already made this obvious request or it's > implemented in a more recent version or in the svn copy or something? > Seems so obvious I surely can't be the first to ask...? i think most people using check_apt are tracking stable releases (or have a pinned system), so it afaik it hasn't been asked. but like i said, seems reasonable to ask for it. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From dermoth at aei.ca Tue Apr 22 09:29:38 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 22 Apr 2008 03:29:38 -0400 Subject: [Nagiosplug-devel] check_apt feature request: No Warning on Non-Security upgrades In-Reply-To: <200804220044.24031.seanius@seanius.net> References: <48076668.9010003@googlemail.com> <200804220044.24031.seanius@seanius.net> Message-ID: <480D93E2.2060703@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/04/08 06:44 PM, sean finney wrote: > hiya, > > On Thursday 17 April 2008 05:02:00 pm Hari Sekhon wrote: >> Perhaps this could be implemented as a switch to enable/disable warning >> on non critical package updates? I did a similar thing for my > > seems reasonable. i guess an option would be like > > -C, --critical-only > only check for critical updates (will not warn if non-critical packages are > available for upgrade) Meanwhile you can the new negate function that appeared in recent releases (1.4.10 I think): /path/to/negate --warning=OK /path/to/check_apt [args] Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIDZPi6dZ+Kt5BchYRAlb+AJ9nV86HnFl2QVRdb8nYCk08sYcB1wCgxfRK n1NQ/K4QnNT3HABO8OcVDm0= =ovrg -----END PGP SIGNATURE----- From seanius at seanius.net Tue Apr 22 18:58:14 2008 From: seanius at seanius.net (sean finney) Date: Tue, 22 Apr 2008 18:58:14 +0200 Subject: [Nagiosplug-devel] =?iso-8859-1?q?check=5Fapt_feature_request=3A_?= =?iso-8859-1?q?No_Warning_on=09Non-Security_upgrades?= In-Reply-To: <480D93E2.2060703@aei.ca> References: <48076668.9010003@googlemail.com> <200804220044.24031.seanius@seanius.net> <480D93E2.2060703@aei.ca> Message-ID: <200804221858.14652.seanius@seanius.net> On Tuesday 22 April 2008 09:29:38 am Thomas Guyot-Sionnest wrote: > On 21/04/08 06:44 PM, sean finney wrote: > > seems reasonable. i guess an option would be like > > > > -C, --critical-only > > only check for critical updates (will not warn if non-critical packages > > are available for upgrade) > > Meanwhile you can the new negate function that appeared in recent > releases (1.4.10 I think): > > /path/to/negate --warning=OK /path/to/check_apt [args] oh, neat. i didn't know about that. well then, Hari: does that suffice or would you still like to see the support added like i mentioned above? i may be spending a bit of time adding some other features to check_apt in the next couple weeks (better chroot/vserver support, possibility to run as non-root for the update/upgrade pair option). sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From Olaf_Ridder at yahoo.com Mon Apr 21 10:47:06 2008 From: Olaf_Ridder at yahoo.com (Olaf Ridder) Date: Mon, 21 Apr 2008 08:47:06 +0000 (UTC) Subject: [Nagiosplug-devel] .cgi Problem Message-ID: Dear All, after installing Nagios 3.01 on a new installed VM-machine with Suse 10.3 I took my older config files from Nagios 2.10 and copy them to 3.01 installation. The first 20 - 30 minutes everything seems to be ok. Nagios is working and websites are shown. Then suddenly the following error occurs: Serverfehler! Die Anfrage kann nicht beantwortet werden, da im Server ein interner Fehler aufgetreten ist. Fehlermeldung: Premature end of script headers: status.cgi Sofern Sie dies f?r eine Fehlfunktion des Servers halten, informieren Sie bitte den Webmaster hier?ber. Error 500 (sorry for the german message) Apache logs the following entry: [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] *** glibc detected *** /usr/lib/nagios/cgi/status.cgi: malloc(): memory corruption: 0x080b0678 ***, referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] ======= Backtrace: =========, referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] /lib/libc.so.6 [0xb7e134b6], referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] /lib/libc.so.6 [0xb7e15701], referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] /lib/libc.so.6 (__libc_malloc+0x97)[0xb7e16d07], referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] /usr/lib/nagios/cgi/status.cgi[0x8056b1b], referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] /usr/lib/nagios/cgi/status.cgi[0x807167c], referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] /usr/lib/nagios/cgi/status.cgi[0x8057c3a], referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] /usr/lib/nagios/cgi/status.cgi[0x8053fd7], referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] /lib/libc.so.6 (__libc_start_main+0xe0)[0xb7dc2fe0], referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] /usr/lib/nagios/cgi/status.cgi[0x80491f1], referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] ======= Memory map: ========, referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] 08048000-08080000 r- xp 00000000 08:02 1284591 /usr/lib/nagios/cgi/status.cgi, referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] 08080000-08081000 r-- p 00037000 08:02 1284591 /usr/lib/nagios/cgi/status.cgi, referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] 08081000-08082000 rw- p 00038000 08:02 1284591 /usr/lib/nagios/cgi/status.cgi, referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] 08082000-0818c000 rw- p 08082000 00:00 0 [heap], referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] b7b00000-b7b21000 rw- p b7b00000 00:00 0 , referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] b7b21000-b7c00000 --- p b7b21000 00:00 0 , referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] b7c54000-b7c5e000 r- xp 00000000 08:02 279177 /lib/libgcc_s.so.1, referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] b7c5e000-b7c60000 rw- p 00009000 08:02 279177 /lib/libgcc_s.so.1, referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] b7c60000-b7d81000 r-- p 00000000 08:02 1561180 /var/lib/nagios/status.dat, referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] b7d81000-b7d82000 rw- p b7d81000 00:00 0 , referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] b7d82000-b7dab000 r- xp 00000000 08:02 647480 /usr/lib/libpcre.so.0.0.1, referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] b7dab000-b7dad000 rw- p 00028000 08:02 647480 /usr/lib/libpcre.so.0.0.1, referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] b7dad000-b7eda000 r- xp 00000000 08:02 279084 /lib/libc-2.6.1.so, referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] b7eda000-b7edb000 r-- p 0012c000 08:02 279084 /lib/libc-2.6.1.so, referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] b7edb000-b7edd000 rw- p 0012d000 08:02 279084 /lib/libc-2.6.1.so, referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] b7edd000-b7ee0000 rw- p b7edd000 00:00 0, referer: http://172.20.11.96/nagios/ [Mon Apr 21 10:07:24 2008] [error] [client 172.20.11.144] , referer: http://172.20.11.96/nagios/ There is no influence by restarting apache or Nagios. The situation still is the same with the error. I only found one procedure to get back the websites: - stop Nagios - delete retention.dat file (or copy an older version to it) - start Nagios Unfortunately this error occurs again after a timeperiod smaler than 1 hour. Has anybody an idea? Thanks, Olaf From dermoth at aei.ca Wed Apr 23 01:25:00 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 22 Apr 2008 19:25:00 -0400 Subject: [Nagiosplug-devel] New threshold syntax (New thread) In-Reply-To: <47F73C46.1040305@aei.ca> References: <47F73C46.1040305@aei.ca> Message-ID: <480E73CC.5050209@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I haven't had a single reply to this. Any objections or comments? During a chat in IRC it was suggested that unit would make a better replacement to uom. Also uprefix could be used instead of uom_prefix. Additionally, in regard to those who prefer the -- syntax, we could make that as a second pass; so we would do: 1st minor release with --metric support 2nd minor (or 1st major) release removing legacy thresholds support (-w, - -c, etc) NB: To be clear, by minor I mean 2nd number like 1.5, 1.6. Thomas On 05/04/08 04:45 AM, Thomas Guyot-Sionnest wrote: > Hi, > > My intent is to provide my suggestion on the latest RFC specification > (modified on 4 Apr 2008 - 5:26pm) so to make thing clear I'm starting a new > thread. These suggestion have been discussed a bit on the #nagios-devel > irc channel and this email will formalize them. > > Everithing in thes imail relates to the "Thresholds" section, although > the proposed changes will reflect in many of the subsequent sections. > > http://nagiosplugins.org/rfc/new_threshold_syntax#thresholds > > Issue #1: > > The current specification of thresholds says the new system will use > "--{metric} {definition}" to define new thresholds. The definition is a > getsubopt(3) list . In regard to this method the new specification will > cause conflicts because some plugins already us similar longopt names > for thresholds that will be converted to the new format. > > Instead, I suggest using "--threshold" (or the shorter "--thresh" if > it's too long) to specify the threshold string, and add the suboption > "metric" to define which metric we're setting the threshold against. > > For example, to check the SSL certificate using check_tcp (that already > has "--certificate") I could use: > > check_tcp -H myhst -S --thresh metric=certificate,warn=<...>,crit=<...> > > The plugin --help output would print a table of all supported metrics, > descriptions, etc. > > > Issue #2: > > The specs should clearly state what uom is and also add uom_prefix (or > just prefix if it's preferred). The current meaning of uom should > actually be uom_prefix. Both would be optionnal. > > uom shouldn't be needed in almost all plugins because the plugin already > know that the thresholds is. It would be useful for checks that are more > generic like check_snmp and check_nt as they can retrieve value they > have no knowledge about. uom is generally a single character (although > it can be more than one) that defines the type of value. It is used in > printing the plugin output _and_ the performance data. > > Some example of uom units: > http://physics.nist.gov/cuu/Units/units.html > http://physics.nist.gov/cuu/Units/outside.html > > > uom_prefix (or prefix) defined a multiplier for: > a. defining the threshold level (the value are multiplied/divided by > the prefix) > b. printing the retrived value in the _plugin_ output. > No matter what prefix is used the performance data should remain the same. > Plugins may define a default prefix fro any threshold. Prefixes are > strictly defined by the prefix tables found on these pages: > http://physics.nist.gov/cuu/Units/prefixes.html > http://physics.nist.gov/cuu/Units/binary.html > One cannot "invent" new prefixes as the plugin needs to know what the > multiplier/divider is. > > For example, to send a warning when a page size isn't between 60KiB and > 80KiB with check_http, one could use: > > --threshold metric=size,ok=60..80,warn=inf..inf,uom_prefix=Ki > > Note that uom is not defined - check_http know it's in bytes (B) > > The plugin would return the data in KiB. ex.: > HTTP OK HTTP/1.1 - 70.99KiB in 0.018 seconds > > However the perfdata will stay in bytes: > time=0.18082s;;;0.000000 size=72694B;61440;81920;0 > > > > This new specs seems very good to me and outside the aforementioned > issues I fully support the latest RFC. > > I also wish to give special thanks to everyone who participated in the > discussion and helped make the new syntax better and simpler. > > > Thomas - ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________________ 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIDnPL6dZ+Kt5BchYRAoMMAJ9MSNadOOkhpo/jnbTg/YGGc/PnrACbBeXH C0O3TY1nMb29h6eF6x7Q+ac= =HUNy -----END PGP SIGNATURE----- From cschneemann at suse.de Wed Apr 23 15:29:26 2008 From: cschneemann at suse.de (Christian Schneemann) Date: Wed, 23 Apr 2008 15:29:26 +0200 Subject: [Nagiosplug-devel] performance data patch for check_ping.c Message-ID: <200804231529.26535.cschneemann@suse.de> Hi, it is not realy a patch, it is just one added line, but maybe it is helpfull. I've just added a line to print the perfdata, I've tested it with Nagios 3.0.1. --- plugins/check_ping.c +++ plugins/check_ping.c @@ -165,6 +165,7 @@ state_text (this_result), warn_text, pl, rta); if (display_html == TRUE) printf (""); + printf("|rta=%2.2f;%f;%f;; pl=%d%%;%d%%;%d%%;;", rta, wrta, crta, pl, wpl, cpl); printf ("\n"); if (verbose >= 2) Greetings -- Christian Schneemann ------------------------------------- SUSE LINUX Products GmbH, Maxfeldstr. 5, D - 90409 N?rnberg Phone:??+49 (0)911 - 740 53 0 e-mail:?cschneemann at suse.de ------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex HRB 16746 (AG N?rnberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: nagios-plugins-perfdata.patch Type: text/x-diff Size: 314 bytes Desc: not available URL: From thomas at zango.com Wed Apr 23 17:05:08 2008 From: thomas at zango.com (Thomas Guyot-Sionnest) Date: Wed, 23 Apr 2008 11:05:08 -0400 Subject: [Nagiosplug-devel] performance data patch for check_ping.c In-Reply-To: <200804231529.26535.cschneemann@suse.de> References: <200804231529.26535.cschneemann@suse.de> Message-ID: <480F5024.5050506@zango.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Schneemann wrote: | Hi, Hi Christian, | it is not realy a patch, it is just one added line, but maybe it is helpfull. | | I've just added a line to print the perfdata, I've tested it with Nagios | 3.0.1. | | --- plugins/check_ping.c | +++ plugins/check_ping.c | @@ -165,6 +165,7 @@ | state_text (this_result), warn_text, pl, rta); | if (display_html == TRUE) | printf (""); | + printf("|rta=%2.2f;%f;%f;; pl=%d%%;%d%%;%d%%;;", rta, wrta, | crta, pl, wpl, cpl); | printf ("\n"); | | if (verbose >= 2) Thanks for summiting a patch. Unfortunately I can't accept it as it's not using the perfdata functions provided y nagios plugins. This sure could be useful and I'll put it in my todo list. Alternatively you can repost your patch using the proper function (look at other plugins for examples). It should be noted that check_icmp already provides performance data and should be preferred over check_ping wherever possible (it requires root privileges so it has to be owned by root and needs the suid permission bit set - might also have issues regarding ping intervals and sequence numbers). check_icmp has a native ICMP implementation and therefore does not rely on the ping command (and does not fork anything either). Thanks, - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFID1Ak6dZ+Kt5BchYRAlatAKDbWMrNAUFAiqlNRmDSUgeiYALn2QCfbt3M FUtyNpsC2YATNWrjBS95B3Q= =EYh2 -----END PGP SIGNATURE----- From cschneemann at suse.de Wed Apr 23 17:29:00 2008 From: cschneemann at suse.de (Christian Schneemann) Date: Wed, 23 Apr 2008 17:29:00 +0200 Subject: [Nagiosplug-devel] performance data patch for check_ping.c In-Reply-To: <480F5024.5050506@zango.com> References: <200804231529.26535.cschneemann@suse.de> <480F5024.5050506@zango.com> Message-ID: <200804231729.00715.cschneemann@suse.de> On Wednesday April 23 2008 05:05:08 pm Thomas Guyot-Sionnest wrote: > Christian Schneemann wrote: > | Hi, > > Hi Christian, > > | it is not realy a patch, it is just one added line, but maybe it is > > helpfull. > > | I've just added a line to print the perfdata, I've tested it with Nagios > | 3.0.1. > | > | --- plugins/check_ping.c > | +++ plugins/check_ping.c > | @@ -165,6 +165,7 @@ > | state_text (this_result), warn_text, pl, rta); > | if (display_html == TRUE) > | printf (""); > | + printf("|rta=%2.2f;%f;%f;; pl=%d%%;%d%%;%d%%;;", rta, > > wrta, > > | crta, pl, wpl, cpl); > | printf ("\n"); > | > | if (verbose >= 2) > > Thanks for summiting a patch. Unfortunately I can't accept it as it's > not using the perfdata functions provided y nagios plugins. This sure > could be useful and I'll put it in my todo list. Alternatively you can > repost your patch using the proper function (look at other plugins for > examples). I had a look at check_icmp, but it seems that this is not using the perdata functions you mention? I will have a look at other checks. > > It should be noted that check_icmp already provides performance data and > should be preferred over check_ping wherever possible (it requires root > privileges so it has to be owned by root and needs the suid permission > bit set - might also have issues regarding ping intervals and sequence > numbers). check_icmp has a native ICMP implementation and therefore does > not rely on the ping command (and does not fork anything either). Yes, I've seen the check_icmp, but the I wanted an alternative that does not need root priviliges. > > Thanks, -- Christian Schneemann ------------------------------------- SUSE LINUX Products GmbH, Maxfeldstr. 5, D - 90409 N?rnberg Phone:??+49 (0)911 - 740 53 0 e-mail:?cschneemann at suse.de ------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex HRB 16746 (AG N?rnberg) From cschneemann at suse.de Wed Apr 23 19:10:00 2008 From: cschneemann at suse.de (Christian Schneemann) Date: Wed, 23 Apr 2008 19:10:00 +0200 Subject: [Nagiosplug-devel] performance data patch for check_ping.c In-Reply-To: <480F5024.5050506@zango.com> References: <200804231529.26535.cschneemann@suse.de> <480F5024.5050506@zango.com> Message-ID: <200804231910.00466.cschneemann@suse.de> On Wednesday April 23 2008 05:05:08 pm Thomas Guyot-Sionnest wrote: > Christian Schneemann wrote: > | Hi, > > Hi Christian, > > | it is not realy a patch, it is just one added line, but maybe it is > > helpfull. > > | I've just added a line to print the perfdata, I've tested it with Nagios > | 3.0.1. > | > | --- plugins/check_ping.c > | +++ plugins/check_ping.c > | @@ -165,6 +165,7 @@ > | state_text (this_result), warn_text, pl, rta); > | if (display_html == TRUE) > | printf (""); > | + printf("|rta=%2.2f;%f;%f;; pl=%d%%;%d%%;%d%%;;", rta, > > wrta, > > | crta, pl, wpl, cpl); > | printf ("\n"); > | > | if (verbose >= 2) > > Thanks for summiting a patch. Unfortunately I can't accept it as it's > not using the perfdata functions provided y nagios plugins. This sure > could be useful and I'll put it in my todo list. Alternatively you can > repost your patch using the proper function (look at other plugins for > examples). > > It should be noted that check_icmp already provides performance data and > should be preferred over check_ping wherever possible (it requires root > privileges so it has to be owned by root and needs the suid permission > bit set - might also have issues regarding ping intervals and sequence > numbers). check_icmp has a native ICMP implementation and therefore does > not rely on the ping command (and does not fork anything either). > > Thanks, Ok, here a new try using fperdata(): --- plugins/check_ping.c +++ plugins/check_ping.c @@ -165,7 +165,7 @@ state_text (this_result), warn_text, pl, rta); if (display_html == TRUE) printf (""); - printf ("\n"); + printf("|%s\n", fperfdata ("rta", (double) rta, "ms", FALSE, 0, FALSE, 0, FALSE, 0, FALSE, 0)); if (verbose >= 2) printf ("%f:%d%% %f:%d%%\n", wrta, wpl, crta, cpl); I have a question to the perfdata() and fperdata() functions. char *fperfdata (const char *label, double val, const char *uom, int warnp, double warn, int critp, double crit, int minp, double minv, int maxp, double maxv) Both have (almost) the same parameters, fperfdata for float values, perfdata for integers, but how are the switches (warnp, critp, minp, maxp) used? Must they be set if the next parameter should be activated? So has warnp be TRUE if the check gives back a WARNING state? How could they be used adequate in this case? I had a look at some checks using perfdata() or fperfdata, and I think I now have a check_ping, that can be used for performancedata. But I don't know what has to be set if the performance should be monitored more exactly. It is hard to use a function just from looking at how it is used from others, a documentation is very helpful (yes, I have the best documentation, the sourcecode, but a written text can be easier to read ;) Greetings -- Christian Schneemann ------------------------------------- SUSE LINUX Products GmbH, Maxfeldstr. 5, D - 90409 N?rnberg Phone:??+49 (0)911 - 740 53 0 e-mail:?cschneemann at suse.de ------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex HRB 16746 (AG N?rnberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: nagios-plugins-perfdata.patch Type: text/x-diff Size: 371 bytes Desc: not available URL: From thomas at zango.com Wed Apr 23 20:36:18 2008 From: thomas at zango.com (Thomas Guyot-Sionnest) Date: Wed, 23 Apr 2008 14:36:18 -0400 Subject: [Nagiosplug-devel] performance data patch for check_ping.c In-Reply-To: <200804231910.00466.cschneemann@suse.de> References: <200804231529.26535.cschneemann@suse.de> <480F5024.5050506@zango.com> <200804231910.00466.cschneemann@suse.de> Message-ID: <480F81A2.90902@zango.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Schneemann wrote: | Ok, here a new try using fperdata(): | --- plugins/check_ping.c | +++ plugins/check_ping.c | @@ -165,7 +165,7 @@ | state_text | (this_result), warn_text, pl, rta); | if (display_html == TRUE) | printf (""); | - printf ("\n"); | + printf("|%s\n", fperfdata ("rta", (double) rta, "ms", FALSE, | 0, FALSE, 0, FALSE, 0, FALSE, 0)); | | if (verbose >= 2) | printf ("%f:%d%% %f:%d%%\n", wrta, wpl, crta, cpl); | | | I have a question to the perfdata() and fperdata() functions. | char *fperfdata (const char *label, | double val, | const char *uom, | int warnp, | double warn, | int critp, | double crit, | int minp, | double minv, | int maxp, | double maxv) | | Both have (almost) the same parameters, fperfdata for float values, perfdata | for integers, but how are the switches (warnp, critp, minp, maxp) used? Must | they be set if the next parameter should be activated? So has warnp be TRUE | if the check gives back a WARNING state? | How could they be used adequate in this case? Normally they are true if a warning/critical threshold is set. Just as an example (it may not fit this particular case) let's say you have "int warn=0, crit=0;" and you check thresholds only if they set so something higher than 0, you could do: fperfdata ("rta", (double) rta, "ms", warn>0?TRUE:FALSE, warn, ~ crit>0?TRUE:FALSE, crit, TRUE, 0, FALSE, 0); NB: with rta, minp (minimum) is always 0 and there is no maxp (rta can be as long as you allow the plugin to run). | I had a look at some checks using perfdata() or fperfdata, and I think I now | have a check_ping, that can be used for performancedata. But I don't know | what has to be set if the performance should be monitored more exactly. It looks pretty close (and I can always close remaining gaps...) Looks like your new patch doesn't report packet loss though. | It is hard to use a function just from looking at how it is used from others, | a documentation is very helpful (yes, I have the best documentation, the | sourcecode, but a written text can be easier to read ;) This is something we'd like to address in the future by having a more complete and generalized API, documented and installable for 3rd party plugins. We have limited development resources in the team so this is something that will take a while to implement. Thanks for your time, - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFID4Gi6dZ+Kt5BchYRAuLSAJ9IaRg4JIgtpK7voo1nuYdBCVmJnACfdDLn jbMpG2fAZssuuv5G4lcOzi8= =8oAl -----END PGP SIGNATURE----- From nathan.vonnahme at bannerhealth.com Fri Apr 25 03:22:43 2008 From: nathan.vonnahme at bannerhealth.com (Vonnahme, Nathan) Date: Thu, 24 Apr 2008 17:22:43 -0800 Subject: [Nagiosplug-devel] New threshold syntax (New thread) In-Reply-To: <480E73CC.5050209@aei.ca> References: <47F73C46.1040305@aei.ca> <480E73CC.5050209@aei.ca> Message-ID: <077F1B782014ED48A58E7927914D36A001D07094@fai01500.bhs.bannerhealth.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- > devel-bounces at lists.sourceforge.net] On Behalf Of Thomas Guyot-Sionnest > Sent: Tuesday, April 22, 2008 3:25 PM > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] New threshold syntax (New thread) > I haven't had a single reply to this. Any objections or comments? I replied on 4/11 but mostly agree with everything you said... but I think the SI is in a small but self-righteous minority in their definition of a GB, and we should stick with `ls` and `df`. > During a chat in IRC it was suggested that unit would make a better > replacement to uom. Also uprefix could be used instead of uom_prefix. +1. 'unit' is better for readability. > Additionally, in regard to those who prefer the -- > syntax, we could make that as a second pass; so we would do: > 1st minor release with --metric support > 2nd minor (or 1st major) release removing legacy thresholds support (-w, > - -c, etc) +1. From tobias at scherbaum.info Sun Apr 27 20:01:19 2008 From: tobias at scherbaum.info (Tobias Scherbaum) Date: Sun, 27 Apr 2008 20:01:19 +0200 Subject: [Nagiosplug-devel] patch to build w/ autoconf-2.62 Message-ID: <1209319279.3000.3.camel@homer.ob.libexec.de> Hi, find attached a patch which is required to build nagios-plugins w/ autoconf-2.62. Thanks, Tobias -- Gentoo Linux - Die Metadistribution http://www.mitp.de/1769 -------------- next part -------------- A non-text attachment was scrubbed... Name: nagios-plugins-1.4.11-autoconf-2.62.patch Type: text/x-patch Size: 558 bytes Desc: not available URL: From persio at totvs.com.br Thu Apr 24 22:51:40 2008 From: persio at totvs.com.br (Persio Bazan) Date: Thu, 24 Apr 2008 17:51:40 -0300 Subject: [Nagiosplug-devel] I need script to check my network traffic for linux - check_netio is not correct Message-ID: <5EAD84C9C95E6C4FAE4F72229730B20B01512D94@apolo.sp01.local> Helo, I need a script to check my network traffic for linux, i use check_netio scrip but they do not work appropriate, there is other ? Tanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at zango.com Mon Apr 28 16:00:50 2008 From: thomas at zango.com (Thomas Guyot-Sionnest) Date: Mon, 28 Apr 2008 10:00:50 -0400 Subject: [Nagiosplug-devel] patch to build w/ autoconf-2.62 In-Reply-To: <1209319279.3000.3.camel@homer.ob.libexec.de> References: <1209319279.3000.3.camel@homer.ob.libexec.de> Message-ID: <4815D892.3000505@zango.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tobias Scherbaum wrote: | Hi, | | find attached a patch which is required to build nagios-plugins w/ | autoconf-2.62. That should belong to Gnulib. If I apply it to Nagios-plugins it'll get reverted on the next Gnulib sync. If you manage to get it in Gnulib and want us to sync it for the next release we'll do. Additionally, autoconf shouldn't be needed when building daily snapshots and releases. It's only needed when you get the source from Subversion. Thanks - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIFdiS6dZ+Kt5BchYRAoRWAKCC64tshLdLHxmQJTmkcfb2dkIgBgCg6Sa3 tHTq/mue2bjU8B1SGzM2wVw= =B/X5 -----END PGP SIGNATURE----- From noreply at sourceforge.net Mon Apr 28 16:06:10 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Apr 2008 07:06:10 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1953437 ] check_mailq does not see "alias database unavailable" Message-ID: Feature Requests item #1953437, was opened at 2008-04-28 16:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1953437&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 Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_mailq does not see "alias database unavailable" Initial Comment: Hi, i have a hp-ux11.11 server with a lot of stuck mails. qqnagio at sshe0020:/lfs/opt/nagios# mailq Mail Queue (5298 requests) --Q-ID-- --Size-- -----Q-Time----- ------------Sender/Recipient------------ HAA23118 163 Tue Jun 14 07:00 root (alias database unavailable) root HAA26134 163 Mon Jun 13 07:00 root (alias database unavailable) root ....... ....... ....... QAI04462 0 Sat Jun 4 16:45 MAILER-DAEMON (alias database unavailable) root qqnagio at sshe0020:/lfs/opt/nagios# check_mailq says "mailq is empty" which is not correct. I propose to add: if (/\(alias database unavailable\)/) { print "$utils::PATH_TO_MAILQ = $_ \n" if $verbose ; $msg_q++; } just before the # Finally look at the overall queue length # if (/mqueue/) { Greetings from Munich, Gerhard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1953437&group_id=29880 From ton.voon at altinity.com Tue Apr 29 00:00:40 2008 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 28 Apr 2008 23:00:40 +0100 Subject: [Nagiosplug-devel] New threshold syntax (New thread) In-Reply-To: <47F73C46.1040305@aei.ca> References: <47F73C46.1040305@aei.ca> Message-ID: <0B24DCC8-2705-40EB-A436-A1901148CA52@altinity.com> On 5 Apr 2008, at 09:45, Thomas Guyot-Sionnest wrote: > Issue #1: > > The current specification of thresholds says the new system will use > "--{metric} {definition}" to define new thresholds. The definition > is a > getsubopt(3) list . In regard to this method the new specification > will > cause conflicts because some plugins already us similar longopt names > for thresholds that will be converted to the new format. > > Instead, I suggest using "--threshold" (or the shorter "--thresh" if > it's too long) to specify the threshold string, and add the suboption > "metric" to define which metric we're setting the threshold against. > > For example, to check the SSL certificate using check_tcp (that > already > has "--certificate") I could use: > > check_tcp -H myhst -S --thresh > metric=certificate,warn=<...>,crit=<...> > Yes, I can see this would be less likely to conflict with existing options. Can we say that the first getsubopt() can be assumed to be metric= ? So your example would be --threshold certificate,warn=...,crit=... The only thing complaint I have is that if "--threshold certificate" is set without any levels, I wanted that to be a way of defining that perf data for the certificate age was to be provided. This isn't really a "threshold". But if no one objects loudly, I guess we can consider that's an education thing. > The plugin --help output would print a table of all supported metrics, > descriptions, etc. +1. I can see that there would be some library functions to "register" that a fixed list of metrics are available from a plugin. > Issue #2: > > The specs should clearly state what uom is and also add uom_prefix (or > just prefix if it's preferred). The current meaning of uom should > actually be uom_prefix. Both would be optionnal. I don't really have any firm opinions about this at the moment, so I'm happy to go with the majority. Thomas, can I suggest that you update the RFC at http://nagiosplugins.org/rfc/new_threshold_syntax and then we can close this shortly and proceed to the next stage. I think the public discussion has been incredibly helpful, but I'm also keen to draw a line under the talking and move onto the implementing. 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 Apr 29 04:12:20 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 28 Apr 2008 22:12:20 -0400 Subject: [Nagiosplug-devel] New threshold syntax (New thread) In-Reply-To: <0B24DCC8-2705-40EB-A436-A1901148CA52@altinity.com> References: <47F73C46.1040305@aei.ca> <0B24DCC8-2705-40EB-A436-A1901148CA52@altinity.com> Message-ID: <48168404.4070101@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/04/08 06:00 PM, Ton Voon wrote: > On 5 Apr 2008, at 09:45, Thomas Guyot-Sionnest wrote: >> Issue #1: >> >> The current specification of thresholds says the new system will use >> "--{metric} {definition}" to define new thresholds. The definition >> is a >> getsubopt(3) list . In regard to this method the new specification >> will >> cause conflicts because some plugins already us similar longopt names >> for thresholds that will be converted to the new format. >> >> Instead, I suggest using "--threshold" (or the shorter "--thresh" if >> it's too long) to specify the threshold string, and add the suboption >> "metric" to define which metric we're setting the threshold against. >> >> For example, to check the SSL certificate using check_tcp (that >> already >> has "--certificate") I could use: >> >> check_tcp -H myhst -S --thresh >> metric=certificate,warn=<...>,crit=<...> >> > > Yes, I can see this would be less likely to conflict with existing > options. Can we say that the first getsubopt() can be assumed to be > metric= ? So your example would be > > --threshold certificate,warn=...,crit=... Well, I don't this it would play well with getsubopt the *exact* way you explain it but I see two ways we can make this work: 1. We pass a list of possible thresholds to the function and make them act as a flag. 2. We allow one unparsed parameter (the metric) and return it as a char*. I don't really like #1 (I just put it up before reading getsubopt man page and finding the other alternative). Also do we want to allow "default" metric when this isn't set? If we do then we won't be able to set default options for other metrics like I once suggested. Using either of these methods will make it valid no mater where it appears in the line. i.e this would be valid as well: --threshold crit=[...],warn=[...],certificate > The only thing complaint I have is that if "--threshold certificate" > is set without any levels, I wanted that to be a way of defining that > perf data for the certificate age was to be provided. This isn't > really a "threshold". But if no one objects loudly, I guess we can > consider that's an education thing. Yes. I'd go for it. Also with --threshold if any other threshold normally-displayed threshold isn't specified shoult is go away? (except possibly when there's only one possible threshold in the plugin). >> Issue #2: >> >> The specs should clearly state what uom is and also add uom_prefix (or >> just prefix if it's preferred). The current meaning of uom should >> actually be uom_prefix. Both would be optionnal. > > > I don't really have any firm opinions about this at the moment, so I'm > happy to go with the majority. I don't have strong opinions about the presence of unit/uprefix at all, but if it's there I strongly believe that: 1. We should have separate unit and uprefix - trying to "be smart" and parse a bundled unit/prefix will likely cause errors and problems. 2. There must be a way to specify the type (decimal or binary). If people don't like using SI representations (KiB, Kib, etc) then we could also go away with a "binary" and "decimal" getsubopt flag to force one or the other. Also I guess the default should be plugin-specific... > Thomas, can I suggest that you update the RFC at http://nagiosplugins.org/rfc/new_threshold_syntax > and then we can close this shortly and proceed to the next stage. I > think the public discussion has been incredibly helpful, but I'm also > keen to draw a line under the talking and move onto the implementing. Ok. I'll see if anything follow this email first... Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIFoQE6dZ+Kt5BchYRApOzAJ9dTX3/SKPOiFiebrHyprT2A++zpACg1PzH QXQJ32fOMMQZ2bmSlCG2S/I= =8fJq -----END PGP SIGNATURE----- From TBarto at novomatic.com Tue Apr 29 11:38:51 2008 From: TBarto at novomatic.com (Thomas Bartosik) Date: Tue, 29 Apr 2008 11:38:51 +0200 Subject: [Nagiosplug-devel] Multi-line output of NRPE plugins Message-ID: <48170335.E517.0056.0@novomatic.com> Hi all! I am doing a lot of plugin development right now and we've started to experiment with Nagios 3.x now. (3.0.1 is currently installed, to be precise). What mostly made me move to 3.x was the multi-line output for the plugins. I have not yet done anything with macros, but I also do not really think that the mentioned macros will help me here. $LONGHOSTOUTPUT$ and $LONGSERVICEOUTPUT$ contain the lines after the first line, but there is no way (for me) to display them in the web interface (nagios.cgi). What is the general design philosophy behind these macros? Should they ever be used for display purposes in the web frontend? Or should they just be used for notifications? I give you an example: I am currently checking an MSSQL server for disabled jobs. There might be more than one disabled job, so my NRPE_NT plugin prints one disabled job per line. But only the first one can be seen in the web frontend. (possibly giving a critical error although only a job causing a warning is displayed; this is irritating) What is the general advice for plugin developers now? Should we not take advantage of multi-line output? (that would be too bad, as this is really limiting) Or should we use ugly HTML markup (like
) to generate the wanted multi-line output in HTML? Please share your thoughts or give advice. I think the best way to solve the problem (if it is a problem; maybe I am just too unexperienced to know how to do it...) is to offer a parameter in the nagios.cfg file to enable or disable long output in the web frontend. Thanks a lot in advance! thomas From jimmy.mathew1 at wipro.com Tue Apr 29 11:55:59 2008 From: jimmy.mathew1 at wipro.com (jimmy.mathew1 at wipro.com) Date: Tue, 29 Apr 2008 15:25:59 +0530 Subject: [Nagiosplug-devel] semantics of macro $SERVICECHECKTIME$ Message-ID: hi all can any one tell the semantics of data(time information) stored in macro $SERVICECHECKTIME$ Actually it stores time information in 10 digits ( eg:1209449397) I wanted to convert this information into time-date format ( dd:mm:yyyy-seconds:minute:hour) Thanks Jimmy Mathew ------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ae at op5.se Tue Apr 29 12:27:06 2008 From: ae at op5.se (Andreas Ericsson) Date: Tue, 29 Apr 2008 12:27:06 +0200 Subject: [Nagiosplug-devel] semantics of macro $SERVICECHECKTIME$ In-Reply-To: References: Message-ID: <4816F7FA.3000405@op5.se> jimmy.mathew1 at wipro.com wrote: > hi all > > can any one tell the semantics of data(time information) stored in macro $SERVICECHECKTIME$ > > Actually it stores time information in 10 digits ( eg:1209449397) > > I wanted to convert this information into time-date format ( dd:mm:yyyy-seconds:minute:hour) > Google for "timestamp" "unix epoch" -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From dermoth at aei.ca Tue Apr 29 13:31:04 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 29 Apr 2008 07:31:04 -0400 Subject: [Nagiosplug-devel] semantics of macro $SERVICECHECKTIME$ In-Reply-To: <4816F7FA.3000405@op5.se> References: <4816F7FA.3000405@op5.se> Message-ID: <481706F8.6080700@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29/04/08 06:27 AM, Andreas Ericsson wrote: > jimmy.mathew1 at wipro.com wrote: >> hi all >> >> can any one tell the semantics of data(time information) stored in macro $SERVICECHECKTIME$ >> >> Actually it stores time information in 10 digits ( eg:1209449397) >> >> I wanted to convert this information into time-date format ( dd:mm:yyyy-seconds:minute:hour) >> > > Google for "timestamp" "unix epoch" > You can use: $ date -d @1209449397 "man date" for the output format string (which will allow printing in the format you want) Or in Perl: $ perl -e 'print scalar(localtime(1209449397)) . "\n";' "perldoc -f localtime" for examples on how to use localtime to print the date in the format you want. Many other programming languages have their own functions to convert epoch time to local time. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIFwb46dZ+Kt5BchYRAuGAAJ0RDtjG73Ev4MxsoIik0M14GgmXXQCfX24Q xJ8YhukzTyvkuV5f7BOuLhg= =ylQT -----END PGP SIGNATURE----- From devinbhullar at gmail.com Wed Apr 30 06:11:01 2008 From: devinbhullar at gmail.com (Devinder Singh) Date: Wed, 30 Apr 2008 12:11:01 +0800 Subject: [Nagiosplug-devel] MRTG Graf Message-ID: <8a8640570804292111i210855f1oa3d39112695b9c3e@mail.gmail.com> Hi I have problems in getting bandwidth statistics using MRTG. define service{ use generic-service ; Inherit values from a template host_name D-Link service_description Port 1 Bandwidth Usage check_command check_local_mrtgtraf!/home/mrtg/cfg/mrtg.cfg!AVG!1000000,1000000!5000000,5000000!10 } I tried to run the above command and see the file is outdated. i have ran the cfgmaker program and stored the mrtg.cfg in /home/mrtg/cfg/mrtg.cfg Please advise -- Devinder -------------- next part -------------- An HTML attachment was scrubbed... URL: