Same status

[Karl DeBisschop]

On Thu, 2003-01-16 at 18:14, Carroll, Jim P [Contractor] wrote:
> > 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?

I don't have another approach -- if I can get the MIB, that is easiest.
But often enough, I can't. And the snmpwalk you describe is exactly what
I do in that case.

> > 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.

In the CVS for the plugins, grep snmp command.cfg.in

> > 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

Prior to 8.0, it's ucd-snmp. Same codebase, new name.

<snip>

> 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?

Yes, therein lies madness.

Well, not a terrible amount of madness if the systems are not totally
divergent. But you're right, disk space is not too scalable.

I think this now merges with the other current discussion about
extending check_snmp. To make it scalable and generalizable, we need to
be able to

1) scan a set of OIDs
2) calculate things like sums, counts, percentages, averages

So it's still got some real limitations in this respect. SNMP is so
widespread and standard, however, that it seems to me well worth
extending check_snmp to handle these cases.

--
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