🚨 Telegraf Error Guide: '[inputs.snmp] agent ... request timeout' — Fix SNMP Collection Timeouts

Overview

The snmp input queries network devices over UDP. When a device does not answer within the configured timeout after all retries, Telegraf logs a gather error naming the agent that failed:

2026-07-10T12:00:00Z E! [inputs.snmp] Error in plugin: agent 10.0.0.1:161: gathering table interfaces: performing get on field ifDescr: request timeout (after 3 retries)

A closely related form appears when a single scalar OID times out rather than a table walk:

E! [inputs.snmp] Error in plugin: agent 10.0.0.1:161: performing get on field uptime: request timeout (after 3 retries)

Telegraf keeps running and collecting from other inputs, but the affected device produces no interface or system metrics.

Symptoms

• Interface/system metrics for one or more devices are missing while other inputs report normally.
• journalctl -u telegraf repeats request timeout (after N retries) on each collection interval.
• The device responds to ping but not to snmpget/snmpwalk, or vice versa.
• Gather duration for the snmp input climbs toward the plugin interval because each field waits out the full timeout.
• Only SNMPv3 devices fail (auth/priv problem) while SNMPv2c devices succeed, or the reverse.

Common Root Causes

• Wrong SNMP version — polling a v3-only device with version = 2 (or v2c credentials against a v3 agent).
• Incorrect community string or v3 credentials — a bad community, or wrong sec_name/auth_password/priv_password so the device silently drops the request.
• Firewall or ACL blocking UDP/161 — a network ACL or host firewall drops SNMP even though ICMP is allowed.
• Device SNMP ACL — many switches restrict SNMP to specific source IPs; the Telegraf host is not on the allow-list.
• Timeout too short / device slow — large interface tables on busy hardware take longer than the default timeout and retries.
• MIB/OID not supported — the device does not implement a requested OID and drops the PDU instead of returning noSuchObject.
• Rate limiting — polling too many OIDs or too frequently trips the device’s SNMP rate limiter.

Diagnostic Workflow

First reproduce the query outside Telegraf with net-snmp tools. If snmpget also times out, the problem is the device/network, not Telegraf:

# v2c
snmpget -v2c -c public 10.0.0.1 sysUpTime.0
snmpwalk -v2c -c public 10.0.0.1 ifDescr

# v3
snmpget -v3 -l authPriv -u telegraf -a SHA -A "$AUTH" -x AES -X "$PRIV" 10.0.0.1 sysUpTime.0

Confirm the port is actually reachable over UDP from the Telegraf host:

nc -u -z -v 10.0.0.1 161

Then run only the snmp input under Telegraf to see the exact fields that time out:

telegraf --config /etc/telegraf/telegraf.conf --test --input-filter snmp --debug

Compare your config against a correct v2c block, raising timeout/retries for slow devices:

[[inputs.snmp]]
  agents = ["udp://10.0.0.1:161"]
  version = 2
  community = "${SNMP_COMMUNITY}"
  timeout = "10s"
  retries = 3
  agent_host_tag = "source"

  [[inputs.snmp.field]]
    name = "uptime"
    oid = "RFC1213-MIB::sysUpTime.0"

  [[inputs.snmp.table]]
    name = "interfaces"
    oid = "IF-MIB::ifTable"
    [[inputs.snmp.table.field]]
      name = "ifDescr"
      oid = "IF-MIB::ifDescr"
      is_tag = true

For SNMPv3, the block uses secure parameters instead of a community string:

[[inputs.snmp]]
  agents = ["udp://10.0.0.1:161"]
  version = 3
  sec_level = "authPriv"
  sec_name = "telegraf"
  auth_protocol = "SHA"
  auth_password = "${SNMP_AUTH}"
  priv_protocol = "AES"
  priv_password = "${SNMP_PRIV}"

If MIB names fail to translate, Telegraf falls back to numeric OIDs — install the MIBs or use numeric OIDs directly (.1.3.6.1.2.1.1.3.0).

Example Root Cause Analysis

A datacenter switch reported request timeout (after 3 retries) for every field, yet ping 10.0.0.1 succeeded. Running snmpget -v2c -c public 10.0.0.1 sysUpTime.0 from the Telegraf host also timed out, ruling out Telegraf. From a jump box on the switch’s management VLAN, the same snmpget returned instantly.

The switch had an SNMP source-address ACL (snmp-server community public RO 10 referencing an access-list) that only permitted the old monitoring host. The Telegraf host’s IP was not on the list, so the switch silently discarded every PDU — which SNMP surfaces only as a timeout, never a rejection. Adding the Telegraf host’s IP to the switch’s SNMP ACL restored collection immediately. The takeaway: an SNMP “timeout” is frequently an authorization drop, not a slow device, so always test with snmpget from the exact source host.

Prevention Best Practices

• Set timeout and retries deliberately per device class; default values are often too aggressive for large routers and switches.
• Store communities and v3 secrets in environment variables (${SNMP_COMMUNITY}) referenced from the config, never inline in version control.
• Add the Telegraf host to every device’s SNMP source ACL as part of onboarding, and document the management subnet.
• Split large fleets across multiple [[inputs.snmp]] blocks or use agents = [...] lists with a sane plugin interval to avoid rate limiting.
• Monitor the snmp input’s own gather time; a rising trend signals timeouts before data goes fully missing.
• Install standard MIBs on the Telegraf host so OID translation is stable and readable.

Quick Command Reference

# Reproduce the query outside Telegraf (v2c / v3)
snmpget -v2c -c public 10.0.0.1 sysUpTime.0
snmpwalk -v2c -c public 10.0.0.1 IF-MIB::ifDescr

# Check UDP/161 reachability from the Telegraf host
nc -u -z -v 10.0.0.1 161

# Run only the SNMP input with debug output
telegraf --config /etc/telegraf/telegraf.conf --test --input-filter snmp --debug

# Confirm version and installed plugins
telegraf --version

# Watch SNMP timeout errors live
journalctl -u telegraf -f | grep -i snmp

Conclusion

[inputs.snmp] ... request timeout means a device did not answer within timeout after retries — usually because of a wrong SNMP version or credential, a firewall/device ACL that silently drops the PDU, or a timeout too short for a slow device. Reproduce with snmpget from the exact Telegraf host, verify UDP/161 reachability, and tune timeout/retries per device. When the standalone snmpget succeeds and Telegraf still times out, the config version or credentials are the mismatch to fix.