Was ist Monitoring?

Einfach erklärt

Monitoring heißt Überwachung. Ein Programm prüft rund um die Uhr, ob Ihre Server und Dienste laufen, und meldet sich, wenn etwas nicht stimmt. Ist die Website erreichbar? Ist die Festplatte bald voll? Läuft das Zertifikat in zehn Tagen ab? Hat das nächtliche Backup geklappt? Es funktioniert wie ein Rauchmelder: Er schlägt beim ersten Rauch an, nicht erst, wenn es brennt.

Warum das wichtig ist

Ohne Monitoring erfahren Sie von einem Ausfall durch einen Kunden, der anruft. Manches merkt niemand, etwa wenn Backups seit Wochen scheitern oder eine Platte langsam vollläuft. Gute Überwachung meldet Probleme, bevor Nutzer sie bemerken, und zeigt im Rückblick, wann etwas begann.

Was Sie klären sollten

• Was wird überwacht? Nicht nur, ob der Server an ist, sondern auch Website, Mailversand, Zertifikate, Speicherplatz und Backups.
• Wer bekommt die Meldung? Eine Warnung an ein Postfach, das niemand liest, nützt nichts.
• Was passiert dann? Wer reagiert und wie schnell, auch am Wochenende?

Tipp: Lassen Sie sich von Ihrem IT-Dienstleister regelmäßig zeigen, welche Warnungen es gab und was daraus folgte. Daran sehen Sie, ob die Überwachung wirklich genutzt wird.

Was Monitoring nicht kann

Überwachung behebt keine Fehler, sie meldet sie nur. Ohne jemanden, der reagiert, bringt sie wenig. Sie erkennt außerdem nur, wonach sie sucht: Ein Dienst, den niemand eingetragen hat, kann unbemerkt ausfallen.

Ebenen der Überwachung

Monitoring sammelt Zustände und Messwerte und löst bei Schwellwerten Alarme aus. Zu unterscheiden sind:

• Von außen (Blackbox): HTTP-Status, Antwortzeit, Ablauf des TLS-Zertifikats, DNS und Mailzustellung, geprüft von einem Standort außerhalb des eigenen Netzes.
• Systemwerte (Whitebox): CPU, Arbeitsspeicher, Plattenplatz, Ein- und Ausgabe, Dienste, Zustand der Container.
• Jobs und Anwendungen: Warteschlangen, Fehlerquoten, letzter erfolgreicher Backup-Lauf. Hier hilft ein Heartbeat: Der Job meldet jeden Erfolg, das Ausbleiben der Meldung löst den Alarm aus.
• Protokolle: zentrale Sammlung der Logs als Grundlage, um Sicherheitsereignisse zu erkennen.

Der BSI-Baustein OPS.1.1.1 „Allgemeiner IT-Betrieb“ verlangt einen Monitoring-Plan mit Schwellwerten je Komponente, festgelegten Meldewegen und Konsequenzen sowie regelmäßigen Berichten (A9). SYS.1.1.A23 fordert, Systemzustand und Dienste von Servern laufend zu überwachen. Verbreitete Werkzeuge sind Prometheus mit Alertmanager, Zabbix, Checkmk und Uptime Kuma.

# Prometheus-Alarmregel: Wurzeldateisystem läuft in vier Tagen voll
- alert: PlatteBaldVoll
  expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 4 * 24 * 3600) < 0
  for: 30m
  labels:
    severity: warning
  annotations:
    summary: "{{ $labels.instance }}: / läuft in weniger als vier Tagen voll"

Typische Fehler

• Überwachung auf dem überwachten Server. Fällt er aus, schweigt auch der Alarm. Mindestens die Prüfung von außen läuft woanders.
• Meldeweg hängt am überwachten System. Alarm-Mails laufen über den Mailserver, der gerade ausgefallen ist.
• Zu viele Alarme. Warnungen ohne Handlungsbedarf stumpfen ab, echte gehen unter. Ein Alarm ohne vorgesehene Reaktion gehört abgeschaltet oder umgebaut.
• Zertifikatsablauf nicht überwacht. Die automatische Verlängerung scheitert still, eines Morgens zeigen Browser eine Warnung.
• Nur Fehler gemeldet. Ein Backup-Skript, das gar nicht mehr startet, meldet auch keinen Fehler.

Prüfen

• Testalarm auslösen: einen unkritischen Dienst stoppen und messen, wann wer benachrichtigt wird.
• Liste der Prüfungen mit der Liste der Dienste abgleichen.
• Nach jedem Vorfall fragen: Hat das Monitoring ihn gemeldet? Wenn nicht, welche Prüfung fehlte?
• Ablauf eines Zertifikats von außen ablesen:

echo | openssl s_client -connect ihre-firma.de:443 -servername ihre-firma.de 2>/dev/null | openssl x509 -noout -enddate