- About LogicMonitor
- Cloud Monitoring
- Dashboards and Widgets
- Getting Started
- LM Service Insight
- Backup and Recovery Systems
- Cloud Resources
- Networking & Firewalls
- Fortinet FortiWLC Monitoring
- Fortinet FortiWeb Monitoring
- Fortinet FortiSwitch Monitoring
- Fortinet FortiManager Monitoring
- Fortinet FortiMail Monitoring
- Fortinet FortiAuthenticator Monitoring
- Fortinet FortiADC Monitoring
- Ruckus ZoneDirector Monitoring
- Cisco VoIP Monitoring
- Cisco UCS Monitoring
- Cisco Wireless Monitoring
- Brocade Application Delivery Controllers
- Checkpoint Firewalls
- Cisco APIC Monitoring
- Cisco ASA/ASR
- Cisco Device SNMP and NTP Configuration
- Cisco Firepower Chassis Manager Monitoring
- Cisco IP SLA Monitoring
- Citrix NetScalers
- Dell Switch Monitoring
- F5 BIG-IP Monitoring
- Fortinet FortiGate Monitoring
- Infoblox Monitoring
- Interface Status alerting and Bandwidth Utilization
- Juniper SRX
- Kemp LoadMaster Load Balancers
- Meraki Cloud Access Controllers
- NetFlow Monitoring
- Palo Alto Firewalls
- pfSense Firewalls
- Sonicwall Firewalls
- Operating Systems & Virtualization
- VMware Horizon Monitoring
- Citrix XenServer Monitoring
- Citrix XenApp/XenDesktop Monitoring
- ESXi Servers and vCenter/vSphere Monitoring
- Linux Disk Performance
- Linux File Systems reporting more than 100% usage
- Linux Inodes
- Linux Interface Bandwidth Utilization
- Linux NFS Server
- Monitoring a Domain Controller (DC)
- Monitoring Remote Linux Files
- NTP Configuration
- NTP Monitoring
- Nutanix HyperConverged Infrastructure
- SNMP v1/v2 Configuration
- SNMPv3 Configuration
- Solaris Monitoring
- Troubleshooting Perfmon Access
- Troubleshooting SNMP
- Troubleshooting WMI
- VMware vCenter Server Appliance (VCSA) Monitoring
- Windows Cluster Monitoring
- Windows Firewall Issues
- Windows Server 2000
- Windows XP
- Applications & Databases
- Atlassian Statuspage (statuspage.io) Monitoring
- Microsoft Office 365 Monitoring
- OpenMetrics Monitoring
- Zoom Monitoring
- Windows Server Failover Cluster (on SQL Server) Monitoring
- Slack Status Monitoring
- Unomaly Monitoring
- Apache Monitoring
- Cassandra Monitoring
- ConnectWise Monitoring
- Email Service Monitoring
- Java Applications
- Lighttpd Monitoring
- Microsoft Exchange Monitoring
- Microsoft SQL Server Monitoring
- MongoDB Monitoring
- MySQL Monitoring
- Nginx Monitoring
- Oracle Monitoring
- Pick & D3
- Postfix Monitoring
- PostgreSQL Monitoring
- RabbitMQ Monitoring
- Redis Monitoring
- Twilio Monitoring
- Varnish HTTP Accelerator
- Server & Operations Hardware
- Storage Systems
- Cisco HyperFlex Monitoring
- Dell SC Monitoring
- Apache Hadoop Monitoring
- EMC ECS
- EMC Isilon Monitoring
- EMC Unity Monitoring
- EMC VMAX
- EMC VNX/Clariion SAN
- EMC VNXe
- EMC VPLEX
- EMC XtremIO
- HPE 3PAR Storage
- HP MSA / StorageWorks / P2000
- HP P4000/Lefthand SANs
- NetApp E/EF-Series Monitoring
- NetApp Monitoring
- Nimble Storage
- Panzura Cloud Storage
- Quantum Small Tape Libraries
- VMware vSAN Monitoring
- Rest API Developers Guide
- RPC API Developers Guide - Deprecated
- Servicenow CMDB Integration
- Terminology and Syntax
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 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”. 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 SNMPv3: 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> .184.108.40.206.220.127.116.11.0
- The hostname must be either the IP address or DNS name. Do not use the display name.
- .18.104.22.168.22.214.171.124.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.
SNMPv1 & v2
If you’re are using SNMPv1 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> .126.96.36.199.188.8.131.52.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> .184.108.40.206.220.127.116.11.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> .18.104.22.168.2.1.1
rocommunity <community_string> <collector.ip/range> A restriction to .1 is in effect no restriction.
If you’re using SNMPv3 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 SNMPv3 credentials for your device.
In this Article: