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, things to check are:
- Is SNMPd running?
- If you're using SNMP v1 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". Therefore, we recommend you set your community string to something else. See the section below to verify that your device has the correct community string set.
- If you're using SNMP v3: Is the device configured with the correct authpass, privpass and username (either at the global, group or device level)? See the section below 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.
Validating your 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 and select Run Debug Command from the drop down support menu for the collector monitoring your device
2. On the debug window, type the following command in the bottom: !snmpget <your hostname> .18.104.22.168.22.214.171.124.0
- The hostname must be either the IP address or DNS name. Do not use the display name.
- .126.96.36.199.188.8.131.52.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.
The collector debug window uses the community string or authpass, privpass and username currently applied to the device, either directly, through inheritance from a device group, or at the global level. If no community string is set, LogicMonitor defaults to using public.
SNMP v1 & v2
If you're are using SNMP v1 or v2 and the device has the correct community string, you should see a value returned on the SysObjectID:
You can override the community string that LogicMonitor is using for the device by specifying it in the debug command window:
!snmpget community=<your_community_string> <your.hostname> .184.108.40.206.220.127.116.11.0.
If this command succeeds when you specify the community string where it previously failed, LogicMonitor has the wrong community string set for this host. You will need to determine where this is set, starting at the host and working up through any host groups of which it is a member to the global setting. See Defining Device Properties and Authentication Credentials for more information. Setting any property at the host level takes precedence over the same property set at a group level.
Edit the appropriate snmp.community entry and supply the correct value. You can then confirm the change has set the correct value by repeating the debug command: !snmpget <your.hostname> .18.104.22.168.22.214.171.124.0.
Note: If the community value is set at a group or global level, and other SNMP hosts in the group are returning data, do not change the group or global property. Either set an snmp.community property for the specific host, or modify the host's snmpd.conf file to use the same community string as your other hosts.
If the above debug command returns a value successfully, but other SNMP datasources on the host are not returning values, it is possible that the host snmpd.conf file restricts the OIDs the collector can view. Check the file for the line defining the community string. Values after the permitted collection IP or range will restrict the OIDs revealed to that section of the OID tree, as per the examples below:
Restricted to basic system information (Description, Object ID, Uptime, Contact Information, etc) only:
rocommunity <community_string> <collector.ip/range> .126.96.36.199.2.1.1
rocommunity <community_string> <collector.ip/range> A restriction to .1 is in effect no restriction.
If you're using SNMP v3 and you have the correct credentials set for your device, a SysOID will be returned:
If the credentials are incorrect, the request will time out.
See this page for help setting SNMP v3 credentials for your device.