Network monitoring tool issues almost always trace back to one of four things: a stopped collector service, broken SNMP or API credentials, a firewall dropping polling traffic, or an overloaded database dropping writes. Verify the service is running, test one device manually with snmpwalk or curl, then work outward from the collector.
Symptoms
- Dashboards show flat lines or gaps in polling graphs for specific devices or interfaces
- Alerts stop firing, or the tool floods you with false 'device down' notifications
- Syslog and trap receivers show zero new messages despite active network traffic
- Web UI loads but reports 'no data' or authentication errors against the backend database
- Agent-based checks on servers report as 'unknown' or 'stale' after a recent update
Common Causes
Collector or poller service stopped
The main service (Zabbix server, PRTG probe, LibreNMS cron, Nagios core) has crashed or failed to restart after a reboot. Nothing polls, nothing writes.
Broken SNMP community, v3 user, or API token
Credentials rotated on the device but not on the monitoring side, or the wrong context/engine ID is configured for SNMPv3. Polls return authorization errors.
Firewall or ACL blocking monitoring traffic
UDP 161 (SNMP), UDP 162 (traps), UDP 514 (syslog), or the vendor API port is dropped somewhere between collector and target, often after a security hardening pass.
Time-series database full or corrupted
RRD files, InfluxDB shards, or the MySQL data partition ran out of space or exceeded retention limits, so new samples are silently discarded even though polls succeed.
Agent version mismatch after upgrade
Server was upgraded but agents on endpoints still run an older protocol version, or a TLS certificate on the agent expired. Checks return 'unsupported' or handshake failures.
Step-by-Step Fix
- Confirm the collector service is actually running and healthy
On Linux, run systemctl status for the daemon (zabbix-server, prtgprobe, snmptrapd, nagios, telegraf). On Windows, check services.msc for the vendor service. Look at the last 200 lines of the tool's own log (usually under /var/log/ or the install directory) for startup errors, database connection failures, or licence expiry warnings before touching anything else. - Test one device manually from the collector host
Skip the UI and query the device directly from the monitoring server. For SNMP: snmpwalk -v2c -c <community> <device-ip> system, or snmpwalk -v3 -l authPriv -u <user> ... for v3. For REST APIs: curl -k -u user:pass https://device/api/status. If this fails, the problem is credentials, network, or the device itself, not the tool. - Trace the path for dropped polling traffic
If the manual test times out, run tcpdump -ni any port 161 on the collector while polling. No reply means a firewall, ACL, or VRF is dropping packets. Check intermediate firewalls, host-based rules (iptables, nftables, Windows Defender Firewall), and any device-side ACL that restricts SNMP to specific source IPs. - Validate credentials, communities, and API tokens end to end
Log into the device and confirm the community string, SNMPv3 user, or API token matches exactly what the monitoring tool stores. Watch for trailing spaces, case sensitivity, and expired tokens. On the tool side, re-enter the secret rather than trusting the masked value in the UI, which can hide legacy encoding issues. - Check the backend database and storage
Run df -h on the collector and any dedicated database host. A full /var partition silently kills RRD writes and MySQL inserts. For InfluxDB or TimescaleDB, verify retention policies and shard status. Look for 'disk full', 'read-only filesystem', or 'too many open files' in both the tool log and dmesg. - Reconcile agent versions and certificates
If agent checks fail while SNMP works, list the agent version on a broken host (zabbix_agentd -V, telegraf --version) and compare against the server's supported range. Reinstall or upgrade the agent, and if TLS is enabled, verify the certificate is not expired and the CA on the server matches the one signing agent certs. - Reduce polling load if the tool is overwhelmed
When CPU on the collector sits near 100% or the poller queue grows, you get gaps that look like device failures. Increase the number of poller processes, split large device groups across additional probes, or extend the polling interval for low-priority metrics. Disable discovery rules that generate thousands of low-value items. - Rebuild the affected host or template as a last resort
If a single device keeps failing after everything checks out, delete and re-add it in the tool. Corrupted host records, stuck queue entries, or orphaned items from a template change can prevent new data from being stored even when polls succeed. Recreating the host forces a clean state.
Common monitoring symptoms mapped to likely cause and first action
| Symptom | Likely cause | First action |
|---|---|---|
| Whole dashboard shows no new data | Collector service stopped or DB full | Check systemctl status and df -h on the collector |
| One device group offline, others fine | Firewall or ACL change on that segment | Run snmpwalk from collector, then tcpdump for replies |
| SNMPv3 devices fail, v2c works | Wrong user, auth protocol, or engine ID | Re-enter v3 credentials and confirm auth/priv protocols |
| Agent checks return 'unsupported' | Agent older than server protocol | Upgrade agent or enable legacy protocol on server |
| Traps received but no alerts | Trap OID not mapped in tool | Check trap definitions and MIB files loaded |
| Web UI slow, gaps in graphs | Poller queue backlog | Add pollers or extend interval for low-priority items |
| 'No data' after upgrade | Schema migration incomplete | Review upgrade log and rerun migration scripts |
Prevention
- Monitor the monitoring server itself: disk, CPU, queue depth, and unreachable-host count
- Store SNMP and API credentials in a secrets manager and rotate them on both sides together
- Document firewall rules for UDP 161, 162, 514, and vendor API ports in your change process
- Test agent and collector upgrades in a lab against your oldest supported endpoint version
FAQ
Why does my monitoring tool show a device as down when I can ping it fine?
The tool uses a specific check, usually SNMP or an agent, not ICMP. If SNMP is blocked, the community string changed, or the agent service stopped, the device is 'down' from the tool's view even though it routes traffic normally. Run the exact check manually from the collector to see the real error.
How often should network devices be polled?
For most enterprise environments, five minutes is a reasonable default for interface counters and CPU. Critical uplinks or SLA-monitored circuits often use one minute. Polling faster than that multiplies load on both the collector and the devices, and rarely improves what you can actually act on.
Should I use SNMPv3 or stick with SNMPv2c?
SNMPv3 is preferred because it supports authentication and encryption, which matters on any network carrying management traffic outside a trusted segment. v2c is simpler and still common for read-only polling inside isolated management VLANs. Whichever you pick, use it consistently across all devices to keep templates manageable.
Need a second pair of eyes on your monitoring stack? Contact our IT support team for a configuration review.