Monitoring aufbauen: Was sollte eine moderne IT-Umgebung überwachen?

Episode von IT for Business Podcast von Mirko Peters · 19. August 2026 · 20 min

Ein Geschäftsprozess steht – und die IT erfährt es erst, wenn der erste Anwender anruft. Genau dann hat Monitoring seinen eigentlichen Zweck verfehlt. Denn modernes IT-Monitoring bedeutet nicht, möglichst viele grüne Statusanzeigen und Dashboards zu produzieren. Es soll Probleme erkennen, bevor daraus ein relevanter Geschäftsausfall entsteht, die Auswirkungen sichtbar machen und dafür sorgen, dass die richtige Person rechtzeitig reagieren kann. In dieser Folge von IT for Business geht es darum, was eine moderne IT-Umgebung tatsächlich überwachen sollte, wie Unternehmen sinnvolle Prioritäten setzen und warum Monitoring immer bei den Geschäftsservices beginnen sollte.

BEI DEN GESCHÄFTSSERVICES BEGINNEN

Der typische Fehler beim Aufbau eines Monitorings besteht darin, zuerst ein Tool auszuwählen und anschließend automatisch möglichst viele Geräte erkennen zu lassen. Das Ergebnis sind hunderte überwachte Komponenten – ohne klare Aussage darüber, ob die wirklich wichtigen Geschäftsprozesse funktionieren.Deshalb sollte zuerst geklärt werden, welche Services für das Unternehmen kritisch sind. ERP, Produktionssteuerung, Kundenportal, E-Mail, Identitätsdienste, Dateizugriffe oder Remotezugänge können beispielsweise direkt auf Umsatz, Produktion und Arbeitsfähigkeit wirken.Für jeden kritischen Service sollten außerdem fachliche und technische Verantwortliche sowie seine wichtigsten Abhängigkeiten dokumentiert werden.

INFRASTRUKTUR RICHTIG ÜBERWACHEN

Ein erfolgreicher Ping bedeutet lediglich, dass ein System antwortet. Er sagt nicht, ob das System seine eigentliche Aufgabe noch erfüllt.Bei Servern gehören deshalb unter anderem CPU-Auslastung, Arbeitsspeicher, Speicherplatz, Datenträgerzustand, Betriebssystemdienste und geplante Jobs in die Überwachung.Virtuelle Umgebungen benötigen zusätzlich eine Sicht auf Hosts, Cluster, Datastores, Replikation, Snapshots und Storage. Eine virtuelle Maschine kann problemlos aussehen, während das gemeinsame Storage bereits an seine Grenzen stößt.

NETZWERK, VPN UND EXTERNE ABHÄNGIGKEITEN

Auch Router, Switches, Firewalls, VPN-Verbindungen, WAN-Strecken und WLAN-Infrastruktur gehören in ein modernes Monitoring. Paketverluste, Interfacefehler, Latenzen oder ausgelastete Verbindungen können sich für Anwender wie ein Problem der eigentlichen Anwendung anfühlen.Zusätzlich müssen externe Abhängigkeiten berücksichtigt werden. Dazu gehören DNS, Internetanbindungen, öffentliche Erreichbarkeit und externe Cloud- oder SaaS-Dienste.Eine öffentliche Statusseite eines Cloud-Anbieters reicht dabei nicht immer aus. Der Anbieter kann funktionieren, während beispielsweise DNS, Firewall, Internetverbindung oder Identitätsdienste im eigenen Unternehmen den Zugriff verhindern.

BACKUPS, ZERTIFIKATE UND DOMAINS NICHT VERGESSEN

Ein erfolgreicher Backupjob beweist noch nicht, dass ein Unternehmen seine Systeme im Ernstfall tatsächlich wiederherstellen kann. Deshalb sollten Backup-Erfolg, Laufzeit, Datenmenge und Repository-Kapazität überwacht und regelmäßige Restore-Tests dokumentiert werden.Auch Zertifikate, Domainregistrierungen und Lizenzen gehören in das Monitoring. Ein abgelaufenes TLS-Zertifikat oder eine nicht verlängerte Domain kann kritische Dienste unterbrechen, obwohl der Ablaufzeitpunkt lange vorher bekannt war.Und selbst die Monitoringplattform muss überwacht werden. Wenn das eigene Frühwarnsystem keine Benachrichtigungen mehr verschickt, kann die scheinbare Ruhe besonders gefährlich werden.

ANWENDUNGEN AUS SICHT DER NUTZER TESTEN

Gesunde Server bedeuten nicht automatisch gesunde Anwendungen. Deshalb sollte Monitoring echte Funktionen überprüfen.Kann sich ein Anwender anmelden? Funktioniert die Datenbankverbindung? Liefert eine API eine gültige Antwort? Kann eine Datei übertragen werden? Funktioniert eine wichtige Transaktion?Antwortzeiten und Fehlerraten sind ebenfalls relevant. Ein Service muss nicht vollständig ausfallen, um das Geschäft zu beeinträchtigen. Bereits deutlich längere Ladezeiten können Arbeitsabläufe verlangsamen und zusätzliche Supportanfragen erzeugen.

SCHNITTSTELLEN UND STILLE FEHLER ERKENNEN

Besonders kritisch sind Fehler, die keinen offensichtlichen Ausfall verursachen. Eine API liefert keine Daten mehr, eine Queue läuft voll oder ein nächtlicher Export produziert eine leere Datei.Deshalb sollte Monitoring nicht nur prüfen, ob ein technischer Job erfolgreich beendet wurde. Entscheidend ist auch, ob die erwarteten Daten tatsächlich vom Quellsystem zum Zielsystem gelangt sind.Gerade bei geschäftskritischen Integrationen sollte ein Problem erkannt werden, bevor am nächsten Morgen Fachabteilungen oder Kunden fehlende Daten bemerken.

METRIKEN, LOGS UND TRACES

Bei komplexeren Anwendungen reicht klassisches Infrastrukturmonitoring häufig nicht mehr aus. Hier wird Observability relevant.Metriken zeigen Veränderungen wie steigende Antwortzeiten, erhöhte Last oder wachsende Fehlerraten. Logs liefern konkrete Ereignisse und Fehlermeldungen. Traces verfolgen einzelne Anfragen über mehrere Systeme hinweg.Bei einer Kette aus Portal, Identitätsanbieter, Anwendung, API und Datenbank kann dadurch sichtbar werden, an welcher Stelle eine Anfrage tatsächlich langsam wird oder fehlschlägt.

ALARME MÜSSEN ZU EINER AKTION FÜHREN

Mehr Daten und mehr Alarme bedeuten nicht automatisch besseres Monitoring. Wenn jede kleine Abweichung eine Benachrichtigung erzeugt, entsteht Alarmmüdigkeit.Informationsmeldungen können in Berichte oder Dashboards gehören. Warnungen benötigen eine geplante Bearbeitung. Kritische Alarme verlangen dagegen eine unmittelbare Reaktion, weil ein wichtiger Geschäftsservice betroffen oder gefährdet ist.Schwellenwerte sollten deshalb nicht einfach aus Vorlagen übernommen werden. Sie müssen zum gemessenen Normalbetrieb, zur Tageszeit, zur Dauer eines Problems und zur geschäftlichen Bedeutung des betroffenen Services passen.

ABHÄNGIGKEITEN STATT ALARMFLUT

Fällt ein zentraler Switch aus, können gleichzeitig Server, Access Points und zahlreiche Anwendungen als nicht erreichbar erscheinen. Ohne modellierte Abhängigkeiten entstehen daraus möglicherweise dutzende Alarme.Ein gutes Monitoring erkennt dagegen die wahrscheinlich gemeinsame Ursache und reduziert nachgelagerte Meldungen.Das Gleiche gilt für Firewalls, Internetanbindungen, Virtualisierungshosts, Cluster oder zentrale Identitätsdienste. Ein technischer Ausfall sollte möglichst einen verständlichen Vorfall erzeugen und nicht dreißig einzelne Symptome.

ESKALATION, TICKETING UND RUNBOOKS

Bereits vor einem Vorfall muss klar sein, wer einen Alarm erhält, wer bei fehlender Reaktion übernimmt und wann technische oder fachliche Verantwortliche beziehungsweise das Management informiert werden.Kritische Alarme sollten außerdem mit Ticketing und Incident Management verbunden sein. Dadurch entsteht eine nachvollziehbare Historie aus betroffenem Service, Zeitpunkt, Schweregrad, Verantwortlichkeit und durchgeführten Maßnahmen.Runbooks unterstützen die operative Reaktion. Sie sollten kurz und praktisch beschreiben, was zuerst geprüft wird, welche Änderungen erlaubt sind, wen man kontaktieren muss und wann eine Eskalation erforderlich ist.

MONITORING IST NICHT AUTOMATISCH SECURITY MONITORING

Verfügbarkeitsmonitoring und Security Monitoring überschneiden sich teilweise, verfolgen aber unterschiedliche Ziele.Eine klassische Monitoringplattform kann beispielsweise ungewöhnliche Last, fehlgeschlagene Verbindungen oder ausgefallene Sicherheitskomponenten erkennen. Sie ersetzt jedoch keine spezialisierten Security-Systeme und keine Security-Organisation.Unternehmen sollten deshalb bewusst definieren, welche Informationen für den IT-Betrieb benötigt werden und welche Daten in spezialisierte Security-Werkzeuge gehören.

DAS RICHTIGE TOOL KOMMT ZUM SCHLUSS

Weitere Episoden von „IT for Business Podcast“

Alle Episoden von IT for Business Podcast · Mehr Technologie-Podcasts