Monitoring bedeutet, den Zustand der IT fortlaufend zu messen und bei Abweichungen zu alarmieren. Der Nutzen liegt weniger im Erkennen von Totalausfällen – die bemerkt man ohnehin – als im rechtzeitigen Erkennen von Entwicklungen: der Datenträger, der in zwei Wochen voll ist, das Netzteil mit wiederkehrenden Fehlermeldungen, die Sicherung, die seit drei Tagen abbricht. Wer diese Signale sieht, behebt Probleme im Wartungsfenster statt im Notfall.
Drei Blickwinkel auf dieselben Systeme
Ein durchdachtes Monitoring betrachtet die IT aus drei Richtungen. Die erste ist die Sicht der Nutzer: Ist der Dienst erreichbar, und antwortet er in akzeptabler Zeit? Eine Ende-zu-Ende-Prüfung – etwa eine echte Testanmeldung an der Warenwirtschaft oder der Abruf der Website von außen – erkennt Probleme, die einzelne Messwerte übersehen. Die zweite ist die Sicht auf Ressourcen und Hardware, die dritte die Sicht auf Ereignisse, also Protokolle und sicherheitsrelevante Vorgänge.
- Erreichbarkeit und Antwortzeit der Systeme, mit denen tatsächlich gearbeitet wird – geprüft von innen und von außen.
- Speicherplatz, Arbeitsspeicher, Prozessorlast – mit Trendbetrachtung, nicht nur als Momentwert.
- Hardwarezustand: Temperaturen, Netzteile, Lüfter, Selbsttests der Datenträger und Status der Speicherverbünde.
- Erfolg der Datensicherung, einschließlich regelmäßiger Prüfung, ob sich Daten tatsächlich wiederherstellen lassen.
- Sicherheitsrelevante Ereignisse: gehäufte fehlgeschlagene Anmeldungen, neu angelegte Administratorkonten, deaktivierter Virenschutz.
- Ablauftermine von Zertifikaten, Domains, Wartungsverträgen und Lizenzen.
Vollständigkeit ist beim Einstieg nicht das Ziel. Sinnvoller ist eine Reihenfolge nach Schadenspotenzial: zuerst die Datensicherung, der Speicherplatz der zentralen Systeme und die Erreichbarkeit der Anwendungen, mit denen Umsatz gemacht wird. Weitere Messpunkte kommen hinzu, wenn die ersten zuverlässig laufen und ihre Alarme ernst genommen werden. Ein kleines Monitoring, auf das reagiert wird, leistet mehr als ein umfassendes, das niemand beachtet.
Der letzte Punkt gewinnt an Gewicht. Nach einem Beschluss des CA/Browser Forums, das die Regeln für öffentlich vertrauenswürdige Zertifikate festlegt, dürfen TLS-Serverzertifikate seit dem 15. März 2026 höchstens 200 Tage gültig sein. Ab dem 15. März 2027 sinkt die Grenze auf 100 Tage, ab dem 15. März 2029 auf 47 Tage. Wer Zertifikate bislang einmal im Jahr von Hand erneuert hat, braucht künftig eine automatisierte Erneuerung – und ein Monitoring, das meldet, wenn diese Automatik versagt.
Schwellwerte, die etwas bedeuten
Ein fester Grenzwert wie „Alarm bei 90 Prozent Belegung“ ist bequem, aber oft wenig aussagekräftig. Auf einem Speicher mit 20 Terabyte bleiben bei 90 Prozent noch zwei Terabyte frei, auf einem kleinen Systemlaufwerk nur wenige Gigabyte. Aussagekräftiger ist die Frage, wann der Platz bei der aktuellen Wachstumsrate erschöpft sein wird.
Ein Rechenbeispiel mit angenommenen Werten: Ein Laufwerk hat 4 Terabyte Kapazität, 3,4 Terabyte sind belegt, der Bestand wächst im Mittel um 20 Gigabyte pro Tag. Die verbleibenden 600 Gigabyte reichen damit rund 30 Tage. Ein Hinweis bei 60 Tagen Restlaufzeit und eine Warnung bei 14 Tagen lassen genug Zeit, um Speicher zu erweitern oder Bestände zu bereinigen – ohne dass jemand nachts geweckt werden muss.
Ähnliches gilt für kurzfristige Spitzen. Eine Prozessorlast von 100 Prozent für wenige Sekunden ist normal; kritisch wird sie, wenn sie über längere Zeit anhält. Schwellwerte sollten deshalb eine Mindestdauer haben, geplante Wartungsfenster sollten Alarme unterdrücken, und Abhängigkeiten sollten hinterlegt sein: Fällt ein zentraler Switch aus, genügt eine Meldung statt vierzig Folgealarmen für jedes dahinterliegende Gerät.
Die größte Gefahr: Alarmmüdigkeit
Ein Monitoring, das täglich zwanzig Meldungen erzeugt, wird nach kurzer Zeit ignoriert – und übersieht dann die eine wichtige. Deshalb gilt: Jeder Alarm braucht einen Empfänger und eine Handlungsanweisung. Was niemanden zum Handeln veranlasst, gehört ins Protokoll, nicht in die Alarmierung. Sinnvoll ist eine Staffelung in Hinweis, Warnung und Notfall, mit unterschiedlichen Wegen vom Wochenbericht bis zum Anruf.
Hilfreich ist eine monatliche Durchsicht: Welche Alarme kamen, welche führten zu einer Handlung, welche nicht? Alarme ohne Folge werden angepasst oder abgeschaltet. Für Meldungen außerhalb der Geschäftszeiten muss außerdem geklärt sein, wer sie erhält, ob diese Person zu diesem Zeitpunkt tätig werden soll und wie die Bereitschaft organisiert ist. Ein Alarm um drei Uhr nachts an ein Postfach, das erst um acht gelesen wird, ist keine Alarmierung.
Wer überwacht die Überwachung?
Ein Monitoring-System, das im selben Netz steht wie die überwachten Server, schweigt genau dann, wenn Strom oder Internetanbindung ausfallen. Eine einfache Gegenmaßnahme ist eine Prüfung von außen, die Alarm gibt, sobald das Monitoring selbst keine Lebenszeichen mehr sendet. Zudem braucht das Monitoring Zugang zu vielen Systemen. Es ist damit ein lohnendes Angriffsziel und sollte mit möglichst geringen Rechten arbeiten, eigene Zugangsdaten verwenden und selbst aktuell gehalten werden.
Eine Frage wird häufig erst spät gestellt: Protokolle und Messdaten können Rückschlüsse auf das Verhalten einzelner Beschäftigter zulassen. Technische Einrichtungen, die dazu geeignet sind, Verhalten oder Leistung zu überwachen, unterliegen der Mitbestimmung des Betriebsrats, sofern einer besteht. Zweck, Auswertungsregeln und Aufbewahrungsdauer der Protokolle sollten deshalb vor der Einführung festgelegt und abgestimmt sein – das erspart spätere Rückbauten und schafft Vertrauen in ein Werkzeug, das dem Betrieb dient und nicht der Kontrolle von Personen.
Verwandte Themen: Wer hier weiterdenkt, liest bei IT-Notfallplan, Servicedesk und IPv6 weiter.
