Todd Michael wrote:

> Thanks Dave. Actually, my issue is not with the base ID, but the
> entire ID. For example, to monitor specific filesystems I'd have the
> following in my snmpd.conf:
> disk /
> disk /foo
> disk /bar

Sorry - I'd got the impression from what you said that you
had been using the "exec" directive rather than "disk"
hence the suggestion of fixing the output OID tree.

Yes - the disk table uses arbitrary integer indexes, and these
can indeed change from one system to another (or over time).
Much as the standard interface table uses arbitrary integer
indexes, which can change from one system to another (or over time).

> I setup my monitoring system to monitor "/bar", for example, by
> checking UCD-SNMP-MIB::dskPath.3 on all my servers. The problem is
> that if I remove the filesystem, /foo, now the OID assignment for /var
> changes to UCD-SNMP-MIB::dskPath.2 ultimately screwing up my
> monitoring system.

Ideally the monitoring system should be able to handle this.
E.g. by retrieving some "constant identifier" (such as dskPath
or ifName) and using that to map to the appropriate index.
So you wouldn't monitor "UCD-SNMP-MIB::dskPath.3".
You'd monitor "UCD-SNMP-MIB::dskPath == /bar"

It's been a while since I've looked at monitoring systems, but
I seem to remember that Cricket can handle this, and I thought
that MRTG could as well. I've not looked at Nagios properly.
(It's on my list!)

The Net-SNMP agent has gone through a fair amount of changes,
and one of the additions that went in recently was the idea of
"persistent enumerations". It hasn't been used for anything yet
(though it was intended for addressing this very problem with the
interface table). But I could see a case for applying it to the
disk table as well. So that would mean:
a) disk row allocations could be consistent for a given system
b) given a suitable shared config file, they could be
consistent across multiple systems as well.

Longer term, I strongly suspect that the disk table will be redefined
to be indexed by the path string directly. I know that's the way
that Wes has tended to think recently. But that'll require a
redefinition of the MIB objects, and probably won't happen immediately.
Making the disk indexes persistent ought to prove a much "lighter"
solution in the meantime.