Date: Sun, 23 Nov 2003 20:00:06 -0600 From: Dan Nelson <dnelson@allantgroup.com> To: paul beard <paulbeard@mac.com> Cc: questions@freebsd.org Subject: Re: POLA violation?: snmp renumbering stuff Message-ID: <20031124020006.GI2146@dan.emsphone.com> In-Reply-To: <8FF2C6A7-1DFB-11D8-B52A-000A95BBCCF8@mac.com> References: <8FF2C6A7-1DFB-11D8-B52A-000A95BBCCF8@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Nov 23), paul beard said:
> For some reason, my locally installed snmp daemons decided to
> renumber the elements in the hrStorageTable, meaning all the attached
> disks were being either misreported or just plain dropped from my
> graphs (paulbeard.no-ip.org/mrtg/blue/index.html). Not that the new
> numbering doesn't make sense but I didn't know this was going to
> happen.
>
> How to discover and fix it? snmptable is my friend. As shown here,
> the memory used by the kernel is listed first, followed by the disks.
> The disks were numbered starting at 1 before . . . . .
I don't think snmp tables have any defined order. I don't even know if
the index for a particular resource is guaranteed to be stable across
filesystem dismount/remounts. Something like this should work:
snmptable -Cf : blue hrStorageTable | grep :/var: | awk -F : '{print $4 * $5}'
I use something similar in a script to graph disk usage in mrtg. It
sould be really nice if snmptable had a built-in flag to print a
particular cell from a table, though.
--
Dan Nelson
dnelson@allantgroup.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031124020006.GI2146>