Date: Tue, 6 Feb 2001 17:26:35 -0600 (CST)
From: announce-admin@opennms.org
To: announce@www.opennms.org
Subject: [opennms-announce] OpenNMS Update v2.6
OpenNMS Update
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
Project Status
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 Dokken
Obviously, 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 Intervals
Please 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, MN
For additional details on these appearances and others, check out
the web site at
http://www.opennms.org/sections/opennms/events
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 ben@opennms.org
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…
Afterthoughts
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 shaneo@opennms.org http://www.opennms.org/
There are few things I like better than being generous with Luke's beer money.