Home view

Home

Node List

Node List

Surveillance

Is a stripped down version of Dashboard only upper part of Dashboard is visible.

Dashboard

To add nodes to the Dashboard or Surveillance view there is currently only one right way of doing it, since to be part of the Surveillance part a node needs to be part of Production, Testing or Development plus a category. The "Manage Surveillance Categories" in the Admin section doesn't allow you to set the Production/Testing/Development part and the Category option in the Assets page has nothing to do with the Dashboard or the Surveillance.

Right way to do it: Select Node List -> click on Node -> Use Surveillance Category Memberships (Edit) (click edit). Click the Function and one of Production/Test/Development. Add nodes to category (with control you can select one more or less, with shift you can select a list).

To add, rename or remove categories: Admin -> Manage Surveillance Categories

Configure Discovery

Configure Discovery: Set up the IP addresses (individual addresses and/or ranges) that you want OpenNMS to scan for new nodes.

Modify Configuration page, click on the 'Add New' button. In the window that pops up, enter the beginning and ending IP addresses for the range that you wish to include for discovery. The default values for Retries and Timeout are usually appropriate. Click the 'Add' button, and the popup window will close and the new range will show up in the Include Ranges section. Click the 'Save and Restart Discovery' button to apply your changes. Discovery of the newly added range will begin within a few seconds; the ping requests and service scans are spread out over time to avoid flooding your network, so it will take some time for all nodes in your newly added range to be scanned and discovered.

Click on the Home link and see the amount of hosts added to the OpenNMS system. Jump around in joy, your first steps are done.

Add interface

Add Interface: Add an interfaces to the database. If the IP address of the interface is contained in the ipAddrTable of an existing node, the interface will be added into the node. Otherwise, a new node will be created.

Enter in a valid IP address to generate a newSuspectEvent. This will add a node to the OpenNMS database for this device. Note: if the IP address already exists in OpenNMS, use "Rescan" from the node page to update it. Also, if no services exist for this IP, it will still be added.

Setting up notification actions

Using the web interface or the users.xml and groups.xml files one can create users and make them part of groups. With this information we can define destination paths for notificiations. The destinationPaths.xml file describes these destination paths. The following example is a default one from this file:

<path name="Email-Admin">
   <target>
      <name>Admin</name>
      <command>javaEmail</command>
   </target>
</path>

The sections that may occur in this file are: destinationPaths, escalate, path, and target. destinationPaths is the main section which always there, unless you are starting the file from scratch. Within this section there is the path section, which uniquely defines a path. The name parameter is used as the unique identifier. In the above example javaMaili (see the notificationCommands.xml file for predefined commands) is used to send notifies to Admin, where Admin can be a group or a user. Default admin (small caps) is the user and Admin is the group in OpenNMS. So in this case the Admin group is notified.

If you are part of the Admin group and your e-mail address is the one used for the admin user you will receive all messages twice!

The path section can also contain an escalate section. The escalate is used to notify somebody when the first person does not repsond to the notification, meaning he or she does not acknowledge the problem. More about acknowledgements can be found in the next section.

The escalate section contains normal target sections:

<escalate delay="string">
	<target> ... </target>
</escalate>

With these destination paths we can tell where notifications have to go in the notification.xml file:

<notification name="interfaceDown" status="on">
   <uei>uei.opennms.org/nodes/interfaceDown</uei>
   <rule>IPADDR != '0.0.0.0'</rule>
   <destinationPath>Email-Admin</destinationPath>
   <text-message>All services are down on interface %interfaceresolve% (%interface%) 
on node %nodelabel%.  New Outage records have been created 
and service level availability calculations will be impacted 
until this outage is resolved.  
   </text-message>
   <subject>[OpenNMS] Notice #%noticeid%: %interfaceresolve% (%interface%) on node %nodelabel% down.</subject>
   <numeric-message>111-%noticeid%</numeric-message>
</notification>

The toplevel section of the notification.xml is the notifications tag. Within this container you will find several notification definitions. Elements that can be found in the notification container are: uei, description, rule, notice-queue, destinationPath, text-message, subject, numeric-message, event-severity, parameter, varbind

But first we will start with the parameters to the notification-tag. The name is a identifier and the status can be on, auto, and off. A status of on means that a message will be sent, off means no message will be sent and auto....?. Not shown in the example is the parameter writeable, it can be set to yes and no, but can't find any explanation....????

The uei defines the trigger for the notification. In this case as soon as the status for an interface goes to down a message will be sent. The different events can be found in eventconf.xml. Next to the fact that there has to be a interfaceDown event, it also has to comply to the rule filter. In this case the IP address of the node may not be equal to 0.0.0.0.

The other elements from our example define how the message looks like and to whom the message will be sent (destinationPath). And they all speak for them selves. The additional tags mentioned before need some explanation: Events also have an associated severity, ranging from Normal for interesting, but non-problematic events, through various levels of importance up to Critical. Also, arbitrary text can be attached to an event for use as operator instructions to deal with the event. For the notifications I assume, that this is a filter... but no documentation found.

The events predefined severity levels are:

Parameter entries are passed to the notification command as switches and look like this:

>parameter name="trapVersion" value="v1" /<
>parameter name="trapTransport" value="UDP" /<
>parameter name="trapHost" value="my-trap-host.mydomain.org" /<
>parameter name="trapPort" value="162" /<
>parameter name="trapCommunity" value="public" /<
>parameter name="trapEnterprise" value=".1.3.6.1.4.1.5813" /<
>parameter name="trapGeneric" value="6" /<
>parameter name="trapSpecific" value="1" /<
>parameter name="trapVarbind" value="Node: %nodelabel%" /<

If the notification has a varbind configured with a name and value, it is used for a case sensitive match against the beginning of an event parameter of the same name. ???

Windows installation

dus alleen SNMP installeren en de rechten op de service wijzigen: - accepted community names op public - accept SNMP packet from OpenNMS server

Mac OS X

Using the SNMP data

Now that everybody talks SNMP we can start collecting data. OpenNMS will automatically find the new services on the host, or you can force a rescan. To force a rescan go to the host-page by selecting "Node List", click on the link to the node and press the Rescan link. Confirm by clicking the Rescan button.

From the node page select the "Resource Graphs" link. IMG Select one or more items and press Submit. Using the CTRL-key one can select or deselect more items.

Add additional MIB information for NET-SNMP

To also display the NET-SNMP disk storage add to /opt/opennms/etc/datacollection-config.xml to the sections <systemDef name="Net-SNMP (UCD)"> and <systemDef name="Net-SNMP"> the following line: <includeGroup>mib2-host-resources-storage</includeGroup>

The node overview "Resource Graphs" will after a restart be expanded with "Storage (MIB-2 Host Resources)" where you can select one or more disk partitions to graph.

NRPE on the to be monitored system

# yum install nrpe nagios-plugins-nrpe nagios-plugins

Edit the /etc/nagios/nrpe.cfg. You should change the line reading allowed_hosts=127.0.0.1 and add the IP address of the OpenNMS system like: allowed_hosts=127.0.0.1,192.168.1.5. Then you should also adjust your firewall to allow connections from the OpenNMS system on port 5666.

# service nrpe start

NRPE testing from the OpenNMS machine

# yum install nagios-plugins-nrpe nagios-plugins

As of version 1.3.10 OpenNMS supports SSL for the NRPE plugin. To check the functionality of NRPE we check with SSL support:

$ /usr/lib/nagios/plugins/check_nrpe -H <to be monitored IP> -c _NRPE_CHECK

Some documentation still refers to the old non-SSL behaviour. In these documents check_nrpe is called with the -n option. If you do that on an SSL enabled system you get:

/usr/lib/nagios/plugins/check_nrpe -n -H <to be monitored IP> -c _NRPE_CHECK
CHECK_NRPE: Error receiving data from daemon.

nrpe[17208]: Error: Could not complete SSL handshake. 1

NRPE and OpenNMS

If you installed the latest 1.6.1 installation from the RPMs, the basic NRPE checks are already configured for you. So no configuration has to be done on the OpenNMS part. Just clicking Rescan on the node should show you NRPE in the availability list.

You now have a check on the presence of NRPE. But nothing else. So you know it is running and that it is healthy. Before we can use scripts on the to be monitored system, we first have to explain a couple of things. We will explain this through the use of shell scripts, but this is true for every kind of test tool. I am just more familiar with shell scripts than with anything else.

NRPE uses exit codes to tell the system the severity of the problem that occured. However this is currently not how OpenNMS treats them. When using NRPE with OpenNMS you should regard the system as an on/off system. Meaning that your test are eighter "everything is ok" or "there is a problem" and nothing in between. To give you an overview of what the relationship is between the NRPE status codes and the OpenNMS events, I will show you a little table:

Everything else is reported as minor code 3, no matter what exit code you use in your tools. The official Nagios Developer Guidelines (http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN78), only describes codes 0-3, so that should be sufficient. The dependent is only mentioned and -1 are only mentioned for completeness, since a couple of scripts (utils.sh in the nagios/plugins directory for example) still use state 4 and the old behaviour of using -1 is still in use.

#!/bin/sh

STATE_OK=0
STATE_WARNING=1
STATE_CRITICAL=2
STATE_UNKNOWN=3
STATE_DEPENDENT=4

echo "check test"

exit ${STATE_OK}

command[check_test]=/usr/lib/nagios/plugins/check_test.sh

    <protocol-plugin protocol="nrpe-test" class-name="org.opennms.netmgt.capsd.plugins.NrpePlugin" scan="on">
        <property key="banner" value="*" />
        <property key="port" value="5666" />
        <property key="timeout" value="3000" />
        <property key="retry" value="2" />
        <property key="command" value="_NRPE_CHECK" />
    </protocol-plugin>

        <service name="nrpe-test" interval="300000" user-defined="true" status="on">
            <parameter key="retry" value="3"/>
            <parameter key="timeout" value="3000"/>
            <parameter key="port" value="5666"/>
            <parameter key="command" value="check_test"/>
            <parameter key="padding" value="2"/>
            <parameter key="rrd-repository" value="/opt/opennms/share/rrd/response"/>
            <parameter key="ds-name" value="nrpe"/>
        </service>

<monitor service="nrpe-test" class-name="org.opennms.netmgt.poller.monitors.NrpeMonitor"/>