OpenNMS

At the front tier of OpenNMS, adapting the system for a specific vertical application domain is quite straightforward.

OpenNMS's monitoring, control, and data collection features are handled by a set of concurrent tasks called daemons (BSD UNIX conventions).

Also see the sidebar " Condensed history of OpenNMS" for a description of the origin of this system.

Thanks to the flexibility of JSP technology, the user interface to OpenNMS can be easily customized by Java developers.

The discovery daemon (discovery) of OpenNMS is responsible for the initial and ongoing discovery of the managed network.

During operation, OpenNMS's capsd will scan a detected node to see if the "CLICKMETER" service is supported.

Because OpenNMS was born without legacy (that is, its originator is not a "blackbox" vendor), it took a rather novel design approach.

See Resources for links to detailed information, including where to download the latest version of OpenNMS.

OpenNMS is a one-of-a-kind software system in the open source world.

Before we work with OpenNMS specifics, let's look at the common design elements and operational model that most NMS products share.

You may also want to edit the discovery-configuration. xml file to limit the range of IPs that OpenNMS will scan to managed nodes.

Using Figure 1 as a reference, we can draw concrete parallels between the reference composition and OpenNMS's architecture.

This class must implement the org. opennms. netmgt. poller. ServiceMonitor interface.

We will use this information to access the MBean remotely from OpenNMS.

I have selected OpenNMS for its wide open availability and simplicity in design.

Outside of SNMP, OpenNMS can also detect and manage popular software services (FTP, file servers, database servers, and so on).

We will see in detail how to code and configure an OpenNMS protocol-plugin shortly.

We now know that creating a capsd plugin, and a pollerd monitor will enable us to integrate OpenNMS with our JMX-enabled ClickMeter.