This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Accept
Reject
Preferences
FAQ
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 
New Article

SNMP Traps Troubleshooting Guide

maciej-tokarz
Dynatrace Contributor
Dynatrace Contributor

on ‎30 Jul 2025 11:46 AM - edited on ‎07 Aug 2025 10:13 AM by Dynatrace Guide

 

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. 

maciejtokarz_0-1753790650397.png

 

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.

maciejtokarz_0-1753791397426.png

 

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

maciejtokarz_0-1753792926698.png

Output

maciejtokarz_1-1753792956531.png

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-exte....

  • 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_....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.

 

SNMP Traps DataSource related knowledge

 

Useful links

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

 

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 
  • 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). 

Version history
Last update:
‎07 Aug 2025 10:13 AM
Updated by:
Dynatrace Guide
Comments
AntonPineiro
DynaMight Guru
DynaMight Guru
‎30 Jul 2025 12:41 PM

Thank you! :take_my_money:

0 Kudos
AntonioSousa
DynaMight Guru
DynaMight Guru
‎30 Jul 2025 02:12 PM

@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

 

Romanenkov_Al3x
DynaMight Champion
DynaMight Champion
‎26 Aug 2025 08:46 AM

Thanks for sharing.

Helpful.

0 Kudos