nv-l
[Top] [All Lists]

RE: [nv-l] details from trapd.log

To: "'nv-l@lists.us.ibm.com'" <nv-l@lists.us.ibm.com>
Subject: RE: [nv-l] details from trapd.log
From: "Allison, Jason (JALLISON)" <JALLISON@arinc.com>
Date: Fri, 9 Jul 2004 09:37:10 -0400
Delivery-date: Fri, 09 Jul 2004 14:52:49 +0100
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
Reply-to: nv-l@lists.us.ibm.com
Sender: owner-nv-l@lists.us.ibm.com
 
Ive sent in a request to division supervisors and should hear back from them by Monday.  Im happy to share the code (and receive feedback, its far from tight software), the initial archiver (C code) simply uses OVsnmpRecv, parses and loops through the varbinds.  I did have to bastardize snmpprint.h to make output is a desired format, but most of the guts was taken from the /usr/OV/prg_samples techniques.  The desired format is a well-defined delimited ASCII text file which the PERL post processor will use as a seed to create the command file (ASCII format) which can also be altered as needed.  Im not sure how NT users will fair trying to use my application suite as it was built on UNIX and uses the 'snmptrap' stack for replaying the traps ... YMMV.
 
I could have coupled the post processor into the archiver, but keeping them seperate allows for other functionality to be built on top of the archiver.  A good example of this would be something Fawad was looking for, like a simple Tk or Java front end to view and scroll through an entire data set which is only bounded by the amount of disk space you have to store the trap data.  We do use datawharehousing methodologies here which is basically what we are talking about, but I always find them to be cumbersome and tightly wound like most COTS solutions so writing something with a small footprint is not only cheaper but more adaptable IMHO.
 

Jason Allison
Principal Engineer
ARINC Incorporated

<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web