From OpenNMS

Discovery

Configure OpenNMS with the relevant subnets to look in, and optionally with your local SNMP community strings. Start it up, and your network will be automatically discovered. Not only will equipment be discovered, but common services (e.g. Telnet, SSH, IMAP, POP3, HTTP and more) will be found and added to the OpenNMS database for monitoring. If full automatic discovery is not for you, OpenNMS will "discover" nodes that send the OpenNMS server an SNMP trap. Failing that, individual nodes can be manually added via the web-interface, or via custom scripts that send an appropriate "event" to OpenNMS.

Monitoring

OpenNMS keeps track of the status of services, servers, and other equipment on your network. ICMP is used for basic node availability testing. For service testing there are protocol specific pollers for a number of common protocols, including Telnet, SSH, IMAP, POP3, HTTP and many more; these ensure that the service is up, responding, and sending back protocol-appropriate responses. If specific pollers are not available, a TCP/IP port poller can check if a port is accessible (usually a good indicator of service availability).

Events/Notifications

When OpenNMS detects something significant has occurred, such as a service outage, an interesting SNMP trap being received, or some service level threshold being exceeded, it is entered as an event. Events can be stored permanently in the database, and can be configured to trigger notifications to appropriate administrators. Reduction is used to coalesce multiple raw events into single "alarm", reducing the cognitive load of the sheer number of events that occur in a modern network, while still keeping the raw events available for tracking purposes.

Data collection

Using SNMP, JMX, HTTP, and/or (coming in 1.3.3) the Nagios "NSClient" agent (to collect Windows PerfMon counters), OpenNMS can collect and store all manner of interesting data. The out of the box configuration includes numerous commonly available and useful SNMP OIDs, which will be automatically collected if found to be available on monitored equipment. Additions or other customisation of collected values is by way of easily edited XML files.

Data is stored in RRD or JRobin format; both are "Round-robin database" formats which store a fixed number of datapoints in a round-robin fashion providing consistent data storage size (unchanging for a given data point over time), and aggregation for older data to minimise data storage requirements

Of course, all this data is useless unless it can be viewed in an appropriate fashion. Graphing uses standard RRDTool style graphs (provided by JRobin graph facilities if using JRobin for storage). Out of the box configuration includes graphs for the standard collected data points. Graphs can be customised, and new graphs by editing of a simple format text file. Ad-Hoc graphs can be created using the web interface, allowing specific one-off views to be created as required.

Response times of various services are also collected and stored in the same manner, and can be viewed in graph form. This can be useful in determining responsiveness of services, possibly warning of building performance issues.

Thresholds can be set on these collected values, which if exceeded, generates events and possible notifications. Using this, situations such as extended raised CPU usage, or limited free disk space, can be detected and notified.

Web interface

Primary interaction is via a web-based interface. The homepage provides a concise view of current availabilties and outages; the rest of the interface provides quick and simple access to the information collected and stored by OpenNMS