Start a Conversation

Unsolved

This post is more than 5 years old

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).

No Responses!
No Events found!

Top