Same status

[Carroll, Jim P [Contractor]]

> It helps, but not really needed. I often use the numeric OID

But how does one know what the numeric OID references?  Let's say a query
against (I'm pulling this fictional OID out of the air)
.1.3.1.2.1.4.1.5.1.6.1.7.21 and it returns a value of 4257.  First, I'd have
to ask myself why I queried that OID to begin with.  ;)

Now if you were to say:

1) do an snmpwalk and dump it to a file
2) look around for things you're interested in
3) do an snmpwalk -O n of the OIDs I'm interested in, in order to get the
numeric OID values
4) define the numeric OIDs in the check_snmp definitions

that would be one approach.  But I'm speculating wildly here; perhaps you
have a more economical approach...?  Am I even on the right track?

> There are some service definitions in the old command.cfg file.

I took a look at the sample config files (if that's what you were referring
to).  Did a "grep snmp *" and found nothing.

> OK. I happen to have a RedHat beta on my laptop here. No nagios, no
> snmp. Let's see just how painful this is, since it's been a few years
> since I first set ip up.
> 
> 1) rpm -Uv net-snmp*

$ rpm -qa|grep snmp
ucd-snmp-devel-4.2.3-18rlx
ucd-snmp-4.2.3-18rlx
ucd-snmp-utils-4.2.3-18rlx
php-snmp-4.1.2-7

> 2) edit /etc/snmp/snmpd.conf (comments in file are enough to tell you
> what to do)

Looks like we're good to go.

> 3) sudo /sbin/service snmpd restart

*nods*

> 4) test with `snmpwalk -c public -v 1 localhost system`

$ snmpwalk -c public -v 1 localhost system
system.sysDescr.0 = Linux itdmll58 2.4.18-3rlx3 #1 Thu Sep 5 08:48:57 CDT
2002 i686
system.sysObjectID.0 = OID: enterprises.ucdavis.ucdSnmpAgent.linux
system.sysUpTime.0 = Timeticks: (4248058406) 491 days, 16:09:44.06
system.sysContact.0 = Root <root at localhost> (configure
/etc/snmp/snmp.local.conf)

[snipped to save space]

> 5) snmpwalk -c public -v 1 localhost .1 | less

Looks good.

> 6) now, since people asked about checking load without 3 test 
> in another
> thread, I'll run
> 
>    snmpwalk -c public -v 1 localhost .1.3.6.1.4.1.2021.10
> 
> Part of what comes back is
> 
>  UCD-SNMP-MIB::laLoad.1 = STRING: 0.00
>  UCD-SNMP-MIB::laLoad.2 = STRING: 0.07
>  UCD-SNMP-MIB::laLoad.3 = STRING: 0.23
> 
> Or, if you prefer:
> 
>     snmpwalk -O n -c public -v 1 localhost .1.3.6.1.4.1.2021.10
> 
>  .1.3.6.1.4.1.2021.10.1.3.1 = STRING: 0.12 
>  .1.3.6.1.4.1.2021.10.1.3.2 = STRING: 0.10
>  .1.3.6.1.4.1.2021.10.1.3.3 = STRING: 0.09

I got *way* too much stuff back, so I had to be more specific, thusly:

$ snmpwalk -c public -v 1 localhost .1.3.6.1.4.1.2021.10.1.3
enterprises.ucdavis.laTable.laEntry.laLoad.1 = 5.32
enterprises.ucdavis.laTable.laEntry.laLoad.2 = 6.92
enterprises.ucdavis.laTable.laEntry.laLoad.3 = 6.69

or,

$ snmpwalk -O n -c public -v 1 localhost .1.3.6.1.4.1.2021.10.1.3
.1.3.6.1.4.1.2021.10.1.3.1 = 1.93
.1.3.6.1.4.1.2021.10.1.3.2 = 5.35
.1.3.6.1.4.1.2021.10.1.3.3 = 6.15

> So I can define a load check like:
> 
> /usr/lib/nagios/plugins/check_snmp -H $HOSTADDRESS$ -C $ARG1$ \
> -o .1.3.6.1.4.1.2021.10.1.5.1 \
> -o .1.3.6.1.4.1.2021.10.1.5.2 \
> -o .1.3.6.1.4.1.2021.10.1.5.3 \
> -w :$ARG2$,:$ARG3$,:$ARG4$ \
> -c :$ARG5$,:$ARG6$,:$ARG7$ \
> -l load
> 
> (Sorry about the line wraps.)

(Hmm.  Looks like you're using a different OID.  But I understand the
intent.)

Alright, so far so good.

> Here's a few new style commands from ny currently running 
> configuration:
> 
> define command{
>         command_name    snmp_procs
>         command_line    /usr/lib/nagios/plugins/check_snmp \
> -H $HOSTADDRESS$ -C $USER5$ \
> -o host.hrSystem.hrSystemProcesses.0 \
> -w :$ARG1$ -c :$ARG2$ -l processes
>         }

Looks good.

> define command{
>         command_name    snmp_disk
>         command_line    /usr/lib/nagios/plugins/check_snmp \
> -H $HOSTADDRESS$ -C $USER5$ \
> -o .1.3.6.1.4.1.2021.9.1.9.1 \
> -w :$ARG1$ -c :$ARG2$ -l percent
>         }

Hmm.  Alright, while technically this works, I can see a problem reconciling
the OIDs with the actual mountpoints, at least in larger
systems/environments.  I can imagine that dskPath.1 will almost always be
"/", but I can also see that dskPath.17 on one system may well have a
different mountpoint than that of another system.  Setting up the first
system check_snmp services for the disk percentages would take a bit of
time, but not overwhelmingly so.  But it does impair cut-pasting definitions
from one host's services to another host's services, unless you're fond of
manual reconciliation.  At least with check_disk, I can specify "/" and it
will always be "/", no matter which host I run it on.  It shouldn't be an
issue for small, repeated configurations, such as blade servers (e.g., RLX).

(In case I'm being vague, I'm referring to the service_description string.
What would be a way of naming it that's both economical and sensible?  It
would be great if the service_description could query check_snmp to get the
appropriate string... however....)

Now if only there were a way of passing a mount point to check_snmp as well
as the OID you're looking to have it return, letting the program do the
reconciliation for you, etc....

Or perhaps more economically, write a script to grok the snmpwalk output, do
the reconciliation, and create the necessary service definitions
automagically.  But then you're faced with having to redefine the
thresholds.  Unless the script referred to a metaconfig file, which would
then have the thresholds.  Argh, this doesn't really help matters much, does
it....

Thoughts?

> define command{
>         command_name    snmp_inodes
>         command_line    /usr/lib/nagios/plugins/check_snmp \
> -H $HOSTADDRESS$ -C $USER5$ \
> -o .1.3.6.1.4.1.2021.9.1.10.1 \
> -w :$ARG1$ -c :$ARG2$ -l percent
>         }

Very nice.  Still has the same naming standard issue as above.  :/

> Hope that helps.

Helps quite a bit actually.

jc

> --
> Karl
> 
> 


-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en