Output problems with check_snmp ...

[Andreas Ericsson]

Justin Hennessy wrote:
> Hi all (again),
> 
> I am trying check the uptime of my managed switches but I have a little
> problem when I put the test into Nagios.
> 
> When I run this:
> /usr/local/nagios/libexec/check_snmp -H 172.16.4.1 -o
> system.sysUpTime.0 -C dragonsbain
> 
> I get this:
> SNMP OK - Timeticks: (563369316) 65 days, 4:54:53.16
> 
> BUT when I run this:
> /usr/local/nagios/libexec/check_snmp -H 172.16.4.1 -o
> system.sysUpTime.0 -C dragonsbain -w 10 -c 30
> 
> I get this:
> SNMP CRITICAL - *563375231*
> 
> Can anyone shed some light on why the output changes when I put the
> WARNING and CRITICAL criteria in?
> 
Which is correct. One timetick represents 1/100 of a second, and 
563369316 1/100's of a second makes for 65 days, 4 hours, 54 minutes and 
53.16 seconds (the above example. There was a time delay of 59.15 
seconds delay between your running of snmpget and check_snmp).

check_snmp doesn't do that translation for you, so you have to specify 
it in timeticks (why you would want thresholds on uptime in the first 
place eludes me, but who am I to say?)

Anyways... The math goes something like this;
threshold=(((((days*24*60)+hours)*60+minutes)*60+seconds)*100)+centiseconds
Mind the math precedense.

One day is 86400 seconds. You do the math on the thresholds you want, 
and don't forget to multiply by 100.

> Thanks,
> 
Anytime.

> Justin
> 

-- 
Andreas Ericsson
OP5 AB
+46 (0)733 709032
andreas.ericsson at op5.se


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null