Wenn Ihr Netzwerküberwachungs-Tool keine Daten liefert oder Fehlalarme meldet, prüfen Sie in dieser Reihenfolge: Dienststatus des Servers, Erreichbarkeit der Ziele (Ping, Port), SNMP- oder API-Credentials, Firewall-Regeln für die Monitoring-Ports und zuletzt die Polling-Intervalle. Meist liegt die Ursache in Zugriff oder Konfiguration, nicht in der Software selbst.
Symptome
- Sensoren stehen dauerhaft auf „Unknown" oder wechseln zwischen Up und Down (Flapping).
- Lücken in Performance-Graphen, obwohl das Zielgerät erreichbar ist.
- Massenhafte Fehlalarme nach einem Firmware- oder Firewall-Update.
- Syslog- oder NetFlow-Meldungen fehlen, obwohl der Kollektor läuft.
- Dashboard lädt langsam, Datenbank oder RRD-Files wachsen unkontrolliert.
Häufige Ursachen
Falsche SNMP-Version oder Community
Zielgerät antwortet nur auf SNMPv3 mit Auth/Priv, das Tool fragt aber v2c an. Umgekehrt scheitert v3 an falschem Kontext, User oder Engine-ID.
Blockierte Monitoring-Ports
Firewall, ACL oder Host-Firewall verwerfen UDP 161 (SNMP), 162 (Traps), 514 (Syslog) oder den API-Port. Der Kollektor sieht schlicht keinen Traffic.
Fehlende Berechtigungen
Der Monitoring-User hat keine Read-Rechte für WMI, keinen sudo-Eintrag für Skripte oder keine API-Rolle mit Lese-Scope auf die benötigten Objekte.
Überlasteter Poller oder Agent
Zu enge Intervalle, zu viele OIDs pro Zyklus oder ein hängender Agent-Prozess führen zu Timeouts. Metriken erscheinen lückenhaft, obwohl kein „echter" Ausfall vorliegt.
Uhrzeit- und Zertifikatsprobleme
Zeitdrift auf Kollektor oder Ziel bricht TLS-basierte API-Abfragen und lässt Traps mit falschem Zeitstempel einlaufen. Alarme werden falsch korreliert.
Schritt-für-Schritt-Lösung
- Zustand des Monitoring-Servers und der Datenbank prüfen
Kontrollieren Sie zuerst, ob der Kern-Dienst (PRTG Core, Zabbix Server, Icinga, LibreNMS-Cron, Nagios) läuft und die Datenbank antwortet. Prüfen Sie freien Plattenplatz, RAM und CPU. Ein vollgelaufenes /var oder eine gesperrte MySQL-Tabelle stoppt Schreibvorgänge, ohne dass das Web-UI sofort einen Fehler zeigt. - Erreichbarkeit des Zielgeräts isolieren
Vom Monitoring-Host aus mit ping, traceroute und tcping (bzw. nc -vz) prüfen, ob das Ziel überhaupt antwortet und der relevante Port offen ist. Antwortet ICMP, aber nicht SNMP, liegt das Problem zwischen Transport und Applikation, nicht am Netz. - SNMP-Antwort direkt vom Kollektor testen
Mit snmpwalk oder snmpget vom Monitoring-Server aus die genutzten Credentials verifizieren: für v2c die Community, für v3 User, Auth- und Priv-Protokoll. Erhalten Sie „Timeout", ist ein Port oder eine ACL zu; „authorizationError" zeigt falsche Zugangsdaten oder eine nicht freigegebene View. - API- und WMI-Zugriffe getrennt validieren
Für Cloud- oder Applikations-Sensoren den API-Call manuell mit curl absetzen und HTTP-Status prüfen: 401 bedeutet Credentials, 403 fehlende Rolle, 429 zu häufiges Polling. Für Windows-Ziele wbemtest oder Get-WmiObject mit dem Monitoring-User ausführen, nicht als Admin. - Firewalls, ACLs und Segmentierung abklären
UDP 161/162, TCP 443 der API und Syslog 514 müssen von der Kollektor-IP zum Ziel offen sein, in beide Richtungen bei Traps. Prüfen Sie auch Zwischenfirewalls, VRF-Trennung und Reverse-Path-Filter. Ein tcpdump am Ziel zeigt schnell, ob die Anfrage überhaupt ankommt. - Agenten und Polling-Intervalle bereinigen
Hängende Agenten (zabbix_agentd, node_exporter, WMI-Provider) neu starten und Logs auf Timeouts prüfen. Reduzieren Sie zu aggressive Intervalle, splitten Sie große Templates und verteilen Sie Sensoren auf mehrere Remote-Probes, wenn ein Poller dauerhaft über 70 % Auslastung liegt. - Alarmierung entrauschen und Schwellwerte kalibrieren
Setzen Sie Dependencies (Parent-Device), damit ein Router-Ausfall nicht 200 Einzelalarme erzeugt. Führen Sie Hysterese oder mehrere Prüfintervalle vor dem Auslösen ein. Prüfen Sie Zeitzonen und NTP auf allen Beteiligten, sonst laufen Wartungsfenster ins Leere. - Software-Version und Templates aktuell halten
Nach Firmware-Updates auf Switches oder Firewalls ändern sich häufig OIDs oder API-Schemas. Aktualisieren Sie die Device-Templates des Herstellers und testen Sie Änderungen zuerst in einer Staging-Instanz, bevor Sie in der Produktion ausrollen.
Typische Fehlerbilder im Netzwerkmonitoring und deren Ursachen
| Symptom | Wahrscheinliche Ursache | Erste Prüfmaßnahme |
|---|---|---|
| Sensor „Unknown", Ping ok | SNMP-Credentials oder Version falsch | snmpwalk mit exakter Community/v3-User |
| Alle Ziele eines Standorts offline | Firewall-Regel oder VPN-Tunnel down | Route und Port 161 vom Kollektor testen |
| Datenlücken alle paar Minuten | Poller-Timeout, Intervall zu kurz | Polling-Zeit und CPU des Kollektors prüfen |
| Traps kommen nicht an | UDP 162 blockiert oder falscher Zielhost | tcpdump port 162 am Kollektor |
| API-Sensor liefert 401/403 | Token abgelaufen oder Rolle geändert | Token erneuern, Scope kontrollieren |
| Massen-Fehlalarme nach Update | OID/Template hat sich geändert | Geräte-Template aktualisieren, in Staging testen |
So beugen Sie vor
- Monitoring des Monitorings: separater Heartbeat-Check auf Kollektor und Datenbank.
- Zugangsdaten (SNMPv3, API-Tokens) zentral im Secret Store, nicht pro Sensor.
- Kapazitätsplanung: Sensoranzahl, Intervalle und Storage regelmäßig gegen die Hardware prüfen.
- Änderungen an Firewalls und Geräten mit Tag „Monitoring-Impact" im Change-Prozess markieren.
Häufige Fragen
Warum zeigt mein Tool SNMP-Timeouts, obwohl ich das Gerät anpingen kann?
ICMP und SNMP nutzen unterschiedliche Protokolle. Der Ping bestätigt nur Layer-3-Erreichbarkeit, SNMP läuft auf UDP 161 und kann durch eine ACL auf dem Gerät, eine Firewall oder eine falsch konfigurierte SNMP-View blockiert werden. Testen Sie direkt mit snmpwalk vom Kollektor und prüfen Sie die Community- bzw. v3-Konfiguration am Zielgerät.
Wie erkenne ich, ob mein Monitoring-Server überlastet ist?
Achten Sie auf steigende Polling-Dauer, wachsende Warteschlangen und regelmäßige Datenlücken zur vollen Minute. In PRTG, Zabbix oder LibreNMS gibt es interne Metriken für Poller-Queue und offene Threads. Liegt die CPU dauerhaft über 70 % oder wachsen die RRD/DB-Writes über den I/O hinaus, sollten Sie Intervalle erhöhen oder Remote-Probes einsetzen.
Sollte ich SNMPv2c oder SNMPv3 verwenden?
SNMPv3 ist wegen Authentifizierung und Verschlüsselung die sicherere Wahl, besonders über Standortgrenzen hinweg. v2c ist einfacher zu betreiben, überträgt Community-Strings aber im Klartext und sollte höchstens in isolierten Management-Netzen laufen. Klären Sie zuerst, ob Ihre Geräte v3 vollständig unterstützen, und rollen Sie schrittweise um.