Betrieb & Monitoring
Monitoring
Monitoring bezeichnet die laufende Überwachung von Systemen, Diensten und Netzen und alarmiert proaktiv, bevor Ausfälle die Nutzer erreichen.
- Verfügbarkeit, Leistung, Zustand
- Metriken, Logs, Traces
- Proaktive Alarmierung
- Agent & agentlos (SNMP, Exporter)
- Zabbix, Prometheus, Grafana
Monitoring ist die laufende Erfassung, Auswertung und Alarmierung von Verfügbarkeit, Leistung und Zustand der IT. Es soll Probleme sichtbar machen, bevor Nutzer sie melden, und liefert die Datenbasis für Fehlersuche und Kapazitätsplanung. Im weiteren Sinne ist es Teil von Observability, dem Erschließen innerer Systemzustände aus ihren Ausgaben.
Dieser Artikel erklärt die drei Signale Metriken, Logs und Traces, die Erfassungsverfahren und Protokolle, die Datenhaltung, Schwellwerte gegen Baselining, das Alerting samt Alarmmüdigkeit, die quelloffene Werkzeuglandschaft, den Bezug zu NIS2 und die typischen Fehler. Security-Monitoring (SIEM) ist ein eigenes Thema und rechts verlinkt.
1. Drei Signale: Metriken, Logs, Traces
Observability stützt sich auf drei Signalarten. Metriken sind numerische Zeitreihen (CPU, Speicher, Durchsatz, Fehlerraten) und sehr effizient. Logs liefern den detaillierten Kontext für die Ursachenanalyse. Traces verfolgen einzelne Anfragen durch verteilte Systeme; sie sind vor allem in Anwendungs- und Microservice-Umgebungen zentral, im klassischen Infrastruktur-Monitoring weniger.
2. Erfassung: agentbasiert, agentlos, Push und Pull
Daten kommen entweder über einen Agenten auf dem Zielsystem (tiefere Sicht) oder agentlos über ein Netzprotokoll (kein Deployment nötig, dafür begrenzter). Die wichtigsten Verfahren:
| Verfahren | Einsatz |
|---|---|
| SNMP (v3) | Netzwerkgeräte und Appliances; Polling und Traps. v1/v2c senden Community-Strings im Klartext, daher v3 bevorzugen |
| IPMI / Redfish | Hardware-Zustand out-of-band (Temperatur, Lüfter, Netzteile); Redfish (REST/JSON) löst IPMI als moderner Standard zunehmend ab, läuft oft parallel |
| WMI | agentlose Windows-Überwachung (Leistung, Dienste, Ereignisse) |
| SSH / Exporter | Linux/Unix per SSH-Check; Prometheus-Exporter liefern Metriken über einen HTTP-Endpunkt |
3. Push oder Pull, und wo die Daten landen
Beim Pull-Modell (Prometheus) holt der Server die Metriken aktiv ab; ein fehlendes Ziel fällt sofort auf. Beim Push-Modell senden die Systeme aktiv (SNMP-Traps, Syslog, Trapper), was für Ereignisse und kurzlebige Jobs passt. Gespeichert werden Metriken in Time-Series-Datenbanken; deren Vorhaltezeit ist begrenzt (Prometheus standardmäßig 15 Tage), für Trends und Kapazitätsplanung braucht es längere Aufbewahrung oder einen Langzeitspeicher.
4. Schwellwerte gegen Baselining
Die einfachste Auswertung sind feste Schwellwerte (Wert über X). Sie sind leicht zu konfigurieren, aber blind für Tages- und Saisonverläufe sowie Wachstum, was zu Fehlalarmen oder übersehenen Problemen führt. Baselining lernt das Normalverhalten aus historischen Daten und alarmiert relativ dazu. Zu unterscheiden sind außerdem Verfügbarkeits-Monitoring (ist es erreichbar?), Performance-Monitoring (wie schnell, unter welcher Last?) und synthetisches bzw. Blackbox-Monitoring, das Nutzersicht und Erreichbarkeit von außen prüft (HTTP, DNS, TLS-Zertifikate).
5. Alerting: nur was handlungsrelevant ist
Aus Messwerten werden Alarme. Gute Alarmierung gruppiert zusammengehörige Ereignisse, dedupliziert Wiederholungen, unterdrückt Folgealarme (wenn das ganze Cluster weg ist, braucht es nicht hundert Einzelmeldungen) und kennt Stummschaltung für Wartungsfenster. Zugestellt wird über E-Mail, SMS, Webhook, Chat oder ein eigenes Skript, mit Eskalation an den nächsten Kontakt, wenn niemand reagiert.
Der häufigste Fehler ist Alarmmüdigkeit: Wer zu viele nicht handlungsrelevante Alarme bekommt, übersieht irgendwann die echten. Die Leitregel lautet, nur dort zu alarmieren, wo jemand tatsächlich etwas tun soll, und Schwellen regelmäßig nachzuschärfen.
6. Werkzeuge: die quelloffene Landschaft
Bewährte Open-Source-Bausteine, je nach Aufgabe:
| Werkzeug | Rolle |
|---|---|
| Zabbix | All-in-one für Infrastruktur und Netzwerk (Agent, SNMP, IPMI, Discovery, Alerting, Dashboards) |
| Prometheus | Metriken im Pull-Modell über Exporter, mit Alertmanager und der Abfragesprache PromQL |
| Grafana | Visualisierung und Dashboards über viele Datenquellen hinweg |
| LibreNMS | SNMP-basiertes Netzwerk-Monitoring mit automatischer Geräteerkennung |
| Loki / OpenSearch / Syslog | Log-Sammlung und -Auswertung (Loki günstig per Label, OpenSearch volltextindiziert) |
Monitoring ist nicht SIEM
Infrastruktur-Monitoring fragt nach Verfügbarkeit und Leistung. Ein SIEM (etwa Wazuh) wertet dieselben Roh-Logs unter einem Sicherheitsblick aus (Angriffserkennung, Regelwerke, Compliance). Beide können Daten teilen, verfolgen aber unterschiedliche Ziele und sind getrennt zu planen.
7. Bezug zu NIS2
Monitoring und Protokollierung sind Bausteine der Angriffserkennung und der Nachweisführung, wie sie auch die NIS2-Richtlinie adressiert: Protokolle über Netzverkehr, Konten- und Konfigurationsänderungen, automatisierte Auswertung mit Alarmschwellen, geschützte und ausreichend lange Aufbewahrung sowie Zeitsynchronisierung. Auch die NIS2-Meldefristen für signifikante Vorfälle setzen ein funktionierendes Monitoring voraus, um Vorfälle überhaupt rechtzeitig zu erkennen.
Einordnung statt Rechtsberatung
Die konkreten Pflichten und Fristen ergeben sich aus der nationalen Umsetzung und dem Einzelfall. Diese Einordnung ersetzt keine rechtliche Beratung; die genaue Ausgestaltung gehört mit Fachleuten abgestimmt.
8. Best Practices und typische Fehler
- Gegen Alarmmüdigkeit nur handlungsrelevante Alarme, Priorisierung, Gruppierung und Eskalation; Schwellen regelmäßig tunen.
- Baselining nutzen feste Schwellwerte allein erzeugen Fehlalarme; Normalverhalten berücksichtigen.
- Das Monitoring selbst absichern ein ausgefallener Monitoring-Server meldet keine Ausfälle; redundant auslegen (HA, getrennte Instanz, Dead-Man-Switch).
- Aufbewahrung planen Rohdaten-Retention bewusst dimensionieren; sonst fehlen Trenddaten oder die Datenbank läuft voll.
- Architektur dokumentieren was überwacht wird und wie alarmiert wird, gehört dokumentiert (auch mit Blick auf Audits).
Prometheus: einfache Alert-Regel (Host nicht erreichbar)
groups:
- name: verfuegbarkeit
rules:
- alert: HostDown
expr: up == 0
for: 5m
labels:
severity: critical
annotations:
summary: "{{ $labels.instance }} ist nicht erreichbar"9. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Frühzeitige Erkennung von Störungen, bevor Nutzer sie melden | Schlecht konfiguriert führt es zu Alarmmüdigkeit und Blindheit |
| Datenbasis für Fehlersuche, Trends und Kapazitätsplanung | Feste Schwellwerte ohne Baselining erzeugen Fehlalarme |
| Offene Werkzeuge ohne Lizenzkosten, volle Datenkontrolle | Höherer Einricht- und Betriebsaufwand als SaaS-Lösungen |
| Standards (SNMP, Syslog, Prometheus-Format) ermöglichen Integration | Mehrteilige Stacks (Metriken + Logs + Alerting) erhöhen die Komplexität |
| Unterstützt Angriffserkennung und Nachweispflichten (NIS2) | Skalierung und Langzeit-Storage brauchen zusätzliche Bausteine |
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Monitoring im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.