OpenNMS Update v2.6Feb 07, 2001, 00:05 (0 Talkback[s])
(Other stories by Shane O'Donnell)
Date: Tue, 6 Feb 2001 17:26:35 -0600 (CST)
Vol 2., Iss. 6
Feb. 6, 2001
In this week's installment...
* Project Status + Another Addition to the Team + SNMP Data Collection Approach + Coding Projects Underway * Upcoming Road Shows * Web Site Questions * The Wish List
Another Addition to the Team:
We are all exceedingly pleased to announce that Jeff Schneider, network and systems management consultant par excellence, has joined the OpenNMS team as an "Implementation Consultant". For documentation purposes, let it be known that we just made up that title at the last minute. We had been planning to call him the "Deputy Assistant Undersecretary for Gruntwork", but we couldn't decide if the "s" in Undersecretary should be capitalized, and it was easier to make up a new title than to log on to dictionary.com.
For those of you that may have heard Jeff's name, you may have seen him in any number of places over the past few years:
* Presenting at the OpenView Forum * Teaching NNM & IT/O classes for HP * Consulting for Onion Peel/Tavve * Working as Roadie & Sound Tech for DokkenObviously, we're interested in the last one...
Seriously, we are thrilled to add Jeff to the roster. Jeff will be in charge of delivering services within and helping to extend the OpenNMS Early Adopter Program. With his extensive background, and willingness to approach problems from a process/workflow perspective, Jeff would be a great addition to any team. We're just glad that it's ours!
A hearty welcome to Jeff!
SNMP Data Collection Approach:
For those of you that haven't had time to dig into the data collection, I wanted to take a minute to give you a peak under the covers as to how it will do its thing.
First, it's implemented as just another poller. It uses the same scheduling mechanism as the other pollers for scheduling and is just as configurable as the others, with timeouts, retries, and community strings available to be set. Once you decide to engage this poller, it jumps out and does its thing, which roughly, is as follows:
* Reads the DataCollection.xml file, which maps the SysObjectID of the device in question to a set of OIDs which will be collected from the device.
* When the scheduler invokes the poller with a target interface, those OIDs are SNMP GETted (SNMP GOT?) and slammed into an RRDTool RRD database.
* The RRDTool database is responsible then for archiving the data in appropriate fashions. By default, the RRD will save the following types and amounts of data:
+ 2016 5-minute Intervals + 744 1-Hour Intervals + 93 1-Day Intervals + 105 1-Week Intervals + 60 1-Month IntervalsPlease note that this is the data that will be gathered and stored by default. THIS IS CONFIGURABLE! Do you have a better plan for what data should be stored? Drop me a line...
* Once in the RRD, the data is queriable by the lightweight interface, which will display a list of available interfaces, and upon selecting one, you'll be presented with a graph(s) that reflect the data stored.
* Since the roll-up and archival of data is automatic within the RRD, the databases will never grow beyond their initial size. The databases, depending on the number of data points collected, will each be about 50K per data point, or 500-700K per each interface.
* And since the underlying data source is open source as well, you can also use any of the existing RRDTool front-ends to view the data within. You can find a list at http://www.rrdtool.org/
Cool? Yeah, we think so. RRDTool is a powerful thing.
Coding Projects Underway:
* Solaris Port Postgres Procedures -- Underway. No update. Apparently discovery is working.
* Postgres for NT -- No update since last week.
* SNMP Poller/Data Collection -- The data collection work is done, now we're working on the interface to generate the reports.
* Event DTD -- Finalized. Should be checked in soon.
* Tuning -- Down to memory requirement of about 128MB for the core processes to run with no swapping. Plenty of other tweaks coming as Weave finishes this one up (again).
* User Interfaces -- Making great progress!
* SCM -- Gutting and replacing JSDT with an RPC mechanism. ACPL Tea, for those of you keeping score at home.
* SCM UI -- Will have to be re-tooled for the SCM change, but many of the problems will be avoided, if not eliminated.
* TCP Poller -- Still waiting for some of the creative configurations that I know you all are capable of...
* Maji Prelim Work -- Rick is building Perl code that is successfully parsing MIB files. Check him out, in all his glory, on the "events" list.
* Notification Configuration -- Works in the U/G/V config panel, but not the Wizard. We're disabling the Wizard until the functionality is there.
Upcoming Road Shows
For the upcoming trip to Albuquerque and SLC, Steve will be making the trip.
* February 15th - Utah JUG, Salt Lake City, UT * May 5th - Twin Cities LUG, Minneapolis, MNFor additional details on these appearances and others, check out the web site at
Web Site Questions
I've gotten a couple of notes this week that our web server has been painfully slow.
We are unable to duplicate this in-house, and was wondering if any of the rest of you have noticed this or not. So far, the reports seem to lean toward a "works for me" resolution, but I want to give PF the benefit of the doubt.
If you are having problems or noticing poor performance, please let Ben know at email@example.com
The Wish List
First, a big thanks to everyone that's actively working with and trying out the product. There are a lot of cool innovations committed recently that you'll want to take a look at as well. Again, our thanks to the testers!
Now, on with the list...
* Test the install.pl script!!!
* Our SNMP Data Collector will rely on a configuration file, DataCollection.xml (or something like that). This file will map what SNMP OIDs we should pull from a device with a given SysOID. Now the question is, "What should we pull?" Recommendations? Tips? I figure we'll pre-populate some canned collections for Cisco routers, Bay routers, and whatever else can be contributed. All ideas are appreciated, and especially ideas that come back in the format of the DataCollection.xml file (available at: http://www.opennms.org/cgi-bin/cvsweb.cgi/data/common/conf/DataCollection.xml
* Now that we have a "generic" TCP Poller, we could use some help in building some configurations to test services that you may be concerned with. For example, is LDAP do-able? How about applications like Peoplesoft, SAP, Baan? Remember, you can deploy multiple of these pollers against multiple ports.
* Testing on new, exciting platforms is always appreciated. Somebody want to mess with the Cygwin port of our Postgres stored procedures and see where we stand?
* Any additional help we can get proving our documentation either right or wrong is appreciated. Thanks.
* Got any creative applications for OpenNMS that we haven't considered? Let us know!
* Anybody up for a security analysis of OpenNMS? We know we've got a lot of holes, but we'd rather have most of them identified before we start trying to plug them. Any security folks that are playing along, feel free to chime in here. Anytime, now. Go on. Anytime...
This is promising to be another week where it's suddenly Friday at 8pm and I wish days and weeks were longer, since I feel like I've gotten nothing done but wage senseless battles on email. I wish I could just let that stuff go, but alas...
Our office is now officially full. We've got more people than desks, and still only one phone. Which gets interesting when Luke needs to fax, Larry needs to take a call from his wife, and Jason is trying to test paging notifications. You've heard of playing "King of the Hill"? Around here it's "King of the Dial-Tone".
0.6 is everso rapidly approaching. We're on target for our Valentine's Day release, and there are enough new and interesting features that you are DEFINITELY going to want to take a look.
We just crossed the 200 mark in bugs registered with Bugzilla. I don't know if this is a good sign or bad, but the good news is that the better part of them have been addressed.
Going to be in Boston and want to meet Luke & I for a beer at the airport? Let me know. Luke's buyin'.
Shane O. ======== Shane O'Donnell firstname.lastname@example.org http://www.opennms.org/
There are few things I like better than being generous with Luke's beer money.