Troubleshooting SNMP
Last updated on 01 October, 2024Overview
For most Linux hosts, all that is necessary for monitoring is for SNMP and NTP to be accessible from the collector machine. If you are not getting data for SNMP DataSources on a host, we’ve compiled a list of troubleshooting items to verify.
General Troubleshooting
Start with these basic checks:
- Ensure that SNMPd is running.
- If you’re using SNMPv1 or v2: Is the device configured with the correct community string in LogicMonitor (either at the global, group or device level)? If no community string is set, LogicMonitor defaults to using public. Note: Some Linux distributions significantly restrict which metrics are exposed if the community string is set to “public”. It is recommended that you set your community string to something else. See the “Validating SNMP Credentials in LogicMonitor” section of this article to verify that your device has the correct community string set.
- If you’re using SNMPv3: Is the device configured with the correct authpass, privpass and username (either at the global, group or device level)? See the “Validating SNMP Credentials in LogicMonitor” section of this article to verify that your device has the correct v3 credentials set.
- Can queries from the collector device reach the monitored device? You can check this by running tcpdump on the monitored host. If the queries are not reaching the device, there may be a firewall issue.
- Is the monitored device replying to the queries from the Collector?
If the queries are reaching the host, but the host is not replying, things to check are:
- The access restrictions in snmpd.conf may not allow queries from the collector, or the community string is wrong.
- The simplest SNMPd v1/v2 configuration would be the single line: rocommunity [community]
- Note that SNMPd must be restarted after changing the configuration file contents. (/etc/init.d/snmpd restart)
- SNMPd may only be listening on a loopback address.
- On some distributions of Debian and Redhat, by default SNMPd only listens on 127.0.0.1. You can correct this in /etc/default/snmpd or /etc/syconfig/snmpd.options and restart SNMPd.
- If you see this line: agentAddress udp:127.0.0.1:161, it means the host is only listening on the loopback address for SNMP queries. Please comment that line.
- IP Access restrictions may be blocking the SNMP requests from being accepted.
- /etc/hosts.allow may be restricting the IP addresses that SNMP will respond to (you will see syslog messages about “Connection Refused”). Ensure the collector is listed in this file for SNMP access, if the file exists.
- IPTables rules may be preventing the reception of SNMP packets from the collector.
Lexicographic order issues:
- If you are receiving the common error message “Agent did not return variable bindings in lexicographic order”, set the snmp.ignore.lexicographic.order Collector setting to TRUE. As discussed in Editing the Collector Config Files, this setting must be updated from the Collector’s agent.conf file.
Validating SNMP Credentials in LogicMonitor
As with other passwords, it is not possible to view the snmp v1/v2 community string, v3 authentication token, v3 privacy token, or v3 username in clear text within LogicMonitor.
The following procedure provides a way to validate these values:
- Navigate to Settings > Collectors > Manage Collector > Support > Run Debug Command.
- On the debug window, type the following command in the bottom: !snmpget <your hostname> .1.3.6.1.2.1.1.2.0
- The hostname must be either the IP address or DNS name. Do not use the display name.
- .1.3.6.1.2.1.1.2.0 is the system Object ID (OID) all SNMP devices return, provided SNMP is configured to permit the collector to gather data from the host.
- Result may take 60 seconds or more to display, especially if the community string is inaccurate and the system has to wait for it to timeout.