10.1 Ziele und Grundlagen des Monitoring and Event Management

Kurz erklärt

Monitoring and Event Management sorgt dafür, dass der Zustand von IT-Services und IT-Systemen kontinuierlich überwacht wird.

Ziel ist es, Abweichungen möglichst früh zu erkennen, bevor daraus Incidents oder Serviceunterbrechungen entstehen.

Ereignisse (Events) werden gesammelt, bewertet und – je nach Bedeutung – automatisch verarbeitet oder an die zuständigen Teams weitergeleitet.


Was ist Monitoring and Event Management?

Monitoring and Event Management ist eine ITIL Practice zur kontinuierlichen Überwachung von Services, Systemen und Infrastruktur.

Dabei werden Informationen über den aktuellen Zustand gesammelt und ausgewertet.

Beispiele:

Das Ziel besteht darin, Probleme möglichst frühzeitig zu erkennen.


Warum Monitoring wichtig ist

Ohne Monitoring werden viele Probleme erst bemerkt,

wenn Benutzer sie melden.

Dadurch entstehen:

Ein gutes Monitoring erkennt viele Probleme bereits,

bevor Benutzer betroffen sind.


Ziele des Monitoring and Event Management

Die wichtigsten Ziele sind:

Monitoring ersetzt dabei keine Fehlerbehebung.

Es liefert die notwendigen Informationen.


Monitoring und Event Management unterscheiden

Diese beiden Begriffe werden häufig gemeinsam verwendet,

beschreiben jedoch unterschiedliche Aufgaben.

Monitoring Event Management
sammelt Messwerte bewertet Ereignisse
überwacht Systeme entscheidet über Reaktionen
erkennt Veränderungen verarbeitet Events
liefert Daten löst Aktionen aus

Monitoring erzeugt Events.

Event Management verarbeitet diese.


Was ist ein Event?

Ein Event ist jede erkennbare Veränderung des Zustands eines Services oder Configuration Items.

Ein Event kann beispielsweise entstehen durch:

Nicht jedes Event bedeutet automatisch ein Problem.


Event ist nicht gleich Incident

Ein häufiger Irrtum:

Jedes Event ist ein Incident.

Das stimmt nicht.

Beispiel:

Ein Server startet nach einer geplanten Wartung neu.

Das Monitoring erzeugt ein Event.

Da die Änderung geplant war,

liegt kein Incident vor.


Beispiel eines echten Incidents

Das Monitoring erkennt:

Es existiert:

Jetzt entsteht aus dem Event möglicherweise ein Incident.


Informationsfluss

Monitoring
      │
      ▼
Event entsteht
      │
      ▼
Bewertung
      │
 ┌────┴────┐
 │         │
Normal   Reaktion
 │         │
 ▼         ▼
Protokoll Alarm oder Automation

Nicht jedes Event benötigt menschliches Eingreifen.


Arten von Monitoring

Typische Bereiche:

Je nach Service kommen unterschiedliche Überwachungen zum Einsatz.


Technisches Monitoring

Technisches Monitoring überwacht einzelne Komponenten.

Beispiele:

Es beantwortet die Frage:

Funktioniert das System technisch?


Service Monitoring

Service Monitoring betrachtet den Service aus Benutzersicht.

Beispiele:

Ein Server kann technisch erreichbar sein,

während der eigentliche Service bereits gestört ist.


Aktives Monitoring

Beim aktiven Monitoring werden Systeme regelmäßig geprüft.

Beispiele:

Die Prüfungen erfolgen automatisch in festgelegten Intervallen.


Passives Monitoring

Beim passiven Monitoring senden Systeme selbst Informationen.

Beispiele:

Hier wartet das Monitoring auf eintreffende Ereignisse.


Synthetisches Monitoring

Synthetisches Monitoring simuliert typische Benutzeraktionen.

Beispiele:

Dadurch wird geprüft,

ob ein Service tatsächlich nutzbar ist.


Real User Monitoring (RUM)

Beim Real User Monitoring werden echte Benutzeraktionen ausgewertet.

Beispiele:

Dadurch erhält die IT Informationen über die tatsächliche Benutzererfahrung.


Überwachungsobjekte

Monitoring kann sich beziehen auf:

Nicht jedes Objekt benötigt dieselbe Überwachung.


Grenzwerte (Thresholds)

Viele Überwachungen arbeiten mit Grenzwerten.

Beispiele:

Messwert Grenzwert
CPU über 90 %
RAM über 95 %
Festplatte über 85 % belegt
Zertifikat läuft in 30 Tagen ab
Backup fehlgeschlagen
Antwortzeit über 2 Sekunden

Grenzwerte sollten regelmäßig überprüft werden.


Frühwarnungen

Nicht jeder Alarm muss sofort kritisch sein.

Beispiel:

Festplatte:

Dadurch bleibt genügend Zeit,

Probleme zu beheben.


Alarmmüdigkeit (Alert Fatigue)

Zu viele unnötige Alarme führen dazu,

dass wichtige Warnungen übersehen werden.

Typische Ursachen:

Ein gutes Monitoring erzeugt möglichst wenige,

aber relevante Alarme.


Praxisbeispiel

Das Monitoring erkennt:

Es entsteht:

Das Zertifikat wird rechtzeitig erneuert.

Ein späterer Incident wird vermieden.


Typische Fehler

Fehler 1

Monitoring existiert nur für Server,

nicht für Services.


Fehler 2

Grenzwerte sind ungeeignet.


Fehler 3

Zu viele unnötige Alarme.


Fehler 4

Alarme werden nicht bearbeitet.


Fehler 5

Backups werden nicht überwacht.


Fehler 6

Zertifikate werden nicht überwacht.


Fehler 7

Monitoring erkennt Fehler erst nach Benutzerbeschwerden.


Fehler 8

Monitoring wird nach Änderungen nicht angepasst.


Checkliste Monitoring


Bedeutung für Fachinformatiker für Systemintegration

Monitoring gehört zu den täglichen Aufgaben vieler Fachinformatiker.

Typische Tätigkeiten:

Ein gut aufgebautes Monitoring verhindert viele Störungen, bevor Benutzer sie überhaupt bemerken.


Zusammenfassung

Systeme und Services überwachen

Messwerte sammeln

Event erzeugen

Event bewerten

Alarm oder Automatisierung

Incident vermeiden oder bearbeiten

Service stabil halten


Merksätze

Monitoring sammelt Informationen – Event Management bewertet sie.

Nicht jedes Event ist ein Incident.

Gutes Monitoring erkennt Probleme vor den Benutzern.

Service Monitoring ist wichtiger als reine Serverüberwachung.

Wenige aussagekräftige Alarme sind besser als viele unnötige Warnungen.


Verwandte Seiten


Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Monitoring-Arten, Beispiele und Grenzwerte sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine konkreten Monitoring-Werkzeuge oder festen Schwellenwerte vor. Diese richten sich nach den überwachten Services, den Geschäftsanforderungen und der technischen Umgebung.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance
Fachlicher Stand: August 2026


Revision #1
Created 2 August 2026 21:02:27 by Admin
Updated 2 August 2026 21:02:41 by Admin