SNMP Traps LogSource Configuration

SNMP Traps type LogSource enables LogicMonitor collector to ingest SNMP traps to LogicMonitor logs without configuring alerts.

Requirements

• Collector version EA Collector 34.500 or later. For more information on upgrading collector, see Managing Collectors.
• Access to LogicMonitor UIv4

Configuration Options

The configuration option includes configuration details specific to the SNMP Traps LogSource. For more information on adding a LogSource, see Configuring a LogSource.

Info

Select LM Logs: SNMP Traps from the Type drop-down and provide basic information such as name, group name, description, and technical notes.

AppliesTo

Applying LogSource on a Collector

With collector version EA-35.200 onwards, you can apply LogSource to a collector directly using the Apply to Collector(s) option. By default, the Apply to Collector(s) option is disabled.

Applying LogSource on the collector is useful in the following scenarios:

• The collector does not monitor the device which is forwarding the SNMP traps to the collector.
• LogicMonitor does not monitor the device which is forwarding the SNMP traps to the collector.

For a device that forwards the SNMP traps to a collector, perform the following steps to apply a LogSource to a collector.

1. Add the SNMP community (for the SNMP v1/v2 traps) or the SNMP credentials (for the SNMP v3 traps) as collector (self-monitoring device) properties to enable the collector to authenticate the traps forwarded to it. For more information, see Defining community strings and SNMP credentials for Ingestion of SNMP traps as LM Logs.
2. Create a LogSource and enable the Apply to Collector(s) option to apply the LogSource on the collector.

Exclude Filters

For collector versions released prior to EA Collector 36.400, traps that match with the exclude filters criteria are not ingested.

With EA Collector 36.400 and later, traps that match with any of the exclude filters criteria are not ingested. You can use the following filters to exclude SNMP traps.

Available Parameters

Log Fields

You can configure Log Fields (tags) to add metadata to the log entry.

Available Parameters

Resource Mappings

For resource mapping you can configure LM log key to match a monitored resource’s LM property.

Available Parameters

For correct resource mapping, it is essential to know how the source (host) address is extracted from the trap based on the SNMP trap version and how it is forwarded to the collector device.

Starting with EA Collector 36.100, based on the SNMP trap version, the collector will use the host address from the following elements of the trap PDU.

Example

Scenario —Traps are forwarded from one device to another before reaching the collector device. 

• Device A (Trap generating device)—The device that generates the SNMP trap. The IP address of this device is 192.168.1.10.
• Device B (Trap forwarding device)—The device that receives the trap from Device A and forwards it to the trap collector device. The IP address of this device is 192.168.1.20.
• Device C (Trap collector device)—The collector device where traps are collected and monitored.

SNMP v1 Trap

• Agent Address—The IP address of the device that generates the SNMP trap (that is, Device A) is included in the agent-addr field of the trap message.
• Trap Forwarding—When the Device B forwards the trap to Device C, typically, the Device B uses the Device C’s address as the destination address for the trap, but the agent-addr field still contains the Device A’s IP address.

 SNMPv1 Trap Packet Example

PDU Type: Trap
Agent Address (agent-addr): 192.168.1.10  (Device A’s IP)
Variable Bindings: ... 

SNMP v2c and v3 Trap

• Variable Bindings—The agent-addr is part of the trap’s variable bindings. The agent-addr variable is explicitly included as one of the OID-value pairs in the trap message.
• Trap Forwarding—When the Device B forwards the trap, it includes Device A’s IP address in the variable bindings. As a result, the Device C can view the IP address in the trap message.

SNMP v2c and v3 Trap Packet Example

PDU Type: Trap
Variable Bindings:
    1.3.6.1.6.3.18.1.3.0 (agent-addr): 192.168.1.10  (Device A’s IP)
    ...

You can observe that for all the supported SNMP versions, when the Device B forwards the traps to Device C, it retains the Device A’s IP address in the relevant field (agent-addr for SNMP v1 and a variable binding for SNMP v2c and v3), ensuring that the Device C knows the original source of the trap.

If the agent-addr is missing or empty for v1 traps, or if the specified variable binding is missing for SNMPv2c and SNMPv3 traps, the collector device uses the socket address which is Device B’s address (192.168.1.20) for resource mapping.

SNMP Traps LogSource Configuration Example

The following is an example of SNMP Traps LogSource configuration.

Basic Information

Exclude Filters

Log Fields

Resource Mappings

Processing SNMP Traps using LogSource and EventSource

Collector processes SNMP traps using LogSource or EventSource. At a time, either LogSource or EventSource is used and under any scenario, both cannot be used simultaneously.

• Processing SNMP traps using LogSource–If a collector monitors a device with LogSource applied on it, the collector processes the SNMP traps only from devices on which LogSource is applied. Collector ignores (that is, does not process) traps from devices that do not have LogSource applied on them.
• Processing SNMP traps using EventSource–If LogSource is not applied on all the devices monitored by a collector, but EventSource is applied on them, the collector processes the SNMP traps from devices on which EventSource is applied.

Refer the following scenarios to understand how collector processes SNMP traps. In these scenarios, we have considered 3 devices monitored by the same collector. 

Scenario 1

The collector processes SNMP traps from both Device 1 and Device 3 only using LogSource as there is at least one device with LogSource applied on them.

The SNMP traps from Device 2 are ignored (that is, not processed) as LogSource is not applied on Device 2.

Scenario 2

The collector processes SNMP traps from both Device 1 and Device 2 only using EventSource as none of the devices have LogSource applied on them. The SNMP traps from Device 3 are ignored (that is, not processed) as Device 3 does not have EventSource applied on it.

SNMP Traps Processing Preference

With the capability to apply LogSource on a collector, depending on the customer requirement, there are three ways in which the collector can process the SNMP traps.

• To ingest the SNMP traps received by the collector–Enable the lmlogs.snmptrap.enabled property in the agent.conf settings. Alternatively, you can select the Enable log collection for Syslog and SNMP trap option on the Add collector page to enable this property. Once enabled, the collector ingests all the SNMP traps without any customisation such as filters, resource mapping, and so on.
• To add customisations–For customisations such as filtering traps or adding a different method for resource mapping, a LogSource should be created and applied on the collector that receives the SNMP trap by enabling the Apply to Collector(s) option on the LogSource.
• To handle the SNMP traps from a device using a specific LogSource definition–A usual LogSource should be applied on the device which is forwarding the SNMP traps to the collector. 

A usual LogSource that is applied on a device is preferred over the LogSource applied on a collector for processing the SNMP traps.

A LogSource that is applied on a collector is preferred over collector’s agent.conf property lmlogs.snmptrap.enabled for processing the SNMP traps.

You can refer the following scenarios to understand the preference in which the collector (that receives the SNMP traps) processes the SNMP traps.

* A collector monitors a device in the following 2 scenarios:

• On the Manage Resource page, the collector is assigned as a Preferred Collector to the device.
• On the Manage Resource page, the collector is assigned as a Log Collector using the Set LM Logs Collector option.

Translating SNMP Traps using Custom MIBs

Starting with EA Collector 35.400 release, you can use the MIBs to JSON Converter Utility to convert the MIB files to JSON files. In a collector, the utility is located at [LogicMonitor Collector Directory]/bin/snmpMibsToJsonConversionUtil.

This Python-based utility is designed to convert the custom MIBs (which LogicMonitor does not support out-of-the-box) to enterprise JSON files, which the collector then uses to translate the SNMP traps. By default, the enterprise JSON files are placed in the [LogicMonitor Collector Directory]/snmpdb/custom directory. 

How SNMP Trap Translation Works

SNMP traps are received as a blob of data in the form of an SNMP Protocol Data Unit (PDU). The PDU contains multiple elements which are initially encoded. After decoding the SNMP trap PDU, we get various elements of metadata associated with the SNMP trap, an Object Identifier (OID) representing the type of trap, and a series of variable bindings (varbinds) which are a list of pairs where each pair consists of an OID and its corresponding value.

The SNMP trap translation serves the following purpose:

• It provides human readable values enclosed in parentheses immediately adjacent to the OIDs contained in the SNMP trap captured by LM Logs.
• It maps the human readable values as fields associated with the SNMP trap along with their corresponding values. These fields can be used in filters and queries in the LM Logs platform, and in log pipelines and alert conditions.

Example

Elements of SNMP Trap PDU

Trap Oid => 1.3.6.1.4.1.9.9.276.0.1
Variable Binding 1 => 1.3.6.1.2.1.2.2.1.1=5
Variable Binding 2 => 1.3.6.1.2.1.2.2.1.2=GigabitEtherenet1/0/5
Variable Binding 3 => 1.3.6.1.2.1.2.2.1.8=2
Variable Binding 4 => 1.3.6.1.2.1.2.2.7=3

Starting with EA Collector 36.200, to format the SNMP trap messages as JSON, you can set the lmlogs.snmptrap.formatMessageAsJson.enabled property to true in the agent.conf settings. By default, this property is set to false. Also, the translated variable binding keys of the SNMP trap are included in a single log field, instead of individual log fields for each translated variable binding key. 

If the lmlogs.snmptrap.formatMessageAsJson.enabled property is set to false

SNMP trap ingested as LM Log after translation
Message => trapOid=1.3.6.1.4.1.9.9.276.0.1(cieLinkDown) 1.3.6.1.2.1.2.2.1.1(ifIndex)=5 1.3.6.1.2.1.2.2.1.2(ifDescr)=GigabitEtherenet1/0/5 1.3.6.1.2.1.2.2.1.8(ifOperStatus)=2(down) 1.3.6.1.2.1.2.2.7=3

Apart from the message field, the translated variable binding keys of the SNMP trap are included in individual log fields for each translated variable binding key along with the respective values. If the variable binding value is not translated, the field will include the raw variable binding value. In this example, the following fields are present in the log:

If the lmlogs.snmptrap.formatMessageAsJson.enabled property is set to true

The SNMP trap messages are formatted as JSON.

{
  "trapOID": {
    "value": "1.3.6.1.4.1.9.9.276.0.1",
    "name": "cieLinkDown"
  },
  "1.3.6.1.2.1.2.2.1.1": {
    "name": "ifIndex",
    "value_raw": "5"
  },
  "1.3.6.1.2.1.2.2.1.2": {
    "name": "ifDescr",
    "value_raw": "GigabitEtherenet1/0/5"
  },
  "1.3.6.1.2.1.2.2.1.8": {
    "name": "ifOperStatus",
    "value_raw": "2",
    "value_desc": "down"
  },
  "1.3.6.1.2.1.2.2.7": {
    "value_raw": "3"
  }
}

The translated variable binding OIDs are included in a single log field varbinds instead of individual log fields. 

Requirements to Use the Utility

• Custom MIB files along with all its dependencies or parent MIB files.
• You must have Python version between 3.8 to 3.12 installed on your machine.
• The utility must be run with the same user which is used for installing the collector.
• Ensure that the definition of a MIB file is not part of multiple input MIB files. If it is, the utility will consider either of such files. For example, for the ABC MIB, there should not be multiple files with the below line
  ABC DEFINITIONS ::= BEGIN
• Install the dependencies of the utility. To do so, go to the utility directory [LogicMonitor Collector Directory]/bin/snmpMibsToJsonConversionUtil/ and run the following command:

pip install -r requirements.txt

How the Utility Generates the JSON Files

1. Run the snmpMibsToJsonConverter.py file provided in the utility directory.
2. Specify the directory path where the custom MIB files are placed.
3. Specify the directory path to generate the converted JSON files. By default, the files are generated in the default directory [LogicMonitor Collector Directory]/snmpdb/custom. However, you can specify a different directory.
4. The utility converts the MIB files and generates the JSON files in the directory that you specified.
5. If the JSON files are generated in a different directory, copy the files to the default directory [LogicMonitor Collector Directory]/snmpdb/custom.
6. When the collector restarts, the collector uses the JSON files to translate the corresponding SNMP traps.

If you have questions or face any issues while using the utility, contact your LogicMonitor Customer Success Manager (CSM).

Troubleshooting Utility Issues

This section helps you troubleshoot issues related to the MIBs to JSON Converter utility such as missing source MIBs and failed MIBs.

Troubleshooting Missing Source MIBs

When running the utility, look for the “Missing source MIBs:” logs. A MIB file name in the log indicates that the MIB conversion failed due to that missing MIB file. For example, you can find the following log message indicating that conversion failed due to the missing “ABC-MIB”:

Missing source MIBs: ABC-MIB

Solution

In the directory that you specified, add the missing source MIB “ABC-MIB” along with the other MIBs and run the utility again.

Troubleshooting Failed MIBs

When running the utility, look for the “Failed MIBs:” logs. Any error in the log indicates that the MIB conversion failed along with the reason for failure. In the “Failed MIBs:” logs, you can find the following log messages.

Missing Parent or Dependent MIB

Failed MIBs: ABC (no module "XYZ" in symbolTable at MIB ABC)

The log indicates that conversion failed for the ABC MIB.

Solution

In the directory that you specified, add the “XYZ” MIB along with the other MIBs and run the utility again.

WinError 183

Failed MIBs: ABC (failure writing file inter_json\ABC.json: [WinError 183] Cannot create a file when that file already exists: 'C:\\snmpMibsToJsonConversionUtil\\inter_json\\tmp44ahdl2d' -> 'inter_json\\ABC.json' at MIB ABC)

Solution

This error can occur only for the Windows OS. You can ignore this error, as the MIB is already compiled by the utility.