OpenNMS Update v1.39Dec 20, 2000, 05:42 (0 Talkback[s])
(Other stories by Shane O'Donnell)
No-Size-Fits-All! An Application-Down Approach for Your Cloud Transformation REGISTER >
Date: Tue, 19 Dec 2000 21:21:33 -0600 (CST)
Vol 1., Issue 39
In this week's installment... * Project Status + More 0.4.x Info + Getting Things Right + Coding Projects Underway * Curious Bostonians? * New Features En Route * The Wish List
More 0.4.x Info:
Effective today, 0.4.1 has been released, and it incorporates fixes to a couple of bugs from 0.4.0. If you haven't gotten it yet, and you aren't heavily invested in your 0.4.0 install yet, make life easier for yourself--download the RPMs for 0.4.1 and install those.
I also wanted to take a minute and address some of the more common questions that we've been getting. These answers will be pushed into the FAQ at some point, hopefully sooner than later.
* Minimum System Requirements
P200, 256MB RAM, Linux, JDK 1.3+, OpenNMS
Yeah, it's a memory pig, but this is effectively an untuned first release, so we're looking at that. And don't forget, this is intended to scale WAY up, so it's going to need more system resources than office apps. Look at the bright side, memory is cheap
* Starting Things Up
0.4.1 includes the latest and greatest init scripts, which Ben is quite proud of and embarrassed by, all at the same time. Big thanks to those of you that contributed code and ideas and fixes for our earlier scripts.
Also, keep in mind that OpenNMS is expecting the following rough order for firing stuff up:
+ Postgres 7 is running
+ icmpd is running
If it is just not working, you can help everyone out a bit by enabling a higher level of logging. This is pretty easily accomplished by mucking with the "bluebird" properties file in /opt/OpenNMS/data/common/properties/. Find the section on logging, read the comment block, and then change the "logLevel" entries appropriately. Also, note that the logs get written to /var/log/opennms/.
Consider yourself forewarned: We enabled maximum logging on discovery and let it run over night. In doing continuous discovery of a small subnet overnight, our log file was over 70MB by the next morning. Make sure you have plenty of disk space if you decide to turn this on!
* Typical Errors
Depending on available system resources, we do generate errors that have become pretty common for us, at least in our little development testbed.
JSDT Timeouts: Typically indicates that for some reason the JSDT Channel has gone away. Happens more often when you are constrained for memory/resources.
JSDT NoSuchChannelException: Typically means that you've either tried to start things out of order or something has mysteriously gone away while you weren't looking.
* Buttloads of Java Processes
With the way Linux handles Java's native threads, every thread shows up as a separate process to "ps". In limited testing, it looks like a lightly loaded system will have around 420-450 processes alive as it runs. You can count yours with a "ps -ef | grep -i java | wc -l". It may not be an official count, but since the electoral college has already voted, it really doesn't matter anyway...
And yes, "Buttload" is the scientific term for over 300 and less than 1000 (in a process-counting context).
Getting Things Right:
This interim "Testdrive" release has proved to be a blessing in disguise for many of our efforts. It seems that what we've been missing to date is user feedback. Until this release, that was impossible and now, we're starting to see some things that we didn't consider earlier.
As a result, we're changing up our development efforts a little bit to continue to focus on some of the problems inherent to the Testdrive release that will impact the project moving forward. This will change our delivery timeframes for the distributed architecture to some extent, but it also ensures a much sounder release when distributed architecture is announced.
Some of the things we're adding back to the development "To-do" list includes performance data collection, easily customizable pollers, white papers that provide a HOWTO on writing custom pollers, and perhaps some further discussions on adding a web interface. You ask--we deliver. Who could ask for anything more? (Other than Toyota, of course.)
Coding Projects Underway:
* Servlets -- Actively working on building/tuning the "extractors".
* SCM -- Jason is introducing Pause/Resume functionality for the schedulers. Once complete, we'll instrument all SCM processes with this ability.
* TCP Poller -- Mike is working on a generic TCP service poller that will read an XML file for its configuration (port info, banner description, etc) and poll based on your configuration. Makes it easier for you to poll your custom services and applications.
* Maji Prelim Work -- Rick is active on the "events" mailing list.
* Distributed Architecture -- Work continues...
Are you in the Boston area? Are you curious about OpenNMS from a technical/business/strategic perspective?
Luke "Flip-flops" Rindfuss and I will be in the Boston area and thanks to our ever-accommodating friends at the airlines, we have the afternoon free on Thursday, Dec 21, 2000.
We can handle just about anything you'd like to do/know/argue, so if you are looking for a presentation, a conversation, an excuse to exercise your expense account, a way to kill the afternoon, or you simply want to see the winter flip-flops, please advise.
So if you'd like to hook up, let us know. Otherwise, the airport bars stand to make a killing.
New Features En Route
As mentioned earlier, we've got some neato stuff in the works. Here's the 50,000 foot view:
* Generic TCP Poller: Poll services running on the port you configure, looking for the response you configure to expect.
* Portable Agent Technology: We're early in the process of a collaborative effort with another open source project to provide an "agent" that will run on your systems to provide you a means to remotely gather performance and system "health" information.
* Performance Data Collector: joeSNMP has been around for a while now, and we're just about ready to push it into use. We'll be building a configurable SNMP poller that will grab the various data points we (or you) want and will slam them into a back-end performance database.
* Distributed Architecture: This is a major effort and I didn't want to leave it out. But the major buzz we're hearing now suggest that some of these other items may be of greater importance to the community at large, so we're not abandoning those in lieu of the Distributed Architecture. It seems our full plates just got moreso.
* Reporting: The data collection piece doesn't make a whole lot of sense without the means to report on that data. This effort has been underway for a while, but will require a slight dusting off before we delve back into it. The good news is that some of the XSLT stuff has revved since we were into this before, so some of the bugs have likely been addressed.
* Bug Fixes: As you'd likely surmise, with actually having a a functional product out the door, some people are finding bugs and we're doing our best to get those fixes prioritized and into the system where appropriate. Note that if the bugs are related to some throw-away piece of the software (e.g., something that was written to get the Testdrive release out the door and is not there for the long haul), then there's a pretty good chance your bug will be prioritized as "WONTFIX" and you'll hear very little back. The good news is that you've got the source and you can fix your own bugs if it comes right down to it. Open Source Rocks!
The Wish List
Given that the entire newsletter was pretty much dedicated to some of the new efforts/features/fixes we're working on, a Wish List seems pretty redundant at this point.
That said, I elect to forego the Wish List this week.
If there are features or fixes you'd like to see incorporated into upcoming releases that I've not mentioned here, please let me know. You can reach my jam-packed email box directly at firstname.lastname@example.org .
I like the thought of Christmas and all, but man, it's hell on productivity. And it seems like when I do finally get a little bit of time to myself, I'm either decorating something or buying something or going somewhere, all Christmas related.
Here's an idea: how about we spread Christmas out over a few months, and let's get it away from New Years and Thanksgiving--how about late March. Now there's a month hurtin' for a holiday (Work holiday that is. I've been lobbying for March 18th as Hangover Day, but haven't gotten far. Although I haven't approached Teddy Kennedy yet...but that's a different story)
Anyway, we move Christmas to late March (OK. Prove it to me that Jesus was born on 12/25 and I'll back-off). Then, we put into place a set of very particular rules about how it is celebrated. First off, no "Eve" celebrations. Day of. Nothing else. Next, no decorating allowed. Trees are allowed, but only fake ones. No more of this "Killin' trees for Jesus" crap. I'm no tree-hugger, but the whole tradition does seem rather insane when you think about it. And finally, all celebrations on the day of New Christmas must be in one location and one location only. If you have multiple places to go (your place and your significant other's place) pick one and stay there. Tell the other folks that you'll go there next year and that they should know the rules.
In my mind, anyway, this buys us back time, productivity, and it gets us a holiday in late March. Come to think of it, why don't we just make it March 18th. We can kill 2 birds with one stone, and a lot fewer trees.
Color me outta here,
0 Talkback[s] (click to add your comment)