SNMP Monitoring

Entstehung und Beteiligte

SNMP-Monitoring verbreitete sich mit dem 1988 entwickelten Simple Network Management Protocol. Hersteller lieferten MIBs für Gerätezustände; Managementsysteme lasen Zähler regelmäßig aus und zeichneten sie als Zeitreihen auf.

Welches Problem sollte gelöst werden?

Ports, Fehlerzähler, CPU, Temperatur und Verfügbarkeit sollten ohne individuelle Agenten pro Hersteller zentral messbar sein.

Technische Hürden und Lösungen

Zähler können überlaufen oder beim Neustart zurückgesetzt werden. Interface-Indizes ändern sich, MIBs unterscheiden sich und zu kurze Intervalle belasten Geräte. SNMPv3 verbessert Sicherheit, verlangt aber sauberes Schlüsselmanagement.

Standardisierung und Einordnung

Monitoring entwickelte sich vom einfachen Prüfen erreichbarer Geräte zu einer eigenen Disziplin aus Metriken, Ereignissen, Protokollen und Traces. Die zentrale Schwierigkeit besteht nicht im Sammeln möglichst vieler Daten, sondern im Erkennen relevanter Abweichungen. Zeitstempel, eindeutige Identitäten, Aufbewahrung, Normalisierung und sinnvoll gesetzte Alarmgrenzen entscheiden darüber, ob Messdaten im Störungsfall helfen.

Technik im praktischen Betrieb

Ein Messwert benötigt Kontext: Einheit, Quelle, Intervall, Aggregation und erwarteten Normalbereich. Durchschnittswerte können kurze Spitzen verdecken, Maximalwerte kleine Ausreißer überbetonen. Aufbewahrung und Auflösung sollten zum Diagnoseziel passen. Alarme müssen einen klaren Besitzer, eine Handlungsanweisung und eine Eskalation besitzen. Regelmäßige Tests mit absichtlich ausgelösten Fehlern zeigen, ob Benachrichtigung, Bereitschaft und Runbook wirklich funktionieren.

Warum das Thema heute noch relevant ist

Historische Daten schaffen erst dann Wert, wenn sie vergleichbar bleiben. Änderungen an Geräten, Namen, Intervallen oder Messdefinitionen müssen deshalb nachvollziehbar sein. Langfristige Trends beantworten Kapazitätsfragen, detaillierte kurze Daten helfen bei Störungen. Beide Ziele verlangen unterschiedliche Auflösung. Monitoring ist zugleich Teil der Beweiskette: Ohne unabhängige Zeit, unveränderte Logs und bekannte Datenlücken lässt sich nach einem Vorfall nur schwer unterscheiden, was tatsächlich geschah und was lediglich vermutet wird.

Daten und Meilensteine

• Counter64 ist für schnelle Interfaces geeigneter als 32-Bit-Zähler.
• OIDs identifizieren Messwerte hierarchisch.
• Polling liefert Zeitreihen, Traps melden Ereignisse.
• Die Differenz zweier Zählerstände ergibt erst mit dem Zeitabstand eine Rate.

SNMP-Monitoring im Detail

SNMP-Monitoring ist die Praxis, Netzwerkgeräte und Server via SNMP regelmäßig nach Metriken zu befragen (Polling). Monitoring-Tools wie Zabbix, LibreNMS, PRTG oder Nagios senden SNMP GET-Anfragen an Geräte-Agents, die mit den angeforderten Werten antworten.

Jeder Wert wird über seine OID (Object Identifier) adressiert. Beispiel: 1.3.6.1.2.1.2.2.1.10.1 = ifInOctets.1 (empfangene Bytes auf Interface 1). Die MIB-Datei übersetzt OID-Nummern in lesbare Namen.

Wichtige SNMP-OIDs

• sysUpTime (1.3.6.1.2.1.1.3): Gerät-Uptime – erkennt unerwartete Reboots.
• ifInOctets/ifOutOctets (1.3.6.1.2.1.2.2.1.10/16): Ein-/ausgehende Bytes pro Interface. Bandbreitenberechnung durch Polling-Differenz.
• ifErrors/ifDiscards: Paketfehler und verworfene Pakete – Hinweis auf Kabelprobleme oder Überlast.
• hrProcessorLoad (HOST-RESOURCES-MIB): CPU-Auslastung des Systems.
• hrStorageUsed/hrStorageSize: Festplatten-Belegung.
• Temperatur, Lüfter, PSU: Herstellerspezifische Enterprise MIBs (Cisco, Juniper, HP).

Auto-Discovery und Graphing

LibreNMS kann via SNMP automatisch alle Interfaces und Geräte-Typen erkennen (Auto-Discovery) und sofort passende Graphs erstellen. Graphing-Backends: RRDtool (traditionell, Round-Robin-Datenbank), InfluxDB + Grafana (modern, zeitreihen-basiert).

SNMPv3-Konfiguration (Empfehlung): authNoPriv (nur Authentifizierung via SHA) oder authPriv (Auth + Verschlüsselung via AES). Separater, read-only Community-String oder SNMPv3-User nur für Monitoring verwenden.