![[LWN Logo]](/images/lcorner.png) |
|
![[LWN.net]](/images/Included.png) |
From: announce-admin@opennms.org
To: announce@opennms.org
Subject: [OpenNMS-Announce] OpenNMS Update v2.17
Date: Tue, 24 Apr 2001 23:23:19 -0400 (EDT)
====================
OpenNMS Update
====================
Vol 2., Issue 17
====================
April 24, 2001
====================
In this week's installment...
* Project Status
+ 0.7.4 -- A Possibility
+ A Quick Tip on Process Dependencies
+ SNMP Threshold Configuration
+ Coding Projects Underway
* Upcoming Road Shows
* Early Adopter Program Status
* The Wish List
==============
Project Status
==============
0.7.4 -- A Possibility:
I'm not promising anything here, but there is a possibility that we
may announce a 0.7.4 release later this week/over the weekend/early
next week. Here's the scoop behind this potential release:
Our very own Sowmya "Java Goddess" Nataraj is abandoning
us^H^H^H^H^H^H^H^H^H^H^H^H^Htaking a vacation for a month. A
month?!? Yep, a month. And as much as I hate to lose her for that
long, I can't think of anybody who deserves this vacation more. As
one of the few people that fully understands all of the intricacies
of OpenNMS, I fully understand her decision to take the time. "May
I please be excused, my brain is full." comes to mind...
So what does this have to do with 0.7.4? Well, Sowmya's been
working on a major rework of RTC, the source of data for the user
interfaces. She's at a point where her changes are pretty well in
and somewhat tested, and we wanted to have everyone working off the
same codebase prior to her leaving, so we're freezing development
later this week to do a build and test a little further. If we find
that everything works as planned (of course it will. Why wouldn't
it?) and that it adds some value over 0.7.3, we'll put together a
0.7.4 release.
And if things don't go so well, we'll cross that bridge when we get
to it.
A Quick Tip on Process Interdependencies
There was a post to the list this week that made me think about the
fact that we haven't done a very good job of explaining some of the
interdependencies between processes within OpenNMS. I'm going to
take a quick stab at it in an attempt to shed a little light on the
subject.
When starting things up from the command line, you'll basically
want to make sure that you do the following things in this order:
* ./opennms.sh icmpd start
NOTE: This starts ICMPD, the daemon that provides ICMP services
for discovery and ICMP polling, if configured. If this ain't
started, discovery won't.
* ./opennms.sh scm start
NOTE: This starts SCM, the Service Control Manager, which is in
turn responsible for starting all of the background processes.
ANOTHER NOTE: You might want to camp out waiting for this one to
start. The next step is dependent on the RTCViewCategoryManager to
be running, and control is returned to the console before it's
necessarily started. You can check its status by doing a
"./opennms.sh scm status"
* ./opennms.sh webui start
NOTE: This one's pretty straight forward. It's basically calling
"/etc/rc.d/init.d/tomcat4 start" by means of the /sbin/service
command.
ANOTHER NOTE: The critical dependency here is caused by the Web
UI's reliance on data provided by RTC in order to present data to
the user. If RTCView Category Manager isn't up when this runs, you
are hosed. You will need to wait and start Tomcat again after RTC
is up. And if you ever restart SCM, note that you should stop
Tomcat, stop SCM, start SCM, and start Tomcat--in that order.
* ./opennms.sh qpage start
NOTE: This assumes that you have paging notifications set up that
rely on qpage and that you have qpage installed. I'll be providing
some insights into qpage next week.
So that's it. And to summarize:
* ./opennms.sh icmpd start
* ./opennms.sh scm start
* Be patient. If you must do something, execute "./opennms.sh scm
status" until RTCViewCategoryManager is in RUNNING state.
* ./opennms.sh webui start
* ./opennms.sh qpage start
And all of this is in the opennms.sh script. And in many cases, the
best documentation is the code itself.
SNMP Thresholding Configuration:
Last week we went through SNMP Data Collection configuration, and I
stopped short on discussing thresholding. So this week, I'll
continue my thought.
First off, let's review the required components of the groups
section of the DataCollection.xml file:
* oid -- The numeric object identifier to GET
* instance -- The instance value for the OID (0 (zero) if it's
actually a "leaf" in the MIB tree, or a keyword of "ifIndex" if we
are after something in the ifTable.
* alias -- a text string to describe the OID. You can populate this
with the OID's name from SMI (which we have done so far), but
since we currently lack any semblance of a MIB compiler, this is
entirely manual.
* type -- a text string (case-insensitive) that describes the data
type for RRD. Currently, acceptable values are Counter, Gauge,
Integer, and TimeTicks.
Within the groups section of the file, there's an additional
optional block that we've not yet mentioned: the <threshold$amp;gt;
block. This block is going to contain the critical information we
need to set up a threshold value:
* What's the threshold value?
* Are we concerned if the collected value rises above or falls below
the threshold value? Or are there two values that should be
considered: one at the low-end of the acceptable range and one at
the high-end?
* How long should the value exceed the corresponding threshold
before we do something?
Mike has implemented this such that we are concerned about two
things: the threshold value (value) and the number of consecutive
polling cycles over which it must be exceeded before we generate an
event (trigger). He addresses the high/low question by embedding
these two data points in either a <low> or <high> block. By using
this construct, he enables setting both a high and low threshold
for the same collected data point. Pretty nifty.
So what does it look like in practice? Well, I could type it out
here, or just refer you to the shipping example we have in place.
In the stock DataCollection.xml, we are configured such that if we
discover a Cisco router, one of the data point we'll collect from
it is avgBusy5 (.1.3.6.1.4.1.9.2.1.58), which is an indicator of
CPU utilization over the past five minutes. If this value exceeds
80% for three polling cycles (fifteen minutes, if you're using our
default polling intervals), we'll generate a thresholdExceeded
event.
Which now brings me back to event configuration (remember this?).
If you check out the stock eventconf.xml, you will see skeletal
configurations for two events:
http://uei.opennms.org/products/bluebird/threshold/highThresholdExceeded
and
http://uei.opennms.org/products/bluebird/threshold/lowThresholdExceeded.
I'll leave it to you to determine the case in which each of
them is generated.
The appropriate event is generated with a series of parms that are
applicable to the event, including the corresponding values for the
"trigger", polling interval, last value polled, OID polled, alias
assigned to that OID. Note that "polled" is kind of a misnomer
here, since the values are actually grabbed from the local RRD
after the data has been collected, rather than keeping the
processing in-line with the actual data collection. That Mike --
he's a thinker...
So using event configuration to handle the resultant event, you
should be able to do just about anything with it you
want--notifications, automated actions, customized log
messages--all that good stuff.
And that's about all there is to it...
Coding Projects Underway:
* CDP/L2/Mapping -- The Pete Siemsen show has begun and comments are
directed to the [disc] (discovery, not discuss) list.
* Snort Integration -- Good news: Matthew is back from vacation. Bad
news: still hasn't had time to brain dump.
* Solaris Port -- Some issues, but everything is getting hashed out
on the [discuss] list.
* NT/2K Port -- No update. The concerns are still with some of our
dependencies.
* SNMP Poller/Data Collection -- Some updates to DataCollection.xml
to handle 3Com and the HostResources MIBs.
* User Interfaces -- As always, Larry's got many new features en
route. If 0.7.4 happens, it will include some cool event viewing
features in the Web UI.
* Maji Prelim Work -- In an effort to actually FINISH his Master's
thesis, Rick has rescoped his effort and has had to drop Maji.
Rick - your efforts to date have been greatly appreciated! If we
can be of help, please let us know! And good luck!
* Configuration -- Jason is working on an event configurator that
will plug into the Web UI. When he's not fixing Admin GUI bugs...
* Discovery/CAPSD/Database Review -- Mike's dreading Sowmya's
vacation. Enough so to schedule his own vacation over the same
timeframe. Just not for the same length...
* Agent Technologies -- No update. Assuming that Craig is still busy
doing Scoreboard stuff...
* Reporting -- Jacinta is hacking something up and Larry is XSLTing
it to display in the Web UI. Looks promising, with PDFs right
around the corner.
* Notification -- Anybody doing anything on this front?
===================
Upcoming Road Shows
===================
In case you've never seen us live and in person, here's your chance:
* May 5th - Twin Cities LUG, Minneapolis, MN
* May 10th - Boulder LUG, Boulder, CO
* June 1st - GNU/Linux BBQ!! Drink good beer and eat fire.
* June 2nd - Northern Virginia LUG (NOVALUG), Alexandria, VA
* June 13-14 - OpenView Forum 2001, New Orleans, LA
* July 25 - O'Reilly Open Source Convention, San Diego, CA
* August 28-30 - Linux World Expo, San Francisco, CA (BOOTH)
For additional details on these appearances and others, check out the
web site at http://www.opennms.org/sections/opennms/events
======================================================
Early Adopter Program Status - Courtesy Jeff Schneider
======================================================
Sorry I missed you all last week, but it was for a good cause.
Since the last update, we've completed a Debian install and also a
first cut at an installation guide for Debian. It won't be ready
today, but by the end of the week we should have it formatted and
published to the Web site as part of the new installation guide.
The installation is officially completed for all Early Adopters. As we
move forward we'll be digging into more complex functionality,
including more advanced data collection and notification.
We'll (in the Jeff sense of the word) also attempt to refrain from
publicly criticizing Shane's grammar and insulting Debian boxes.
Tip of the week: If you add a second poller package, remember to
assign the package to a distributed poller (right now, localhost is
the only poller available)
=============
The Wish List
=============
And now, on with the list...
* In the 0.7.x release (and CVS), checkout the TODO file
* Testing on notification
* New Data Collection configs wanted for the DataCollection.xml
* Build some event configurations.
* Any interest in more TCP pollers? Let us know (or better yet,
build one yourself...)
* LDAP/POP3/nmap Pollers
* Documentation and development your game? How about a white paper
on how to extend OpenNMS with custom pollers, custom configs,
and/or your own scripts/code.
* 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!
* A Security analysis of OpenNMS?
=============
Afterthoughts
=============
Last week, I mentioned that we were targeting 0.7.4 for 5/4.
Obviously, there's a very strong chance we'll deliver it sooner but it
won't have the Web authentication stuff in it. But on the other hand,
it will have Larry's other stuff, which is pretty cool in its own
right...
We've discussed doing an overhaul of our current mailing lists.
Options include adding an "Installation Help" list and dropping some
of the unused ones. Any opinions on this?
Thanks to those of you who let us know that some of the links on the
web server were broken. They should be fixed now.
We're in worse need of documentation help now than ever before. It was
tough having little/no documentation, but having old documentation is
even worse.
Later,
Shane O.
========
Shane O'Donnell
OpenNMS.org
shaneo@opennms.org
==================
_______________________________________________
announce mailing list (announce@opennms.org)
To subscribe, unsubscribe, or change your list options, go to:
http://www.opennms.org/mailman/listinfo/announce