From: jrg@blodwen.demon.co.uk (James R Grinter)
Ignoring some of the architectural problems with collector (it'll request
all values for a target at once, but not at the host level; it
serialises the requests), I've been trying to make SNMP collection more
efficient in the face of unavailable hosts/agents.
At present, each snmp-walk or snmp-get to a non-responding agent (dead
host or dead agent) costs around 10 seconds. If you have multiple
targets per host, as I do in my situation (configuring filesystems,
interfaces as seperate targets to make it easier to add new ones) then
this can make it very hard to collect everything inside 5 minutes.
As a bit of a temporary hack, I've implemented (and am currently
testing) a "deadhost" check in snmpUtils.pm, which will add the
host/port combination into a list of non responding hosts.
Problems:
- the SNMP Session routines don't make it easy to differentiate between
no response (at all, or UDP port unreachable), or noSuchName (invalid OID,
eg because someone removed the filesystem, interface, etc).
- because we call the collector afresh each 5 minutes, this 'dead host'
only persists for one collection cycle.
With point 1 in mind, I'm currently checking to see if the operation
takes over 5 seconds: assuming that if it does it was probably a
timeout and so the entire agent is to be considered dead. But is there
a correct way?
Point 2 is probably not really a problem, at the moment, as long as there
aren't 30 hosts down in one collection cycle.
Anyone else concerned about this sort of thing? Or have you approached
the variable-number of targets per host differently?
I'll post the small patch to snmpUtils.pm, when I'm sure it's working.
James.
--------------------------- ONElist Sponsor ----------------------------
Thinking about putting your business on the Web?
MindSpring Biz has helped over 100,000 businesses get their .com.
Join MindSpring Biz and save $50!
<a href=" http://clickme.onelist.com/ad/mindspring3 ">Click Here</a>
------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Mon Mar 06 2000 - 19:01:04 PST