-
Gebiet der
Erfindung
-
Die
vorliegende Erfindung bezieht sich allgemein auf eine Netzwerkverwaltung
und insbesondere auf ein Datenschema und ein Verfahren zum Speichern
von Netzwerkverwaltungssystem-Ereignisdaten,
um eine effiziente Wiedergewinnung von Informationen und einer Ansammlung
zur Verwendung beim Verfolgen von Trends und Erzeugen nützlicher
Berichte zu ermöglichen.
-
Hintergrund
der Erfindung
-
Bekannte
Netzwerkverwaltungssysteme sammelten Netzwerksystem-Ereignisinformationen
in einer ASCII-Textdatei, üblicherweise
in einem Serieller-Datenstrom-Format.
-
Netzwerksystemverwalter
benötigen
häufig
Statistiken und Berichte basierend auf gesammelten Systemereignissen,
um dieselben über
Systemtrends zu warnen, um proaktiv eine normale Systemverwendung beizubehalten.
Allgemein ausgedrückt
werden diese Informationen aus der Seriell-ASCII-Text-Ereignisdatei hergeleitet, durch
eine externe Statistikprozess-Steuerung (SPC; SPC = statistical
process control) und Trendverfolgungsanwendungen, die hierin kollektiv
als Berichterzeugungsanwendungen bezeichnet werden, die Informationen
aus der Ereignisdatei ansammeln, manipulieren und formatieren, um
benutzerlesbare Berichte zu erzeugen. In der Vergangenheit musste
jedoch jede Berichterzeugungsanwendung das systemspezifische Format
der Inhalte der Ereignisdatei kennen, um die erforderlichen Informationen
herzuleiten, um Berichte zu erzeugen. Dementsprechend musste eine
Berichterzeugungsanwendung das systemspezifische Format von Ereignisdaten
kennen, die in der Ereignisdatei gespeichert sind, entweder durch
separates Kompi lieren der Anwendung mit einem systemspezifischen
Ereignisdateiformat oder durch Zuführen von Ereignisformatinformationen
zu demselben zur Einrichtungszeit oder Laufzeit. Somit, um eine
solche Anwendung zu verwenden, musste der Anwendungsentwickler eine
Einrichtung zum Unterstützen
des Ereignisdateiformats bereitstellen. Dementsprechend besteht
ein Bedarf in der Industrie nach einem formalen, standardisierten
Datenschema, einem Verfahren zum Besetzen desselben und einer Möglichkeit
zum einfachen Extrahieren von Informationen, aus denen verschiedene
Berichte erzeugt werden.
-
Zusätzlich dazu,
aufgrund der Breite von unterschiedlichen Kategorien von Systemereignissen,
umfassten nicht alle Systeme die selbe Menge an Informationen. Bei
einigen bekannten Implementierungen wurde dieses Problem behandelt
durch Zuordnen eines Standardgrößen-Systemereignispakets
für jede
Art von Systemereignis und Erlauben, dass die Felddefinitionen innerhalb
des Pakets für
jeden Ereignistyp variieren, um die unterschiedlichen Berichtinformationen
für unterschiedliche
Typen von Systemereignissen zu berücksichtigen. Während diese
Technik einen Spielraum bei der Art von Informationen schafft, die
bei unterschiedlichen Arten von Systemereignissen berichtet werden,
erfordert sie, dass die Standardgröße eines Systemereignispakets
groß genug
ist, um ein Systemereignis des Typs zu speichern, der Systemereignisinformationen größter Länge aufweist,
und führt
somit zu einer bedeutenden Speicherineffizienz aufgrund von zugeordneten aber
nicht verwendeten Bytes bei Ereignispaketen für jene Systemereignisse, die
nicht die gesamte Größe des Standardgrößen-Systemereignispakets
erfordern. Dementsprechend besteht ein Bedarf nach einem Verfahren
und einem Datenschema zum Speichern von Systemereignissen, dynamisch,
gemäß der Menge
an erforderlichem Speicherungsraum.
-
Ein
Verfahren zum Überwinden
dieses Problems ist durch Definieren eines Standardgrößen-Systemereignispakets,
das nur jene Felder umfasst, die allen Ereignissen gemeinsam sind,
und das Verknüpfen desselben
mit einem variablen Verbindungspaket, das in der Größe gemäß dem Systemereignistyp
variieren kann. Diese Technik ermöglicht, dass die Anzahl und
Definitionen der Ereignisfelder zwischen unterschiedlichen Systemereignistypen
variiert, und stellt eine maximale Speichereffizienz sicher. Daten
jedoch, die zum Erzeugen nützlicher
Berichte über
die Systemereignisse erforderlich sind, sind nichts desto trotz
schwierig zu extrahieren. Berichterzeugende Anwendungen organisieren
Ereignisinformationen gemäß einer
oder einigen Kategorien gleichzeitig und summieren dann Informationen
um diese Kategorien herum, auf eine Weise, die für den Systemadministrator nützlich ist.
Beim Erzeugen eines Berichts verwendet die Anwendung üblicherweise
in nur einem geringen Teilsatz des gesamten detaillierten Systems
Ereignisdaten für
jedes Ereignis. Bei den bekannten Ereignisspeicherungstechniken,
die oben beschrieben sind, erfordert die Extrahierung des relevanten
Felderteilsatzes aus dem vollständigen
detaillierten Satz aus Ereignisfeldern eine separate Abfrage an
der Datenbank nach jedem erforderlichen Ereignisfeld für jedes
Ereignis. Wenn große
Mengen an Ereignisdaten verarbeitet werden und/oder wenn die Anwendung
mehr als einige wenige Ereignisfelder für jedes Ereignis erfordert,
wird das große
Volumen von Abfragen an der Datenbank zu einer Belastung des Verhaltens in
Bezug auf das System. Dementsprechend besteht ein Bedarf nach einem
Verfahren zum Speichern von Ereignisdaten auf eine Weise, die ermöglicht,
dass relevante Informationen für
Berichterzeugungsanwendungen ohne weiteres extrahierbar sind.
-
Das
US-A-Patent 5,049,873 beschreibt einen Kommunikationsnetzwerk-Zustand-und-Topologie-Überwacher,
der eine Ereignisprotokollanwendung umfasst, die eine Liste von
Ereignisaufzeichnungen beibehält,
die in ein Knotenereignisprotokoll in dem Netzwerk eingegeben werden,
und ein Protokoll mit einer Mehrzahl von verteilten Schaltknoten
unterstützt.
Jeder der Mehrzahl von verteilten Schaltknoten betreibt eine Anwendung,
gekoppelt mit dem Knotenereignisprotokoll an dem Knoten und spricht
auf das Protokoll mit der Ereig nisprotokollanwendung an, und verpackt
und sendet Daten, die Ereignisberichte anzeigen, die in das Knotenereignisprotokoll
eingegeben werden, zu der Ereignisprotokollanwendung. Um auf Informationen
zur Erzeugung eines gewünschten
Berichts zuzugreifen, schafft die US-A-5,049,873 eine Ereignisprotokollschnittstelle,
genannt eine angebrachte Prozessor-Ausführeinrichtung, die angepasst
ist, um Informationen von dem Ereignisprotokoll vorab zu verarbeiten
und zu packen, vor dem Senden angeforderter Informationen zu einem Überwacherknoten
ansprechend auf Anforderungen von dem Überwacherknoten. Somit werden
die Ereignisdaten nicht in Formaten gespeichert, wie z. B. berichtfertigen
Tabellen, die ohne weiteres durch andere Anwendungen zugreifbar
sind.
-
Die
WO 98/00784 beschreibt ein System und ein Verfahren zum Berichten
von Zuständen
von Telekommunikationsdiensten, an denen sich ein Kunde beteiligt.
Das System verwendet einen Server zum Sammeln fehlerhafter Informationen
aus dem Telekommunikationsnetzwerk-Verwaltungssystem in eine Datenbank und
eine Kundenarbeitsstation zum Betrachten der Informationen. Die
Datenbank organisiert Ereignisinformationen in der Datenbank in
Ansichten. Zum Beispiel liefert eine Alarmansicht eine Alarmbeschreibung,
eine Alarmernsthaftigkeit und ausgewählte Zustände, die dem Alarm zugeordnet
sind. Der Kunde verwendet die Arbeitsstation zum Definieren einer
Ereignisansicht der Daten, die er empfangen möchte. Der Server empfängt die
angeforderten Ansichten und baut Berichte unter Verwendung der Ansichten
auf, und liefert die Berichte zu dem Kunden. Das System benötigt einen
Server zum Zugreifen auf jede der angeforderten Ansichten, um den
Bericht aufzubauen. Somit sind die Daten nicht berichtfertig.
-
Zusammenfassung
der Erfindung
-
Ein
Datenschema und ein Verfahren zum Speichern von Netzwerkverwaltungssystem-Ereignisdaten, um
eine effiziente Wiedergewinnung von Informationen und Ansammlung
zur Verwendung beim Verfolgen von Systemtrends und Erzeugen nützlicher
Berichte zu ermöglichen,
wird präsentiert.
Die Erfindung schafft ein standardisiertes Systemereignisformat,
das im Allgemeinen für
den Benutzer durch Standardschnittstellen verfügbar ist, zusammen mit einem
Verfahren zum Besetzen desselben. Die Daten sind ohne weiteres zugreifbar über Standardschnittstellen
für Statistikprozess-Steuerungs-, Trendverfolgungs-
und Berichterzeugungs-Anwendungen,
die Informationen von Interesse darstellen, die sich auf die Ereignisse
auf nützliche
Weise beziehen, um dadurch deren Wert zu erhöhen.
-
Gemäß der Erfindung
empfängt
ein Exportverwalter Systemereignisse, die eine Mehrzahl von Ereignisfeldern
umfassen. Der Exportverwalter formatiert einen ersten Satz der Ereignisfelder
in eine berichtfertige Tabelle, die alle verfügbaren Ereignisfelder umfasst,
die wesentlich für
eine Erzeugung eines bestimmten Berichts sind. Die berichtfertige
Tabelle wird gesendet, über
eine standardisierte Kommunikationsschnittstelle, zu einem Datenlager,
wo sie gespeichert wird und über
eine Standardkommunikationsschnittstelle für leichten Zugriff verfügbar gemacht
wird (d. h. eine einzelne Abfrage), durch Berichterzeugungsanwendungen.
Die Verwendung von mehreren Tabellen in einer relationalen Datenbank
eignet sich für
eine Strukturierte-Abfrage-Sprache
(SQL; SQL = structured query language) für eine Datenwiedergewinnung
oder Berichterzeugung. Eine Ansammlungsfunktion summiert gesammelte
Daten und behält
einen Ereigniszählwert
jedes Ereignistyps bei, der an jedem Knoten auftritt. Eine Trimm-Funktion
beseitigt ungewollte Daten aus dem Datenlager, nachdem die Daten
angesammelt wurden. Eine Filterfunktion ist verfügbar, um zu ermögli chen,
dass Bedingungen spezifiziert werden, bei denen Ereignisdaten nicht
in dem Datenlager gespeichert werden.
-
Das
Datenlager speichert Ereignisdaten in einer Mehrzahl von verwandten
Tabellen, die jeweils einem bestimmten Ereignis oder Ereignistyp
zugeordnet sind. Die Tabellen umfassen berichtfertige Ereignistabellen, die
einen Teilsatz enthalten, der sich auf einen bestimmten Typ des
Berichtens bezieht, der verfügbaren
Ereignisfelder für
ein gegebenes Ereignis. Berichterzeugungsanwendungen, die diesen
bestimmten Typ des Berichtens ausführen, können dann auf alle notwendigen
Felder für
ein gegebenes Ereignis bei einer einzelnen Abfrage zugreifen, wodurch
das Verhalten des Systems verbessert wird.
-
Kurze Beschreibung
der Zeichnungen
-
Die
Erfindung ist besser verständlich
aus dem Lesen der nachfolgenden detaillierten Beschreibung in Verbindung
mit den Zeichnungen, in denen gleiche Bezugszeichen verwendet werden,
um gleiche Elemente zu bezeichnen, und in denen:
-
1 ein
Blockdiagramm eines Systems gemäß der Erfindung
ist;
-
2 ein
Diagramm eines Objekts gemäß dem formalen
Datenschema der Erfindung für
einen Ereignistyp ist;
-
3 ein
Blockdiagramm ist, das Beispielinhalte eines Datenlagers der Erfindung
darstellt; und
-
4 ein
Flussdiagramm bei einem bevorzugten Ausführungsbeispiel der Schritte
ist, die durch die Ansammlungsfunktion ausgeführt werden.
-
Detaillierte
Beschreibung
-
1 ist
ein Blockdiagramm eines Systems gemäß der Erfindung. Ereignisse 101 werden
durch ein Netzwerkverwaltungssystem (nicht gezeigt) gesammelt. Ereignisse 101 werden
durch eine Systemhardware, das Betriebssystem und Anwendungen erzeugt,
die auf dem Netzwerk laufen. Ereignisse 101 warnen üblicherweise
den Systemadministrator im Hinblick auf verschiedene Erscheinungen
auf dem Netzwerk, aus denen der Status des Netzwerks hergeleitet
werden kann. Typische Systemereignisse fallen in verschiedene Kategorien,
die Ereignisse umfassen, die anzeigen, dass ein Netzwerkelement
hinzugefügt,
entfernt, aktiviert oder ausgefallen ist, Ereignisse, die anzeigen,
dass ein Netzwerkelement einen kritischen Status erreicht hat, Ereignisse,
die anzeigen, dass eine vorbestimmte Schwelle für eine spezifische Netzwerkressource überschritten
wurde und Ereignisse, die anzeigen, dass ein potentielles Autorisierungsproblem
aufgetreten ist. Ereignisse 101 werden üblicherweise durch SNMP-Programmunterbrechungen
als Alarme oder Warnungen erzeugt, die unnormale Situationen in
dem Netzwerk anzeigen. Üblicherweise
verarbeitet das Betriebssystem des Netzwerks Programmunterbrechungen über eine
Ereignisdirektor-Hintergrundroutine, die die Ereignisse zu verschiedenen
Verarbeitungsanwendungen leitet. Abhängig von dem Typ der Ereignisse
und ihrer wahrgenommenen Ernsthaftigkeit lösen verschiedene reaktive Netzwerkverwaltungsaktivitäten einen
Softwareprozess aus oder warnen den Systemadministrator und resultieren
schließlich
in einer Lösung
des Problems.
-
Ein
Exportverwalter 102 empfängt Ereignisse 101.
Bei einem Ausführungsbeispiel
ist geplant, dass der Exportverwalter 102 Ereignisse 101 von
einem Ereignisdepot (nicht gezeigt) wiedergewinnt, in das die Ereignisse 101 in
Echtzeit durch das Netzwerkverwaltungssystem (nicht gezeigt) abgelegt
werden. Bei einem alternativen Ausführungsbeispiel empfängt der
Exportverwalter 102 Ereignisse 101 in Echtzeit
direkt von dem Netzwerkverwaltungssystem, wenn die Ereignisse auftreten.
Jedes Ereignis 101 ist eine Reihe von Rohdaten-Bytes, die in ihrer
Länge abhängig von
dem Ereignistyp variieren können.
Anhang A stellt eine Implementierung von verschiedenen Ereignissen 101 in
einem Beispielformat dar, das durch einen Exportverwalter 102 empfangen
wird. Ausschließlich
zur Referenz umfasst, ist nachfolgend jeder Satz von empfangenen
Rohdaten im Anhang A eine ASCII-Pseudo-Interpretation
der Rohdaten ihres entsprechenden Ereignisses. Der Pseudo-Interpretationsabschnitt
ist das, was Systemadministratoren in gegenwärtigen Systemen entschlüsseln, um den
Status des Netzwerks zu bestimmen und Netzwerk-Probleme und Trends
zu lokalisieren. Das Verarbeiten der Pseudo-Interpretationsdatei
zum Extrahieren bedeutender Informationen ist eine Technik, die
nur durch fachmännische
Administratoren ausgeführt
wird.
-
Anhang
A stellt den Rohdatenstrom dar, der für ein Beispielereignis empfangen
wird. Die Pseudo-Interpretation dieses Ereignisses ist:
Die
Software-Anwendungslizenz auf der Maschine „mercutio.cnd.hp.com" mit dem Namen „Network
Node Manager 250 Instant-On",
die 250 Benutzer unterstützt,
läuft am
Dienstag, 28. Juli 1998 um 11:25:30 ab. Dieses Ereignis wurde am
Freitag, 29. Mai 1998 um 11:27:49 erzeugt. Dieses Ereignis weist
einen Objektdeckel von „1.3.6.1.4.11.2.17.1.0.59179231" auf.
-
Der
Exportverwalter 102 formatiert jedes Ereignis 101 in
ein formales Datenschema, das unterschiedliche Definitionen für jeden
Ereignistyp erlaubt. Das formale Datenschema umfasst einen Satz
aus Tabellen, die die Ereignisfelder des Ereignisses 101 auf
eine Weise speichern, die förderlich
für eine
effiziente Wiedergewinnung von relevanten Informationen für verschiedene
Typen einer Informationsberichterstattung ist. Dementsprechend,
abhängig
von dem erwarteten Typ des Berichtens, das durchgeführt wird,
werden nur jene Ereignisfelder, die wesentlich für einen bestimmten Typ eines
Berichtens sind, in einem entsprechenden Tabellentyp gespeichert.
Jedes Ereignis kann mehrere unterschiedliche Tabellen aufweisen,
die demselben zugeordnet sind, wobei sich jede von einer anderen
unterscheidet durch Speichern von zumindest einem unterschiedlichen
Ereignisfeld. Dementsprechend, wenn eine Anwendung Informationen
benötigt,
die sich auf einen bestimmten Typ des Berichtens beziehen, wird
eine einzelne Abfrage an der entsprechenden Tabelle ausgeführt, die
diesem Typ des Berichtens zugeordnet ist, um alle wesentlichen Informationen
für dieses
Ereignis zu erhalten.
-
Jede
Tabelle ist definiert, um alle wesentlichen Ereignisfelder zu umfassen,
die für
diesen Berichttyp erforderlich sind. 2 stellt
einen Fall eines Beispielobjekts 200 gemäß dem formalen
Datenschema der Erfindung für
einen Ereignistyp dar, der Ereignisfelder 201, 202, 203, 204 und 205 aufweist.
Ein Objekt 200 stellt einen Fall eines Objekts von nur
einem Ereignistyp dar. Wie jedoch vorangehend beschrieben wurde,
kann jeder Ereignistyp eine Anzahl von unterschiedlichen berichtfertigen
Tabellen umfassen. Bei diesem Beispiel umfasst das Objekt 200 eine
erste Tabelle event_table_A 210, die im Hinblick auf einen
ersten Typ des Berichtens formatiert ist, der Ereignisfelder event_field_1 201,
event_field_2 202 und event_field_3 203 umfasst.
Das Objekt 200 umfasst eine zweite Tabelle event_table_B 220,
die im Hinblick auf einen zweiten Typ des Berichtens formatiert
ist, der Ereignisfelder event_field_1 201, event_field_4 204 und
event_field_5 205 umfasst. Bei diesem Beispiel, wenn ein
erster Typ des Berichtens ausgeführt
wird, wird eine Abfrage an der event_table_A 210 ausgeführt, um
alle Ereignisfelder 201, 202 und 203 bei
einer einzelnen Kommunikation zu erhalten. Auf ähnliche Weise, wenn ein zweiter
Typ des Berichtens durchgeführt
wird, wird eine Abfrage an der event_table_B 220 ausgeführt, um
alle Ereignisfelder 201, 204 und 205 bei
einer einzelnen Kommunikation zu erhalten. Somit wird der Bedarf
zum Ausführen
einer separaten Abfrage an einem Ereignisobjekt für jedes Ereignisfeld,
das wesentlich für
einen bestimmten Typ des Berichtens ist, oder zum Wiedergewinnen
unnötiger Informationen,
die für
diesen Typ des Berichtens wesentlich sind, umgangen.
-
Bezug
nehmend zurück
auf 1, nachdem Ereignis 101 in seine entsprechenden
Tabellen formatiert wurde, sendet der Exportverwalter 102 das
formatierte Ereignis 103 zu einem Datenlager 111 unter
Verwendung einer Standardkommunikationsschnittstelle. Bei dem darstellenden
Ausführungsbeispiel
werden formatierte Ereignisdaten 103 zu dem Datenlager 111 unter
Verwendung der bekannten Anwendungsprogrammierungsschnittstelle
(API; API = Application Programming Interface) mit dem Namen Open
DataBase Connectivity (ODBC) von Microsoft gesendet. ODBC ist eine übliche Schnittstelle
zum Zugreifen auf unterschiedliche oder heterogene Datenbanken der
Structured Query Language (SQL = Strukturierte-Abfrage-Sprache), die ermöglicht,
dass eine einzelne Anwendung auf unterschiedliche SQL-Datenbankverwaltungssysteme
(SDMS; DMS = Database Management Systems) über einen gemeinsamen Codesatz
zugreift. Dies ermöglicht,
dass der Anwendungsentwickler die Anwendung aufbaut und verteilt,
ohne auf ein bestimmtes DBMS zu zielen. Ein Datenbanktreiber, der
auf einer Ziel-DBMS läuft,
verknüpft
die Anwendung mit dem DBMS des Benutzers.
-
Das
Datenlager 111 speichert die formatierten Ereignisdaten 103 gemäß dem formalen
Datenschema, das hierin nachfolgend erörtert wird, definiert für den Ereignistyp
des Ereignisses 101.
-
Ereignisdaten,
die in dem Datenlager 111 gespeichert sind, sind über eine
Standardschnittstelle 108 zugreifbar (d. h., ODBC bei dem
darstellenden Ausführungsbeispiel),
die Zugriff auf die Daten durch Berichterstattungsanwendungen 112 ermöglicht,
die auf Systemen laufen, basierend auf einem unterschiedlichen DBMS.
-
Im
Lauf der Zeit, wenn mehr und mehr Daten in dem Datenlager 111 angesammelt
werden, werden in einigen Situationen die detaillierten Informationen
jedes Ereignisses weniger wichtig als Informationen über das
Ereignis. Eine Ansammlungsfunktion 104 schafft ein Verfahren
zum Summieren von Informationen über ein
Ereignis, ohne alle Details des Ereignisses zurückzuhalten. Diese Funktion
hilft beim Beibehalten einer bearbeitbaren Datenbankkapazität, durch
Ermöglichen,
dass die Details von Ereignissen aus dem Datenlager 111 entfernt
werden, während
Zusammenfassungsinformationen über
die entfernten Ereignisse zurückgehalten
werden. Die Zusammenfassungsinformationen ermöglichen, dass Anwendungen Langzeitfragen
beantworten (z. B. Häufigkeit
des Auftretens eines bestimmten Typs eines Ereignisses an einem
bestimmten Knoten). Zum Beispiel zählt bei dem darstellenden Ausführungsbeispiel
die Ansammlungsfunktion 104 Typen von Ereignissen für jeden
Netzwerkknoten und zählt
das Auftreten dieser Ereignisse über
verschiedene Zeitperioden nach (z. B. täglich, wöchentlich und monatlich). Somit
kann man die Zählungen
betrachten und z. B. bestimmen, dass ein bestimmter Knoten n Mal
einen bestimmten Ereignistyp aufwies. Die Bedeutung dieser Informationen
hängt von
dem Ereignistyp ab. Wenn z. B. der Ereignistyp node_up (Knoten_ein)
ist, kann die Zählung
ergeben, dass in einem bestimmten Monat ein bestimmter Knoten x
node_up-Ereignisse erfährt,
und dass über
das Jahr diese Zählung
sich kontinuierlich von x auf x + y erhöht hat. Diese Situation ergibt
einen Trend von ansteigenden node_up-Ereignissen an diesem Knoten,
und könnte
dem Systemadministrator signalisieren, dass ein Problem an diesem
Knoten existiert. Anders ausgedrückt
hilft die Ansammlungsfunktion 104 beim Summieren von Ereignissen,
Zurückhalten
der Historie der Ereignisse und Zulassen, dass Details alter Ereignisse
aus dem Datenlager 111 entfernt werden. Somit liefert die
Ansammlungsfunktion 104 einen Wert zu dem Administrator
durch Reflektieren eines Profils der Netzwerkaktivität über Zeit.
-
Eine
Trimmfunktion 106 entfernt detaillierte Ereignisse ganz
oder teilweise aus dem Datenlager 111. Die Trimmfunktion 106 wird
vorzugsweise durchgeführt,
nachdem die detaillierten Ereignisse durch die Ansammlungsfunktion 104 summiert
werden.
-
Netzwerkverwaltungssysteme
erzeugen häufig
Ereignisse, die nur ein normales Vorkommnis auf dem System signalisieren.
Ein übermäßiges Auftreten
dieser Ereignistypen wird häufig
als Störung
für Systemadministratoren
betrachtet. Eine Filterfunktion 110 liefert die Fähigkeit
zum Herausfiltern benutzerdefinierter Störungsereignisse, wie z. B.
bestimmter normaler Vorkommnis-Ereignisse. Bei dem darstellenden
Ausführungsbeispiel
ermöglicht
die Filterfunktion 110, dass der Benutzer alle Typen von
Ereignissen auf einem bestimmten Knoten, einen bestimmten Typ eines
Ereignisses auf einem bestimmten Knoten oder einen bestimmten Typ eines
Ereignisses auf allen Knoten spezifiziert, die nicht gespeichert
werden sollen. Zum Beispiel, wenn eine Vorrichtung an dem Knoten
n bekannter Weise an einem Plan nach oben und unten geht, und der
Benutzer nicht möchte,
dass diese Ereignisse gespeichert werden, da sie nur Verkehr über das
Netzwerk und in dem Datenlager 111 verursachen, kann der
Benutzer diese bestimmten Ereignisse an diesem spezifischen Knoten als
Störungsereignisse
spezifizieren, und sie werden nicht gespeichert.
-
3 ist
ein Blockdiagramm, das ein Beispiel davon darstellt, wie Ereignisse
in dem Datenlager 111 gespeichert werden. Obwohl nur einige
Ereignistabellen in 3 dargestellt sind, speichert
ein besetztes Datenlager 111 üblicherweise eine Mehrzahl
von Ereignistabellen. Die Tabellen sind in Objekten 310a, 310b, 320a, 320b, 330a, 330b gespeichert.
Jeweilige Tabellen in Objekten 310a, 310b, sind
durch ein jeweiliges gemeinsames universell eindeutiges Identifiziererfeld
event_uuid verknüpft,
das nachfolgend hierin erörtert
wird. Ansammlungstabellen in Objekten 320a und 320b sind
durch einen gemeinsamen eindeutigen Objekti dentifizierer verknüpft, das
Feld event_oid, das nachfolgend hierin erörtert wird. Die Kombination
aus Tabellen, die für
einen gegebenen Ereignistyp definiert sind, hängt von dem erwarteten Typ
des Berichtens ab, der an dem Ereignistyp ausgeführt wird. Entsprechend kann
beispielsweise Ereignistyp A sich für ein Verfügbarkeitsberichten eignen aber
nie für
ein Schwellenverstoßberichten,
und ist entsprechend definiert, um eine Verfügbarkeitstabelle 316 zu
umfassen. Im Gegensatz dazu kann sich Ereignistyp B für ein Schwellenverstoßberichten
eignen aber nie für
ein Verfügbarkeitsberichten,
und ist entsprechend mit der Schwellenverstoßtabelle 318 definiert.
-
Bei
dem bevorzugten Ausführungsbeispiel
ist die Speicherung jedes Ereignistyps definiert durch eine oder
mehrere Tabellenklassen, einschließlich: event_detail_table (event
= Ereignis) (detail = Detail) (table = Tabelle) 312, event_varbinds_table 314,
event_availability_table (availability = Verfügbarkeit) 316, event_threshold_table
(threshold = Schwelle) 318, event_daily_table (daily =
täglich) 322,
event_weekly_table (weekly = wöchentlich) 324,
event_monthly_table (monthly = monatlich) 326, und event_filter_table
(filter = Filter) 330. Es können zusätzliche Tabellen vorliegen,
die definiert sind, um Zugriff auf die Tabellen zu unterstützen, die
bereits definiert sind. Die Klassendefinitionen für jede dieser
Tabellen sind hierin nachfolgend in Anhang B umfasst.
-
Die
Detailtabelle event_detail_table 312 umfasst Ereignisfelder,
die allen Ereignistypen gemeinsam sind. Bei dem bevorzugten Ausführungsbeispiel
umfasst die Detailtabelle alle gemeinsamen Ereignisfelder. Dies
stellt eine maximale Speichereffizienz der Detailtabelle sicher,
da sie anordnet, dass jedes Feld in der Tabelle voll ist. Bei dem
darstellenden Ausführungsbeispiel
umfasst die event_detail_table 312 die Felder event_uuid,
event_timestamp (timestamp = Zeitspempel), category (Kategorie),
nodename (Knotenname), application_id (Anwendungs- ID), message (Meldung),
severity (Wichtigkeit), event_oid, ov_objectid, protocol (Protokoll),
event_type (Ereignis_Typ), ip_address (ip-Adresse), trapsource (Programmunterbrechungs-Quelle),
trap_name (Programmunterbrechungsname), pid, forward_address (Weiterleiten_Adresse),
event_source (Ereignis_Quelle), event_time (Ereignis_Zeit), and
number_varbinds (Anzahl_Varbinds). Das Feld event_uuid wird verwendet,
um Daten in der Detailtabelle zu Daten in anderen verwandten Tabellen
zuzuordnen. Das Feld event_timestamp zeichnet die Sekunden seit
dem Zeitraum für
das Vorkommnis des Ereignisses auf und wird verwendet, da Datendarstellungen
in variierenden Datenlagern nicht notwendiger Weise konsistent sind.
Dementsprechend wird durch Verwenden einer Standardform von „Zeiträume seit
einem gegebenen Datum" sichergestellt,
dass der Zeitstempel über
alle DBMSs konsistent ist. Das Feld category speichert den Ereignistyp
des zugeordneten Ereignisses, das Feld nodename identifiziert den
Namen des Knotens, an dem das Ereignis aufgetreten ist. Das Feld
application_id (Anwendung_id) identifiziert die Softwareanwendung,
die das Ereignis erzeugt hat. Das Feld message weist ASCII-Textinformationen über das
Ereignis auf. Das Feld severity zeigt den Pegel der Wichtigkeit
des Ereignisses an (z. B. keine, normal, Warnung, gering, groß oder kritisch).
Das Feld event_oid speichert einen Identifizierer, der eindeutig
für den
bestimmten Ereignistyp des Ereignisses ist. Das Feld number_varbinds
zeigt an, wie viele Einträge
in der Varbinds-Tabelle
existieren, die diesem Ereignis zugeordnet sind, das in der Ereignisdetailtabelle
gespeichert ist. Die event_detail_table 312 umfasst zusätzliche Felder
zum Identifizieren von Ereignisinformationen, einschließlich den
Feldern ov_objectid, protocol, event_type, ip_address stores, trapsource,
trap_name, pid, forward_address, event_source, event_time.
-
Spezifische
Ereignisse können
zusätzliche
unterstützende
Informationen über
das Ereignis aufweisen. Diese zusätzlichen Informationen, die
nicht allen Ereignistypen gemeinsam sind, sind in einer Variable-Bindungen-Tabelle
gespeichert, event_varbinds_table 314. Die event_varbinds_table 314 bringt
eine variable Anzahl von zusätzlichen
Datenfeldern an das Ereignis an. Bei dem bevorzugten Ausführungsbeispiel
umfasst die Variable-Bindungen-Tabelle event_varbinds_table 314 die
Felder event_uuid, varbind_sequence, event_oid, val_len, type, und
eine Anzahl von anderen Feldern verschiedener Typen, einschließlich string
(Zeichenfolge), integer (ganze Zahl), flt, unsigned32, und unsigned64.
Das Feld event_uuid ist das Feld, das ebenfalls in der event_detail_table 312 gespeichert
ist, das verwendet wird, um die zusätzlichen Ereignisfelder zurück auf die
Detailtabelle abzubilden. Das Feld varbind_sequence identifiziert
den Variable-Bindung-Eintrag für den
bestimmten Eintrag in die event_varbinds-table 314, wo
die Gesamtanzahl von varbind-Einträgen (varbind = variable binding
= variable Bindung) in der event_varbind-Tabelle für dieses
Ereignis gleich der Anzahl sein sollte, die in dem Feld number_varbinds
in der Detailtabelle event_detail_table 312 gespeichert
ist. Wenn z. B. das Feld number_varbinds in der Detailtabelle event_detail_table 312 eine
ganze Zahl „3" speichert, existieren drei
Einträge
mit dem selben event_uuid in der Variable-Bindungen-Tabelle event_varbinds_table 314.
Für unterschiedliche
Klassen von Ereignissen.
-
Die
Detailtabelle event_detail_table 312 und die Variable-Bindung-Tabelle event_varbinds_table 314 umfassen
jeweils und sind verknüpft
durch einen Universell-Eindeutig-Identifizierer-(UUID-;
UUID = universally unique identifier) Feld event_uuid. Die Detailtabelle
event_detail_table 312 und die Variable-Bindungen-Tabelle
event_varbinds_table 314 speichern zusammen alle verfügbaren Informationen
für ein
gegebenes Ereignis. Der event_uuid wird zur Bezugnahme auf die Informationen
verwendet, die dem Ereignis zugeordnet sind, die nicht in der Detailtabelle
sondern in der Variable-Bindungen-Tabelle gespeichert sind. Dementsprechend,
im Hinblick auf die Detailtabelle event_detail_table 312,
die Variable-Bindungen-Tabelle event_varbinds_table 314 und
das UUID-Feld event_uuid, kann auf alle verfügbaren Informationen zugegriffen
werden, die über
ein Ereignis von der Außenwelt
bekannt sind.
-
Im
Allgemeinen sind nicht alle verfügbaren
Informationen für
ein Ereignis zu Zwecken des Ausführens einer
Statistisch-Prozess-Steuerung, dem Verfolgen von Trends oder Erzeugen
von Berichten verwendet. Zum Beispiel werden Berichte, die üblicherweise
für Ereignisse
erzeugt werden, gemäß Ereignistyp,
Ereigniswichtigkeit, etc. organisiert, um dieselben dem Benutzer
so zu präsentieren,
dass sie Sinn machen. Ein Versuch zum Ausführen des Berichtens unter Verwendung
von ausschließlich
der Detailtabelle und der Variable-Bindung-Tabelle erfordert, wie
vorangehend erörtert
wurde, eine Reihe von separaten Feldabfragen an der Detail- und
Variable-Bindung-Tabelle, um alle wesentlichen Informationen zu
erhalten, die notwendig sind, um den Bericht zu erzeugen, was das
Verhalten des Systems verschlechtert. Dementsprechend werden die
berichtfertigen Tabellen Verfügbarkeitstabelle 316 und
eine Schwellenverstoßtabelle 318 bei
dem bevorzugten Ausführungsbeispiel
bereitgestellt, um einer Berichterzeugungsanwendung zu ermöglichen,
alle Informationen zu erhalten, die zum Erzeugen eines Berichts
in einer einzelnen Abfrage pro Ereignis notwendig sind.
-
Die
Verfügbarkeitstabelle
event_availability_table 316 enthält alle Felder aus der Detailtabelle event_detail_table 312 und
der Variable-Bindungen-Tabelle event_varbind_table 314,
die sich auf einen Verfügbarkeits-Ereignistyp beziehen.
Bei dem bevorzugten Ausführungsbeispiel
umfassen Verfügbarkeitsereignisse:
node_added, node_deleted, node_up und node_down. Das Verfügbarkeitsereignis
node_added (Knoten_hinzugefügt)
zeigt an, dass ein gegebener Knoten durch das Netzwerkverwaltungssystem
entdeckt wurde und das Netzwerkverwaltungssystem das Verwalten desselben
startet. Das Verfügbarkeitsereignis node_deleted (Knoten_gelöscht) zeigt
an, dass das Netzwerkverwaltungssystem einen gegebenen Knoten nicht
mehr weiter verwaltet. Die Verfügbarkeitsereignisse
node_up (Knoten_ein) und node_down (Knoten_aus) zeigen einen aktiven
und inaktiven Statusübergang
für diesen
Knoten an.
-
Die
Verfügbarkeitstabelle
event_availability_table 316 wird durch eine Berichterzeugungsanwendung verwendet,
um einen Bericht zu erzeugen, der ein Profil der Verfügbarkeit
eines gegebenen Knotens in dem Netzwerk über Zeit darstellt.
-
Ein
Verfügbarkeitsbericht
und Schwellenbericht erfordern zusätzliche Tabellen 316 und 318 zum
Speichern der angesammelten oder manipulierten Daten, um somit den
Bericht zu erzeugen. Die Informationen in der Verfügbarkeitstabelle
event_availability_table 316 und der Schwellentabelle event_threshold_table 318 sind
eine manipulierte Version oder ein Teilsatz der Informationen, die
in der Detail- und Variable-Bindung-Tabelle enthalten sind, und
die event_availability_table 316 ist mit der event_detail_table 312 und
der event_varbinds_table 314 durch das Feld event_uuid
verknüpft.
Somit sind die event_availability_table 316 und die Schwellentabelle
event_threshold_table 318 Extraktionen der Daten, die in
der event_detail_table 312 und der event_varbinds_table 314 vorhanden
sind, die für
eine leichtere Extraktion für
Berichterzeugungsanwendungen formatiert sind. Anders ausgedrückt, sobald
das Datenlager 111 besetzt wird, wird ein gegebenes Ereignis
in der event_detail_table 312 und der event_varbind_table 314 des
Ereignisses gespeichert, und bestimmte Felder aus diesen Tabellen
werden mit einem unterschiedlichen Layout in der event_availability_table 316 und
der event_threshold_table 318 kopiert. Die Organisation
der Informationen, die in der event_availability_table 316 und
der event_threshold_table 318 enthalten sind, führt zu einem
besseren Verhalten im Hinblick auf die Datenextraktions-Zugriffszeit
und die Systemressourcenverwendung.
-
Bestimmte
Netzwerkereignisse werden erzeugt, wenn ein überwachter Vorrichtungszustand
einen vorspezifizierten Zielwert überschreitet. Zum Beispiel,
wenn einem Computer der Platten-Raum ausgeht, kann ein Schwellenverstoßereignis
erzeugt werden, wenn die Schwelle eine Kapazität von 90% überschreitet. Schwellen werden üblicherweise
durch den Systemadministrator definiert und werden auf Pegel eingestellt, die
der Schwelle eines Zustands entsprechen, den der Administrator anzeigen
möchte.
Die Schwellenverstoßtabelle
event_threshold_table 318 ist eine Extraktion der Ereignisfelder,
die in ihrer zugeordneten event_detail_table 312 und event_varbinds_table 314 gespeichert
sind, die sich zum Vereinfachen des Erzeugens von Schwellenverstoßberichten
eignen.
-
Im
Lauf der Zeit kann die Anzahl von Ereignissen, die in einem typischen
Netzwerkverwaltungssystem erzeugt werden, relativ groß werden
und zum Beibehalten bedeutende Verarbeitungs- und Speicherressourcen
erfordern. Zu Trendverfolgungs- und Berichterzeugungs-Zwecken, bei
denen das Augenmerk auf dem Verfolgen der Anzahl von Vorkommnissen
bestimmter Ereignistypen pro Knoten liegt, liefern die detaillierten Informationen,
die jedem Ereignis zugeordnet sind, keinen nützlichen Zweck. Was jedoch
wichtig ist, ist das Beibehalten einer Zählung der Anzahl von Vorkommnissen
von Ereignistypen pro Knoten. Dementsprechend wird bei dem bevorzugten
Ausführungsbeispiel
eine Anzahl von Ansammlungstabellenklassen definiert: event_daily_table,
event_weekly_table und event_monthly_table. Eine Definition eines
bevorzugten Ausführungsbeispiels
für diese
Klassen wird in Anhang B erläutert.
Somit wird für
jeden Ereignistyp, der durch das Feld event_oid verknüpft ist,
und jeden Knoten, ein Zählwertfeld
event_cnt beibehalten unter Verwendung der event_daily_table, der
event_weekly_table und der event_monthly_table, und in dem Datenlager 111 auf
einer täglichen,
wöchentlichen
und monatlichen Basis gespeichert. Dies ermöglicht, dass Trendverfolgungs-
und Berichterzeugungs-Anwendungen eine durchschnittliche Anzahl von
Vorkommnissen und/oder ansteigende oder abfallende Trends von Vorkommnissen
eines bestimmten Ereignisses für
einen bestimmten Knoten über
Zeit zeichnen oder identifizieren.
-
Die
Ansammlungstabellen event_daily_table 322, event_weekly_table 324,
und event_monthly_table 326 werden für jeden Ereignistyp definiert,
identifiziert und verknüpft
durch das Feld event_oid 328, wenn erwünscht ist, Zählungen
von Ereignisvorkommnissen des selben Ereignistyps wie des Ereignisses
zu verfolgen. Jede aus event_daily_table 322, event_weekly_table 324,
und event_monthly_table 326 behält ein Feld event_cnt bei,
wie in ihren jeweiligen Klassendefinitionen definiert ist, gezeigt
in Anhang B, das den Zählwert des
Ereignistyps speichert. Bei dem bevorzugten Ausführungsbeispiel aktualisiert
der Exportverwalter 102 das Feld event_cnt, über die
Standard-ODBC-Schnittstelle 103,
für event_daily_table 322 für jeden
Ereignistyp, während
die Ansammlungsfunktion 104 das Feld event_cnt für die event_weekly_table 324 und
die event_monthly_table 326 über die Standard-ODBC-Schnittstelle 105 für jeden
Ereignistyp aktualisiert.
-
Wenn
der Exportverwalter 102 Ereignisse 101 empfängt, zählt und
behält
er eine Zählung
der Anzahl von Vorkommnissen von Ereignistypen pro Knoten, die er
verarbeitet. Der Exportverwalter 102 erzeugt einen Eintrag
in die event_daily_table 322 für jeden Ereignistyp-Fall und
-Knoten und inkrementiert einen laufenden täglichen Zählwert in dem Feld event_cnt
für jeden
Ereignisfall, den er verarbeitet. Eine event_daily_table 322 kann
für jeden
Ereignis-Typ und -Knoten für
jeden Tag beibehalten werden oder alternativ, wie bei dem bevorzugten
Ausführungsbeispiel,
kann das Feld event_cnt zu der entsprechenden event_weekly_table 324 und
der event_monthly_table 326 täglich hinzugefügt werden
und dann jeden Tag auf Null erneut initialisiert werden.
-
4 ist
ein Flussdiagramm der Schritte, die durch die Ansammlungsfunktion 104 bei
dem bevorzugten Ausführungsbeispiel
ausgeführt
werden. Die Ansammlungsfunktion 104 ist geplant, um die
Ereignisdaten anzusammeln, die in dem Datenlager 111 gespeichert
sind. Bei einem Schritt 402 gewinnt die Ansammlungsfunktion 104 eine
event_daily_table aus dem Datenlager 111 wieder. Wie vorangehend
beschrieben wurde, enthält
die event_daily_table alle Ereignisse eines gegebenen Ereignistyps
für einen
gegebenen Knoten. Das Feld event_timestamp wird bei Schritt 404 bezeichnet,
um die Ansammlung der Ereignisse zu koordinieren. Wenn die event_weekly_table
oder event_monthly_table für
die entsprechende Zeitperiode noch nicht existieren, erzeugt die
Ansammlungsfunktion 104 dieselben erst, bevor ihre entsprechenden
event_cnt-Felder mit entsprechenden Zählungen aktualisiert werden.
Bei einem Schritt 408 speichert die Ansammlungsfunktion 104 die
aktualisierte event_weekly_table und event_monthly_table in dem
Datenlager 111. Als eine Darstellung, wenn ein Ereigniszählwert eines
vorangehenden Tages zwanzig Ereignisse für einen Ereignistyp a für Knoten x
war, fügt
die Ansammlungsfunktion 104, wenn sie betrieben wird, die
zwanzig Ereignisse zu dem Feld event_cnt in der event_weekly_table
und der event_monthly_table hinzu, die der entsprechenden Zeitperiode zugeordnet
sind.
-
Die
Nützlichkeit
der Ansammlungsfunktion 104 ist, dass ein Bericht über die
Ansammlungszählungen erzeugt
werden kann, mit einem Datenpunkt für jede Woche und jeden Monat,
und über
Zeit gezeichnet werden kann, um Trends zu identifizieren. Ferner
werden diese Trendinformationen behalten, unabhängig davon, ob die detaillierten
Informationen jedes Ereignisses behalten werden.
-
Da
im Lauf der Zeit nur die historischen Informationen vergangener
Ereignisse im Allgemeinen von Interesse sind, sind die Details der
Ereignisse selbst üblicherweise
nicht mehr notwendig, sobald die Ansammlungsfunktion 104 das Ereignis
gezählt
hat. Dementsprechend wird eine Trimm-Funktion 106 bereitgestellt,
um unnötige
Ereignisinformationen aus einem Datenlager 111 zu löschen, wie
in 1 dargestellt ist. Die Trimm-Funktion 106 entfernt über die
Standardschnittstelle ODBC 107 die event_detail_tables 312, event_varbind_tables 314,
event_availability_tables 316, und event_threshold_tables 318,
wie durch den Systemadministrator spezifiziert wird. Bei dem bevorzugten
Ausführungsbeispiel
spezifiziert der Systemadministrator einen Zeitstempel und Tabellentyp,
und die Trimm-Funktion 106 löscht alle Tabellen des spezifizierten
Tabellentyps, die einen Zeitstempel vor dem spezifizierten Zeitstempel
aufweisen. Zum Beispiel kann eine Trimm-Funktion 106 verwendet
werden, um alle event_detail_tables 312 und event_varbind_tables 314 zu
löschen,
die einen Zeitstempel vor dem Zeitstempel t aufweisen. Bei dem bevorzugten
Ausführungsbeispiel weist
die Trimm-Funktion 106 die Fähigkeit auf, alle Tabellen
vor einer Zeit zu löschen,
die in relativen Sekunden, Minuten, Stunden etc. gemessen wird (z.
B. eine Tabelle, die einem Ereignis zugeordnet ist, das vor mehr als
48 Stunden passiert ist). Schließlich hat eine Trimm-Funktion 106 die
Fähigkeit,
eine Tabelle zu löschen, die
einem Ereignis zugeordnet ist, das seit einem gegebenen Zeitpunkt
aufgetreten ist, was nützlich
ist beim Entfernen von Daten, die aufgetreten sind, während das
Netzwerk abgeschaltet und im Fehlerbeseitigungsmodus war.
-
Die
Filterfunktion 110 empfängt
eine Filterspezifikationseingabe 113 in der Form eines
Ereignistyps, einen J/N-Indikator,
der, wenn er eingestellt ist (d. h., „J"), anzeigt, Ereignisse des Ereignistyps
immer zu filtern, und, wenn er nicht eingestellt ist (d. h., „N"), anzeigt, Ereignisse
des Ereignistyps nie zu filtern, und eine ganzzahlige Grenze. Die
Filterfunktion 110 erzeugt eine Filtertabelle event_filter_table 330 für den bestimmten
Ereignistyp. Vorzugsweise erlaubt die event_filter_table 330 Platzhalter.
Zum Beispiel wird ein Platzhalter verwendet, um alle Ereignistypen
für den
spezifizierten Knoten zu filtern oder alle Knoten für einen
spezifizierten Ereignistyp zu filtern. Zusätzlich dazu ist die ganzzahlige
Grenze N eingestellt, um bis zu den ersten N Ereignissen zu spezifizieren,
für den
spezifizierten Knoten für
diesen Tag, der gespeichert werden soll. Die event_filter_table 330 wird
in dem Datenlager 111 über
die Standardschnittstelle ODBC 109 gespeichert. Der Exportverwalter 102 greift
auf die event_filter_table über
die Standardschnittstelle 103 zu und verwirft alle Ereignisinformationen,
die mit den definierten Filterspezifikationen übereinstimmen.
-
Wie
Fachleute auf dem Gebiet erkennen werden, schafft die Erfindung,
wie sie hierin beschrieben wird, ein Verfahren zum Organisieren
der Rohdaten aus einem Netzwerkverwaltungssystem-Ereignisstrom in spezielle
Behälter,
um berichtrelevante Daten einfacher zugreifbar für Berichterzeugungsanwendungen
zu machen. Zusätzlich
dazu schafft die Erfindung einen Mechanismus zum Ansammeln der Daten
in ein historisches Format, um Trends aufzudecken und leicht zugreifbar
zu machen, um Berichte zu erzeugen, ohne zu erfordern, dass die
detaillierten Ereignisinformationen zurückgehalten werden.
-
-
-
-
