Now let me preface, I come from a strong background in Nagios.  Since taking employment with LimeWire almost a year ago,  I’ve quickly come up to speed with OpenNMS.  I do want to point out that I drank the OpenNMS cool-aid long before this training, if for no reason other than how easy it is to install, configure and maintain.

So, being that I came from a Nagios background, I went into the training looking to map my Nagios/NRPE knowledge to OpenNMS for really custom monitoring.

Like most of you who will actually read this, I’ve seen a lot on NRPE integration with OpenNMS, so I presumed I would be getting a better understanding of how to scale that out.  However, after formulating a better understanding of eventd I’ve decidely abandoned NRPE integration alltogether.

Eventd is configured to only listen on localhost by default, however you can configure it to listen on a particular IP for remote connection.  I suggest you use a host-based firewall to ACL this address.

Bundled with OpenNMS is a script send-event.pl (found at $OPENNMS_HOME/bin/send-event.pl) which is used for sending events to eventd.  This is actually far more scalable than NRPE as it behaves much like traps.

With NRPE, each monitored machine requires a daemon that is added to the polling queue of the monitoring server.  Whereas using send-event.pl, you can cron a poller on your monitored servers and only create an event when necessary.  This will reduce load on the monitoring server as well as each monitored machine.

Events are also easier to configure than creating you own custom traps, as well as being far more configurable with far less work.

In addition, you can configure events to spawn new events and/or pass events to remote OpenNMS eventd servers.

Events and eventd is just one more reason to give OpenNMS a shot.