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>