From OpenNMS

Contents 1 Overview 2 Determining if a node will be collected from 3 SNMP Collection Phases and OID Matching 4 Collection Matches OIDs, but No Data

Overview

Applies To: 1.5.9x

OpenNMS's collection daemon, collectd, runs periodically based on the configuration file OPENNMS_HOME/etc/collectd-configuration.xml. Multiple collections can be defined, and the collection parameter maps to the collection name in OPENNMS_HOME/etc/datacollection-config.xml. The actual SNMP collection is controlled by OPENNMS_HOME/etc/snmp-configuration.xml.

collectd-configuation.xml:

<collectd-configuration threads="100">
       <package name="example1">
               <filter>IPADDR != '0.0.0.0'</filter>
               <include-range begin="1.1.1.1" end="254.254.254.254"/>
               <service name="SNMP" interval="300000" user-defined="false" status="on">
                       <parameter key="collection" value="default"/>
                       <parameter key="retry" value="2"/>
                       <parameter key="timeout" value="1000"/>
               </service>
       </package>
       <collector service="SNMP" class-name="org.opennms.netmgt.collectd.SnmpCollector"/>
</collectd-configuration>

The <filter> statement is turned into a database query (see filters for details), while the <specific> and <include-range> options used to filter the IP addresses returned by the query.

collectd's logs are written to OPENNMS_HOME/logs/daemon/collectd.log, and the verbosity of this log file is controlled by the log4j.category.OpenNMS.Collectd entry in OPENNMS_HOME/etc/log4j.properties. The value of this variable (and all other logging levels) can be changed on the fly, and collectd will change its logging level after a short period of time.

For the rest of this documentation, the log level for collectd has been set to DEBUG, and the IP address of the node being checked is 1.2.3.4.

Determining if a node will be collected from

The default collectd package name is example1. You may have renamed this, or may have multiple collectd packages configured.

# grep -E 'CollectdPackage|getSpecificationsForInterface|scheduleInterface' collectd.log | grep 1.2.3.4
CollectdPackage: interfaceInPackage: Interface 1.2.3.4 passed filter and specific/range
 for package example1?: true
Collectd: getSpecificationsForInterface: address/service: ... interface does belong to package: example1
Collectd: scheduleInterface: found 1 matching specs for interface: ... 1, issnmpprimary = P]
Collectd: scheduleInterface: [OnmsIpInterface@71f56ac ipaddr = '1.2.3.4', ... collection, scheduled

You may or may not see more lines of output, but these are the ones that indicate that a node's primary interface has been found to match a collection package, and that collection has been scheduled. If the getSpecificationsForInterface line says does not belong to package, and you expected to to belong, check your <filter> and <specific>/<include-range> definitions for the collection package.

SNMP Collection Phases and OID Matching

collectd has two collection phases. The first phase is classified as '-1', and the second as '-2'. It appears that the -1 phase is for OIDs that are single-collection types, while the -2 phase is for OIDs that are present in tables. The finalised collection OIDs can be found with

# grep getAttributeTypes collectd.log | grep 1.2.3.4
 OnmsSnmpCollection: getAttributeTypes(Agent[nodeid = 69 ipaddr= 1.2.3.4], -1): [tcpActiveOpens [.1.3.6.1.2.1.6.5],
  ... tcpPassiveOpens [.1.3.6.1.2.1.6.6], tcpAttemptFails [.1.3.6.1.2.1.6.7], tcpEstabResets ... 
 OnmsSnmpCollection: getAttributeTypes(Agent[nodeid = 69 ipaddr= 1.2.3.4], -2): [ifInOctets [.1.3.6.1.2.1.2.2.1.10],
  ...

You can either eye-ball this output, or add a | grep --color name_defined_in_data_collection to the end of the search. If you don't see the OID that you're expecting, it's possible that OpenNMS has decided that it does not match the machine. This can be verified in the datacollection-config.xml configuration file and with an snmpget command.

For instance, assume that you are checking a Linux machine for disk usage and disk percent usage, with a configuration that looks like:

     <systemDef name="Net-SNMP (UCD)">
       <sysoidMask>.1.3.6.1.4.1.2021.250.</sysoidMask>
       <collect>
         <includeGroup>mib2-host-resources-system</includeGroup>
         <includeGroup>net-snmp-disk</includeGroup>
         <includeGroup>net-snmp-disk-more</includeGroup>
       </collect>
     </systemDef>

     <systemDef name="Net-SNMP">
       <sysoidMask>.1.3.6.1.4.1.8072.3.</sysoidMask>
       <collect>
         <includeGroup>mib2-host-resources-system</includeGroup>
         <includeGroup>net-snmp-disk</includeGroup>
       </collect>
     </systemDef>

Checking the collectd log shows that the OIDs for net-snmp-disk-more are not showing up as being matched to the node. The answer is probably that you've got the wrong sysObjectOID, and that while you think your server is under the UCD enterprise ID, it's actually under the Net-SNMP enterprise ID. This can be checked with

# snmpget -On -v1 -c <community> 1.2.3.4 sysObjectID.0
.1.3.6.1.2.1.1.2.0 = OID: .1.3.6.1.4.1.8072.3.2.10

You may need to change the value of -v to either 2c or 3, depending on the configuration of the node. Since the node matches 8072, copy the <includeGroup> line down to the Net-SNMP system definition and restart OpenNMS.

Collection Matches OIDs, but No Data

One of the more perplexing problems is when the getAttributeTypes search indicates that the OID has been matched to the machine, but no data files are appearing in OPENNMS_HOME/share/rrd/snmp/<node>. FIXME