SNMP Trap Monitoring

Overview

SNMP traps involve the monitored device sending a message to a monitoring station (the LogicMonitor Collector in our case) to notify of an event that needs attention. Through the creation of an EventSource, LogicMonitor can alert on SNMP traps received by the Collector.

Preferred Alternatives to SNMP Trap Monitoring

LogicMonitor generally recommends SNMP polling (where LogicMonitor queries the device for its status) as opposed to monitoring SNMP traps, for the following reasons:

• An SNMP trap is a single packet sent without any deliverability guarantees, to tell you something is going wrong. Unfortunately, it is sent when something is going wrong—exactly the time a single packet is least likely to be delivered.
• Setting up SNMP traps requires configuring your device to send the traps to the correct destination—on every device.
• There is no way to ensure traps are configured correctly to be sent by the device (not blocked by the network or a firewall), and received by the Collector, except sending a trap. So months later, when you need to receive a trap, and things have changed, you may not receive it.
• Traps give no context: did a temperature trap get sent because temperature just recently spiked, or has it been climbing for months?

However, if there is a particular trap that you would like to capture and alert on, perform the various configurations outlined in this support article.

Configuring Your Device to Send SNMP Traps to the Collector Machine

LogicMonitor can alert on SNMP traps received by the Collector. Please follow these general steps to configure your device to send its SNMP traps to the Collector machine:

1. Check your device’s SNMP configuration and ensure that this device’s Collector machine is configured as the SNMP “trap destination” for the device to dispatch its SNMP trap messages out to.
   

   If you run a backup Collector, configure both Collectors as trap destinations. Only the Collector that is currently active for the device will report the trap.

   
   
2. Ensure that UDP port 162 is open between this device and the Collector machine and that no other applications are listening on this port on your Collector machine.
   

   If you run a backup Collector, please make sure that UDP port 162 is open between your device and secondary Collector machine as well.

   
   

   If necessary, the default listening SNMP trap port that the Collector uses can be changed. Please contact support for assistance.

   
   

Configuring an SNMP Trap EventSource

To add a new SNMP Trap Eventsource, navigate to Settings | LogicModules | EventSource | New | EventSource. There are three categories of settings that must be established in order to configure a new SNMP Trap EventSource:

• General Information
• Collector Attributes
• Alert Settings

The settings in these three categories collectively determine the type of EventSource, which devices the EventSource will be applied to, and the conditions that must exist in order for the EventSource to trigger an alert.

General Information

In the General Information area of an EventSource’s configurations, complete the basic settings for your new EventSource. These settings are global across all types of EventSources; see Creating EventSources for more information on these basic settings.

Filters

In the Filters area of an EventSource’s configurations, you can specify a set of filters that will allow you to inclusively filter and select for particular SNMP traps to alert on. All filters defined here are assessed, and any traps that fail any of the filters are excluded from capture and alerting.

The following objects included in most standard SNMPv1 trap messages can be referenced as the Type for your trap filters:

• generalCode
• specificCode
• enterpriseOid
• sysUpTime
• trapVariableBindingCount
• Message*

For SNMPv2 and v3, LogicMonitor supports the following trap filters:

• sysUpTime
• TrapOID
• trapVariableBindingCount
• Message*

* “Message,” when selected as the filter from the Type field, allows users to filter message strings using the RegexMatch and RegexNotMatch operators.

Alert Settings

In the Alert Settings area of an SNMP Trap’s EventSource configurations, use the Severity field’s dropdown to indicate the severity level that will be assigned to the alerts that are triggered by this EventSource.

The other alert settings found in this area are global settings that must be configured across all types of EventSources; see Creating EventSources for more information on configuring these.

Configuring a Collector for SNMPv3 Traps

In order for a Collector to decrypt SNMPv3 traps, you must manually enter additional credentials into into the Collector’s agent.conf file, which, as discussed in Editing the Collector Config Files, is accessible from the LogicMonitor interface. This must be done for every Collector that will receive v3 traps, including backup Collectors.

The following parameters must be edited in the agent.conf file to match those of the device sending v3 traps:

eventcollector.snmptrap.security
eventcollector.snmptrap.auth
eventcollector.snmptrap.auth.token
eventcollector.snmptrap.priv
eventcollector.snmptrap.priv.token

For more information on these SNMPv3 credentials, see Defining Authentication Credentials.

SNMP Traps and SNMP Polling Credentials

Usually, a single set of credentials (for example, snmp.community, snmp.security, and so on) is applied on a device’s host property to receive SNMP traps (v1, v2c, and v3) and to collect data for SNMP DataSources that is SNMP polling. However, some devices may need different SNMP configuration where separate credentials are used for SNMP traps and SNMP polling. In such cases, you can use the following:

• SNMP Polling – The set of credentials/host properties for data collection are as follows: snmp.community, snmp.security, snmp.auth, snmp.authToken, snmp.priv, and snmp.privToken.
• SNMP Traps – The set of credentials/host properties to receive SNMP trap requests are as follows: snmptrap.community, snmptrap.security, snmptrap.auth, snmptrap.authToken, snmptrap.priv, and snmptrap.privToken.
Because the SNMP traps properties are optional, if you do not define them, collector will continue to use SNMP polling credentials (snmp.*) in the host properties to decrypt traps. This also ensures backward compatibility. 

To decrypt the SNMP traps request, the credentials are used in the following order:

1. Collector first checks for the set of credential snmptrap.* in the host properties.
2. If the snmptrap.* credentials are not defined, it looks for the set of snmp.* in the host properties.
3. If sets for both snmptrap.* and snmp.* properties are not defined, it looks for the set eventcollector.snmptrap.* present in the agent.conf setting.