SNMP Trap Monitoring
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.
LogicMonitor generally recommends SNMP polling (where LogicMonitor queries the device for its status) as opposed to 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.
- 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.
LogicMonitor can alert on SNMP traps received by the collector. Please follow these generalized steps to configure your device to send its SNMP traps to the collector machine:
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, please make sure that you configure both collectors as trap destinations. Only the collector that is currently active for the device will report the trap.
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 more assistance.
Add a new SNMP Trap eventsource from Settings | LogicModules | Eventsource | New | Eventsource and set the Type to SNMP Trap:
The EventSource definition in the example above will display alert for any SNMP traps with generalCode=3 ("linkUp") received by the collector from any device that has the category "CiscoASA".
- Applies To - This field is used to associate an EventSource with a particular device (or group of devices). Click here for more information on how to use the AppliesTo field.
- Group - This field is used to group several EventSources in a folder. This field is optional. Click here for more information on how to use grouping.
- Filters - This section is used for inclusive filtering. This is allows you to specify parameters to receive a particular trap. This field is optional.
- Alert Settings - This section allows you to define the severity level of the alert to generate when a matching trap is received and whether or not there should be a custom alert template used for the alert notification. Alert routing is still dependent on the Alert Rules that you use.
- Effective Interval - This field defines a period of time in minutes to regard the trap as being in alert. For example, given an Effective Interval of 60, an event such as system restart will show as a current alert for 60 minutes after the trap is received. This gives people time to be notified of the alert, acknowledge it, or possibly have it escalated. After the Effective Interval has expired, the device will no longer be in alert from this trap. (Of course, the alert will be visible in the alert history, and will have been sent according to applicable escalation rules already.)
As with filtering used in LogicMonitor datasource templates, you can specify a set of filters in your SNMP trap-collecting eventsource that will allow you to inclusively filter on and select for particular SNMP traps to alert on. These filters are assessed consecutively from top-to-bottom, and any traps that fail any of the filters that you define here will be excluded from capture & alerting.
The following objects included in most standard SNMPv1 trap messages can be referenced for your trap filters:
For SNMPv2 and v3 we support the following trap filters:
Receiving SNMPv3 traps requires additional configuration as described in the next section.
Note: Filtering & alerting on other arbitrary strings contained in your trap message body are not supported at this time.
Collector configuration for SNMPv3 traps
In order for the Collector to decrypt SNMPv3 traps, you must enter the necessary credentials in the Collector's agent.conf file. This must be done for each Collector that will receive v3 traps, including backup Collectors.
- Go to Settings > Collectors and find the Collector that will be receiving v3 traps.
- Click the Manage button, and then select Collector Configuration from the the Support menu.
- Make sure you are on the Agent Config tab, then enable "Edit agent.config manually".
- Click anywhere in the text window, then search for "snmptrap" using your browser's search function. Find the section "# SnmpTrap".
- The following parameters must be edited to match those of the device sending v3 traps. For more information about these parameters, see this page on device credentials.
- When you have made the necessary edits, click the Save and Restart button at the bottom right of the Collector Configuration window.
Testing your EventSource
It is recommended that your first create an EventSource without any filters initially to receive all traps from a device (and see all their parameter values), and to add an appropriate filter later.
Alternatively, you can use a network sniffer to capture a sample trap packet from a device you want to monitor to find out specific parameter values to use in a filter.
When a trap is sent by a device to a collector, and is matched by a filter, it will be displayed in the devices Tab:
Note: If multiple traps have been received by the same EventSource, only the most recent trap will be shown in the alert list.