Unsolved
This post is more than 5 years old
4 Posts
0
2808
September 4th, 2008 23:00
the snmp
While trying to steer the GSC
into your lap with this;
underlying requirement is short-run,
granular but imprecise collection of a
small number of OID's across a small number
of elements - usually to collect sufficient
datapoints to convince a customer that a
preliminary diagnosis is correct
(reactive support, quite late in a case lifecycle).
The requirement I see in the field is a lightweight
SNMP collector that can have {agentaddress, ttl, oid}
tuples configured, that will stop collections once ttl
has expired, will delete collection data that is ttl'ly-expirable,
and that has a user tool for creating, deleting, and reporting
(as csv extract) on collections; obviously once the user tool
and daemon exists, linkage to SAM server tools is a freebie.
The goal would be to allow some upper bounded number of
concurrent collections, with the polling rounds
configured in 1s increments (no averaging support or rollups,
this is usually done in a tertiary pass - and we probably don't have to
be terribly precise in terms of jitter between polls either). For
extra points - allow for Telnet transport, and collections using
regex to set a focus for "show" command output parsing. Simple
enough to do in Perl using Net::SNMP libraries codewise; the NMS
platform has any number of implementations of this same requirement
(hacked together by various folk) for what it's worth. The key weeknesses
in NNM's snmpCollect is that the collections are not in any way bounded,
and housekeeping is essentially "holy cow batman where'd my disk space
go" shortly followed by a "rm -f" spree (there's no duration defined for the
collection when first created nor configurable in the collector itself).