DE102019006539A1

DE102019006539A1 - Ereignisbasierte Serviceerkennung und Fehlerursachenanalyse

Info

Publication number: DE102019006539A1
Application number: DE102019006539.5A
Authority: DE
Inventors: Balram Reddy KAKANI; Ravindra Kumar PULI; Smrati Gupta
Original assignee: Ca Lnc
Current assignee: Ca Lnc
Priority date: 2018-09-28
Filing date: 2019-09-16
Publication date: 2020-04-02
Also published as: US10616044B1; US20200106660A1

Abstract

Ein System verwendet eine Ereigniskorrelation, um Komponenten zu identifizieren, die zum demselben Service oder zur derselben Servicedomäne gehören. Das System korreliert Ereignisse, indem es Kovarianzmatrizen generiert oder indem es mit zeitbasierten Datenbanken eine Sequenzmustersuche durchführt, um Ereignismuster zu erkennen, die sequenziell in einem festen Zeitfenster auftreten. Den korrelierten Ereignissen entsprechende Komponenten werden als Teile ein und derselben Servicedomäne identifiziert und können in einer Servicedomänen-Datenstruktur, wie beispielsweise einer Topologie, angegeben werden. Das System nutzt die identifizierten Servicedomänen während der Fehlerursachenanalyse. Das System kann ein ungewöhnliches Ergebnis, das bei einer Komponente auf der niedrigsten Schicht in einer Servicedomäne auftritt, als Ursache bestimmen, oder es kann ein ungewöhnliches Ereignis, das als Erstes in einer identifizierten Ereignissequenz einer Servicedomäne auftritt, als Ursache bestimmen. Nach dem Identifizieren des Fehlerursachenereignisses unterdrückt das System Benachrichtigungen über Ereignisse, die bei anderen Komponenten in der Servicedomäne auftreten.

Description

Die Offenbarung betrifft im Allgemeinen das Gebiet der Informationssicherheit und insbesondere die Entwicklung, Installation und Verwaltung von Software.
Informationen zu Verbindungen zwischen Komponenten in einem System werden oft zur Fehlerursachenanalyse bei Systemproblemen verwendet. Zum Beispiel kann ein Netzwerkadministrator oder eine Netzwerk-Verwaltungssoftware die Netzwerktopologie und Netzwerkereignisse als Hilfestellung bei der Behebung von Problemen und Ausfällen nutzen. Die Netzwerktopologie beschreibt Verbindungen zwischen physischen Komponenten eines Netzwerks und beschreibt möglicherweise keine Beziehungen zwischen Software-Komponenten. Ereignisse werden mittels einer Vielfalt von Quellen oder Komponenten einschließlich Hardware und Software generiert. Ereignisse können in Nachrichten angegeben werden, die zahlreiche Aktivitäten angeben können, wie beispielsweise, dass eine Anwendung eine Aufgabe abschließt oder dass ein Server ausgefallen ist.
Gemäß einer Erscheinungsform der Erfindung wird ein Verfahren vorgesehen, das Folgendes umfasst:

Korrelieren von in einem Netzwerk generierten Ereignissen, um Komponenten einer Servicedomäne zu identifizieren;
Abrufen, auf der Grundlage des Erkennens eines ersten Ereignisses, das ein Problem bei einer ersten Komponente in der Servicedomäne angibt, eines ersten Satzes von Ereignisbenachrichtigungen, die Ereignisse angeben, die bei den Komponenten innerhalb der Servicedomäne auftreten;
Identifizieren einer Ursache des Problems bei der ersten Komponente wenigstens teilweise auf der Grundlage der in der Servicedomäne angegebenen Komponenten und des ersten Satzes von Ereignisbenachrichtigungen; und
Unterdrücken der Generierung von Ereignisbenachrichtigungen für die Komponenten in der Servicedomäne.

Zweckmäßigerweise umfasst das Identifizieren der Ursache des ersten Ereignisses wenigstens teilweise auf der Grundlage der in der Servicedomäne angegebenen Komponenten und des ersten Satzes von Ereignisbenachrichtigungen Folgendes:

Identifizieren von ungewöhnlichen Ereignissen in dem ersten Satz von Ereignisbenachrichtigungen;
Identifizieren einer Komponente auf der niedrigsten Schicht der Servicedomäne, die ein zweites Ereignis der identifizierten, ungewöhnlichen Ereignisse erfahren hat; und
Angeben des zweiten Ereignisses als Ursache des Problems bei der ersten Komponente.

Zweckmäßigerweise umfasst das Verfahren ferner Folgendes:

Identifizieren von Komponententypen der Komponenten in der Servicedomäne; und
Zuweisen der Komponenten zu Schichten wenigstens teilweise auf der Grundlage der Komponententypen der Komponenten in der Servicedomäne.

Identifizieren eines der Reihe nach ersten Ereignisses, das in einer mit der Servicedomäne verbundenen Ereignissequenz angegeben ist;
Identifizieren eines zweiten Ereignisses in dem ersten Satz von Ereignisbenachrichtigungen, das mit dem in der Ereignissequenz angegebenen, der Reihe nach ersten Ereignis übereinstimmt; und
Angeben des zweiten Ereignisses als Ursache des Problems bei der ersten Komponente.

Zweckmäßigerweise umfasst das Korrelieren der in dem Netzwerk generierten Ereignisse zum Identifizieren von Komponenten der Servicedomäne Folgendes:

Identifizieren einer wiederholten Ereignissequenz in den in dem Netzwerk generierten Ereignissen; und
Angeben von der Ereignissequenz entsprechenden Komponenten als den Komponenten der Servicedomäne.

Generieren einer ersten Kovarianzmatrix mit Einträgen, die eine Kovarianz von Ereignissen zwischen Komponenten in dem Netzwerk angeben;
Identifizieren der Einträge in der ersten Kovarianzmatrix, die einen Schwellenwert überschreiten; und
Angeben von den Einträgen in der ersten Kovarianzmatrix entsprechenden Komponenten, die den Schwellenwert überschreiten, als den Komponenten der Servicedomäne.

Zweckmäßigerweise umfasst das Verfahren ferner Folgendes:

Generieren eines Satzes von Kovarianzmatrizen über mehrere Betriebszeiträume der Komponenten in dem Netzwerk hinweg; und
Validieren der Einträge in der ersten Kovarianzmatrix, welche den Schwellenwert überschreiten, wenigstens teilweise auf der Grundlage von Einträgen in dem über die mehreren Betriebszeiträume generierten Satz von Kovarianzmatrizen.

Zweckmäßigerweise umfasst das Verfahren ferner, nach dem Bestimmen, dass das Problem bei der ersten Komponente gelöst wurde, das Wiederaufnehmen des Generierens von Ereignisbenachrichtigungen für die Komponenten in der Servicedomäne.
Zweckmäßigerweise umfasst das Verfahren ferner das Generieren einer Diagrammdatenstruktur zum Darstellen der Komponenten der Servicedomäne, wobei die Diagrammdatenstruktur Knoten zum Angeben der Komponenten und Grenzlinien zum Darstellen der Beziehungen zwischen den Komponenten umfasst.
Gemäß einer Erscheinungsform werden ein oder mehrere nichtflüchtige, maschinenlesbare Medien vorgesehen, die Programmcode umfassen, wobei der Programmcode zu Folgendem dient:

Identifizieren eines ersten Ereignismusters in einem Ereignisprotokoll, das von Einrichtungen in einem Netzwerk generierte Ereignisse umfasst;
Bestimmen einer ersten Servicedomäne wenigstens teilweise auf der Grundlage von Einrichtungen, die Ereignissen in dem ersten Ereignismuster entsprechen;
Bestimmen, auf der Grundlage des Erkennens eines Problems bei einer ersten Einrichtung in der ersten Servicedomäne, ob ein von der ersten Einrichtung generiertes Ereignis mit einem Ereignis in dem ersten Muster übereinstimmt; und
Angeben, auf der Grundlage des Bestimmens, dass ein von der ersten Einrichtung generiertes Ereignis mit einem Ereignis in dem ersten Ereignismuster übereinstimmt, einer zweiten Einrichtung in der ersten Servicedomäne als Ursache des Problems bei der ersten Einrichtung, wobei die zweite Einrichtung einem ersten Ereignis in dem ersten Ereignismuster entspricht.

Zweckmäßigerweise umfasst der Programmcode zum Identifizieren des ersten Ereignismusters in dem Ereignisprotokoll Programmcode, der zu Folgendem dient:

Aufteilen der Ereignisse in dem Ereignisprotokoll in mehrere Sammlungen von Ereignissen wenigstens teilweise auf der Grundlage eines Zeitfensters; und
Bestimmen, dass sich das erste Ereignismuster in einer Schwellenwert-Anzahl der Sammlungen von Ereignissen wiederholt, bevor die erste Servicedomäne bestimmt wird.

Zweckmäßigerweise umfassen die maschinenlesbaren Medien ferner Programmcode, der zu Folgendem dient:

Identifizieren eines zweiten Ereignismusters in dem Ereignisprotokoll; und
Bestimmen einer zweiten Servicedomäne wenigstens teilweise auf der Grundlage von Einrichtungen, die Ereignissen in dem zweiten Ereignismuster entsprechen.

Zweckmäßigerweise handelt es sich bei dem ersten Ereignismuster um eine zeitlich aufeinanderfolgende Reihe von Ereignissen.
Zweckmäßigerweise umfassen die maschinenlesbaren Medien ferner einen Programmcode zum Unterdrücken von Ereignissen für die Einrichtungen der ersten Servicedomäne nach dem Erkennen des Problems bei der ersten Einrichtung.
Gemäß einer Erscheinungsform wird eine Vorrichtung vorgesehen, die Folgendes umfasst:

einen Prozessor; und
ein maschinenlesbares Medium mit mittels des Prozessors ausführbarem Programmcode, um die Vorrichtung zu veranlassen,
- in einem Netzwerk generierte Ereignisse zu korrelieren, um Komponenten einer oder mehrerer Servicedomänen zu identifizieren;
- ein erstes Ereignis zu erkennen, das ein Problem bei einer ersten Komponente in dem Netzwerk angibt;
- wenigstens eine erste Servicedomäne von der einen oder den mehreren Servicedomänen zu identifizieren, welche die erste Komponente umfasst; und
- eine Ursache des Problems bei der ersten Komponente wenigstens teilweise auf der Grundlage der in der ersten Servicedomäne angegebenen Komponenten zu identifizieren.

Zweckmäßigerweise umfasst die Vorrichtung ferner Programmcode, der zu Folgendem dient:

Identifizieren einer zweiten Servicedomäne, welche die erste Komponente umfasst; und
Unterdrücken der Generierung von Ereignisbenachrichtigungen für die Komponenten in der ersten Servicedomäne und der zweiten Servicedomäne, bis das Problem bei der ersten Komponente gelöst ist.

Zweckmäßigerweise der Programmcode zum Identifizieren der Ursache des ersten Ereignisses auf der Grundlage der wenigstens der in der ersten Servicedomäne angegebenen Komponenten:

Abrufen eines ersten Satzes von Ereignisbenachrichtigungen für ungewöhnliche Ereignisse, die bei den Komponenten in der ersten Servicedomäne auftreten;
Identifizieren einer Komponente auf der niedrigsten Schicht der ersten Servicedomäne, die ein in dem ersten Satz von Ereignisbenachrichtigungen angegebenes, zweites Ereignis erfahren hat; und
Angeben des zweiten Ereignisses als Ursache des Problems bei der ersten Komponente.

Identifizieren von Komponententypen der Komponenten in der ersten Servicedomäne; und
Zuweisen der Komponenten zu Schichten wenigstens teilweise auf der Grundlage der Komponententypen der Komponenten in der ersten Servicedomäne.

Identifizieren eines der Reihe nach ersten Ereignisses, das in einer mit der Servicedomäne verbundenen Ereignissequenz angegeben ist;
Identifizieren eines zweiten, bei einer der Komponenten in der ersten Servicedomäne auftretenden Ereignisses, das mit dem in der Ereignissequenz der Reihe nach als Erstes angegebenen Ereignis übereinstimmt; und
Angeben des zweiten Ereignisses als Ursache des Problems bei der ersten Komponente.

Zweckmäßigerweise umfasst der Programmcode zum Korrelieren von in einem Netzwerk generierten Ereignissen, um Komponenten von einer oder mehreren Servicedomänen zu identifizieren, Programmcode, der zu Folgendem dient:

Identifizieren von einer oder mehreren Ereignissequenzen in den in dem Netzwerk generierten Ereignissen; und
Generieren einer Servicedomäne für jede der identifizierten Ereignissequenzen, die verschiedenen Sätzen von Komponenten entsprechen.

KURZE BESCHREIBUNG DER ZEICHNUNGEN
Erscheinungsformen der Offenbarung sind unter Bezugnahme auf die beigefügten Zeichnungen möglicherweise besser verständlich.

1 bildet ein beispielhaftes Netzwerkverwaltungssystem ab, das eine ereignisbasierte Identifikation von Servicedomänen und eine Fehlerursachenanalyse durchführt.
2 bildet auf der Grundlage einer Ereigniskorrelation identifizierte Servicedomänen ab.
3 bildet zum Identifizieren von Beziehungen zwischen Komponenten auf der Grundlage einer Ereigniskorrelation verwendete Kovarianzmatrizen ab.
4 bildet ein Beispiel für die Verwendung einer Ereignis-Sequenzmustersuche zum Durchführen einer Ereigniskorrelation und zum Identifizieren von Beziehungen zwischen Komponenten ab.
5 bildet ein Ablaufdiagramm mit beispielhaften Operationen zum Durchführen einer ereignisbasierten Identifikation von Servicedomänen und einer Fehlerursachenanalyse ab.
6 bildet ein beispielhaftes Computersystem mit einer Servicedomänenkennung und einem Fehlerursachenanalysator ab.

BESCHREIBUNG
Die nachfolgende Beschreibung umfasst beispielhafte Systeme, Verfahren, Techniken und Programmabläufe, die Erscheinungsformen der Offenbarung verkörpern. Es versteht sich jedoch, dass diese Offenbarung ohne diese spezifischen Einzelheiten ausgeführt oder in anderen Umgebungen ausgeführt werden kann. Zum Beispiel betrifft diese Offenbarung das Durchführen einer Fehlerursachenanalyse unter Verwendung identifizierter Servicedomänen in veranschaulichenden Beispielen. Erscheinungsformen dieser Offenbarung können außerdem auf die Verwendung identifizierter Servicedomänen zum Bestimmen einzelner Ausfallpunkte in einem System oder zum Identifizieren anderer Schwachpunkte, wie beispielsweise Lastverteilungsprobleme, für ein System angewendet werden. Bei anderen Beispielen werden allgemein bekannte Anweisungsbeispiele, Protokolle, Strukturen und Techniken nicht im Detail gezeigt, um die Beschreibung nicht unübersichtlich zu machen.
Einführung
Ohne Kenntnis eines Systems kann das Erkennen von Beziehungen für Komponenten über Domänen eines Service hinweg bei Nicht-Vorhandensein von Topologie-Informationen schwierig sein. Während einige Techniken für die Korrelation von Komponenten über Domänen hinweg zur Verfügung stehen, erfordern diese einen beträchtlichen Aufwand, um den Umfang der Korrelation vorab zu laden oder zu definieren. Zusätzlich sind einige Formen der Korrelation über Domänen hinweg hinsichtlich der Domänen, in denen sie arbeiten, sehr begrenzt, und sie erfordern möglicherweise noch etwas Frontend-Design oder Festcodierung durch Fachleute, um ordnungsgemäß zu funktionieren. Diese Techniken zur festen Codierung von Korrelationen versagen, wenn sie neuen Domänen (oder neuen Netzwerkkonfigurationen oder Netzwerktechnologien) bereitgestellt werden.
Übersicht
Um eine verbesserte Identifikation von Servicekomponenten und eine Fehlerursachenanalyse vorzusehen, verwendet ein System eine Ereigniskorrelation, um Komponenten zu identifizieren, die zu demselben Service oder zu derselben Servicedomäne gehören. Das System korreliert Ereignisse, indem es Kovarianzmatrizen generiert oder mit zeitbasierten Datenbanken eine Sequenzmustersuche durchführt, um Ereignismuster (oder Episoden von Ereignissen) zu erkennen, die sequenziell in einem Zeitfenster auftreten. Den korrelierten Ereignissen entsprechende Komponenten werden als Teile ein und derselben Servicedomäne identifiziert und können in einer Servicedomänen-Datenstruktur, wie beispielsweise einer Topologie, angegeben werden. Das System nutzt die identifizierten Servicedomänen während der Fehlerursachenanalyse. Das System kann ein ungewöhnliches Ergebnis, das bei einer Komponente auf der niedrigsten Schicht in einer Servicedomäne auftritt, als Ursache bestimmen, oder es kann ein ungewöhnliches Ereignis, das als Erstes in einer identifizierten Ereignissequenz einer Servicedomäne auftritt, als Ursache bestimmen. Nach dem Identifizieren des Fehlerursachenereignisses unterdrückt das System Benachrichtigungen über Ereignisse, die bei anderen Komponenten in der Servicedomäne auftreten, um zu vermeiden, dass einem Administrator über die Netzwerkverwaltungssoftware überflüssige Benachrichtigungen bereitgestellt werden.
Begriffsdefinitionen
Der Begriff „Komponente“, wie er in der nachfolgenden Beschreibung verwendet wird, umspannt sowohl Hardware- als auch Software-Ressourcen. Der Begriff Komponente kann eine physische Einrichtung, wie beispielsweise einen Computer, Server, Router usw. betreffen; eine virtualisierte Einrichtung, wie beispielsweise eine virtuelle Maschine oder eine virtualisierte Netzwerkfunktion; oder Software, wie beispielsweise eine Anwendung, einen Prozess einer Anwendung, ein Datenbankverwaltungssystem usw. Eine Komponente kann weitere Komponenten umfassen. Zum Beispiel kann eine Server-Komponente eine Web-Service-Komponente umfassen, die eine Web-Anwendungskomponente umfasst.
Die nachfolgende Beschreibung bezieht sich auf ein „Ereignis“, um eine Nachricht, Angabe oder Benachrichtigung bezüglich eines Ereignisses zu beschreiben. Ein Ereignis ist ein Vorkommnis in einem System oder in einer Komponente des Systems zu einem Zeitpunkt. Ein Ereignis betrifft oft den Ressourcenverbrauch und/oder den Zustand eines Systems oder einer Systemkomponente. Als Beispiele seien genannt: Es kann ein Ereignis sein, dass eine Datei zu einem Dateisystem hinzugefügt wurde, dass eine Anzahl von Benutzern einer Anwendung eine Schwellenwert-Anzahl von Benutzern überschreitet, dass eine Menge von verfügbarem Speicher einen Speichermengen-Schwellenwert unterschreitet oder dass eine Komponente aufgehört hat zu antworten oder ausgefallen ist. Eine Ereignisangabe kann auf Informationen über das Ereignis Bezug nehmen oder solche umfassen und wird mittels eines Agenten oder einer Sonde an eine Komponente/einen Agenten/einen Prozess gesendet, die bzw. der Ereignisangaben verarbeitet. Beispielhafte Informationen über ein Ereignis umfassen einen Ereignistypen/Ereigniscode, eine Anwendungskennung, einen Zeitpunkt des Ereignisses, einen Schweregrad, eine Ereigniskennung, eine Ereignisbeschreibung usw.
Die nachfolgende Beschreibung betrifft korrelierende Ereignisse bzw. Ereigniskorrelation. Der Prozess der Ereigniskorrelation beinhaltet das Identifizieren von Ereignissen, die eine Verbindung oder Beziehung zueinander haben, wie beispielsweise eine zeitbasierte Verbindung, eine Ursache-und-Wirkung-Beziehung, eine statistische Beziehung usw. Korrelierende Ereignisse bzw. Ereigniskorrelation, wie in dem vorliegenden Dokument verwendet, betrifft die Identifikation dieser vorhandenen Beziehung und umfasst nicht das Ändern von Ereignissen, um eine Verbindung oder Beziehung herzustellen.
In der nachfolgenden Beschreibung wird der Begriff „Servicedomäne“ verwendet, um eine Sammlung von Ressourcen oder Komponenten zu bezeichnen, die beim Bereitstellen eines Service, wie beispielsweise einer Anwendung, einer Datenbank, eines Web-Servers usw. genutzt werden. Zum Beispiel kann eine Servicedomäne eine Cloud-Speicheranwendung, eine die Anwendung ausführende virtuelle Maschine, einen der virtuellen Maschine zugrunde liegenden Hypervisor, einen den Hypervisor hostenden Server und einen den Server mit dem Netzwerk verbindenden Router umfassen.
Beispielhafte Veranschaulichungen
1 bildet ein beispielhaftes Netzwerkverwaltungssystem ab, das eine ereignisbasierte Identifikation von Servicedomänen und eine Fehlerursachenanalyse durchführt. 1 bildet eine virtuelle Maschine A 101, eine virtuelle Maschine B 120, einen Server 121, ein Speichersystem 122 und einen Ereignissammler 105 ab, die über ein Netzwerk 104 miteinander verbunden sind. Die virtuelle Maschine A 101 umfasst eine Anwendung 102. 1 bildet außerdem ein Netzwerkverwaltungssystem 110 ab, das einen Ereigniskorrelator 107 und einen Fehlerursachenanalysator 109 umfasst. Der Ereignissammler 105, der Ereigniskorrelator 107 und der Fehlerursachenanalysator 109 sind mit einer Ereignisdatenbank 106 kommunikativ gekoppelt.
In Phase A empfängt der Ereignissammler 105 Ereignisse von Komponenten in dem Netzwerk 104 und speichert sie in der Ereignisdatenbank 106. Der Ereignissammler 105 kann die Ereignisse von Agenten der Komponenten in dem Netzwerk 104 empfangen. In 1 empfängt der Ereignissammler 105 die Ereignisse 1 bis 5 und speichert sie in der Ereignisdatenbank 106. Ereignis 1 gibt an, dass die Prozessorlast für die virtuelle Maschine A 101 zu dem Zeitpunkt 1:00 95 % betrug, und Ereignis 2 gibt an, dass die Antwortzeit für die virtuelle Maschine B 120 zu dem Zeitpunkt 1:01 500 Millisekunden betrug. Ereignis 3 gibt an, dass die Anwendung 102 das Speichersystem 122 zu dem Zeitpunkt 1:15 fünf Mal aufgerufen hat, und Ereignis 4 gibt an, dass die Antwortzeit des Speichersystems 122 zu dem Zeitpunkt 1:16 100 Millisekunden betrug. Ereignis 5 gibt an, dass die Prozessorlast des Servers 121 zu dem Zeitpunkt 1:20 85 % betrug. Die Ereignisangaben können zusätzliche Informationen umfassen, die nicht abgebildet sind. Zum Beispiel kann Ereignis 1 angeben, dass die Prozessorlast für eine gewisse Zeitspanne ein Mittel darstellt und eine Minimal- und Maximallast für die Zeitspanne umfassen kann. Die Ereignisse 1 bis 5 sind Beispiele für bestimmte Typen von Ereignisindikatoren, die von dem Ereignissammler 105 empfangen werden können. Der Ereignissammler 105 empfängt und speichert außerdem Ereignisangaben anderer, nicht abgebildeter Typen in der Ereignisdatenbank 106.
In Phase B ruft der Ereigniskorrelator 107 Ereignisse aus der Ereignisdatenbank 106 ab und korreliert sie, um Komponenten für die Servicedomänen 108 zu identifizieren. Ereigniskorrelation betrifft die Identifikation einer Beziehung oder statistischen Verbindung zwischen zwei oder mehr Ereignissen. Ereignisse können auf der Grundlage einer Bestimmung, dass ein erstes Ereignis ein zweites Ereignis verursacht hat, dass eine erste Reihe von Ereignissen eine zweite Reihe von Ereignissen verursacht hat, dass zwei Ereignisse oft annähernd zeitgleich auftreten usw. korreliert sein. Der Ereigniskorrelator 107 kann Ereignisse außerdem auf der Grundlage einer statistischen Analyse, einer kausalen Analyse oder einer Wahrscheinlichkeitsanalyse unter Verwendung einer statistischen Korrelations-/Kovarianzmatrix, wie in 3 beschrieben, korrelieren. Der Ereigniskorrelator 107 kann Ereignisse außerdem auf der Grundlage einer Sequenzmustersuche oder einer Identifikation von sich wiederholenden Ereignismustern (das heißt zeitbasiert aufeinander folgenden Reihen von Ereignissen) korrelieren, wie in 4 ausführlicher beschrieben ist. In 1 zum Beispiel kann der Ereigniskorrelator 107 bestimmen, dass es eine Korrelation zwischen dem Ereignis 3, bei dem die Anwendung 102 das Speichersystem 122 aufruft, und dem Ereignis 4, das eine Minute später auftritt und eine lange Antwortzeit bei dem Speichersystem 122 angibt, gibt. Der Ereigniskorrelator 107 kann Korrelationen über mehrere Zeitspannen hinweg validieren. Zum Beispiel kann der Ereigniskorrelator 107 eine Korrelationswahrscheinlichkeit auf der Grundlage des Identifizierens eines Musters in vergangenen Ereignissen erhöhen, welches angibt, dass ein Ereignis mit einer langen Antwortzeit für das Speichersystem 122 häufig nach Ereignissen auftritt, die Aufrufe des Speichersystems 122 durch die Anwendung 102 angeben.
Eine Korrelation zwischen Ereignissen gibt eine Beziehung zwischen den entsprechenden Komponenten an. Eine Ereigniskorrelation kann Komponentenbeziehungen aufdecken, die möglicherweise aus den Informationen zu der Netzwerktopologie nicht offensichtlich sind, und diese Beziehungen können identifiziert werden, ohne dass umfangreiche manuelle Eingaben durch einen Administrator erforderlich sind. Der Ereigniskorrelator 107 verwendet die bestimmten Beziehungen, um Komponenten zu identifizieren, die Teil von ein und derselben Servicedomäne sind. Der Ereigniskorrelator 107 gibt die Komponenten in den Servicedomänen 108 an, was die beispielhafte Servicedomäne 1 115 umfasst. Wie in 1 gezeigt, umfasst die Servicedomäne 1 115 die Anwendung 102, die virtuelle Maschine A 101, das Speichersystem 122, einen Hypervisor und einen Router, der ebenfalls Teil des Netzwerks 104 sein kann. Der Ereigniskorrelator 107 hat diese Komponenten auf der Grundlage des Bestimmens einer Korrelation zwischen Ereignissen dieser Komponenten, wie der oben beschriebenen, beispielhaften Korrelation zwischen Ereignissen der Anwendung 102 und dem Speichersystem 122, in dieselbe Servicedomäne aufgenommen. Zusätzlich hat der Ereigniskorrelator 107 möglicherweise auf der Grundlage des Bestimmens, dass der Router von Komponenten der logischen Schicht, wie beispielsweise der Anwendung 102 genutzt wurde, den Router, eine Komponente der Bitübertragungsschicht, in die Servicedomäne 1115 aufgenommen. Beziehungen zwischen Komponenten der Bitübertragungsschicht und der logischen Schicht können unter Verwendung einer Rückwärtssuche oder über eine dem Ereigniskorrelator 107 bereitgestellte Netzwerktopologie identifiziert werden. Die Schicht, der eine Komponente zugewiesen ist, kann auf dem OSI-Modell (Open Systems Interconnection) basieren. Die Schichten können mehrere Komponenten umfassen, zum Beispiel können sich Router und Switches auf derselben Schicht befinden. Der Ereigniskorrelator 107 kann die Servicedomänen 108 in einer Diagrammdatenstruktur mit Knoten bereitstellen, welche die Komponenten und Grenzlinien identifizieren, welche die Beziehungen zwischen den Komponenten angeben, oder er kann die Komponenten in einer Liste angeben. Der Ereigniskorrelator 107 kann Daten in den Servicedomänen 108, wie beispielsweise einen zum Identifizieren von Beziehungen verwendeten Korrelationstypen, eine bestimmte Korrelationswahrscheinlichkeit, Ereignisattributwerte, eine entsprechende Netzwerk- oder Serviceschicht für jede Komponente usw. umfassen. Wenn zum Identifizieren von Ereigniskorrelationen eine Sequenzmustersuche verwendet wurde, kann der Ereigniskorrelator 107 die Diagrammdatenstruktur kennzeichnen oder auf andere Weise in den Servicedomänen 108 eine Sequenz angeben, in der Ereignisse bei den Komponenten typischerweise auftreten. Zum Beispiel kann der Ereigniskorrelator 107 die Servicedomäne 1 115 kennzeichnen, um anzugeben, dass typischerweise zunächst bei der Anwendung 102 ein Ereignis auftritt und dann bei dem Speichersystem 122 ein Ereignis auftritt.
In Phase C führt der Fehlerursachenanalysator 109 unter Verwendung der Servicedomänen 108 und von Ereignissen in der Ereignisdatenbank 106 eine Fehlerursachenanalyse durch. Der Fehlerursachenanalysator 109 kann die Ereignisdatenbank 106 überwachen, um ein oder mehrere ungewöhnliche Ereignisse zu identifizieren, die bei den Komponenten auftreten. Bei einem ungewöhnlichen Ereignis handelt es sich um ein Ereignis, das ein Netzwerkvorkommnis oder eine Netzwerkbedingung angibt, das bzw. die von einem normalen oder erwarteten Wert oder Ergebnis abweicht. Zum Beispiel kann ein Ereignis einen Attributwert aufweisen, der einen bestimmten Schwellenwert oder einen erforderlichen Wert über- oder unterschreitet, oder ein Ereignis kann angeben, dass eine Komponente vor einem angesetzten Zeitpunkt heruntergefahren ist oder einen Neustart durchgeführt hat. Zusätzlich kann es sich bei einem ungewöhnlichen Ereignis um ein Ereignis handeln, das ein Netzwerkproblem, wie beispielsweise den Ausfall einer Komponente, angibt.
Nach dem Identifizieren eines oder mehrerer ungewöhnlicher Ereignisse identifiziert der Fehlerursachenanalysator 109 eine oder mehrere Servicedomänen aus den Servicedomänen 108, die den ungewöhnlichen Ereignissen entsprechende Komponenten umfassen. Der Fehlerursachenanalysator 109 nutzt dann die identifizierte(n) Servicedomäne(n) als Hilfe in dem Prozess zur Fehlerursachenanalyse. Wenn zum Beispiel ein ungewöhnliches Ereignis, wie beispielsweise eine lange Antwortzeit, bei der Anwendung 102 aufgetreten ist, identifiziert der Fehlerursachenanalysator 109 aus den Servicedomänen 108 die Servicedomäne 1 115. Der Fehlerursachenanalysator 109 identifiziert dann in Beziehung stehende Komponenten in der Servicedomäne 1115 und ruft Ereignisse für diese Komponenten aus der Ereignisdatenbank 106 ab. Bei einer Implementierung identifiziert der Fehlerursachenanalysator 109 ein bei einer Komponente auf der niedrigsten Schicht auftretendes, ungewöhnliches Ereignis in der Servicedomäne 1115 und gibt dieses Ereignis als Fehlerursachenereignis 111 aus. Wenn zum Beispiel ein Ereignis mit einer hohen Prozessorlast bei dem Hypervisor aufgetreten ist, bei dem es sich um eine Komponente auf einer niedrigeren Schicht als die Anwendung 102 handelt, priorisiert der Fehlerursachenanalysator 109 das Ereignis mit der hohen Prozessorlast als Ursache und gibt dieses Ereignis als Fehlerursachenereignis 111 aus. Bei einer weiteren Implementierung kann der Fehlerursachenanalysator 109 eine Ereignissequenz bzw. ein Ereignismuster nutzen, die bzw. das in der Servicedomäne 1 115 angegeben wurde, um zu identifizieren, welche Komponente typischerweise die Reihe der zu einer Abweichung führenden Ereignisse beginnt. Wenn die Ereignissequenz typischerweise durch die Anwendung 102 eingeleitet wird, gibt der Fehlerursachenanalysator 109 ein Ereignis bei der Anwendung 102 als Fehlerursachenereignis 111 aus. Der Fehlerursachenanalysator 109 kann außerdem in Beziehung stehende Elemente 112, die bei anderen Komponenten in der Servicedomäne 1 115 auftreten, ausgeben; wie jedoch mittels der gestrichelten Linien in 1 angegeben ist, können die damit in Beziehung stehenden Ereignisse 112 verborgen oder unterdrückt sein, sodass ein Administrator nicht mit Alarmen oder Benachrichtigungen über ungewöhnliche Ereignisse oder andere mögliche Ursachen überhäuft wird. Im Allgemeinen unterdrückt der Fehlerursachenanalysator 109 mittels der Komponenten in der Servicedomäne 1 115 generierte Ereignisse, während ein Problem, das die ungewöhnlichen Ereignisse verursacht, nach wie vor auftritt. Der Fehlerursachenanalysator 109 oder ein weiterer Service des Netzwerkverwaltungssystems 110 kann Ereignisse mittels Filtern von Ereignissen unter Verwendung von Kennungen für die Komponenten in der Servicedomäne 1 115 und Verhindern, dass die gefilterten Ereignisse zur Anzeige gebracht werden, unterdrücken. Sobald das Problem gelöst ist und die Komponenten in der Servicedomäne 1 115 ordnungsgemäß funktionieren, nimmt der Fehlerursachenanalysator 109 die normale Generierung von Ereignisbenachrichtigungen wieder auf.
2 bildet Servicedomänen ab, die auf der Grundlage einer Ereigniskorrelation identifiziert wurden. 2 zeigt eine Servicedomäne 1 201 und eine Servicedomäne 2 202, die jeweils eine Untermenge von Komponenten umfassen, die in verschiedenen Schichten eines Netzwerks 203 ausgeführt werden. Die Komponenten in den Servicedomänen wurden möglicherweise auf der Grundlage einer Ereigniskorrelation über eine Sequenzmustersuche oder durch eine Kovarianzmatrix als in Beziehung stehend bestimmt. Die Komponenten stehen insofern in Beziehung, als sie zusammen funktionieren, um Sitzungen für einen IP-Telepräsenzservice vorzusehen: die Servicedomäne 1 201 umfasst eine Sitzung 1, und die Servicedomäne 2 202 umfasst eine Sitzung 2. Diese Sitzungen werden von anderen Komponenten in dem Netzwerk 203, wie beispielsweise IP-Multicast-Gruppen, IP-QoS-Klassen (Quality of Service, Dienstgüte) und L3-Netzwerkpfaden (Layer-3, Schicht 3), einem BGP (Border Gateway Protocol), MPLS-LSPs (Multiprotocol Label Switching Paths), einem VLAN (Virtual Local Area Network, virtuelles lokales Netzwerk) und einem Router, unterstützt.
Wenn die „Sitzung 1“ der Servicedomäne 1 201 ausfällt oder auf ein Problem trifft, kann die Fehlerursachenanalyse der Sitzung durch Begrenzen der Analyse auf die Komponenten in der Servicedomäne 1 201 vereinfacht werden. Zusätzlich können weitere Informationen über die Servicedomäne 1 201 zum Identifizieren einer Ursache genutzt werden. Bei einer Implementierung werden Ursachen auf der Grundlage einer Komponente der niedrigsten Schicht in der Servicedomäne 1 201, welche auf ein Problem stößt, abgeleitet. Wenn zum Beispiel die IP-Multicast-Gruppe „Gruppe 1“ auf ein Problem stößt und der Router auf ein Problem stößt, wird bestimmt, dass das Router-Problem die Ursache von Problemen der Servicedomäne 1 201 ist, da sich der Router auf einer niedrigeren Schicht befindet als die IP-Multicast-Gruppe. Die Schicht einer Komponente kann auf der Grundlage eines Komponententyps, einer zugewiesenen oder logischen OSI-Schicht usw. bestimmt werden. Zusätzlich kann eine Komponentenschicht relativ zu anderen Komponenten bestimmt werden. Zum Beispiel wird eine virtuelle Maschine als höhere Schicht als der Hypervisor angesehen, auf dem sie ausgeführt wird. Auf ähnliche Weise befindet sich ein Server, auf dem der Hypervisor ausgeführt wird, auf einer höheren Schicht als ein Router, den er zum Übertragen von Netzwerk-Datenverkehr verwendet.
Nach dem Bestimmen der Ursache können Alarme und Benachrichtigungen für weitere Komponenten in der Servicedomäne 1 201 unterdrückt, zum Beispiel einem Benutzer nicht angezeigt werden. Wenn ferner „Sitzung 2“ der Servicedomäne 2 202 ebenfalls auf Probleme stößt, können Alarme oder Benachrichtigungen für andere Komponenten in der Servicedomäne 2 202 ebenfalls unterdrückt werden, und letztendlich wird nur ein einzelnes Ereignis oder eine einzelne Benachrichtigung dargestellt, welches bzw. welche die Ursache identifiziert, wodurch das Überladen einer Schnittstelle der Netzwerkverwaltungssoftware mit Benachrichtigungen vermieden wird. Ereignisse für Komponenten der Servicedomänen können unterdrückt werden, bis das Problem gelöst ist, und dann können Ereignisbenachrichtigungen wieder wie in dem Normalbetrieb ausgegeben werden.
3 bildet Kovarianzmatrizen ab, die zum Identifizieren von Beziehungen zwischen Komponenten auf der Grundlage einer Ereigniskorrelation verwendet werden. 3 bildet einen Ereigniskorrelator 307, der eine Kovarianzmatrix 301 in einer Phase A erzeugt, und einen Satz von Kovarianzmatrizen 302 über mehrere Zeitspannen während einer Phase B ab. Die Spalten und Zeilen der Matrizen identifizieren Komponenten in einem Netzwerk, wie beispielsweise die in 2 abgebildeten Komponenten. Die Einträge in den Matrizen stehen für die Korrelation oder Kovarianz von Ereignissen zwischen den Komponenten. In der Wahrscheinlichkeitstheorie und -statistik stellt die Kovarianz ein Maß für die gemeinsame Veränderlichkeit zweier Zufallsvariablen dar. In dem Fall von 3 handelt es sich bei den Zufallsvariablen um Ereignisse, die bei den Komponenten auftreten. Die Kovarianzanalyse der Ereignisse generiert eine Zahl zwischen 0 und 1, welche die Wahrscheinlichkeit angibt, dass eine Korrelation zwischen den Ereignissen besteht, wobei 1 für eine hohe Wahrscheinlichkeit und 0 für eine niedrige Wahrscheinlichkeit steht. Es kann ein Schwellenwert eingestellt werden, um zu bestimmen, ob die Wahrscheinlichkeit der Korrelation hoch genug ist, um mit statistischer Sicherheit zu bestimmen, dass zwei Komponenten miteinander in Beziehung stehen und zu derselben Servicedomäne gehören. In 3 beträgt der Schwellenwert 85 %, und die Einträge in den Matrizen, die den Schwellenwert einhalten, sind fett und unterstrichen dargestellt. Wie zum Beispiel in der Matrix 301 zu sehen ist, besteht eine 90 %-Korrelation zwischen Ereignissen der Komponente „Sitzung 1“ und Ereignissen der Komponente „Gruppe 1“, sodass der Ereigniskorrelator 307 bestimmen kann, dass die Komponenten Teil ein und derselben Servicedomäne sind.
In Phase A generiert der Ereigniskorrelator 307 auf der Grundlage einer Ereigniskorrelation eine erste Matrix, die Matrix 301. Der Ereigniskorrelator 307 kann Ereignisse aus einem Ereignisprotokoll aus einer ersten oder jüngsten Zeitspanne verwenden, um die Matrix 301 zu generieren. Zum Beispiel kann der Ereigniskorrelator 307 Ereignisse verwenden, die in den letzten 10 Minuten generiert wurden, oder Ereignisse aus den ersten 30 Minuten des Betriebs der Komponenten. Da die Matrix 301 auf einer Korrelation aus lediglich einer einzelnen Zeitspanne basiert, wird die Matrix 301 als Hypothese behandelt und wird im Zuge des Empfangs und der Analyse zusätzlicher Ereignisse getestet/validiert.
Während der Phase B setzt der Ereigniskorrelator 307 das Sammeln und Analysieren von Ereignissen über mehrere Zeitspannen hinweg fort, um den Satz von Kovarianzmatrizen 302 zu generieren. Sowie zusätzliche Matrizen generiert und Korrelationen identifiziert werden, steigt die statistische Aussagekraft der Korrelationen, wodurch sich das Risiko eines Fehlers des Typs II verringert. Ein Fehler des Typs II betrifft das Unvermögen, eine falsche Hypothese zurückzuweisen; in diesem Fall ist eine Hypothese, dass es eine Korrelation zwischen Ereignissen zweier Komponenten gibt, wie in der Matrix 301 gezeigt. Die statistische Aussagekraft ist umgekehrt mit Beta korreliert, wobei es sich bei Beta um die Wahrscheinlichkeit eines Fehlers des Typs II handelt (Aussagekraft = 1 - β). Der Ereigniskorrelator 307 kann das Sammeln und Analysieren von Ereignissen über mehrere Zeitspannen hinweg fortsetzen, bis die Wahrscheinlichkeit eines Fehlers des Typs II unter einen Schwellenwert sinkt, oder, anders ausgedrückt, bis die statistische Aussagekraft einen Schwellenwert überschritten hat. Im Allgemeinen gibt die Konsistenz, mit der eine Korrelation über die mehreren Zeitspannen identifiziert wird, die statistische Sicherheit an, die der identifizierten Korrelation eingeräumt werden kann. Wenn zum Beispiel der Ereigniskorrelator über drei Zeitspannen hinweg drei Matrizen generiert und in allen dreien eine Korrelation vorhanden ist, die den Schwellenwert einhält, dann kann der Ereigniskorrelator 307 eine hohe statistische Sicherheit der Korrelation annehmen, und die Korrelation hat wahrscheinlich eine hohe statistische Aussagekraft. Nach dem Erreichen eines statistisch soliden Ergebnisses kann der Ereigniskorrelator 307 auf der Grundlage einer Aggregierung des Satzes von Kovarianzmatrizen 302 oder einer Liste von zugehörigen, anhand der Korrelation identifizierten Komponenten eine Matrix ausgeben.
4 bildet ein Beispiel für die Verwendung einer Ereignis-Sequenzmustersuche zum Durchführen einer Ereigniskorrelation und zum Identifizieren von Beziehungen zwischen Komponenten ab. 4 bildet einen Ereignisschlüssel 401, ein Ereignisprotokoll 402 und ein durch eine Mustersuche erkanntes Muster 403 ab, die mittels eines Ereigniskorrelators 407 generiert wurden. Der Ereignisschlüssel 401 identifiziert bekannte Entitäten oder Komponenten in einem System zusammen mit ihren Komponentenkennungen. Zusätzlich identifiziert der Ereignisschlüssel 401 Ereignistypen für diese Komponenten zusammen mit Ereigniskennungen. Das Ereignisprotokoll 402 zeigt eine Reihe von in einer Ereignisdatenbank 406 gespeicherten, anhand des zugehörigen Zeitstempels sortierten Ereignissen. Jede Ereignisangabe in dem Ereignisprotokoll 402 gibt eine Komponentenkennung für die entsprechende Komponente und eine Ereigniskennung für den Typ des aufgetretenen Ereignisses an. Zum Beispiel ist die erste Ereignisangabe in dem Ereignisprotokoll 402 bei einer Komponente mit der Kennung „1“ aufgetreten, bei der es sich, wie in dem Ereignisschlüssel 401 gezeigt, um die Komponente „Port“ handelt. Zusätzlich weist die erste Ereignisangabe eine Ereigniskennung „16“ auf, die dem Ereignistyp „Port ausgefallen“ entspricht.
Der Ereigniskorrelator 407 verwendet eine Sequenzmustersuche in der zeitbasierten Auflistung von Ereignissen 402, um die Muster (oder Ereignisepisoden) zu erkennen, die nacheinander in einem festen Zeitfenster auftreten. Dieser Ansatz erlaubt die Erkennung von Mustern, die wiederholt auftreten, mit einem hohen Index hinsichtlich der statistischen Sicherheit, wodurch das durch eine Mustersuche erkannte Muster als ursächlich und nicht als zufällig definiert wird. Der Ereigniskorrelator 407 kann die Mustersuche unter Verwendung von A-Priori-Algorithmen durchführen, um Sequenzen zu identifizieren. Wenn ein Ereignismuster oder eine Ereignisepisode innerhalb eines bestimmten Zeitrahmens mit einem hohen statistischen Sicherheitsindex für Kausalität (auf der Grundlage von Faktoren wie der Anzahl von Wiederholungen, probabilistischer Verteilung usw.) erkannt wird, dann handelt es sich bei dieser Episode um einen Satz von Ereignissen, die eines nach dem anderen auftreten und korreliert sind. Mit diesem Satz von Ereignissen verbundene Komponenten werden dann als Teil von ein und derselben Servicedomäne angegeben.
In 4 führt der Ereigniskorrelator 407 unter Verwendung eines Mustersuche-Algorithmus eine Mustersuche in dem Ereignisprotokoll 402 durch, um Muster bzw. Sequenzen von Ereignissen zu identifizieren. Bei dem Sequenzmustersuche-Algorithmus kann es sich um den Algorithmus PrefixSpan handeln. Als Ergebnis der Mustersuche in dem Ereignisprotokoll 402 wird das durch die Mustersuche erkannte Muster 403 identifiziert. Bei dem durch die Mustersuche erkannten Muster 403 handelt es sich um die längste Teilsequenz, die sich in dem Ereignisprotokoll 402 wiederholt. Das durch die Mustersuche erkannte Muster 403 kann weiter verarbeitet werden, um einen Index der statistischen Sicherheit für Kausalität zwischen den Ereignissen in dem durch die Mustersuche erkannten Muster 403 zu bestimmen. Wenn eine hohe statistische Sicherheit für eine Kausalität vorliegt, wird bestimmt, dass die Ereignisse und ihre entsprechenden Komponenten in Beziehung stehen und Teile von ein und derselben Servicedomäne sind. Auf ähnliche Weise wie bei den Kovarianzmatrizen kann der Ereigniskorrelator 407 die Sequenzmustersuche über mehrere Zeitspannen hinweg durchführen, um die statistische Aussagekraft der Korrelationen zu verbessern, bevor er eine Bestimmung durchführt, dass die Ereignisse in dem durch die Mustersuche erkannten Muster 403 und ihre entsprechenden Komponenten in Beziehung stehen. Das durch eine Mustersuche erkannte Muster 403 stellt nur ein beispielhaftes Muster für eine Servicedomäne dar. Eine Servicedomäne kann mehrere Ereignismuster bzw. -sequenzen umfassen, an denen eine oder mehrere derselben Komponenten und Ereignistypen beteiligt sind. Zum Beispiel kann eine Sequenz, anstatt mit dem Ereignis „Port ausgefallen“ zu beginnen, mit einem Dienstgüte-Verletzungsereignis beginnen, was bei den Multicast- und Videokonferenzkomponenten Ereignisse, wie beispielsweise lange Antwortzeiten, verursacht. Bei der Durchführung einer Fehlerursachenanalyse können in einer Servicedomäne generierte Ereignisse mit Ereignismustern verglichen werden, die mit der einen oder den mehreren Servicedomänen verbunden sind, um zu bestimmen, welches Muster gerade auftritt. Das identifizierte Muster wird dann verwendet, um eine Ursache eines Problems zu bestimmen.
5 bildet ein Ablaufdiagramm mit beispielhaften Operationen zum Durchführen einer ereignisbasierten Identifikation von Servicedomänen und einer Fehlerursachenanalyse ab. Die Operationen von 5 werden aus Gründen der Konsistenz mit 1 als mittels eines Netzwerkverwaltungssystems durchgeführt beschrieben, obwohl die Benennung eines Programmcodes zwischen Implementierungen unterschiedlich sein kann.
Ein Netzwerkverwaltungssystem („System“) ruft zur Analyse Ereignisse von einem Ereignisprotokoll ab (502). Das System kann eine Ereignisdatenbank abfragen, um Ereignisse abzurufen, oder es kann einen Ereignisverwaltungsservice abonnieren, der Stapel von Ereignissen an das System weiterleitet. Das System kann die Ereignisse in chronologischer Reihenfolge sortieren, nach Ereignissen eines bestimmten Typs filtern oder die Sammlung von Ereignissen zur Analyse vorbereiten.
Das System beginnt mittels der Ereignisse repräsentierte Operationen für mehrere Zeitspannen (504). Das System kann die Ereignisse für die Verarbeitung in Zeitspannen unterteilen oder aufteilen. Zum Beispiel kann das System die Ereignisse in Sammlungen von fünfminütigen Zeiträumen aufteilen. Alternativ kann das System bei einigen Implementierungen die Ereignisse in Sätze mit einer bestimmten Anzahl von Ereignissen unterteilen, zum Beispiel 100 Ereignisse pro Satz. Die aktuell verarbeitete Zeitspanne oder Sammlung von Ereignissen wird im Folgenden als „Ereignisse aus der ausgewählten Zeitspanne“ bezeichnet.
Das System identifiziert Korrelationen von Ereignissen für die ausgewählte Zeitspanne (506). Das System analysiert die Ereignisse und kann eine Kovarianzmatrix für in den Ereignissen repräsentierte Komponenten generieren oder eine Sequenzmustersuche für die Ereignisse durchführen. Das System kann Korrelationen auf der Grundlage der Ereignisse aus der ausgewählten Zeitspanne mit Korrelationen vergleichen/kombinieren, die auf der Grundlage von früheren Zeitspannen generiert wurden. Das System kann dann auf der Grundlage der über die verschiedenen Zeitspannen hinweg durchgeführten Analyse einen kumulativen Satz von Ereigniskorrelationen generieren.
Das System bestimmt, ob es Ereigniskorrelationen gibt, die einen statistischen Schwellenwert einhalten (508). Das System kann Werte vergleichen, die eine Wahrscheinlichkeit der statistischen Korrelationen bezüglich eines oder mehrerer Schwellenwerte darstellen, um zu bestimmen, ob irgendeine der Korrelationen eine zufriedenstellende statistische Aussagekraft oder Sicherheit aufweist. Zusätzlich kann das System, wie oben beschrieben, bestimmen, ob die Wahrscheinlichkeit eines Fehlers des Typs II für eine oder mehrere der Ereigniskorrelationen in ausreichendem Maße verringert wurde. Für Ereignissequenzen kann das System bestimmen, ob die Ereignissequenz eine dem Schwellenwert entsprechende Anzahl von Malen oder eine ausreichende Anzahl von Malen aufgetreten ist, um eine statistische Wahrscheinlichkeit zu erfüllen, dass es sich bei der Sequenz nicht um ein zufälliges Vorkommnis handelt und sie korrelierte Ereignisse repräsentiert.
Wenn keine Korrelationen den Schwellenwert einhalten, wartet das System auf eine zusätzliche Zeitspanne mit Ereignissen (510). Beim Analysieren von Ereignissen aus einem Protokoll kann das System eine Sammlung von Ereignissen aus einer nächsten Zeitspanne auswählen. Alternativ wartet das System, bis eine nachfolgende Zeitspanne abgelaufen ist, und ruft Ereignisse für diese Zeitspanne ab oder wartet, bis ein weiterer Stapel von Ereignissen von einem Ereignisverwaltungssystem empfangen wird. Das System setzt dann die Operationen bei Block 504 fort.
Wenn Korrelationen vorliegen, die den Schwellenwert einhalten, generiert das System auf der Grundlage von den Schwellenwert einhaltenden Korrelationen Servicedomänen (512). Das System identifiziert den Ereigniskorrelationen entsprechende Komponenten und generiert eine Servicedomäne, welche die Komponenten umfasst. Bei der Servicedomäne kann es sich um eine Topologie, eine Diagrammdatenstruktur oder eine Auflistung handeln, welche die Komponenten als zu ein und derselben Servicedomäne gehörend identifiziert. Das System kann Informationen in der Datenstruktur der Servicedomäne umfassen, wie beispielsweise identifizierte Ereignissequenzen, mit jeder von den Komponenten verbundene Service- oder Netzwerkschichten, die statistische Stärke von Ereigniskorrelationen usw. Nachdem es wenigstens eine erste Servicedomäne auf der Grundlage der Ereigniskorrelationen generiert hat, ist das System so weit vorbereitet, dass es unter Nutzung der generierten Servicedomäne eine mittels der Operationen bei den Blöcken 514, 516, 518 und 520 dargestellte Fehlerursachenanalyse beginnen kann. Das System setzt außerdem das Verfeinern und Validieren der Ereigniskorrelationen und der generierten Servicedomänen fort. Zum Beispiel kann das System auf der Grundlage einer zusätzlichen Ereigniskorrelation Komponenten hinzufügen oder entfernen. Als Ergebnis kehrt das System außerdem zu Block 510 zurück, um die Durchführung der Ereigniskorrelation parallel zu den Operationen der Fehlerursachenanalyse fortzusetzen.
Das System erkennt ein Vorkommen eines ungewöhnlichen Ereignisses (514). Block 514 ist mit einer gestrichelten Umrandung abgebildet, um darzustellen, dass das System eine ständige Überwachung auf das Vorkommen von ungewöhnlichen Ereignissen als Hintergrundoperation durchführt und dass die Operationen der Blöcke 516, 518 und 520 jedes Mal nach dem Erkennen eines ungewöhnlichen Ereignisses ausgelöst werden können. Das System kann ein ungewöhnliches Ereignis durch Identifizieren eines Ereignisses, das angibt, dass ein Komponentenproblem oder -ausfall aufgetreten ist, oder durch Vergleichen von Metriken in einem Ereignis mit vorher festgelegten Leistungsschwellenwerten erkennen.
Das System wählt wenigstens eine erste, mit dem ungewöhnlichen Ereignis in Beziehung stehende Domäne aus (516). Das System bestimmt die dem Ereignis entsprechende Komponente auf der Grundlage einer Komponentenkennung oder eines anderen Indikators in dem mit der Komponente verbundenen Ereignis. Das System durchsucht dann die generierten Servicedomänen mit der Komponentenkennung, um eine oder mehrere Servicedomänen abzurufen, welche die Komponente umfassen. Das System wählt wenigstens eine erste Servicedomäne zum Durchführen einer Fehlerursachenanalyse aus, es kann aber auch parallel eine Fehlerursachenanalyse für alle betroffenen Servicedomänen durchführen, da die Servicedomänen wahrscheinlich alle dieselbe Ursache wahrnehmen, da die Servicedomänen die ungewöhnliche Komponente gemeinsam verwenden.
Das System ruft Ereignisse ab, die in Beziehung zu Komponenten in der Servicedomäne stehen (518). Das System identifiziert alle Komponenten in der Servicedomäne und fragt dann eine Ereignisdatenbank ab, um kürzlich aufgetretene Ereignisse für die Komponenten abzurufen. Das System kann die Abfrage so strukturieren, dass nur ungewöhnliche Ereignisse für die Komponenten abgerufen werden.
Das System identifiziert eine Ursache des ungewöhnlichen Ereignisses auf der Grundlage der Ereignisse innerhalb der Servicedomäne (520). Bei einer Implementierung kann das System eine Fehlerursachenanalyse durch Identifizieren einer Komponente der niedrigsten Schicht in der Servicedomäne, die ein ungewöhnliches Ereignis wahrnimmt, durchführen und diese Komponente als Ursache identifizieren. Bei einer weiteren Implementierung kann das System eine in der Servicedomäne angegebene Ereignissequenz analysieren, um das früheste Ereignis in der Sequenz zu identifizieren, das mit einem Ereignis von einer der Komponenten übereinstimmt. Wenn die Sequenz zum Beispiel mit einem Ereignis des Typs 3 bei einer Komponente A beginnt, bestimmt das System, ob ein Ereignis des Typs 3 kürzlich bei der Komponente A aufgetreten ist. Das System kann den Vorgang durch die Sequenz hindurch fortsetzen, um zu bestimmen, ob es für jedes Ereignis in der Sequenz ein übereinstimmendes Ereignis gibt. Wenn eine übereinstimmende Sequenz von Ereignissen vorhanden ist, bestimmt das System, dass das Ereignis bei der dem ersten Ereignis in der Sequenz entsprechenden Komponente die Ursache ist. Das System gibt das als Ergebnis der Analyse identifizierte Fehlerursachenereignis aus und unterdrückt weitere Alarme oder Ereignisse für die Servicedomäne. Das System kann außerdem automatisierte Abhilfeaktionen zum Beheben des Problems durchführen. Wenn zum Beispiel das Fehlerursachenereignis ein Router-Problem war, kann das System den Router aus der Ferne neu starten oder ein Skript zum Zurücksetzen eines Ports an dem Router aufrufen. Nach dem Identifizieren der Ursache kehrt das System zu Block 514 zurück, bis ein weiteres ungewöhnliches Ereignis erkannt wird.
Varianten
1 und 3 sind mit einer Reihe von Anmerkungsbuchstaben versehen. Diese Buchstaben stehen für Phasen von Operationen. Obwohl diese Phasen für dieses Beispiel geordnet sind, veranschaulichen die Phasen ein Beispiel, um das Verständnis dieser Offenbarung zu unterstützen, und sie sollten nicht zur Einschränkung der Patentansprüche verwendet werden. Der in den Schutzumfang der Patentansprüche fallende Gegenstand kann im Hinblick auf die Reihenfolge und einige der Operationen abweichen.
Die Ablaufdiagramme sind vorgesehen, um das Verständnis der Veranschaulichungen zu unterstützen, und sollen nicht zur Einschränkung des Schutzumfangs der Patentansprüche verwendet werden. Die Ablaufdiagramme bilden beispielhafte Operationen ab, die innerhalb des Schutzumfangs der Patentansprüche abweichen können. Es können zusätzliche Operationen durchgeführt werden; es können weniger Operationen durchgeführt werden; die Operationen können parallel durchgeführt werden; und die Operationen können in einer anderen Reihenfolge durchgeführt werden. Zum Beispiel können die in den Blöcken 506 und 520 von 5 abgebildeten Operationen parallel oder gleichzeitig durchgeführt werden. Außerdem ist die Iteration über mehrere Zeitspannen möglicherweise nicht notwendig, wenn in einer einzigen Iteration statistisch solide Korrelationen identifiziert werden können. Es versteht sich, dass jeder Block der Ablaufdiagramm-Veranschaulichungen und/oder der Blockdiagramme und Kombinationen von Blöcken in den Ablaufdiagramm-Illustrationen und/oder den Blockdiagrammen mittels Programmcode implementiert werden kann. Der Programmcode kann einem Prozessor eines Allzweckcomputers, eines Spezialcomputers oder einer anderen programmierbaren Maschine oder Vorrichtung bereitgestellt werden.
Es versteht sich, dass Erscheinungsformen der Offenbarung als System, Verfahren oder Programmcode/-anweisungen in einem oder mehreren maschinenlesbaren Medien verwirklicht werden können. Demgemäß können Erscheinungsformen als Hardware, Software (einschließlich Firmware, speicherresidenter Software, Mikrocode usw.) oder als Kombination von Software- und Hardware-Erscheinungsformen, die in dem vorliegenden Dokument ganz allgemein als „Schaltung“, „Modul“ oder „System“ bezeichnet werden kann, vorliegen. Die in den beispielhaften Veranschaulichungen als einzelne Module/Einheiten dargestellte Funktionalität kann gemäß einem beliebigen von den Elementen Plattform (Betriebssystem und/oder Hardware), Anwendungs-Okosystem, Schnittstellen, Vorlieben des Programmierers, Programmiersprache, Vorlieben des Administrators usw. anders organisiert sein.
Es kann eine beliebige Kombination aus einem oder mehreren maschinenlesbaren Medien genutzt werden. Bei dem maschinenlesbaren Medium kann es sich um ein maschinenlesbares Signalmedium oder um ein maschinenlesbares Speichermedium handeln. Bei einem maschinenlesbaren Speichermedium kann es sich zum Beispiel um ein System, eine Vorrichtung oder eine Einrichtung handeln, das bzw. die zum Speichern von Programmcode eine beliebige von elektronischer, magnetischer, optischer, elektromagnetischer, Infrarot- oder Halbleitertechnologie verwendet, ist aber nicht darauf beschränkt. Spezifischere Beispiele (Liste nicht vollständig) des maschinenlesbaren Speichermediums würden Folgendes umfassen: eine tragbare Computerdiskette, eine Festplatte, ein RAM (Random Access Memory, Speicher mit wahlfreiem Zugriff), ein ROM (Read-Only Memory, Festwertspeicher), einen löschbaren, programmierbaren Festwertspeicher (EPROM (Erasable Programmable Read-Only Memory) oder Flash Memory), einen tragbaren CD-ROM-Speicher (Compact Disc Read-Only Memory, kompakter Platten-Festwertspeicher), eine optische Speichereinrichtung, eine magnetische Speichereinrichtung oder eine beliebige, geeignete Kombination der Vorgenannten. In dem Kontext dieses Dokuments kann es sich bei einem maschinenlesbaren Speichermedium um jedes materielle Medium handeln, das ein Programm zur Verwendung durch oder in Verbindung mit einem Anweisungsausführungssystem, einer entsprechenden Vorrichtung oder Einrichtung enthalten oder speichern kann. Bei einem maschinenlesbaren Speichermedium handelt es sich nicht um ein maschinenlesbares Signalmedium.
Ein maschinenlesbares Signalmedium kann ein weiterverbreitetes Datensignal mit einem darin verwirklichten, maschinenlesbaren Programmcode, zum Beispiel in dem Basisband oder als Teil einer Trägerwelle, umfassen. Ein solches weiterverbreitetes Signal kann eine beliebige einer Vielfalt von Formen annehmen, einschließlich, aber nicht beschränkt auf eine elektromagnetische oder optische Form oder eine beliebige geeignete Kombination daraus. Bei einem maschinenlesbaren Signalmedium kann es sich um ein beliebiges maschinenlesbares Medium handeln, das kein maschinenlesbares Speichermedium ist und das ein Programm zur Verwendung durch oder in Verbindung mit einem Anweisungsausführungssystem, einer entsprechenden Vorrichtung oder Einrichtung kommunizieren, weiterverbreiten oder transportieren kann.
Ein in einem maschinenlesbaren Signalmedium verwirklichter Programmcode kann unter Verwendung eines beliebigen geeigneten Mediums, einschließlich, aber nicht beschränkt auf drahtlose, drahtgebundene, Glasfaserkabel-, Funkfrequenzmedien usw. oder eine beliebige geeignete Kombination der Vorgenannten übertragen werden.
Computerprogrammcode zum Ausführen von Operationen für Erscheinungsformen der Offenbarung kann in einer beliebigen Kombination aus einer oder mehrerer Programmiersprachen geschrieben sein, einschließlich einer objektorientierten Programmiersprache, wie beispielsweise Java®, C++ oder dergleichen; in einer dynamischen Programmiersprache, wie beispielsweise Python; in einer Skript-Sprache, wie beispielsweise der Programmiersprache Perl oder der Skript-Sprache PowerShell; und in herkömmlichen, prozeduralen Programmiersprachen, wie beispielsweise der Programmiersprache „C“ oder ähnlichen Programmiersprachen. Der Programmcode kann vollständig auf einer eigenständigen Maschine ausgeführt werden, er kann über mehrere Maschinen auf verteilte Weise ausgeführt werden und er kann auf einer Maschine ausgeführt werden, während er auf einer anderen Maschine Ergebnisse bereitstellt oder Eingaben annimmt.
Der Programmcode bzw. die Programmanweisungen können auch in einem maschinenlesbaren Medium gespeichert sein, das eine Maschine so steuern kann, dass sie auf eine bestimmte Weise funktioniert, sodass die auf dem maschinenlesbaren Medium gespeicherten Anweisungen ein Erzeugnis herstellen, einschließlich Anweisungen, welche die Funktion/den Vorgang, die bzw. der in dem Block bzw. den Blöcken des Ablaufdiagramms und/oder des Blockdiagramms angegeben sind, implementieren.
6 bildet ein beispielhaftes Computersystem mit einer Servicedomänenkennung und einem Fehlerursachenanalysator ab. Das Computersystem umfasst eine Prozessoreinheit 601 (möglicherweise mit mehreren Prozessoren, mehreren Kernen, mehreren Knoten und/oder mit Implementierung von Multi-Threading usw.). Das Computersystem umfasst den Speicher 607. Bei dem Speicher 607 kann es sich um einen Systemspeicher handeln (zum Beispiel eines oder mehrere von einem Cache, SRAM, DRAM, Z-RAM (Zero Capacitor RAM, RAM ohne Kondensator), TTRAM (Twin Transistor RAM, Doppeltransistor-RAM), eDRAM, EDO-RAM, DDR-RAM, EEPROM, NRAM, RRAM, SONOS, PRAM usw.) oder um eine beliebige oder mehrere der oben bereits beschriebenen Verwirklichungen von maschinenlesbaren Medien. Das Computersystem umfasst außerdem einen Bus 603 (zum Beispiel PCI, ISA, PCI-Express, HyperTransport®-Bus, InfiniBand®-Bus, NuBus usw.) sowie eine Netzwerkschnittstelle 605 (zum Beispiel eine Fiber-Channel-Schnittstelle, eine Ethernet-Schnittstelle, eine SCSI-Internet-Schnittstelle (Small Computer System Interface), eine SONET-Schnittstelle, eine drahtlose Schnittstelle usw.). Das System umfasst außerdem eine Einheit aus Servicedomänenkennung und Fehlerursachenanalysator 611. Die Einheit aus Servicedomänenkennung und Fehlerursachenanalysator 611 führt eine ereignisbasierte Identifikation von Servicedomänen durch und nutzt bei der Durchführung von Fehlerursachenanalysen das in den Servicedomänen enthaltene Wissen. Beliebige der zuvor beschriebenen Funktionalitäten können teilweise (oder vollständig) in Hardware und/oder in der Prozessoreinheit 601 implementiert sein. Zum Beispiel kann die Funktionalität mit einer anwendungsspezifischen integrierten Schaltung, in einer in der Prozessoreinheit 601 implementierten Logik, in einem Co-Prozessor auf einer Peripherieeinrichtung oder -karte usw. implementiert sein. Ferner können Verwirklichungen weniger oder zusätzliche, in 6 nicht veranschaulichte Komponenten (zum Beispiel Videokarten, Audiokarten, zusätzliche Netzwerkschnittstellen, Peripherieeinrichtungen usw.) umfassen. Die Prozessoreinheit 601 und die Netzwerkschnittstelle 605 sind mit dem Bus 603 gekoppelt. Obwohl der Speicher 607 so veranschaulicht ist, dass er mit dem Bus 603 gekoppelt ist, kann er auch mit der Prozessoreinheit 601 gekoppelt sein.
Während die Erscheinungsformen der Offenbarung unter Bezugnahme auf verschiedene Implementierungen und Nutzungen beschrieben werden, versteht es sich, dass diese Erscheinungsformen veranschaulichend sind und dass der Schutzumfang der Patentansprüche nicht auf sie beschränkt ist. Im Allgemeinen können Techniken zur ereignisbasierten Identifikation von Servicedomänen und eine Fehlerursachenanalyse, wie in dem vorliegenden Dokument beschrieben, mit Einrichtungen implementiert werden, die mit einem beliebigen Hardware-System oder mit beliebigen Hardware-Systemen konsistent sind. Viele Varianten, Modifikationen, Ergänzungen und Verbesserungen sind möglich.
Für Komponenten, Operationen oder Strukturen, die in dem vorliegenden Dokument als einzelne Instanz beschrieben sind, können mehrere Instanzen vorgesehen werden. Schließlich sind Grenzen zwischen verschiedenen Komponenten, Operationen und Datenspeichern etwas willkürlich, und bestimmte Operationen sind in dem Kontext spezifischer, veranschaulichender Konfigurationen veranschaulicht. Andere Zuteilungen von Funktionalität sind vorstellbar und können unter den Schutzumfang der Offenbarung fallen. Im Allgemeinen können Strukturen und Funktionalität, die in den beispielhaften Konfigurationen als gesonderte Komponenten dargestellt sind, als kombinierte Struktur oder Komponente implementiert werden. Auf ähnliche Weise können Strukturen und Funktionalität, die als eine einzige Komponente dargestellt sind, als gesonderte Komponenten implementiert werden. Diese und weitere Variationen, Modifikationen, Ergänzungen und Verbesserungen können unter den Schutzumfang der Offenbarung fallen.
Die Verwendung der Formulierung „wenigstens einer/eine/eines von“ vor einer Liste mit der Konjunktion „und“ ist nicht im Sinne einer ausschließlichen Liste gedacht und sollte nicht als Liste von Kategorien mit einem Element aus jeder Kategorie ausgelegt werden, es sei denn, es ist spezifisch etwas anderes angegeben. Eine Klausel, in der „wenigstens einer/eine/eines von A, B und C“ genannt ist, kann mit nur einem der aufgeführten Elemente, mehreren der aufgeführten Elemente und einem oder mehreren der Elemente in der Liste plus einem nicht aufgeführten Element verletzt werden.

Claims

Verfahren, das Folgendes umfasst: Korrelieren von in einem Netzwerk generierten Ereignissen, um Komponenten einer Servicedomäne zu identifizieren; Abrufen, auf der Grundlage des Erkennens eines ersten Ereignisses, das ein Problem bei einer ersten Komponente in der Servicedomäne angibt, eines ersten Satzes von Ereignisbenachrichtigungen, die Ereignisse angeben, die bei den Komponenten innerhalb der Servicedomäne auftreten; Identifizieren einer Ursache des Problems bei der ersten Komponente wenigstens teilweise auf der Grundlage der in der Servicedomäne angegebenen Komponenten und des ersten Satzes von Ereignisbenachrichtigungen; und Unterdrücken der Generierung von Ereignisbenachrichtigungen für die Komponenten in der Servicedomäne.
Verfahren nach Anspruch 1, wobei das Identifizieren der Ursache des ersten Ereignisses wenigstens teilweise auf der Grundlage der in der Servicedomäne angegebenen Komponenten und des ersten Satzes von Ereignisbenachrichtigungen Folgendes umfasst: Identifizieren von ungewöhnlichen Ereignissen in dem ersten Satz von Ereignisbenachrichtigungen; Identifizieren einer Komponente auf der niedrigsten Schicht der Servicedomäne, die ein zweites Ereignis der identifizierten, ungewöhnlichen Ereignisse erfahren hat; und Angeben des zweiten Ereignisses als Ursache des Problems bei der ersten Komponente.
Verfahren nach Anspruch 2, das ferner Folgendes umfasst: Identifizieren von Komponententypen der Komponenten in der Servicedomäne; und Zuweisen der Komponenten zu Schichten wenigstens teilweise auf der Grundlage der Komponententypen der Komponenten in der Servicedomäne.
Verfahren nach Anspruch 1, wobei das Identifizieren der Ursache des ersten Ereignisses wenigstens teilweise auf der Grundlage der in der Servicedomäne angegebenen Komponenten und des ersten Satzes von Ereignisbenachrichtigungen Folgendes umfasst: Identifizieren eines der Reihe nach ersten Ereignisses, das in einer mit der Servicedomäne verbundenen Ereignissequenz angegeben ist; Identifizieren eines zweiten Ereignisses in dem ersten Satz von Ereignisbenachrichtigungen, das mit dem in der Ereignissequenz angegebenen, der Reihe nach ersten Ereignis übereinstimmt; und Angeben des zweiten Ereignisses als Ursache des Problems bei der ersten Komponente.
Verfahren nach Anspruch 1, wobei das Korrelieren der in dem Netzwerk generierten Ereignisse zum Identifizieren von Komponenten der Servicedomäne Folgendes umfasst: Identifizieren einer wiederholten Ereignissequenz in den in dem Netzwerk generierten Ereignissen; und Angeben von der Ereignissequenz entsprechenden Komponenten als den Komponenten der Servicedomäne.
Verfahren nach Anspruch 1, wobei das Korrelieren der in dem Netzwerk generierten Ereignisse zum Identifizieren von Komponenten der Servicedomäne Folgendes umfasst: Generieren einer ersten Kovarianzmatrix mit Einträgen, die eine Kovarianz von Ereignissen zwischen Komponenten in dem Netzwerk angeben; Identifizieren der Einträge in der ersten Kovarianzmatrix, die einen Schwellenwert überschreiten; und Angeben von den Einträgen in der ersten Kovarianzmatrix entsprechenden Komponenten, die den Schwellenwert überschreiten, als den Komponenten der Servicedomäne.
Verfahren nach Anspruch 6, das ferner Folgendes umfasst: Generieren eines Satzes von Kovarianzmatrizen über mehrere Betriebszeiträume der Komponenten in dem Netzwerk hinweg; und Validieren der Einträge in der ersten Kovarianzmatrix, welche den Schwellenwert überschreiten, wenigstens teilweise auf der Grundlage von Einträgen in dem über die mehreren Betriebszeiträume generierten Satz von Kovarianzmatrizen.
Verfahren nach Anspruch 1, das ferner, nach dem Bestimmen, dass das Problem bei der ersten Komponente gelöst wurde, das Wiederaufnehmen des Generierens von Ereignisbenachrichtigungen für die Komponenten in der Servicedomäne umfasst.
Ein oder mehrere nichtflüchtige, maschinenlesbare Medien, die Programmcode umfassen, wobei der Programmcode zu Folgendem dient: Identifizieren eines ersten Ereignismusters in einem Ereignisprotokoll, das von Einrichtungen in einem Netzwerk generierte Ereignisse umfasst; Bestimmen einer ersten Servicedomäne wenigstens teilweise auf der Grundlage von Einrichtungen, die Ereignissen in dem ersten Ereignismuster entsprechen; Bestimmen, auf der Grundlage des Erkennens eines Problems bei einer ersten Einrichtung in der ersten Servicedomäne, ob ein von der ersten Einrichtung generiertes Ereignis mit einem Ereignis in dem ersten Muster übereinstimmt; und Angeben, auf der Grundlage des Bestimmens, dass ein mittels der ersten Einrichtung generiertes Ereignis einem Ereignis in dem ersten Ereignismuster entspricht, einer zweiten Einrichtung in der ersten Servicedomäne als Ursache des Problems bei der ersten Einrichtung, wobei die zweite Einrichtung einem ersten Ereignis in dem ersten Ereignismuster entspricht.
Vorrichtung, die Folgendes umfasst: einen Prozessor; und ein maschinenlesbares Medium mit mittels des Prozessors ausführbarem Programmcode, um die Vorrichtung zu veranlassen, in einem Netzwerk generierte Ereignisse zu korrelieren, um Komponenten einer oder mehrerer Servicedomänen zu identifizieren; ein erstes Ereignis zu erkennen, das ein Problem bei einer ersten Komponente in dem Netzwerk angibt; wenigstens eine erste Servicedomäne von der einen oder den mehreren Servicedomänen zu identifizieren, welche die erste Komponente umfasst; und eine Ursache des Problems bei der ersten Komponente wenigstens teilweise auf der Grundlage der in der ersten Servicedomäne angegebenen Komponenten zu identifizieren.