DE69622026T2

DE69622026T2 - Verfahren und gerät zur verfahrensbasierter alarmmeldung in einer verteilter netzwerkverwaltingsumgebung

Info

Publication number: DE69622026T2
Application number: DE69622026T
Authority: DE
Inventors: Russell Arrowsmith; Lundy Lewis; R. Poliquin; William Tracy
Original assignee: Aprisma Management Technology Inc
Current assignee: Aprisma Management Technology Inc
Priority date: 1995-03-29
Filing date: 1996-03-29
Publication date: 2003-02-27
Anticipated expiration: 2016-03-30
Also published as: US5696486A; EP0818096A1; AU5325896A; WO1996031035A1; ATE219874T1; DE69622026D1; EP0818096B1; AU720061B2

Description

Technisches Gebiet

Die vorliegende Erfindung betrifft die Alarmbenachrichtigung in einem Kommunikationsnetz und insbesondere ein Verfahren und eine Vorrichtung zum Empfangen von Alarmen von mehreren Netzmanagement-Servern, zum Anwenden von Richtlinien auf diese Alarme und zum Weiterleiten der Alarme, die den Richtlinien entsprechen, zu einer oder mehreren Netzmanagement- Anwendungen, wie zum Beispiel einem Verfahren und einer Vorrichtung zur telefonischen Alarmbenachrichtigung.

Allgemeiner Stand der Technik

SpectrumTM ist ein modellgestütztes Netzmanagementsystem von der Cabletron Systems, Inc., Rochester, New Hampshire, zum Halten und Verarbeiten von Informationen bezüglich des Zustands eines Kommunikationsnetzes und zur Bereitstellung dieser für einen Benutzer. Zum Beispiel fragt SpectrumTM periodisch ein Netzgerät ab, um Informationen anzufordern, wie zum Beispiel die Anzahl von Paketen, die in einer gegebenen Zeit auf dem Netz gesendet wurden, und die Anzahl aufgetretener Fehler. Wenn die Fehlerrate über einer vorbestimmten Grenze liegt, wird in der Datenbank von SpectrumTM ein Fehleralarm verzeichnet, ein Alarm zu der Benutzeroberfläche gesendet, um den Netzmanager zu benachrichtigen, und eine Nachricht wird gesendet, um das entsprechende Netzgerät abzuschalten.
Wenn nach seiner Abfrage keine Antwort von dem Netzgerät empfangen wurde, sollte alternativ dazu der Grund für den Kontaktverlust bestimmt werden, so daß entsprechende Maßnahmen, wie zum Beispiel ein Wartungseinsatz, unternommen werden können. In einer Netzumgebung kann der Kontaktverlust mit einem Netzgerät auf den Ausfall dieses Netzgeräts oder den Ausfall eines anderen Netzgerätes, das an der Übertragung einer Nachricht beteiligt ist, zurückzuführen sein.
Bei vielen vorbekannten Netzmanagementsystemen wurde dem Netzadministrator in der Regel eine Liste möglicher Ursachen für einen Fehler bereitgestellt, und er mußte den Fehler auf der Grundlage seiner Erfahrung und Kenntnis des Netzes isolieren. Bei SpectrumTM isoliert das System selbst Netzfehler mit Hilfe eines als Status-Unterdrückung bekannten Verfahrens. SpectrumTM führt eine Datenbank von Modellen für jedes Netzgerät. Wenn der Kontakt zwischen einem Modell und seinem entsprechenden Netzgerät verloren geht, setzt das Modell einen Fehlerstatus und leitet das Fehlerisolationsverfahren ein. Das Modell (erste Modell), das den Kontakt mit seinem entsprechenden Netzgerät (ersten Netzgerät) verloren hat, bestimmt, ob angrenzende Modelle den Kontakt mit ihren entsprechenden Netzgeräten verloren haben; angrenzende Netzgeräte sind definiert als diejenigen, die direkt mit einem angegebenen Netzgerät verbunden sind. Wenn angrenzende Modelle die entsprechenden Netzgeräte nicht kontaktieren können, dann kann das erste Netzgerät nicht die Ursache des Fehlers sein, und sein Fehlerstatus in dem ersten Modell wird übersteuert. Durch Unterdrücken des Fehlerstatus der Netzgeräte, die als nicht defekt bestimmt werden, kann man das defekte Netzgerät identifizieren. Nach der Isolation des Fehlers kann der Zustand des defekten Geräts in der Datenbank von SpectrumTM aktualisiert werden, eine Steuernachricht zum Abschalten des defekten Geräts kann gesendet werden und der Netzadministrator kann über die Benutzeroberfläche benachrichtigt werden.
Die zugehörige SpectroGRAPHTM-Benutzeroberfläche von SpectrumTM liefert eine grafische Ansicht in die Netzmodelle. Eine Alarmprotokollansicht 123 (siehe Fig. 1) enthält einen Bereich 120 zum Auflisten aktueller Alarme und einen Bereich 122 zum Anzeigen von Informationen bezüglich eines gewählten Alarms. Der Benutzer kann einen bestimmten Alarm in der Auflistung aktueller Alarme anklicken, um weitere Informationen zu erhalten. Ein Mehrfunktionssymbol 124, das das Netzgerät mit einem Fehler darstellt, wird in einem Bereich 122 angezeigt, wobei ein oder mehrere Textfelder 126, 128 dem Benutzer Informationen bezüglich der Ursache des Alarms und des Status des Geräts geben. Durch Anklicken angegebener Bereiche des Symbols 124 kann der Benutzer weitere Informationen bezüglich des Geräts, für das ein Alarm registriert wird, erhalten.
Ein anderes Verfahren für das Fehlermanagement in großen Kommunikationsnetzen besteht darin, ein sogenanntes "Störungs-Ticket"-System zu verwenden. Dieses System stellt eine Anzahl von Werkzeugen bereit, die von Netzbenutzern, administratoren und Reparatur- und Wartungspersonal verwendet werden können. Die grundlegende Datenstruktur, ein "Störungs-Ticket" enthält eine Anzahl von Feldern, in die ein Benutzer Daten eingeben kann, die die Parameter eines beobachteten Netzfehlers beschreiben. Ein von einem Benutzer ausgefülltes Störungs-Ticket kann dann zum Beispiel durch ein E-mail-System zu Wartungs- und Reparaturpersonal übertragen werden. Ein Störungs-Ticket, das einen aktuellen Netzfehler, auf den hin gehandelt werden muß, beschreibt, wird als "ein ausstehendes Störungs-Ticket" bezeichnet. Wenn der Netzfehler korrigiert worden ist, wird die Lösung des Problems, die in der Regel "Auflösung" genannt wird, in ein entsprechendes Datenfeld in dem Störungs-Ticket eingetragen, und das Störungs-Ticket wird als abgeschlossen bezeichnet. Das System ermöglicht die Speicherung abgeschlossener Störungs-Tickets im Speicher, und somit wird eine Bibliothek solcher Tickets erzeugt, durch die Benutzer, Administratoren und Wartungs- und Reparaturpersonal die gespeicherten ausgefüllten Störungs-Tickets begutachten können, um Hilfe bei der Bestimmung von Lösungen für zukünftige Netzfehler zu erhalten. Ein Beispiel für ein Störungs-Ticketsystem ist das System ACTION REQUEST, das von der Remedy Corporation, Mountain View, Kalifornien, entwickelt wurde, und von der Cabletron Systems, Inc., Rochester, New Hampshire, vertrieben wird.
ARS GatewayTM ist eine Netzmanagementanwendung von der Cabletron Systems, Inc., die Fehlerinformationen von dem SpectrumTM-System erhält und automatisch ein Störungs-Ticket erzeugt, das durch das System ACTION REQUEST verarbeitet werden kann. Dieses System wird in der gleichzeitig anhängigen eigenen U.S.-Anmeldung mit der Anmeldenummer 08/023,972, angemeldet am 26.02.1993, von Lundy Lewis mit dem Titel "Method and Apparatus For Resolving Faults In Communications Networks", worauf hiermit ausdrücklich und vollständig Bezug genommen wird, weiter beschrieben.
Das System SpectrumTM wird in dem U.S.-Patent Nr. 5,261,044, erteilt am 9.11.1993 an Roger Dev et al., beschrieben, auf das, hiermit ausdrücklich und vollständig Bezug genommen wird. Das Netzmanagementsystem SpectrumTM ist im Handel erhältlich und wird außerdem in verschiedenen Benutzerhandbüchern und in von der Cabletron Systems, Inc., Rochester, New Hampshire, verfügbarer Literatur, beschrieben.
Zu anderen Netzmanagement-Plattformen und -Anwendungen für das einfache Filtern von Alarmen, die im Handel erhältlich sind, gehören: (1) HP OpenView, Hewlett Packard Corp., 3000 Hanover Street, Palto, CA 94304; (2) LattisNet, SynOptics Communications, 4401 Great American Pkwy., Santa Clara, CA 95054; (3) IBM Netview/6000, IBM Corp., Old Orchard Road, Armonk, NY 10504; und (4) SunNet Manager, SunConnect, 2550 Garcia Ave, Mountain View, CA 94043.
Leider können bei den vorbekannten Systemen Alarme nur von einem Netzmanagement-Server empfangen werden. Außerdem gibt es keine Vorkehrungen zum Anwenden desselben richtliniengestützten Filters auf mehrere Netzmanagementanwendungen.
Somit ist es eine Aufgabe der vorliegenden Erfindung, eine bessere Kontrolle darüber bereitzustellen, welche Alarme Netzmanagement-Anwendungen gemeldet werden, und ein Mittel zur Sicherstellung der Stimmigkeit berichteter Alarme über mehrere Netzmanagementanwendungen hinweg bereitzustellen.
Ein Beispiel für eine Netzmanagementanwendung, die gemeldete Alarme verwendet, ist SpectroPHONETM von Cabletron Systems, Inc., Rochester, New Hampshire. SpectroPHONETM liefert einen Fernzugriff auf Alarminformationen von SpectrumTM von einem beliebigen Tonwahl-Fernsprecher aus. SpectroPHONETM ermöglicht dem Benutzer, über das öffentliche Fernsprechkommunikationssystem Anfragen zu stellen, und kann eingestellt werden, um den Benutzer automatisch von Alarmzuständen zu benachrichtigen.
Fig. 15 zeigt eine typische Konfiguration von SpectroPHONETM. Alarme 150 werden in einem Kommunikationsnetz erzeugt, und ein virtueller Netzmanager (VNM) 152 verwaltet die Informationen bezüglich dieser Alarme. SpectroPHONETM verwendet eine Computerfone-Einheit 154 als Vermittler zwischen einem Telefon 156 oder einem Pager 158 (oder einem beliebigen anderen Gerät auf dem öffentlichen Fernsprechkommunikationssystem) und den Alarminformationen aus dem VNM 152. Die Computerfone-Einheit 154 interpretiert außerdem Eingaben von einem Fern-Tonwahl-Tastenfeld und erzeugt dann eine Sprachausgabe aus den Alarminformationen für den Zuhörer an dem fernen Telefon 156 oder Pager 158.
SpectroPHONETM, Version 3.0, ist ein Verfahren und eine Vorrichtung zur Telefonbenachrichtigung nach dem Stand der Technik, wodurch Alarminformationen für kleinere Kommunikationsnetze oder für isolierte Segmente solcher Netze über eine Netzmanagement-Plattform, wie zum Beispiel SpectrumTM von Cabletron Systems, gesammelt und gemeldet werden. Weitere Beschreibungen der vorbekannten Version von SpectroPHONETM sind von der Cabletron Systems, Inc., Rochester, New Hampshire verfügbar.
Die heutigen Netze sind wesentlich größer und komplexer als die Netze der Vergangenheit. Folglich unterteilen Netzmanagement-Plattformen häufig diese für Leistungs- und Diagnosebewertungen logisch in Segmente. Da die vorbekannte Version von SpectroPHONETM nur ein einziges Segment des Netzes auf einmal überwachen kann, muss für eine vollständige Überwachung des Netzes auf jedem Segment des Netzes eine Instanz des Verfahrens und der Vorrichtung installiert werden.
Diese Installationsanforderung kann zu größeren Anschaffungs- und Wartungskosten, einer unbeständigen Datensammlung, verpassten Benachrichtigungen und zu einer Unmöglichkeit, Netzsegmentausfälle in bezug auf das gesamte Netz visuell darzustellen, führen. Außerdem ist ein Eingreifen durch den Benutzer notwendig, wenn Informationen von verschiedenen Segmenten erforderlich sind. Der Benutzer muss die Betriebsmittel-Dateien ändern, die der Netzmanagement- Plattform mitteilen, welches Segment abgefragt werden soll. Der Benutzer muss dann SpectroPHONETM stoppen und neu starten. Ein Benutzerfehler könnte zu ungültigen Betriebsmittelinformationen führen, und neue Segmente sind eventuell für SpectroPHONETM, Version 3.0, nicht sichtbar. Alle diese Situationen würden zu einer Dienstunterbrechung führen.
SpectroPHONETM, Version 3.0, fragt das Netz periodisch nach Alarminformationen ab. In einem großen Kommunikationsnetz können hunderte von Alarmen entstehen, es sind aber in der Regel nur wenige von ihnen kritisch genug, um unmittelbare Aufmerksamkeit zu rechtfertigen. Ein Ausfall, der unmittelbare Aufmerksamkeit erfordert, ist zum Beispiel ein Stromausfall auf einem zentralen Gerät, das viele andere Geräte verbindet. Deshalb wird bei vorbekannten telefonischen Verfahren und Vorrichtungen außerdem eine Filterung einer großen Anzahl von Alarmen durchgeführt, so daß der Benutzer von den Alarmen benachrichtigt wird, die kritisch für die Systemleistung sind. Das Verfahren und die Vorrichtung zur telefonischen Benachrichtigung im Stand der Technik enthalten jedoch nur begrenzte Filterfähigkeiten, die nur auf dem Namen und Typ des Geräts auf dem Netz und auf dem Ausmaß und der Art des Ausfalls basieren.
Somit ist es eine weitere Aufgabe der vorliegenden Erfindung, den Systemalarmbenachrichtigungsmanager der vorliegenden Erfindung in eine neue SpectroPHONETM-Anwendung zu integrieren. Als Ergebnis können Kommunikationsnetzadministratoren über das öffentliche Fernsprechkommunikationssystem über Ausfälle auf einem großen und komplexen Kommunikationsnetz mit Genauigkeit und mit Bezug nur auf Ausfälle, die für die Aufrechterhaltung der Leistung des Netzes kritisch sind, benachrichtigt werden.
Eine Veröffentlichung mit dem Titel "Rounding Out The Roster Of SNMP Agents", Data Communications 24, Januar 1995, Seiten 119-120, beschreibt ein Problem bei der Nachrichtenübermittlung bei SNMP (einfaches Netzmanagementprotokoll) zur Überwachung des Status von Anwendungen und Geräten auf dem großen verteilten Netz, und zwar, daß sie Bandbreite verbraucht und die Management-Konsole mit ankommenden Warnungen überhäufen kann. Die vorgeschlagene Lösung besteht darin, auf jedem der Netzgeräte oder -server ablaufende Teilnehmer und einen Bereichs-Systemmanager oder DB-Manager, der auf einem einzigen Netzgerät abläuft und die Teilnehmer abfragt und die Ergebnisse gemäß benutzerdefinierten SNMP-Schwellen anzeigt, bereitzustellen. Der Manager filtert Warnungen von mehreren Teilnehmern auf lokaler Basis, um den Abfrageverkehr und Warnungen vom Backbone fernzuhalten. Die lokalen Manager senden die gefilterten Warnungen zu einer zentralen Unternehmens-Ansichtsmanagementplattform, die nur diejenigen Alarme anzeigt, die die lokalisierte Filterung passieren.
Eine Veröffentlichung mit dem Titel "A Cool MOM Makes It Easy", Data Communications 24, Januar 1995, Seiten 120-121, beschreibt ein System, bei dem mehrere Netzmangement- Plattformen Warnungen zu einem Objekt-Server senden, der Regeln zum Korrelieren der Warnungen anwendet.
Eine Veröffentlichung mit dem Titel "Real Distributed Management", Data Communications 24, Januar 1995, Seiten 116- 118, beschreibt das Spectrum-Netzmanagementsystem, Version 3.0, von Cabletron mit mehreren Spectrum-Servern (SSs), wobei jeder Server einen einzelnen Netzbereich überwacht und Managementdaten bezüglich jedes Bereichs zu Benutzeroberflächenkonsolen meldet, die als Spektrographen (SGs) bezeichnet werden. Jeder SS kann mehrere Ereignisse in einem gegebenen Bereich korrelieren und einen Alarm ausgeben, wenn eine bestimmte Korrelation von Ereignissen auftritt. Diese Alarme werden in den SGs gezeigt.

Kurze Darstellung der Erfindung

Die vorliegende Erfindung betrifft eine Vorrichtung und ein Verfahren zur Alarmbenachrichtigung, umfassend: a) Empfangen von Alarmen von mehreren Netzmanagementservern; b) Zuweisen von auf Richtlinien basierenden Filtern zu zugeordneten Netzmanagementanwendungen; und Anwenden der auf Richtlinien basierenden Filter auf die Alarme, und für die Alarme, die die Filter passieren, Erzeugen einer Alarmbenachrichtigung, wobei diese zu den zugeordneten Netzmanagementanwendungen weitergeleitet wird.
Bei einer hier beschriebenen Ausführungsform legt ein Benutzer mehrere solche Filter, die eine Alarm-Benachrichtigungsrichtlinie bilden, für eine oder mehrere zugeordnete Netzmanagementanwendungen fest. Die auf Richtlinien basierenden Filter werden in einer Datenbank gespeichert, und zur Identifizierung jedes Filters wird eine Kennzeichnung zugewiesen. Dieselben Filter können mehreren Anwendungen zugewiesen werden.
Bei einer weiteren Ausführungsform kann der Benutzer die Zuweisung solcher auf Richtlinien basierenden Filter so einplanen, daß sie zu einem festgelegten Zeitpunkt in der Zukunft auftritt. Zum Beispiel kann ein Benutzer eine Richtlinie aus einer Liste verfügbarer Richtlinien auswählen, um sie einer gewählten Anwendung zuzuordnen, und dann die Häufigkeit, mit der die Richtlinie angewandt wird, z. B. einmal, stündlich, täglich, wöchentlich oder monatlich, angeben.
Außerdem kann die Erfindung im selben Modus wie ähnliche Werkzeuge im Stand der Technik verwendet werden, d. h. mit einer Alarmweiterleitungskomponente für jedes Paar von Netzmanagementsystem und Netzmanagementanwendung oder alternativ als eine einzige Entität in einer verteilten Netzmanagementumgebung.
Bei einer anderen Ausführungsform werden die Vorrichtung und das Verfahren der Alarmbenachrichtigung der erwähnten vorbekannten Ausführungsformen in ein Verfahren und eine Vorrichtung zur telefonischen Alarmbenachrichtigung integriert. Bei dieser Ausführungsform wird der Administrator des Kommunikationsnetzes über ein öffentliches Fernsprechkommunikationssystem von Alarmen benachrichtigt, die auf mehreren Segmenten eines Kommunikationsnetzes erzeugt wurden und die vorbestimmte, auf Richtlinien basierende Filter passiert haben.
Diese und andere Merkmale der vorliegenden Erfindung werden in der folgenden ausführlichen Beschreibung und in den Figuren ausführlicher beschrieben.

Kurze Beschreibung der Zeichnungen

Fig. 1 ist ein Beispiel für eine Alarm-Protokollanzeige, die von dem SpectrumTM-Netzmanagementsystem nach dem Stand der Technik bereitgestellt wird.
Fig. 2 ist ein Blockschaltbild eines Alarmbenachrichtigungsmanagers gemäß der vorliegenden Erfindung bei Verwendung mit mehreren Netzmanagementservern und mehreren Netzmanagementanwendungen.
Fig. 3 ist ein Flußdiagramm, das die erfindungsgemäße Anwendung von auf Richtlinien basierenden Filtern auf einen Alarm und des Weiterleitens des Alarms, der die Filter passiert, zu einer Anwendung veranschaulicht.
Fig. 4 ist ein Beispiel einer Fensterdarstellung für Zuordnungen (engl.: Association window display) des Alarmbenachrichtigungsmanagers.
Fig. 5 ist ein Beispiel einer Fensterdarstellung für neue (engl.: New Association window display) des Alarmbenachrichtigungsmanagers.
Fig. 6 ist ein Beispiel einer Fensterdarstellung für modifizierte Zuordnungen (engl.: Modified Association window display) des Alarmbenachrichtigungsmanagers.
Fig. 7 ist ein Beispiel einer Fensterdarstellung für eine Ablaufsteuerung (engl.: Scheduler window display) des Alarmbenachrichtigungsmanagers.
Fig. 8 ist ein Beispiel einer Fensterdarstellung für Richtlinien (engl.: Policies window display) des Alarmbenachrichtigungsmanagers.
Fig. 9 ist ein Beispiel einer Fensterdarstellung für das Öffnen von Richtlinien (engl.: Open Policies window display) des Alarmbenachrichtigungsmanagers.
Fig. 10 ist ein Beispiel einer Fensterdarstellung zum Hinzufügen von Filterwerten (engl.: Add Filter Values window display) des Alarmbenachrichtigungsmanagers.
Fig. 11 ist ein Beispiel einer Fensterdarstellung des Alters des Alarms (engl.: Alarm Age window display) des Alarmbenachrichtigungsmanagers.
Fig. 12 ist ein Beispiel der Fensterdarstellung für neue Richtlinien (engl.: New Policy window display) des Alarmbenachrichtigungsmanagers.
Fig. 13 ist ein Blockschaltbild zweier separater Prozesse zwischen der Netzmanagementanwendung und dem Alarmbenachrichtigungsmanager.
Fig. 14 ist ein Blockschaltbild, das eine zentrale Verarbeitungseinheit und Speicher zur Verwendung in der vorliegenden Erfindung darstellt.
Fig. 15 ist eine typische Konfiguration eines Kommunikationssystems, das eine vorbekannte SpectroPHONETM-Anwendung verwendet.
Fig. 16 ist ein Blockschaltbild der Integration der auf Richtlinien basierenden Filterung in das Verfahren und die Vorrichtung zur telefonischen Alarmbenachrichtigung gemäß der vorliegenden Erfindung.
Fig. 17 ist ein Blockschaltbild, das die Integration des System-Alarmbenachrichtigungsverfahrens (SANM, engl.: System Alarm Notification Method) der vorliegenden Erfindung in eine neue SpectroPHONETM-Anwendung veranschaulicht.
Fig. 18 ist ein Beispiel für eine Fensterdarstellung der grafischen Benutzeroberfläche (GUI, engl.: Graphical User Interface) für eine neue SpectroPHONETM-Anwendung.

Ausführliche Beschreibung

Die vorliegende Erfindung betrifft einen Alarmbenachrichtigungsmanager, der Alarme von mehreren Netzmanagementservern empfängt, die Definition einer unbegrenzten Anzahl von Filtern innerhalb einer Richtlinie ermöglicht, ein Benennen und Speichern von Richtlinien in einer Datenbank ermöglicht, eine Richtlinien-Ablaufplanung für verschiedene Zeiten ermöglicht und ein Anwenden derselben Richtlinie auf eine oder mehrere Netzmanagementanwendungen ermöglicht.
Wie in Fig. 2 dargestellt, ist ein in Betrieb befindliches Netz 10 durch Strecken 11 mit einem oder mehreren Netzmanagementservern 12 verbunden, die das Netz überwachen. Die Server erkennen Fehler oder Störungen auf dem Netz und senden über die Strecken 13 Alarminformationen zu dem Alarmbenachrichtigungsmanager 14. Der Alarmbenachrichtigungsmanager enthält eine Richtliniendatenbank 16, ein Verfahren zum Anwenden von Richtlinien auf Alarme 18, eine grafische Oberfläche 20 und eine Ablaufsteuerung 22. Der Manager wendet auf Richtlinien basierende Filter auf die von den Servern empfangenen Alarmnachrichten an, und für diejenigen Alarme, die die Filterkriterien passieren, wird über die Strecken 23 eine Alarmnachricht zu der entsprechenden Netzmanagementanwendung 24 gesendet.
Bei einer hier beschriebenen spezifischen Ausführungsform werden zur Modellierung des in Betrieb befindlichen Netzes 10 mehrere verteilte SpectroServerTM verwendet, die Teil des Systems SpectrumTM von Cabletron Systems, Inc., Rochester, New Hampshire sind, und mehrere SpectrumTM-Anwendungen empfangen die gefilterten Alarmnachrichten aus dem Manage 14. Diese Komponenten wurden in der objektorientierten Programmiersprache C++ implementiert. Die Erfindung ist jedoch nicht an eine bestimmte Sprache und auch nicht auf etwaige bestimmte im Netzmanagement verwendete Produkte gebunden.

Das SpectrumTM-Netzmanagementsystem

Ein Verständnis der vorliegenden Erfindung wird durch ein Verständnis des als SpectrumTM bekannten modellgestützten Netzmanagementsystems vermittelt, das in dem U.S.-Patent Nr. 5,261,044, erteilt am 9.11.1993 an R. Dev et al., beschrieben wird, worauf hiermit ausdrücklich und vollständig Bezug genommen wird. Das SpectrumTM-Netzmanagementsystem ist im Handel erhältlich und wird außerdem in verschiedenen Benutzerhandbüchern und in von Cabletron Systems, Inc., Rochester, New Hampshire, verfügbarer Literatur beschrieben.
Zusammenfassend ist SpectrumTM ein System zum Unterhalten und Verarbeiten von Informationen bezüglich des Zustands des Computernetzes und zum Bereitstellen dieser für einen Benutzer, wobei das Netz mehrere Netzentitäten, wie zum Beispiel Computergeräte und auf solchen Geräten ausgeführte Softwareanwendungen, enthält. Das System enthält eine virtuelle Netzmaschine, die einen programmierten digitalen Computer umfaßt, wobei ein Programm unter Verwendung einer objektorientierten Programmiersprache wie zum Beispiel C++, Eiffel, SmallTalk oder Ada, implementiert wird. Das virtuelle Netz besteht aus miteinander zusammenhängenden intelligenten Modellen von Netzentitäten und Relationen zwischen Netzentitäten, darunter Mittel zum Erfassen von Netzdaten bezüglich des Zustands einer Netzentität von der entsprechenden Netzentität. Das virtuelle Netz enthält ferner Mittel zum Aufrechterhalten von Objekten, die Netzdaten enthalten, die mit der entsprechenden Netzentität zusammenhängen, und einen oder mehrere Inferenz-Handler zur Verarbeitung der Netzdaten, wobei die Inferenz-Handler auf Änderungen reagieren, die in demselben und/oder einem anderen Objekt auftreten. Die Netzdaten können dann zu einer mit der virtuellen Netzmaschine gekoppelten Benutzeroberfläche übermittelt werden, um die Netzdaten einem Benutzer zuzuführen.
Somit werden die Modelle als Software-"Objekte" implementiert, die sowohl "Daten" (Attribute), die mit der entsprechenden Netzentität zusammenhängen, als auch einen oder mehrere "Inferenz-Handler" (Funktionen) zur Verarbeitung der Daten enthalten. Siehe Grady Booch "Object-Oriented Analysis And Design, With Applications", 2. Auflage, Benjamin/Cummings Publishing Co., Redwood City, CA, Kapitel 2, 1994. Die Inferenz-Handler werden durch vorbestimmte virtuelle Netzereignisse eingeleitet, wie zum Beispiel eine Änderung von spezifizierten Netzdaten in demselben Modell, eine Änderung spezifizierter Netzdaten in einem anderen Modell und vordefinierte Ereignisse oder Veränderungen in Modellen oder Modellrelationen. Informationen bezüglich des Zustands der Netzentität können aus der Netzentität durch Abfragen dieser erhalten, automatisch von der Netzentität (ohne Abfrage) empfangen oder aus in anderen Modellen enthaltenen Daten gewonnen werden. Ein Alarmzustand kann erzeugt werden, wenn die Netzdaten ein vorbestimmtes Kriterium erfüllen. Ereignisse, Alarme und statistische Informationen aus dem virtuellen Netz werden in einer Datenbank gespeichert und selektiv für den Benutzer angezeigt.
Die Daten in der SpectrumTM-Datenbank können zur Erzeugung topologischer Anzeigen des Netzes verwendet werden, wobei hierarchische Beziehungen zwischen Netzgeräten gezeigt, ein Netzfehler isoliert und statistische Informationen begutachtet werden.
SpectrumTM ermöglicht ein kollektives Management autonomer lokaler Netze (LANs) mit Geräten von verschiedenen Herstellern. Es entspricht den Standards des aktuellen SNMP (Simple Network Management Protocol) und kann außerdem andere standardmäßige und proprietäre Protokolle berücksichtigen. Die virtuelle Netzmaschine führt eine Vorverarbeitung der rohen Informationen aus den Netzgeräten durch, um ein Modell des aktuellen Status und der Leistungskenngrößen des Netzes zu konstruieren. Netzelemente, mit denen nicht direkt kommuniziert werden kann (z. B. Kabel und Gebäude), können auf ihren Status von dem Status der mit ihnen verbundenen (oder in ihnen enthaltenen) Geräte schließen. Die virtuelle Netzmaschine liefert eine konsistente Schnittstelle für Managementanwendungen zum Zugriff auf beliebige der Informationen in dem Modell und stellt diesen Anwendungen dadurch eine vereinigte Ansicht des Netzes bereit.
Die zugehörige SpectroGRAPHTM-Benutzeroberfläche von SpectrumTM liefert eine hochgrafische mehrfachperspektivische Ansicht in das Netzmodell. Durch SpectroGRAPHTM können Benutzer durch eine Landschaft navigieren, in der Kabel, Netze, lokale Netze und sogar Räume als Symbole dargestellt sind, und wobei die Symbole den Gesundheitszustand und die Leistungskenngrößen dieser Elemente anzeigen. Diese Symbole können weiter nach zusätzlichen Informationen abgefragt werden. Die Hauptfunktion von SpectroGRAPHTM besteht darin, dem Benutzer visuell das Modell in der virtuellen Netzmaschine darzustellen. Dadurch kann der Benutzer frei in dem Netzmodell navigieren und ist nur durch die vom Netzadministrator zugewiesenen Zugangsrechte beschränkt. Die Informationen können mit verschiedenen Auflösungsgraden abgerufen werden, von einer Makro-Übersicht bis zu den Geräten und Kabeln, die diese verbinden. Zusätzlich zu seinen Navigationsfunktionen liefert SpectroGRAPHTM eine Alarmmanagementvorrichtung, ein Ereignisprotokollfenster, eine Meldevorrichtung, eine Suchvorrichtung und andere Merkmale.
Die obige Beschreibung des SpectrumTM-Systems liefert einen Kontext für ein Verständnis der vorliegenden Erfindung.

Der Alarmbenachrichtigungsmanager

Die folgenden Definitionen sind hilfreich für ein Verständnis der vorliegenden Erfindung.
SANM-SPECTRUMTM Alarmbenachrichtigungsmanager Richtlinie Eine Menge von Kriterien, die ein gegebener Alarm erfüllen muss, um zu der Anwendung weitergeleitet zu werden, der die Richtlinie zugeordnet ist. Eine Richtlinie kann aus einem oder mehreren Filtern bestehen.
Filter Eine Menge von Filterparametern und zugeordneten Filterwerten. Mehrere Filter definieren mehrere Mengen von Werten für die Filterparameter.
Filterparameter Ein Datentyp, wie zum Beispiel ein Modellname oder IP-Subnetz, wofür der Benutzer einen Wert oder eine Liste von Werten angeben kann. SANM gibt dem Benutzer eine feste Liste von Filterparametern.
Zuordnung Wenn der Benutzer eine Richtlinie einer Anwendung zuordnet, gibt er die Filterkriterien an, die SANM auf die Alarme, die es zu der Anwendung sendet, anwenden soll.
Ein Filter besteht aus einer Liste von Filterparametern und einer Liste zugeordneter Filterwerte. Ein Benutzer (einer Netzmanagementanwendung) gibt den Wert bzw. die Werte an, den bzw. die jeder Filterparameter annehmen kann, damit ein gegebener Alarm die Filterkriterien passiert. Es folgt eine Liste repräsentativer Filterparameter:
- Modellname
- Modelltypname
- Geräte-IP-Subnetz
- Geräteposition
- Alarm-Umfang
- Alarm-Alter
- Hostname des SpectroSERVER
- Landschaftsname (engl.: landscape name)
- Alarmursache
Der Wert für jeden der obigen Filterparameter würde von SpectrumTM empfangen, mit Ausnahme des Alarmalterparameaers. Der Alarmalterparameter wird intern von SANM verwendet und gibt die Zeitdauer an, für die er einen Alarm halten sollte, bevor er ihn zu einer Anwendung sendet. Wenn der Alarm während dieser Zeit von SpectrumTM gelöscht wird, wird er nicht zu der Anwendung gesendet. Dieses Merkmal kann zum Ausfiltern transienter Alarme dienen.
Jeder Filterwert weist außerdem eine entsprechende Kennzeichnung (Flag) auf, die angibt, ob er negiert werden soll. Wenn das Negierungsflag zum Beispiel für einen Modelltypnamenwert von Hub_CSI_IRM3 gesetzt wird, sagt dieser Filterwert aus, daß alle Alarme für Modelle, die NICHT vom Typ Hub CSI_IRM3 sind, passieren sollten.
Eine komplexere Filterung lässt sich durch Definieren mehrerer Filter in einer Richtlinie erzielen. Jedes Filter gibt eine separate Menge von Filterwerten an.
SANM führt eine logische AND-Verknüpfung aller Filterkriterien in einem Filter und eine logische OR-Verknüpfung zwischen allen Filtern in einer Richtlinie durch.
Zum Beispiel enthält eine Richtlinie zwei Filter wie folgt:

Filter 1

Modelltyp: Rtr_Cisco
Landschaft: wiz

Filter 2

Modelltyp: Rtr_Wellfleet
Landschaft: brat
SANM würde diese Richtlinie folgendermaßen auf einen gegebenen Alarm anwenden:
IF der Alarm folgendes aufweist:
Modelltyp Rtr_Cisco AND Landschaft wiz OR Modelltyp Rtr_Wellfleet AND Landschaft brat THEN Alarm zu der Anwendung senden.
Jedes Filter enthält außerdem eine Filterkennzeichnung, bei der es sich um eine Textzeichenkette handelt, die der Benutzer eingibt. Diese Kennzeichnung, die in der Alarmbenachrichtigung enthalten ist, identifiziert, welches bzw. welche Filter passierten und kann von einer Anwendung zum Routen von Alarmen verwendet werden.
Zum Beispiel kann man in das Filterkennzeichnungsfeld jedes Filters einen verschiedenen Benutzernamen eingeben, so daß, wenn die Kriterien in einem Filter passieren, die Anwendung einen bestimmten Benutzer benachrichtigt, während, wenn die Kriterien in einem anderen Filter passieren, die Anwendung einen anderen Benutzer benachrichtigt. Wenn mehrere Filter passieren, wird eine Liste entsprechender Filterkennzeichnungen in der Alarmbenachrichtigung gesendet.
Ein weiteres Beispiel für den SANM-Filtermechanismus ist in Fig. 3 gezeigt. In dieser Figur sind die in jedem Filter aufgelisteten Kriterien die Kriterien, für die Werte vom Benutzer angegeben wurden. Aus diesem Beispiel ist ersichtlich, daß alle Filter parallel auf einen gegebenen Alarm angewandt werden (d. h. es wird eine logische OR-Verknüpfung zwischen Filtern durchgeführt). Alle Kriterien in einem gegebenen Filter müssen jedoch erfüllt sein, damit der Alarm das Filter passiert (d. h. es wird eine logische AND- Verknüpfung zwischen den Kriterien in einem gegebenen Filter durchgeführt). Da in diesem Beispiel der Alarm die Kriterien in den Filtern 1 und 3 passiert, wird eine Alarmbenachrichtigung, die die Filterkennzeichnungen "A" und "C" enthält, zu der Anwendung gesendet.
Richtlinien und die Zuordnungen zwischen Richtlinien und Anwendungen werden in der SPECTRUMTM-Datenbank gespeichert. Dies bedeutet, daß jeder beliebigen Client-Maschine, auf der SANM abläuft, dieselben Richtlinien verfügbar sind. Es bedeutet außerdem, daß die in den durch SANM protokollierten Ereignisnachrichten enthaltenen Richtliniennamen für alle Client-Maschinen, die dieselbe SPECTRUMTM-Datenbank benutzen, Bedeutung haben.

1.0 Alarmbenachrichtigung

Nachdem sich eine Anwendung bei SANM registriert hat, um Alarme zu empfangen, wird dieser Anwendung jedes Mal, wenn ein Alarm von SPECTRUMTM, der die in der dieser Anwendung zugeordneten Richtlinie angegebenen Kriterien passiert, empfangen wird, eine Alarmbenachrichtigung gesendet. Die in jeder Alarmbenachrichtigung enthaltenen Informationen bestehen aus Echtzeitwerten jedes Filterparameters plus den Werten der folgenden Parameter:
- Modell-Handle (engl.: model handle)
- Modelltyp-Handle
- Modellzustandswert
- Modellsicherheits-Zeichenkette
- Alarm-ID
- Alarmzeit
- wahrscheinliche Ursache des Alarms
- Alarmstatus
- dem Alarm zugeordnete Ereignisnachricht
- zugewiesene Reparaturperson
- vom Benutzer löschbare Kennzeichnung
Dabei ist eine Ausnahme, daß eine IP-Subnetzadresse als ein Filterkriterium angegeben werden kann, aber die vollständige IP-Adresse des Geräts, das den Alarm erzeugt hat, in der Alarmbenachrichtigung weitergeleitet wird.
Eine Benachrichtigung, daß ein Alarm gelöscht oder aktualisiert wurde, wird zu einer Anwendung gesendet, wenn SANM eine solche Benachrichtigung von SPECTRUMTM empfängt, aber nur dann, wenn der Alarm, der gerade gelöscht oder aktualisiert wird, zuerst zu der Anwendung gesendet wurde, als er auftrat (d. h. er die Filterkriterien für diese Anwendung passiert hat).

2.0 Konfigurationswerkzeug

Das SANM-Konfigurationswerkzeug gibt dem Benutzer die Möglichkeit, Alarmbenachrichtigungsrichtlinien zu definieren und diese Richtlinien den Anwendungen, die SANM benutzen, zuzuordnen.
Das Konfigurationswerkzeug wird durch Wählen des Benachrichtigungsmanagers aus dem Stern-Menü von SpectroGRAPHTM aufgerufen.

2.1 Zuordnungsfenster

Wenn das Konfigurationswerkzeug aufgerufen wird, erscheint als erstes das Zuordnungsfenster (siehe Fig. 4). Dieses Fenster zeigt eine Liste der gerade definierten SANM- Anwendungen und die Richtlinie, die jeder dieser zugeordnet ist.
Eine neue Zuordnung wird durch Wählen von New aus dem File- Menü erzeugt. Dadurch wird das in Fig. 5 gezeigte Fenster Neue Zuordnung hervorgebracht.
Eine bestehende Zuordnung wird modifiziert durch Wählen der Zuordnung und anschließendes Wählen von Modify aus dem File- Menü. Dadurch wird das in Fig. 6 gezeigte Fenster Zuordnung modifizieren hervorgebracht.
Eine bestehende Zuordnung wird gelöscht durch Wählen der Zuordnung und anschließendes Wählen von Delete (Löschen) aus dem File-Menü. Die gewählte Zuordnung wird gelöscht, nachdem der Benutzer die Operation in einem (nicht gezeigten) Fenster "Confirmation Dialog" (Dialog bestätigen) bestätigt. Die Modifikation einer bestehenden Zuordnung kann durch Wählen der Zuordnung und anschließendes Wählen von Schedule aus dem File-Menü geplant werden. Dadurch wird das in Fig. 7 gezeigte Ablaufsteuerungsfenster hervorgebracht.
Alle gerade definierten Richtlinien können begutachtet werden, indem Policies aus dem Tools-Menü gewählt wird. Dadurch wird das in Fig. 8 gezeigte Policies-Fenster hervorgebracht.

2.2 Das Fenster "Neue Zuordnung"

Das Fenster "Neue Zuordnung" ist in Fig. 5 dargestellt. In diesem Fenster wird aus der Liste verfügbarer Richtlinien eine Richtlinie ausgewählt, und der Anwendungsname wird eingegeben. Wenn OK gedrückt wird, verschwindet das Fenster und die neue Zuordnung erscheint in dem Zuordnungsfenster (Fig. 4).

2.3 Das Fenster "Zuordnung modifizieren"

Das Fenster "Zuordnung modifizieren" ist in Fig. 6 dargestellt. In diesem Fenster wählt der Benutzer eine Richtlinie aus der Liste verfügbarer Richtlinien, die der gewählten Anwendung (in diesem Beispiel SpectroPHONETM von der Cabletron Systems, Inc.) zugeordnet wird. Durch Drücken von OK verschwindet dieses Fenster und die modifizierte Zuordnung wird in dem Ablaufplanungsfenster (Fig. 4) angezeigt.

2.4 Das Scheduler-Fenster

Das Scheduler-Fenster ist in Fig. 7 dargestellt. Durch Drücken der Associate-Taste wird das in Fig. 6 dargestellte Fenster Modify Association hervorgebracht. In dem Fenster Modify Association wählt der Benutzer aus der Liste verfügbarer Richtlinien eine Richtlinie, die der gewählten Anwendung (in diesem Beispiel SpectroPHONETM) zugeordnet werden soll. In dem Scheduler-Fenster drückt der Benutzer dann die Frequency-Taste, um die Häufigkeit der Zuordnung anzugeben. Die Frequency-Optionen lauten: Einmal (Once), Stündlich (Hourly), Täglich (Daily), Wöchentlich (Weekly) und Monatlich (Monthly). Die Informationen in dem Bereich unterhalb der Frequency-Taste ändern sich abhängig davon, welche Häufigkeitsoption gewählt wird, auf die folgende Weise:
- Durch die Einmal-Funktion kann der Benutzer den Monat, den Tag und die Startzeit angeben.
- Durch die Stündlich-Option kann der Benutzer die Anzahl von Minuten nach jeder Stunde angeben
- Durch die Täglich-Option kann der Benutzer die Zeit angeben.
- Durch die Wöchentlich-Option kann der Benutzer den Wochentag und die Zeit angeben.
- Durch die Monatlich-Option kann der Benutzer den Tag des Monats und die Zeit angeben.
Nachdem die gewünschten Ablaufsteueroptionen gewählt wurden, fügt ein Drücken der Add-Taste die Ablaufsteuerinformationen in den Teil Scheduled Entries des Fensters ein. Weitere Einträge können durch Wiederholen der obigen Schritte hinzugefügt werden. Einträge können modifiziert und entfernt werden, indem sie gewählt und die Tasten Modify und Remove benutzt werden.

2.5 Das Richtlinien-Fenster

Das Richtlinien-Fenster ist in Fig. 8 dargestellt. Dieses Fenster zeigt alle gerade definierten Richtlinien.
Eine neue Richtlinie wird durch Wählen von New aus dem File- Menü erzeugt. Dadurch erscheint das Fenster New Policy (Fig. 12).
Eine bestehende Richtlinie wird betrachtet und modifiziert durch Wählen der Richtlinie und anschließendes Wählen von Open aus dem File-Menü. Dadurch erscheint das Fenster Open Policy (Fig. 9).
Eine bestehende Richtlinie wird gelöscht durch Wählen der Richtlinie und anschließendes Wählen von "Delete" (Löschen) aus dem File-Menü. Die gewählte Richtlinie wird gelöscht, nachdem der Benutzer die Operation in einem (nicht gezeigten) Fenster "Confirmation Dialog" bestätigt.

2.6 Das Fenster "Richtlinie öffnen"

Das Fenster "Richtlinie öffnen" ist in Fig. 9 dargestellt. Dieses Fenster zeigt alle Filter, aus denen die Richtlinie besteht. In dem in Fig. 9 gezeigten Beispiel sind die Filter 1 und 2 sichtbar, nachfolgende Filter können jedoch betrachtet werden, indem man die Rollleiste auf der rechten Seite des Fensters benutzt. Ähnlich kann man die anderen Filterparameter für Filter 1 und ihre zugeordneten Werte mit der Rollleiste unter den Filterparametern des Filters 1 betrachten.
Um die angezeigte Richtlinie zu modifizieren, muss "Edit" (Bearbeiten) aus dem File-Menü gewählt werden. Das View- Element in der Menüleiste wird dann zu Edit. Im Edit-Modus können dann mehrere Werte für einen bestimmten Filterparameter gelöscht oder negiert werden, indem man die Werte wählt und die Delete- oder Negate-Taste (Löschen oder Negieren) drückt. Werte können für einen bestimmten Filterparameter hinzugefügt werden, indem man die Filterparametertaste drückt (z. B. Landschaft oder Modelltyp). Dies bringt ein separates Fenster hervor, das eine Liste verfügbarer Werte enthält, aus der mehrere Werte gewählt werden können. Ein Beispiel für dieses Fenster ist in Fig. 10 gezeigt.
Filterparameter können zu einem Filter hinzugefügt werden, indem man die Parameter-Taste in dem Filter drückt. Ein Popup-Menü erscheint, das alle acht Filterparameter enthält. Die Filterparameter, die bereits in dem Filter vorhanden sind, sind jedoch grau herausgenommen und können nicht gewählt werden. Ein Wählen einer der verfügbaren Filterparameter aus diesem Menü bewirkt, daß der neue Filterparameter und eine zugeordnete Werte-Box in dem Filter erscheinen.
Das Alarmalter für ein bestimmtes Filter kann durch Drücken der "Alter"-Taste in dem Fenster "Richtlinie öffnen" modifiziert werden. Dadurch wird das in Fig. 11 gezeigte Fenster "Alarmalter" hervorgebracht. Die Werte für die Stunden- und Minuten-Felder enthalten zu Anfang die Werte aus dem "Alter" -Textfeld in dem Fenster "Richtlinie öffnen". Diese Werte können mit den Aufwärts- und Abwärts-Pfeiltasten für Stunden und Minuten modifiziert werden.
Eine Filterkennzeichnung kann in dem Fenster "Filter öffnen" durch direktes Eintippen in das Tag-Textfeld eines Filters modifiziert werden.
Durch Drücken der Taste "Filter erzeugen" kann ein neues Filter zu der in dem Fenster "Filter öffnen" angezeigten Richtlinie hinzugefügt werden. Dies bewirkt, daß ein neues Filter ohne Filterparameter am Ende der Filterliste hinzugefügt werden kann.
Ein bestehendes Filter kann auch dupliziert werden. Dazu muss zuerst das zu duplizierende Filter durch Klicken in dem Filterkennzeichnungsfeld (z. B. den Bereich um die Kennzeichnung Filter 2 herum) geklickt und dann die Taste "Filter duplizieren" gedrückt werden. Dies bewirkt, daß ein neues Filter, das dieselben Filterparameter und Werte wie das gewählte Filter enthält, am Ende der Filterliste hinzugefügt wird. Dieses neue Filter kann dann modifiziert werden.
Nach dem Modifizieren einer Richtlinie kann Save (Speichern) aus dem File-Menü gewählt werden, um die modifizierte Richtlinie unter ihrem bestehenden Namen zu sichern, oder es kann Save As (Speichern unter) gewählt werden, um die modifizierte Richtlinie unter einem anderen Namen zu sichern.
Die Informationen in dem Fenster "Richtlinie öffnen" können durch Wählen von Print (Drucken) aus dem File-Menü ausgedruckt werden.

2.7 Das Fenster "Neue Richtlinie"

Das Fenster "Neue Richtlinie" ist in Fig. 12 dargestellt. Die in dem Fenster "Neue Richtlinie" ausführbaren Operationen sind dieselben wie die in dem Fenster "Richtlinie öffnen" (Fig. 9) durchgeführten. Es erscheinen zuerst keine Filterparameter in Filter 1, so daß die erste Operation, die durchgeführt werden muss, das Wählen eines Filterparameters durch Drücken der Parameter-Taste in Filter 1 ist. Alle Filterparameter sind an diesem Punkt aus dem Popup-Menü verfügbar, da das Filter noch keine Filterparameter enthält.
Eine neue Richtlinie wird durch Wählen von "Save As" aus dem File-Menü und Eingeben des Namens für die Richtlinie in einer Dialog-Box gesichert.

3.0 Integration von SANM und Anwendung

Ein Entwickler würde die folgende Schnittstelle benutzen, um eine in C oder C++ geschriebene Anwendung mit dem SpectrumTM- Alarmmechanismus zu integrieren.
Eine Anwendung, die SANM zum Empfangen von Alarmbenachrichtigungen und zum Löschen/Bestätigen von Alarmen verwendet, erfordert zwei separate Prozesse, wie in Fig. 13 dargestellt.
Als ein Beispiel dafür, wie diese beiden separaten Prozesse in einer Anwendung verwendet werden würden, würde das Produkt ARS GatewayTM Prozess 1 verwenden, um gefilterte Alarme aus SANM zu empfangen, diese zu Trouble Tickets (Störungs- Tickets) formatieren und sie in der ARS-Datenbank ablegen. Prozess 2 würde verwendet, wenn ein Benutzer, der ein bestimmtes Trouble-Ticket (Fehlerbenachrichtigung) betrachtet, eine Lösch- oder Bestätigungstaste in dem Trouble-Ticket drückt.
Es werden zwei verschiedene Programmierungs-Paradigmata für die beiden Anwendungsprozesse, die SANM benutzen, benötigt:
Für den Prozeß, der Alarmbenachrichtigungen von SANM empfängt, wird ein asynchrones Callback-Paradigma verwendet. Das heißt, daß, wenn sich der Anwendungscode bei SANN registriert, um Alarme zu empfangen, er die Programmsteuerung an SANM übergibt. Wenn SANM eine Alarmbenachrichtigung zu der Anwendung senden muss, empfängt die Anwendung ein Callback von SANM. Dieser Prozeß wird beendet, indem ihm ein TERM (Endesignal, 15) gesendet wird.
Für den Prozeß, der Alarme löscht oder bestätigt, wird jedoch ein synchrones Paradigma verwendet. Das heißt, daß der Anwendungscode in diesem Prozeß die Programmsteuerung besitzt. Wenn dieser Anwendungscode einen Aufruf zu dem SANM API durchführt, um einen Alarm zu löschen oder zu bestätigen, blockiert der Aufruf die Anwendung, bis es beendet ist.

3.1 Definitionen und Datenstrukturen

Alle Definitionen und Datenstrukturen sind in der SANM-Kopfdatei sanm.h enthalten und werden unten beschrieben.
Der Prototyp für die Callback-Funktionen der Anwendung wird folgendermaßen definiert:
typedef void (*SANMCb) (struct SANM_Alarm_Notify*);
Alle Daten in einer Alarmbenachrichtigung sind in der SANM_Alarm_Notify-Struktur enthalten, die folgendermaßen definiert ist:
Alle Fehler und Warnungen werden folgendermaßen in der Auflistung SANM_error definiert:

3.2 Funktionen

Die Funktionen, aus denen SANM C/C++ API besteht, werden in den folgenden Abschnitten in einem Handbuchseitenformat beschrieben.

3.2.1 SANMInit

NAME SANMInit - Interaktion mit SANM initialisieren SYNOPSIS #include "sanm.h" SANM_error SANMInit (char *application name, SANMBoolean rcv_or_clr);

BESCHREIBUNG

SANMInit dient zur Initialisierung des Programms für die Interaktion mit SANM. Diese Funktion sollte von innerhalb beider Anwendungsprozesse vor jeder anderen Funktion in der SANM API aufgerufen werden.

EINGANGSARGUMENTE

application_name der Name, der vom Benutzer zur Indentifizierung dieser Anwendung bei Verwendung des Configuration Tool zur Zuordnung der Richtlinie zu ihr verwendet werden muss.
rev_or_clr ein Flag, das angibt, ob dieser Prozeß Alarmbenachrichtigungen empfangen oder Alarme löschen/bestätigen wird. Dieses Flag kann einen der beiden folgenden Werte annehmen: SANM_RCV_ALARMS SANM_CLR_ALARMS

ZURÜCKGELIEFERTE WERTE

status Der zurückgelieferte Wert weist einen der folgenden Werte auf: SANM_RETURN_OK

3.2.2 SANMRegister

NAME SANMRegister - bei SANM registrieren
SYNOPSIS #include "sanm.h"
SANM_error SANMRegister (SANMCb set_cb, SANMCb clear_cb, SANMCb update_cb);

BESCHREIBUNG

SANMRegister registriert die Anwendung, damit sie Alarmbenachrichtigungen von SANM empfängt. Durch Aufrufen dieser Funktion gibt die Anwendung die Programmsteuerung an SANM ab, bis eine der Callback-Funktionen der Anwendung aufgerufen wird.

EINGANGSARGUMENTE

set_cb Name der Funktion, die SANM aufruft, um eine Alarmbenachrichtigung für einen neuen Alarm zu senden. Alle Anwendungen müssen eine gültige Funktion für diesen Parameter weiterleiten.
clear_cb Name der Funktion, die SANM aufruft, um eine Alarmbenachrichtigung für einen gelöschten Alarm zu senden. Dieser Parameter kann NULL sein, wenn die Anwendung keine Benachrichtigungen für gelöschte Alarme empfangen will.
update_cb Name der Funktion, die SANM aufruft, um eine Alarmbenachrichtigung für einen aktualisierten Alarm zu senden. Dieser Parameter kann NULL sein, wenn die Anwendung keine Benachrichtigungen für aktualisierte Alarme empfangen will.

ZURÜCKGELIEFERTE-WERTE

status Im normalen Betrieb kehrt diese Funktion niemals zurück. Wenn sie jedoch versagt, wird einer der folgenden Fehler zurückgegeben: SANM_REGISTER_ERROR

3.2.3 SANMClear

NAME SANMClear - einen Alarm löschen
SYNOPSE #include "sanm.h" SANM_error SANMClear (SANMUlong alarm_ID, char*landscape)

BESCHREIBUNG

SANMClear löscht einen Alarm in SPECTRUM. Eine Anwendung kann nur Alarme löschen, für die sie Benachrichtigungen aus SANM empfangen hat. Außerdem muss das Flag user clearable in der Alarmbenachrichtigung auf CLEARABLE gesetzt worden sein.

EINGANGSARGUMENTE

alarm-ID ID des zu löschenden Alarms landscape die Landschaft, die den Alarm erzeugt hat

ZURÜCKGELIEFERTE-WERTE

status Der Rückkehr-Wert ist einer der folgenden Werte SANM_RETURN_OK SANM_INVALID_ALARM SANM_INVALID_LANDSCAPE SANM_ALARM_NOT_CLEARABLE

3.2.4 SANMack

NAME SANMAck - einen Alarm bestätigen SYNOPSIS #include "sanm. h" SANN error SANMAck (SANMUlong alarm_ID, char*landscape);

BESCHREIBUNG

SANMAck bestätigt einen Alarm in SPECTRUM. Eine Anwendung kann nur Alarme bestätigen, für die sie Benachrichtigungen von SANM empfangen hat.

EINGANGSARGUMENTE

alarm_ID ID des zu bestätigenden Alarms
landscape Die Landschaft, die den Alarm erzeugt hat

ZURÜCKGELIEFERTE-WERTE

status Der Rückkehr-Wert ist einer der folgenden Werte: SANM_RETURN_OK SANM_INVALID_ALARM SANM_INVALID_LANDSCAPE
Die vorliegenden Ausführungsformen können in einem Vielzweck-Computer 70, wie in Fig. 14 gezeigt, implementiert werden. Der Vielzweck-Computer kann eine Computer- Verarbeitungseinheit (CPU) 71, Speicher 72, einen Verarbeitungsbus 73, durch den die CPU auf den Speicher zugreifen kann, und eine Schnittstelle 74 zum Rest des Alarmbenachrichtigungsmanagers enthalten.
Bei alternativen Ausführungsformen kann die Erfindung eine Computervorrichtung sein, die die Funktionen beliebiger der obigen Ausführungsformen durchführt. Als Alternative kann die Erfindung ein Speicher sein, wie zum Beispiel eine Diskette, eine Compakt-Disk oder eine Festplatte, der das Computerprogramm oder die Datenstruktur zur Bereitstellung der Vielzweck-Computer-Befehle und -Daten zum Ausführen der Funktionen der obigen Ausführungsform enthält.

SpectroPHONETM: eine Anwendung, die SANM integriert

Bei einer alternativen Ausführungsform der vorliegenden Erfindung enthalten ein Verfahren und eine Vorrichtung zur telefonischen Alarmbenachrichtigung die Fähigkeiten des SANM.
Dadurch können ein Verfahren und eine Vorrichtung für telefonischen Alarm Alarme von mehreren Segmenten in einem großen und komplexen Kommunikationsnetz behandeln.
Fig. 16 zeigt ein Blockschaltbild dieser Ausführungsform der vorliegenden Erfindung. Ein Verfahren und eine Vorrichtung 186 zur telefonischen Alarmbenachrichtigung umfaßt eine Alarm-Überwachungseinrichtung 178 und einen Benachrichtigungsmanager 184. Ein Richtlinienadministrator 170 (wie zum Beispiel der von SANM in der vorbekannten Ausführungsform) dient zum Erzeugen eines Richtlinienmodells 172, das zu der Alarm-Überwachungseinrichtung 178 gesendet wird. Alarme, die aus mehreren Segmenten eines Kommunikationsnetzes entstehen, wie zum Beispiel einem ersten Netzsegment 174 und einem zweiten Netzsegment 176, werden zu der Alarm-Überwachungseinrichtung 178 gesendet. Diese Segmente senden außerdem Informationen bezüglich den Benutzern, die für jeden Alarm benachrichtigt werden sollen.
Die Alarm-Überwachungseinrichtung 178 bestimmt, welche Alarme die durch das Richtlinienmodell 172 spezifizierten Kriterien passieren, und Informationen bezüglich dieser Alarme (der kritischen Alarme), die die Kriterien passieren, werden zur Verwendung durch den Benachrichtigungsmanager 184 in zwei externen Dateien abgelegt. Eine Alarminformationsdatei 180 enthält Informationen bezüglich der kritischen Alarme, und die Benutzerinformationsdatei 182 enthält eine Liste jeweiliger Benutzer, die für jeden kritischen Alarm benachrichtigt werden sollen.
Inder Regel ist zu jedem gegebenen Zeitpunkt eine Richtlinie in dem Richtlinienmodell 172 für das Benachrichtigungsverfahren effektiv. Diese Richtlinie kann jedoch über den Richtlinienadministrator 170 (wie beim SANM der vorbekannten Ausführungsform) durch einen Benutzer verändert werden. Alle Alarme, ungeachtet des Netzsegmentursprungs, werden durch das Filter des Richtlinienmodells 172 gefiltert.
Der Benachrichtigungsmanager 184 liest periodisch die Alarminformationsdatei 180 und leitet Benachrichtigungen auf der Grundlage der in beiden Dateien 180 und 182 enthaltenen Informationen ein. Für einen kritischen Alarm in der Datei 180 werden über das öffentliche Fernsprechkommunkationssystem 194 automatisch der entsprechende Benutzer bzw. die entsprechenden Benutzer in der Datei 182 benachrichtigt. Dieser Benutzer kann über ein Telefon 188, einen Pager 190 oder eine andere Art von Gerät 192 auf dem öffentlichen Fernsprechkommunikationssystem 194 benachrichtigt werden.
Als Alternative kann ein Benutzer den Benachrichtigungsmanager 184 über das öffentliche Fernsprechkommunikationssystem 194 anrufen. In diesem Fall liest der Benachrichtigungsmanager 184 die Informationen in den beiden Dateien 180 und 182 und benachrichtigt den anrufenden Benutzer von kritischen Alarmen, die den anrufenden Benutzer als einen zu benachrichtigenden Benutzer auflisten.
Nachdem ein Benutzer (wie zum Beispiel ein Systemadministrator) von einem kritischen Alarm benachrichtigt wurde, kann der Benutzer Behebungsmaßnahmen treffen, um die den kritischen Alarmen in dem Kommunikationsnetz zugeordneten Probleme zu korrigieren. Der Benutzer kann dann den kritischen Alarm aus der Alarminformationsdatei 180 löschen, indem er den Benachrichtigungsmanager 184 anruft. Wenn ein kritischer Alarm gelöscht wird, werden die diesem kritischen Alarm zugeordneten Informationen aus beiden Dateien 180 und 182 gelöscht.
Während Alarme auf einem Kommunikationsnetz auftreten oder gelöscht werden, werden sie über ein unaufgefordertes Anforderungsmanagement behandelt, so daß, sobald Alarme erkannt und gefiltert oder gelöscht werden, ihre zugeordneten Informationen in den beiden Dateien 180 und 182 in Echtzeit korrigiert werden. Diese Korrekturen können durch die Alarm- Überwachungseinrichtung 178 geschehen, während der Benachrichtungsmanager 184 andere Aktivitäten durchführt, wie: zum Beispiel das Anrufen von Benutzern oder das Abfragen von Hardware auf dem öffentlichen Fernsprechkommunikationssystem 194.
Diese Arbeitsaufteilung in dem telefonischen Alarmbenachrichtigungsverfahren 186 in die Alarm-Überwachungseinrichtung 178 und den Benachrichtigungsmanager 184 und eine enge Integration dieser beiden Teile ermöglicht eine Überwachung kritischer Alarme mit hoher Genauigkeit und rechtzeitiger Reaktion durch die Benutzer. Zusätzlich ermöglicht die Integration der SANM-Fähigkeiten in das telefonische Alarmbenachrichtigungsverfahren ein kompliziertes Filtern von Alarmen über den Richtlinienadministrator 170 und das Überwachen von Alarmen aus mehreren Netzsegment-Servern.
Fig. 17 zeigt eine typische Systemarchitektur für die neue SpectroPHONEm-Anwendung, die ein Ausführungsbeispiel des Verfahrens und der Vorrichtung zur telefonischen Alarmbenachrichtigung der vorliegenden Erfindung ist. Eine Host- Maschine 200 führt die neue SpectroPHONEm-Anwendung aus, die den SANM 204 der vorbekannten Ausführungsformen integriert.
Ein Benutzer kann durch die grafische Benutzeroberfläche (GUI) 206 von SpectroPHONETM Richtlinienmodelle spezifizieren. Der Richtlinienadministrator 208 sendet die vorspezifizierten Richtlinienmodelle zu mehreren verteilten Netzmanagern 210 und 214 (in den Fern-Maschinen 212 bzw. 216), die separate Netzsegmente versorgen. Die verteilten Netzmanager 210 und 214 senden Informationen bezüglich Alarmen, die in ihren jeweiligen Netzsegmenten erzeugt werden, und bezüglich Richtlinien zu dem SANM 204 und Informationen bezüglich Benutzern, die von diesen Alarmen benachrichtigt werden sollen, zu SpectroPHONETM 202. SpectroPHONETM 202 benachrichtigt dann Benutzer, wenn kritische Alarme entstehen, über die Computerfone-Hardware 218, die der Vermittler zudem externen öffentlichen Kommunikationsmedium 220 ist.
Die neue SpectroPHONETM-Anwendung liefert außerdem zusätzliche Benutzeradministrationsfunktionen über die SpectroPHONETM-GUI 206. Fig. 18 zeigt eine beispielhafte GUI- Fensteranzeige 230 mit einem SpectroPHONEm-Attributfeld 232. In diesem Feld kann der Benutzer eine vorbestimmte Positionsnummer auf dem öffentlichen Fernsprechkommunikationssystem angeben, die SpectroPHONETM für eine Benachrichtigung von kritischen Alarmen, die diesem Benutzer entsprechen, anrufen soll. Diese Positionsnummer kann für ein Telefon oder für einen Pager sein.
Zusätzlich kann der Benutzer in das SpectroPHONETM- Attributfeld ein diesem Benutzer entsprechendes Passwort eingeben. SpectroPHONETM fragt einen angerufenen Benutzer, die Identifikation des angerufenen Benutzers durch Eingeben des Passworts zu verifizieren, bevor dieser angerufene Benutzer von den kritischen Alarmen benachrichtigt werden kann. Somit liefert die neue SpectroPHONETM-Anwendung zusätzliche Sicherheit für den Zugang zu Alarminformationen.
Der Benutzer kann außerdem Neuversuchs-Zeitintervalle in das SpectroPHONETM-Attributfeld 232 eingeben. SpectroPHONETM versucht dann in jedem Zeitintervall automatisch erneut, den Benutzer anzurufen, wenn vorherige Anrufe des Benutzers erfolglos gewesen sind.
Als letztes dient ein Kennzeichnungsfeld in dem SANM 204, der in die SpectroPHONETM-Anwendung 202 integriert ist, zur Bereitstellung einer Eskalationsfunktion. In dieser Funktion kann ein Benutzer eine Kette von Benutzern angeben, die benachrichtigt werden soll, wenn Alarme ein gegebenes auf Richtlinien basierendes Filter passieren. Somit ist ein Eintrag in dem Kennzeichnungsfeld einem gegebenen auf Richtlinien basierenden Filter zugeordnet. Wenn ein vorheriger Benutzer in der Kette nicht erreicht werden kann, wird ein nachfolgender Benutzer in der Kette angerufen, bis ein Benutzer in der Kette erreicht werden kann oder bis der letzte Benutzer in der Kette nicht erreicht werden kann.
Die GUI 206 und das Kennzeichnungsfeld in dem SANM liefern benutzerfreundlichere Funktionen in SpectroPHONETM. Diese Merkmale geben dem Administrator des Kommunikationsnetzes mehr Kontrolle über die Benachrichtigung bezüglich kritischer Alarme, die auf dem Netz entstehen, über das öffentliche Fernsprechkommunikationssystem.
Nachdem somit bestimmte konkrete Ausführungsformen der Erfindung beschrieben wurden, werden für Fachleute verschiedene Modifikationen erkennbar sein, die in den Schutzumfang der vorliegenden Erfindung fallen sollen. Dementsprechend erfolgte die obige Beschreibung lediglich als Beispiel und soll keine Einschränkung darstellen.

Claims

1, Verfahren zur Verarbeitung von Alarmen, die von mehreren Servern erzeugt werden, in einer Management-Umgebung eines verteilten Netzes mit mehreren Netzmanagement-Servern (12), wobei jeder Server eine Fehlerüberwachung für mehrere Netzentitäten in einem zugeordneten Netzsegement (174, 176) durchführt und Alarme erzeugt, wobei das Verfahren zur Verarbeitung solcher Alarme, die von den mehreren Servern erzeugt werden, durch folgendes gekennzeichnet ist:

Senden der Alarme von den mehreren Servern zu einer Alarm- Überwachungseinrichtung (14);

Zuweisen einer Richtlinie zu einer oder mehreren zugeordneten Anwendungen (24), wobei die Richtlinie mehrere Filter umfasst und jedes Filter wenigstens einen Filterparameter enthält;

wobei die Alarm-Überwachungseinrichtung die Alarme von den mehreren Servern empfängt und die Richtlinie auf die Alarme anwendet, um einen kritischen Alarm zu bestimmen, der mindestens ein Filter passiert, und wobei die Alarm- Überwachungseinrichtung eine Alarmbenachrichtigung, die den kritischen Alarm und das wenigstens eine von dem kritischen Alarm passierte Filter identifiziert, zu der mindestens einen zugeordneten Anwendung (24) sendet.

2. Verfahren nach Anspruch 1, bei dem sich die zugeordneten Anwendungen (24) bei der Alarm- Überwachungseinrichtung (14) registrieren, um von den kritischen Alarmen, die die Richtlinie passieren, benachrichtigt zu werden.

3. Verfahren nach Anspruch 1, bei dem der Zuweisungsschritt so eingeplant wird, dass er zu festgesetzten Zeiten erfolgt, so dass sich die angewandte Richtlinie ändert.

4. Verfahren nach Anspruch 1, bei dem der Benachrichtigungsschritt das Angeben von Echtzeitwerten jedes Filterparameters in der Alarmbenachrichtigung umfasst.

5. Verfahren nach Anspruch 1, bei dem mehrere Richtlinien und ihre zugeordneten Richtlinienmittel in einer allen Servern zugänglichen Datenbank (16) gespeichert werden.

6. Verfahren nach Anspruch 1, bei dem der Zuweisungsschritt das Zuweisen einer Kennzeichnung (Etikett A, Etikett B, ...) zu jedem Filter umfasst und der Benachrichtigungsschritt das Angeben der Kennzeichnung für das von dem kritischen Alarm passierte Filter in der Alarmbenachrichtigung umfasst.

7. Verfahren nach Anspruch 1, bei dem der Anwendungsschritt das Durchführen einer logischen UND- Verknüpfung aller Parameter in einem Filter und das Durchführen einer logischen ODER-Verknüpfung zwischen allen Filtern in einer Richtlinie umfasst.

8. Verfahren nach Anspruch 1, bei dem die zugeordneten Anwendungen Netzmanagementanwendungen. sind.

9. Verfahren nach Anspruch 1, bei dem der Benachrichtigungsschritt das Angeben eines Benutzernamens in der Alarmbenachrichtigung umfasst, um der zugeordneten Anwendung, die die Alarmbenachrichtigung empfängt, zu ermöglichen, einen Benutzer mit dem angegebenen Benutzernamen zu benachrichtigen.

10. Verfahren nach Anspruch 1, bei dem die Häufigkeit, mit der die Richtlinie angewandt wird, geplant wird (22).

11. Verfahren nach Anspruch 1, das weiterhin den Schritt aufweist, nach der Auflösung eines Alarms, eine Alarmlöschnachricht zu der wenigstens einen zugeordneten Anwendung weiter zu leiten.

12. Verfahren nach Anspruch 1, bei dem der Zuweisungsschritt das Zuweisen derselben Richtlinie zu mehreren zugeordneten Anwendungen umfasst.

13. Verfahren nach Anspruch 1, bei dem der Zuweisungsschritt von einem Benutzer über eine graphische Benutzeroberfläche (20) durchgeführt wird.

14. Verfahren nach Anspruch 1, bei dem die Alarmbenachrichtigung Informationen über eine Netzentität enthält, die den Alarm erzeugt hat, der als kritischer Alarm ermittelt wurde.

15. Verfahren nach Anspruch 1, bei dem weiterhin eine oder mehrere der zugeordneten Anwendungen eine Alarmlöschnachricht erzeugen und diese zu dem Server weiterleiten, der den Alarm gesendet hat, der als kritischer Alarm ermittelt wurde.

16. Verfahren nach Anspruch 1, bei dem beim Löschen der kritischen Warnung eine Alarmlöschnachricht zu den zugeordneten Anwendungen gesendet wird.

17. Verfahren nach Anspruch 1, bei dem der Benachrichtigungsschritt das Benachrichtigen eines Benutzers über kritische Alarme über ein öffentliches Kommunikationssystem (194) umfasst.

18. Verfahren nach Anspruch 17, bei dem weiterhin der Benutzer über das öffentliche Kommunikationssystem (194) eine Anforderungsnachricht sendet, von den kritischen Alarmen benachrichtigt zu werden; und

vor dem Schritt des Benachrichtigens auf die Anforderungsnachricht von dem Benutzer gewartet wird.

19. Verfahren nach Anspruch 17, das weiterhin den Schritt umfasst: Speichern von Alarminformationen (180) und Benutzerinformationen (182), die den kritischen Alarmen zugeordnet sind.

20. Verfahren nach Anspruch 17, bei dem weiterhin der Benutzer die Richtlinie bestimmt durch Auswählen der Anzahl von Filtern, aus denen die Richtlinie besteht.

21. Verfahren nach Anspruch 17, bei dem weiterhin der Benutzer die Filterparameter der mehreren Filter setzt.

22. Verfahren nach Anspruch 17, wobei bei dem Schritt des Benachrichtigens der Benutzer vorbestimmte Zeitintervalle für eine automatische Benachrichtigung über die kritischen Alarme angibt; und der Benutzer automatisch in den vorbestimmten Zeitintervallen benachrichtigt wird.

23. Verfahren nach Anspruch 17, wobei bei dem Schritt des Benachrichtigens

der Benutzer eine vorbestimmte Positionsnummer des öffentlichen Kommunikationssystems (194) zum Empfangen einer Benachrichtigung über die kritischen Alarme angibt; und

die Alarm-Überwachungseinrichtung (186) zur Benachrichtigung über die kritischen Alarme die vorbestimmte Positionsnummer ruft.

24. Verfahren nach Anspruch 23, wobei bei dem Schritt des Benachrichtigens weiterhin

der Benutzer eine nachfolgende Positionsnummer zum Empfangen einer Benachrichtigung über die kritischen Alarme angibt; und

wenn die vorbestimmte Positionsnummer nicht erreicht werden kann, die Alarm-Überwachungseinrichtung (186) zur Benachrichtigung über die kritischen Alarme die nachfolgende Positionsnummer ruft.

25. Verfahren nach Anspruch 17, wobei bei dem Schritt des Benachrichtigens

der Benutzer aufgefordert wird, ein Passwort anzugeben, bevor der Benutzer über den kritischen Alarm benachrichtigt wird.

26. Verfahren nach Anspruch 17, bei dem der Benutzer den kritischen Alarm, löscht und dadurch die Alarm-Überwachungseinrichtung benachrichtigt.

27. Verfahren nach Anspruch 17, wobei weiterhin

der Benutzer ein Kommunikationsgerät (188, 190, 192) in dem öffentlichen Kommunikationssystem angibt; und

der Benutzer über das Kommunikationsgerät über die kritischen Warnungen benachrichtigt wird.

28. Verfahren nach Anspruch 27, wobei das Kommunikationsgerät ein Telefon (188) oder ein Pager (190) ist.