Monitoring: Definition, Arten und Rolle im IT Service Management

Monitoring (IT-Monitoring) ist die fortlaufende, weitgehend automatisierte Erfassung und Auswertung von Messwerten und Zustandsmeldungen aus IT-Systemen, Anwendungen und Services mit dem Ziel, Abweichungen vom Sollzustand früh zu erkennen und eine festgelegte Reaktion auszulösen. Überwacht werden zum Beispiel Server, Netzwerke, Datenbanken, Cloud-Dienste, Geschäftsanwendungen und die Antwortzeiten, die Anwender tatsächlich erleben.

Im IT Service Management ist Monitoring kein Selbstzweck. ITIL^® 4 beschreibt es zusammen mit dem Event Management als eigene Practice: Services und ihre Komponenten werden systematisch beobachtet, bedeutsame Zustandsänderungen werden als Events erfasst, und für jedes Event ist festgelegt, was daraus folgt, etwa ein Incident, ein Problem oder ein Change. Auch der IT-Grundschutz-Baustein OPS.1.1.1 des BSI sieht vor, das IT-Monitoring mit dem übergeordneten Service-Management abzustimmen.

Das Wichtigste in Kürze

• Prinzip: messen, vergleichen, melden. Ein Monitoring-System sammelt Metriken, Logs und Statusmeldungen, vergleicht sie mit Schwellenwerten oder erwarteten Mustern und alarmiert bei Abweichungen.
• Ebenen: Infrastruktur, Netzwerk, Anwendung, Endnutzererlebnis, Geschäftsprozess und Sicherheit. Erst die Verbindung der Ebenen zeigt, ob ein Service für seine Nutzer funktioniert.
• Abgrenzung: Monitoring prüft vorab definierte Fragen („Läuft der Dienst?“). Observability soll auch unbekannte Fehlerbilder erklärbar machen. Event Management entscheidet, welche Meldung welche Reaktion auslöst.
• Nutzen im ITSM: Störungen fallen auf, bevor viele Anwender anrufen. Tickets starten mit technischen Details statt mit „geht nicht“, und Trends liefern die Datengrundlage für Problem- und Kapazitätsmanagement.

Stand: November 2026 · Fachlich abgeglichen mit ITIL^® 4 (PeopleCert), dem IT-Grundschutz des BSI und dem SRE-Handbuch von Google (Quellen am Ende des Artikels)

Was Monitoring erfasst: Ebenen, Signale und Messverfahren

Ein Monitoring-Konzept beginnt nicht mit dem Werkzeug, sondern mit der Frage, welche Services für das Unternehmen kritisch sind und woran man erkennt, dass sie funktionieren. Daraus ergeben sich die Ebenen, die überwacht werden müssen.

Sechs Ebenen der Überwachung

• Infrastruktur: CPU, Arbeitsspeicher, Datenträger, Temperatur und Erreichbarkeit von Servern, Hypervisoren und Speichersystemen.
• Netzwerk: Verfügbarkeit von Leitungen, Auslastung der Bandbreite, Paketverluste und Latenz zwischen Standorten und Rechenzentren.
• Anwendung (Application Performance Monitoring, APM): Antwortzeiten, Fehlerraten und Durchsatz einer Anwendung bis hinunter zu einzelnen Datenbankabfragen.
• Endnutzererlebnis: Real User Monitoring misst, was echte Nutzer erleben. Synthetisches Monitoring spielt definierte Abläufe wie eine Anmeldung in festen Abständen automatisch durch.
• Geschäftsprozess: fachliche Messgrößen wie verarbeitete Aufträge pro Stunde oder offene Zahlungsläufe. Sie zeigen Störungen, die technisch unauffällig bleiben.
• Sicherheit: Auswertung sicherheitsrelevanter Ereignisse wie gehäufter Fehlanmeldungen. Dafür sind meist eigene Werkzeuge zuständig, etwa ein SIEM (Security Information and Event Management).

Signale: Metriken, Logs, Traces und Events

Metriken sind numerische Messreihen über die Zeit, zum Beispiel die Belegung eines Datenträgers. Logs sind zeitgestempelte Meldungen einzelner Komponenten. Traces verfolgen eine einzelne Anfrage über mehrere Dienste hinweg und zeigen, wo Zeit verloren geht. Diese drei Signalarten bilden auch den Kern des offenen Standards OpenTelemetry. Events schließlich sind Zustandsänderungen, die für den Betrieb eines Services Bedeutung haben, etwa „Dienst gestoppt“ oder „Zertifikat läuft in 14 Tagen ab“.

Messverfahren

Beim aktiven Monitoring fragt das System die Komponenten selbst ab, etwa per Ping, HTTP-Aufruf oder SNMP. Beim passiven Monitoring liefern die Komponenten ihre Daten von sich aus, über Agenten, Log-Weiterleitung oder Schnittstellen.

Das SRE-Handbuch von Google unterscheidet außerdem zwischen White-Box-Monitoring, das interne Messwerte eines Systems auswertet, und Black-Box-Monitoring, das von außen prüft, was ein Nutzer sehen würde. Beide ergänzen sich: Black-Box-Prüfungen zeigen, dass ein Problem besteht. White-Box-Daten helfen, die Ursache zu finden und drohende Engpässe vorherzusehen, bevor Nutzer etwas merken.

Monitoring, Observability und Event Management: die Unterschiede

Die drei Begriffe werden oft gleichgesetzt. Sie beschreiben aber unterschiedliche Aufgaben, und wer sie trennt, plant Werkzeuge und Zuständigkeiten sauberer.

Monitoring beantwortet vorab definierte Fragen: Ist der Dienst erreichbar, liegt die Antwortzeit unter dem Zielwert, ist genug Speicherplatz frei? Observability (Beobachtbarkeit) ist dagegen eine Eigenschaft des Systems. Das OpenTelemetry-Projekt beschreibt sie als die Möglichkeit, ein System von außen zu verstehen, indem man ihm Fragen stellt, ohne sein Innenleben zu kennen. Wichtig wird das vor allem bei verteilten Anwendungen und Microservices, in denen viele Fehlerbilder neu sind. Event Management schließlich ist der Prozess, der aus den Meldungen beider Welten die richtigen Schlüsse zieht: filtern, bewerten, zuordnen und eine Reaktion auslösen.

Observability ersetzt das Monitoring nicht. Wer seine Dienste beobachtbar macht, gewinnt bessere Daten für die Fehlersuche. Alarme sollten trotzdem an wenigen, klar definierten Messgrößen hängen.

Und wo steht das SIEM?

Ein SIEM sammelt sicherheitsrelevante Logs, korreliert sie und meldet Auffälligkeiten an ein Security-Team oder ein Security Operations Center. Technisch überschneidet es sich mit dem Log-Monitoring des Betriebs, fachlich verfolgt es ein anderes Ziel: Angriffe statt Störungen erkennen. Die Ergebnisse beider Welten sollten trotzdem im selben Incident-Prozess landen. Sonst wird eine Störung, die in Wahrheit ein Angriff ist, in zwei getrennten Warteschlangen parallel bearbeitet.

Vom Messwert zum Incident: Monitoring im ITSM-Prozess

Ein Monitoring-System, das nur Alarme verschickt, verlagert die Arbeit ins Postfach. Seinen Wert entfaltet es erst, wenn für jede Meldung feststeht, wer sie bearbeitet und in welchem Prozess. ITIL^® 4 unterscheidet dafür drei Arten von Events:

• Information: Ein Backup wurde erfolgreich abgeschlossen. Das Event wird protokolliert, aber nicht bearbeitet.
• Warnung: Ein Datenträger ist fast voll. Noch ist nichts passiert, ohne Eingriff droht aber eine Störung. Daraus kann eine Aufgabe oder ein Change entstehen.
• Ausnahme: Ein Dienst antwortet nicht mehr. Die Ausnahme löst einen Incident aus, bei kritischen Services mit hoher Priorität.

Fünf Regeln für einen standardisierten Ablauf

1. Monitoring-Plan festlegen: Für jede Komponente ist dokumentiert, was gemessen wird, welche Schwellenwerte gelten, welcher Meldeweg greift und was aus einer Meldung folgt. Einen solchen Plan sieht der BSI-Baustein OPS.1.1.1 in der Standard-Anforderung A9 vor.
2. Events filtern und verdichten: Fällt ein zentraler Switch aus, melden auch alle Geräte dahinter einen Fehler. Diese Folgealarme gehören in einen gemeinsamen Incident.
3. Events Services zuordnen: Erst über den betroffenen Service und seine Configuration Items lässt sich die Priorität aus Dringlichkeit und Auswirkung ableiten. Grundlage dafür ist eine gepflegte CMDB.
4. Tickets automatisch anlegen: Ausnahmen werden per Schnittstelle zu Incidents, mit Zeitpunkt, betroffenem System und Messwert. Das spart die Abschrift und macht die Erkennungszeit messbar.
5. Wiederholungen an das Problem Management geben: Treten dieselben Events immer wieder auf, ist die Ursache ein Fall für das Problem Management und nicht für den nächsten Neustart.

Beispiel aus einem Referenzprojekt

Wie diese Kopplung aussieht, zeigt ein Projekt von KYBERNA: Die CCT Software Solutions GmbH überwacht mit einer Standard-Monitoring-Software Kundennetzwerke an über 90 Standorten weltweit. Eine REST-API-Schnittstelle fragt die Events aus dem Monitoring-System laufend ab. Wird ein Problem erkannt, legt ky2help^® automatisch ein Ticket an und startet den kundenspezifischen Incident-Prozess (Referenzbericht CCT).

Für größere Organisationen ist ein einheitlicher Weg vom Event zum Ticket die Voraussetzung, um zu skalieren. Angenommen, ein Unternehmen setzt drei Monitoring-Werkzeuge für Netzwerk, Server und Anwendungen ein. Münden alle drei in denselben Incident-Prozess mit gemeinsamen Prioritäten und Service Level Agreements, lassen sich Erkennungs- und Lösungszeiten über alle Bereiche vergleichen. Verschickt jedes Werkzeug eigene E-Mails, fehlt diese Vergleichbarkeit.

Zum Incident Management

Alarmierung und Kennzahlen: Woran gutes Monitoring zu erkennen ist

Mehr Messpunkte bedeuten nicht mehr Sicherheit. Erhält ein Team täglich Hunderte Meldungen, gehen die wichtigen unter. Dieses Phänomen heißt Alarmmüdigkeit (Alert Fatigue). Das SRE-Handbuch von Google setzt einen strengen Maßstab dagegen: Jeder Alarm, der einen Menschen unterbricht, muss dringend und handlungsrelevant sein. Verlangt er nur eine immer gleiche Routinehandlung, sollte diese automatisiert werden, statt jemanden zu alarmieren.

Die vier goldenen Signale

Für nutzernahe Services nennt das SRE-Handbuch vier Messgrößen als Mindestausstattung: Latenz (Antwortzeit, getrennt nach erfolgreichen und fehlerhaften Anfragen), Traffic (Nachfrage, etwa Anfragen pro Sekunde), Fehler (Anteil fehlgeschlagener Anfragen) und Sättigung (wie nah eine Ressource an ihrer Grenze ist). Alarme auf diese Symptome melden, was Nutzer spüren. Ursachen wie hohe CPU-Last sind auf dem Dashboard oft besser aufgehoben als im Alarm.

Kennzahlen für das Monitoring selbst

• Mean Time to Detect (MTTD): durchschnittliche Zeit vom Beginn einer Störung bis zu ihrer Erkennung.
• Anteil der Incidents aus dem Monitoring: Wie viele Störungen meldet das System, bevor Anwender anrufen? Ein niedriger Wert deutet auf Lücken in der Abdeckung hin.
• Anteil handlungsrelevanter Alarme: Wie viele Alarme führen tatsächlich zu einer Aktion? Ein niedriger Wert spricht für zu empfindliche Schwellenwerte.
• Abdeckung: Anteil der kritischen Services und Configuration Items, für die ein Monitoring eingerichtet ist.
• Mean Time to Restore (MTTR): Zeit bis zur Wiederherstellung. Sie hängt nicht allein vom Monitoring ab, sinkt aber, wenn Tickets mit präzisen technischen Angaben starten.

Wie solche Werte definiert und verfolgt werden, beschreibt der Glossarartikel KPI.

Rahmenbedingungen in Deutschland

Monitoring-Daten sind nicht immer rein technisch. Logs enthalten Benutzernamen, IP-Adressen und Zeitstempel und damit personenbezogene Daten. Für technische Einrichtungen, die dazu bestimmt sind, Verhalten oder Leistung von Beschäftigten zu überwachen, sieht § 87 Abs. 1 Nr. 6 BetrVG ein Mitbestimmungsrecht des Betriebsrats vor. Ob ein Monitoring-Werkzeug darunterfällt, sollten IT, Datenschutz und Betriebsrat vor der Einführung gemeinsam klären.

Unternehmen, die unter die deutsche NIS-2-Umsetzung fallen, müssen nach § 30 BSI-Gesetz unter anderem die Bewältigung von Sicherheitsvorfällen und die Aufrechterhaltung des Betriebs regeln. Ohne verlässliche Erkennung lassen sich diese Pflichten kaum erfüllen. Für die Protokollierung beschreibt der BSI-Baustein OPS.1.1.5 typische Fehler, etwa fehlende Zeitsynchronisation, durch die sich Ereignisse verschiedener Systeme nicht mehr korrelieren lassen.

Häufige Fragen zum Monitoring

Was versteht man unter Monitoring in der IT?

Monitoring ist die fortlaufende, meist automatisierte Überwachung von IT-Systemen, Anwendungen und Services. Es sammelt Messwerte und Zustandsmeldungen, vergleicht sie mit Sollwerten und meldet Abweichungen, damit Störungen erkannt werden, bevor sie viele Nutzer betreffen.

Was ist der Unterschied zwischen Monitoring und Observability?

Monitoring prüft vorab festgelegte Zustände und Schwellenwerte, etwa Erreichbarkeit oder Antwortzeit. Observability beschreibt, wie gut sich das Verhalten eines Systems aus Metriken, Logs und Traces erklären lässt, auch bei Fehlerbildern, die vorher niemand kannte. Beide ergänzen sich.

Was bedeutet Event Management nach ITIL?

In ITIL^® 4 bilden Monitoring und Event Management eine gemeinsame Practice. Events sind Zustandsänderungen, die für den Betrieb eines Services Bedeutung haben. Sie werden als Information, Warnung oder Ausnahme eingestuft, und für jede Stufe ist festgelegt, welche Reaktion folgt, zum Beispiel ein Incident.

Welche Monitoring-Tools gibt es?

Verbreitet sind Open-Source-Werkzeuge wie Zabbix, Prometheus, Icinga oder Nagios sowie kommerzielle Plattformen wie Datadog, Dynatrace oder PRTG. Für Azure und hybride Umgebungen bietet Microsoft Azure Monitor an. Die Auswahl richtet sich nach den zu überwachenden Ebenen, der Zahl der Systeme und dem vorhandenen Know-how.

Welche Kennzahlen zeigen, ob das Monitoring funktioniert?

Aussagekräftig sind die Mean Time to Detect, der Anteil der Incidents, die das Monitoring vor den Anwendern meldet, der Anteil handlungsrelevanter Alarme und die Abdeckung der kritischen Services. Für die Services selbst empfiehlt das SRE-Handbuch von Google Latenz, Traffic, Fehler und Sättigung.

Kann ky2help^® Meldungen aus Monitoring-Systemen übernehmen?

ky2help^® lässt sich über die REST-API (Webservices) mit Monitoring-Systemen verbinden. Im Referenzprojekt bei CCT Software Solutions fragt eine solche Schnittstelle die Events laufend ab und legt bei einem erkannten Problem automatisch ein Ticket an. Welche Regeln für Ihre Umgebung sinnvoll sind, klären wir gern in einer Live-Demo.

Quellen und weiterführende Artikel

Quellen

• PeopleCert: ITIL^® 4 Foundation (Practice Monitoring and Event Management)
• BSI: IT-Grundschutz-Baustein OPS.1.1.1 Allgemeiner IT-Betrieb (Anforderung A9 Durchführung von IT-Monitoring, PDF)
• BSI: IT-Grundschutz-Baustein OPS.1.1.5 Protokollierung (PDF)
• Google: Site Reliability Engineering, Kapitel „Monitoring Distributed Systems“ (englisch)
• OpenTelemetry: Observability primer (englisch)
• Gesetze im Internet: § 87 Betriebsverfassungsgesetz und § 30 BSI-Gesetz
• KYBERNA: Referenzbericht CCT Software Solutions und Funktionsumfang von ky2help^®

Weiterlesen im Glossar und in der Wissenswelt

• Incident und ITIL Incident Management
• Problem Management und Root Cause Analysis
• Service Level Agreement (SLA) und KPI
• CMDB und Predictive Maintenance
• Automatisierung von Routineaufgaben im ITSM
• IT Service Management (ITSM) und ITIL