SNMP Traps Troubleshooting Guide

maciej-tokarz — Thu, 04 Sep 2025 12:19:09 GMT

Summary

This troubleshooting article will help you resolve some common issues faced while installing and setting up SNMP trap-based extensions.

Things to know

SNMP Traps (com.dynatrace.extension.snmp-traps-generic) is a special extension that generates Log Events based on the captured traps in the network. It also produces single metric com.dynatrace.extension.snmp-traps-generic.traps.count that is number of captured traps in the interval.

SNMP Traps extensions use datasource that binds to and listens on the configured UDP port. Incoming packets are filtered by the configured IP address and mask. Finally, the packets are verified against provided credentials (v1, v2c, or v3). If there were no errors along the way, the Log Events should be visible in the Logs screen.

Where to look for symptoms?

Specific symptoms mentioned in this article can be seen in the Extensions app/Extension page in the Dynatrace Hub and file logs. Here is how you can find them.

SFM logs

SFM logs are available in the health tab on the Extension page in the Extensions app or on Extension page in the Dynatrace Hub.

Log files can be found in the paths:

Linux ActiveGate: /var/lib/dynatrace/remotepluginmodule/log/extensions/datasources/<directory_corresponding_to_the_used_extension>
Windows ActiveGate: %PROGRAMDATA%/dynatrace/remotepluginmodule/log/extensions/datasources/<directory_corresponding_to_the_used_extension>
Generated support archive from the ActiveGate (How to collect a Support Archive): /remotepluginmodule/log/extensions/datasources/<directory_corresponding_to_the_used_extension>

Problems

No Traps count metric nor(or) trap Log Events

Troubleshooting

Verify the result of metric dsfm:server.metrics.rejections. Common cause of issue are exhausted DDUs.

Verify the result of metric dsfm:extension.engine.logs_ingest.records_rejected.

Check Logs limits in the Dynatrace environment.

Investigate snmptraps datasource and Extensions Execution Controller logs.

Traps count metrics is non-zero but trap Log Events are missing

Troubleshooting

Verify the result of metric dsfm:extension.engine.logs_ingest.records_rejected.

Check Logs limits in the Dynatrace environment.

Make sure you use the latest version of SNMP Traps extension and have Events feature set enabled.

Traps count metric is zero and trap Log Events are missing

There can be multiple reasons that can cause metrics and trap LogEvents to not show up. Listed below are some common causes -

Rejected Metrics

Troubleshooting

Verify the result of metric dsfm:server.metrics.rejections. Common cause of issue are exhausted DDUs.

Rejected Logs

Troubleshooting

Verify the result of metric dsfm:extension.engine.logs_ingest.records_rejected.

Split the metric on the log source and see if the traps are in there.

Monitoring Configuration is in Pending status

Troubleshooting

For SNMP Traps extension, due to the "reverse" function of the data source listening rather than making requests, the EEC status for the extension is not set by using a fastcheck.

The monitoring configuration will stay pending until an ActiveGate in the configured AG group has received the configuration, which can take a few minutes.

If the monitoring configuration is still in pending state after approximately 10 minutes or so, the issue may be related to the Extension Execution Controller (EEC) or something on the ActiveGate blocking the extension from running properly.

Solution

Generate a support archive from the relevant ActiveGate and review the EEC and SNMP Traps-based extension logs.

Verify Network Connectivity

Troubleshooting

First, verify that there is network connectivity from the device that is sending the SNMP Traps to the ActiveGate that is running the SNMP Traps extension using curl with the telnet protocol. The default port for receiving SNMP Traps is port 162, however, different ports can be used.

curl telnet://<AG ip-address/hostname>:162

If the curl from the SNMP-enabled device fails, there may be an intermediate network device, such as a firewall, blocking the traffic between the SNMP-enabled device and the AG, or potentially a missing network route between subnets.

Wrong IP net address

Troubleshooting

This error occurs when a monitoring configuration has been set with an IP address that does not follow CIDR Notation, if targeting traps from a single host, /32 must be added to meet the requirements. i.e. 10.126.240.38/32.

[ds:snmptraps] [severe] [INVALID_CONFIG_ERROR] Wrong ip net address 10.126.240.38 [status code=32]

Solution

Use a correct IP address/Mask.

Verify SNMP Trap source IP included in address space

Troubleshooting

Each monitoring configuration for an SNMP Traps extension has a field that configures the IP address space in CIDR Notation that expected SNMP Traps will be received from, sometimes it may be a /32 listing for a single host up to /8 for an entire class A private network full of IP addresses.

If you are unfamiliar with the process of calculating subnets and determining the IP addresses that would be contained in the address space, a subnetting calculator tool can be utilized to determine the valid IP range. For example, this subnet calculator that takes the input of the subnet mask and an IP address and provides the network address and usable IP range among additional details.

Input

Output

Notice: The IP address/Mask used in the extension monitoring configuration must match the source IP address of the packet that the datasource 'sees' - therefore, if a proxy is used, the extension monitoring configuration must be configured with the IP address/Mask that includes the proxying service IP address.

Verify that the SNMP Traps datasource is listening on the port

Troubleshooting

If an SNMP trap listener is already running on the same host and using port 162, the SNMP Traps extension will not be able to bind to that port, preventing it from receiving SNMP traps properly.

Utilize the command below to output the ports that the host is listening on and review the output to determine if port 162 or the port in the monitoring configuration is actively being listened on by a process other than the ActiveGate/EEC.

The below commands aim to filter the listening processes to target the specific process of the SNMP Traps datasource.

Linux:sudo lsof -a -u dtuserag -nP -iUDP ---- COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME dynatrace 1904 dtuserag 7u IPv6 23455 0t0 UDP *:162
Windows:netstat -abon -p UDP Active Connections Proto Local Address Foreign Address State PID UDP 0.0.0.0:123 *:* 2916 W32Time [svchost.exe] UDP 0.0.0.0:162 *:* 6800 [dynatracesourcesnmptraps.exe]

Notice: Depending on the OS, datasource might not report any issue with port binding even if it's already used by another program. Effectively it will bind to the port, but traps would reach the other program that had bound to port in the first place.

Authentication Error

Troubleshooting

Check the correctness of the authentication parameters and try to manually enter them in the extension monitoring configuration. Compare the authentication parameters from the extension monitoring configuration with the trap sender authentication settings (they should be the same). Avoid using special characters (@ $ # % etc.). Pay attention to smallest details e.g. usage of AES256C instead of AES256. Verify that environment is configured according to documentation.

Verify that traps reach the host that runs the extension

Troubleshooting

It can be done with tcpdump tool or Wireshark.tcpdump -i eth0 -w output.pcap

Verify firewall, SELinux or similar tools settings

Troubleshooting

Even if the packets reach the host running extension, firewall or similar tools might still block datasource from getting the traps. This is very common issue and it is being frequently overlooked by a customer.

Review the firewall settings and make sure that the incoming traffic is allowed on the specified port and there are no rules that block it.

Review the SELinux settings, and make sure that dynatracesourcesnmp is allowed (or not blocked) to bind to ports lower than 1024. Notice: In case SELinux here is the command that you can use to see if UDP traffic on port 162 is allowed semanage port -l | grep http_port. If there is no rule for UDP on port 162 then you can add this by calling this command: semanage port -a -t http_port_t -p udp 162.
As an additional test, configure SNMP Traps to listen on higher port like 9162 and try sending traps on that port. If traps are received, that means the problem still lies somewhere in the customer's environment.

Send traps manually

Troubleshooting

If the SNMP trap provider doesn't produces ones all the time. Use snmptrap tool or any of your choice. It is worth collecting network packets when sending SNMP traps. This can help investigate the issue and confirm that the trap has reached the desired host.

tcpdump -i eth0 -w output.pcap

Device name is coming as Device IP

Troubleshooting

Verify resolving the raw IP to the DNS name from the host where the extension monitoring configuration works.

nslookup <IP>

Notice: The SNMP traps datasource needs at least two traps with the same address to send the resolved IP. Resolving raw IP to DNS name is running in parallel to avoid blocking the sending of traps and improve performance.

MIBs issues

Troubleshooting

The SNMP traps data source uses a default set of MIB files. You can also extend the default set with your own files. There are often issues with loading MIBs and translating OIDs based on the MIB files https://docs.dynatrace.com/docs/ingest-from/extensions20/data-sources/snmp-extensions/snmptraps-extensions#mib-files.

Verify if the traps are translated after changing the SNMP version. For example, from SNMP v1 to SNMP v2c. It can mean that the MIB module cannot support all SNMP versions, and an updated MIB file is required.
Verify NOTIFICATION-TYPE in the MIB file. Some vendor's MIB modules, and even some RFCs, defined a NOTIFICATION-TYPE with a parent of zero but without an object name for that zero, which results in incorrect MIB resolution by our SNMP traps datasource. More information can be found at the link https://www.ibm.com/docs/en/netcoolomnibus/8.1.0?topic=snmp-mib-object-types#omn_ref_mib_mibobjects__title__6.For example:
- At the start of the mib, this is defined. netapp0 OBJECT IDENTIFIER ::= { netapp 0 }
- Then there is some kind of overlap.::= { netapp 0 1131 }

Potential solution:

Try to manually updating mib file to change ::= { netapp 0 x} to ::= { netapp0 x} or remove all '0' in all objects (expect for netapp0).

Verify if in the MIB file in the fragment DEFINITIONS ::= BEGIN, there are excessive whitespaces in between ::= and BEGIN and there should be only a single space.
Check MIB files defines the names from the ROOT, otherwise OIDs are not resolved correctly.
SmiType is nil - it is common warning log SmiType is nil. Module name <module_name>, if the warning in the log file doesn't lead to a missing OID name resolution, it can be discarded. It occurs, because SmiType is verified to be non-nil before parsing. Potential causes:
- SYNTAX clause of a Textual Convention can refer to a previously defined Textual Convention (RFC 2579).DisplayString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "" SYNTAX OCTET STRING (SIZE (0..255)) ObjName ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "" SYNTAX DisplayString (SIZE (0..32))
- MIB object does not define a type (syntax).

SNMP Traps DataSource related knowledge

Useful links

SNMP traps data source - official documentation for SNMP traps data source

Custom MIB files - official documentation how to add custom MIB files.

Dynatrace HUB - all released extensions, where you can download and gain more information about them

Extensions 2.0 - what are extensions 2.0

Custom Extensions Creator - create custom extension directly on the Dynatrace web UI

Signing extensions - how to sing an extension

Dt-CLI usage

What's next

If none of the solutions above has worked for you and you are still experiencing issues with the SNMP Traps extension you are trying to configure there's always a chance that there is a problem with the extension itself or the underlying data source.

In that case feel free to open a support ticket specifying:

A description of the problem

A list of troubleshooting steps that have been performed

Logs from the ActiveGate - support_archive.zip (How to collect a Support Archive)

Working link to the environment

Dynatrace version

ActiveGate version

Extensions Module version

Monitoring configuration ID/name

Screens from the UI where the problem is visible (e.g., monitoring configuration error, errors in log monitoring, data gaps, or lack of data on the dashboard/data explorer)

If it's a custom extension please provide the extension YAML or ZIP file

TCP dump (recorded communication between ActiveGate and SNMP trap provider)

If this article has helped you and provided you with valuable insight, please give it a thumbs-up (kudos).

Re: SNMP Traps Troubleshooting Guide

AntonPineiro — Wed, 30 Jul 2025 11:41:30 GMT

Thank you!

Re: SNMP Traps Troubleshooting Guide

AntonioSousa — Wed, 30 Jul 2025 13:12:17 GMT

@maciej-tokarz ,

Congratulations for this excellent article! I'm a heavy user of traps, in several clients, and wasn't expecting to learn anything, but I did! Some notes:

Traps are typically UDP/162, so a telnet curl might not work, but traps still get through
I normally do the tcpdump with a filter for the specific SNMP traps port, as you might have much more traffic in the AG server:

tcpdump -i eth0 -w output.pcap udp port 162

Re: SNMP Traps Troubleshooting Guide

Romanenkov_Al3x — Tue, 26 Aug 2025 07:46:07 GMT

Thanks for sharing.

Helpful.

Re: SNMP Traps Troubleshooting Guide

fstekelenburg — Tue, 27 Jan 2026 16:23:54 GMT

When running with firewalld on Linux (RH9) make sure the snmptrap is loaded as service. (service snmp does not apply to traps)

# cat /usr/lib/firewalld/services/snmptrap.xml
<?xml version="1.0" encoding="utf-8"?>
<service>
<short>SNMPTRAP</short>
<description>SNMP traps enable an agent to notify the management station of significant events by way of
an unsolicited SNMP message.</description>
<port protocol="tcp" port="162"/>
<port protocol="udp" port="162"/>
</service>

# firewall-cmd --info-service=snmp
snmp
ports: 161/tcp 161/udp
protocols:
source-ports:
modules:
destination:
includes:
helpers:

article SNMP Traps Troubleshooting Guide in Troubleshooting

SNMP Traps Troubleshooting Guide

Summary

Things to know

Where to look for symptoms?

Problems

No Traps count metric nor(or) trap Log Events

Troubleshooting

Traps count metrics is non-zero but trap Log Events are missing

Troubleshooting

Traps count metric is zero and trap Log Events are missing

Rejected Metrics

Troubleshooting

Rejected Logs

Troubleshooting

Monitoring Configuration is in Pending status

Troubleshooting

Solution

Verify Network Connectivity

Troubleshooting

Wrong IP net address

Troubleshooting

Solution

Verify SNMP Trap source IP included in address space

Troubleshooting

Verify that the SNMP Traps datasource is listening on the port

Troubleshooting

Authentication Error

Troubleshooting

Verify that traps reach the host that runs the extension

Troubleshooting

Verify firewall, SELinux or similar tools settings

Troubleshooting

Send traps manually

Troubleshooting

Device name is coming as Device IP

Troubleshooting

MIBs issues

Troubleshooting

SNMP Traps DataSource related knowledge

Useful links

What's next

Re: SNMP Traps Troubleshooting Guide

Re: SNMP Traps Troubleshooting Guide

Re: SNMP Traps Troubleshooting Guide

Re: SNMP Traps Troubleshooting Guide