DE102005049055A1 - Verfahren, um Ereignisse in einem Systemereignisprotokoll in eine Reihenfolge zu bringen - Google Patents

Verfahren, um Ereignisse in einem Systemereignisprotokoll in eine Reihenfolge zu bringen Download PDF

Info

Publication number
DE102005049055A1
DE102005049055A1 DE102005049055A DE102005049055A DE102005049055A1 DE 102005049055 A1 DE102005049055 A1 DE 102005049055A1 DE 102005049055 A DE102005049055 A DE 102005049055A DE 102005049055 A DE102005049055 A DE 102005049055A DE 102005049055 A1 DE102005049055 A1 DE 102005049055A1
Authority
DE
Germany
Prior art keywords
event
events
entry
primary
address space
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
DE102005049055A
Other languages
English (en)
Other versions
DE102005049055B4 (de
Inventor
Austin P. Austin Bolen
Anand Round Rock Joshi
Mukund P. Austin Khatri
Allen C. Round Rock Wynn
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Dell Products LP
Original Assignee
Dell Products LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Dell Products LP filed Critical Dell Products LP
Publication of DE102005049055A1 publication Critical patent/DE102005049055A1/de
Application granted granted Critical
Publication of DE102005049055B4 publication Critical patent/DE102005049055B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466Performance evaluation by tracing or monitoring
    • G06F11/3476Data logging
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/86Event-based monitoring

Abstract

Ein Verfahren und ein System zum Speichern von Hardware- und Softwar-Ereignissen eines Computersystems wird offenbart. Ein Ereignisprotokollierer, der typischerweise Teil einer Systemmanagementsoftware ist, speichert sowohl primäre Ereigniseinträge als auch sekundäre Ereigniseinträge. Sekundäre Ereigniseinträge werden verwendet, wenn der Datenraum in einem primären Ereigniseintrag unzureichend ist, um das primäre Ereignis adäquat zu beschreiben. Die Datenfelder eines sekundären Ereigniseintrags bezeichnen den Eintrag als ein sekundäres Ereignis und enthalten die zusätzlichen Daten über das Ereignis.

Description

  • Technischer Bereich der Erfindung
  • Die Erfindung betrifft die Verwaltung von Computersystemen und insbesondere die Bereitstellung von Ereignisprotokollen für Computersysteme.
  • Hintergrund der Erfindung
  • Das Protokollieren von Ereignissen stellt für Computersysteme ein standardisiertes, zentralisiertes Verfahren zum Speichern von Software- und Hardwareereignissen dar. Eine oder mehrere Hardware- oder Softwarekomponenten des Systems sind „Ereigniserzeuger" und erzeugen und senden Ereignisnachrichten an einen „Ereignisprotokollierer", der die Ereignisse in einem Speicher speichert. Ein „Ereignisbetrachter" stellt eine Anwenderschnittstelle zum Betrachten der Ereignisse bereit. Ereignisdaten können ferner freigestellt und durchsucht werden unter Verwendung von ausgefeilter Anwendungssoftware zum Verwaltung von Ereignisprotokollen.
  • Für ein aktives System wie z.B. einen Server ist die Aufgabe der Erzeugung eines Ereignisprotokolls nicht einfach – selbst ein einzelner Server kann Tausende von Ereignissen in einem kurzen Zeitintervall erzeugen. Für heutige Server werden Ereignisse gemäß einem Industrie-weiten Standard protokolliert, der als Intelligent Platform Management Interface Specification (IPMI) bekannt ist.
  • IPMI definiert die Nachrichten und die Systemschnittstelle zu „intelligenten" Plattformsensoren, die dazu verwendet werden, um Charakteristika über die phy sikalische Gesundheit des Systems zu überwachen, wie z.B. die Temperaturen des Prozessors und des Systems, die Lüftergeschwindigkeit und Spannungsniveaus. Ereignisse können auch durch Software erzeugt werden. Die IPMI-Spezifikation etabliert Standardrichtlinien für die Implementierung eines Subsystems zur Überwachung und Ausgabe eines Alarms mit dem Ziel, eine „immer verfügbare Verwaltungsfähigkeit" von Softwaresystemen zu erreichen.
  • Zusammenfassung der Erfindung
  • Gemäß den Lehren der vorliegenden Offenbarung werden Systeme und Verfahren zum Erzeugen und Betrachten eines Ereignisprotokolls beschrieben. Die Erfindung ist insbesondere geeignet, wenn die Ereigniseinträge, die das Ereignisprotokoll umfassen, ein vorbestimmtes Format haben mit begrenztem Datenplatz für die Daten, die das Ereignis beschreiben. Gemäß der Erfindung sind Ereignisse entweder „primär" oder „sekundär". Primäre Ereignisse werden gespeichert unter Verwendung des konventionellen Formats zum Speichern von Ereignissen. Jedes primäre Ereignis kann mit einem oder mehreren sekundären Ereignissen verbunden werden. Das sekundäre Ereignis wird als solches identifiziert unter Verwendung eines Datenfeldes des Ereigniseintrags. Das Datenfeld des sekundären Ereigniseintrags oder der Eintträge enthält die zusätzlichen Daten, um das Ereignis zu beschreiben.
  • In einem Ausführungsbeispiel der Erfindung wird das Ereignisprotokoll gemäß dem IPMI-Standard gespeichert. Der Eintrag für das sekundäre Ereignis wird als solcher bezeichnet in einem der IPMI-Ereigniseintragfelder, beispielsweise in dem Feld für die Art des Ereignisses. Das Datenfeld für das sekundäre Ereignis enthält die zusätzlichen Daten.
  • Kurze Beschreibung der Zeichnungen
  • Ein vollständigeres Verständnis der vorliegenden Ausführungsbeispiele und ihrer Vorteile erhält man durch Bezugnahme auf die folgende Beschreibung in Verbindung mit den begleitenden Zeichnungen, in denen ähnliche Bezugszeichen ähnliche Merkmale anzeigen und wobei:
  • 1 erläutert ein Computersystem mit einem Ereignisprotokollierer gemäß der Erfindung.
  • 2 erläutert ein Beispiel eines Ereignisprotokolls mit ausschließlich primären Ereigniseinträgen.
  • 3 erläutert ein Beispiel eines Ereignisprotokolls mit sowohl primären als auch sekundären Ereigniseinträgen.
  • Detaillierte Beschreibung der Erfindung
  • 1 zeigt ein typisches Computersystem 100, welches im Beispiel dieser Beschreibung ein Serversystem ist. Die hier beschriebenen Konzepte können auf jedes „informationsverarbeitende System" 100 angewendet werden, welches ein „Ereignisprotokoll" 30 vorhält.
  • Zusätzlich zu einem Serversystem könnte daher das Computersystem 100 irgendein „informationsverarbeitendes System" sein, das programmierbar ist unter Verwendung von höheren Programmiersprachen. Das Computersystem kann ferner implementiert werden unter Verwendung von speziell programmierter oder für spezielle Zwecke dienender Hardware. Im Computersystem 100 ist der Prozessor typischerweise ein kommerziell erhältlicher Prozessor wie z.B. diejenigen, die von der Intel Corporation, Sun Microsystems oder Motorola erhältlich sind. Der Prozessor führt im Allgemeinen ein Betriebssystem aus, welches beispielsweise ein Betriebssystem sein kann, wie es von der Firma Microsoft Corporation, von den Firmen Apple Computer, Sun Microsystems, Palm Inc. erhältlich ist oder andere, UNIX-basierende Betriebssysteme, die aus verschiedenen Quellen erhältlich sind.
  • Ein „Ereignisprotokoll" 30 ist definiert als ein Datenspeicher, typischerweise in nichtflüchtigem Speicher, zum Speichern von Systemereignissen. Es wird angenommen, dass das System 100 einen Mechanismus zum Protokollieren von Ereignissen hat, um Ereignisse zu speichern (hier DMC 111) und einen Mechanismus zum Betrachten von Ereignissen (hier ein Teil der Systemverwaltungssoftware 122) zum Betrachten des Ereignisprotokolls oder um in anderer Weise darauf zuzugreifen.
  • Wenn das Computersystem 100 ein Serversystem ist, kommuniziert es mit einem oder mehreren Clientsystemen (nicht gezeigt) zum Zwecke des Austauschs von Information und zum Durchführen von Transaktionen, wie z.B. Datenbanktransaktionen. Diese Systeme kommunizieren unter Verwendung eines Kommunikationsprotokolls über ein Netzwerk. Der Server 100 kann beispielsweise ein Hypertext-Transfer-Protokoll (http)-Server sein, der konfiguriert ist, um Datenbankvorgänge durchzuführen. Das Kommunikationsnetzwerk (nicht gezeigt) kann ein Ethernet-Netzwerk, ein Fast-Ethernet-Netzwerk oder eine andere Art von lokalem oder Wide-Area-Netzwerk (LAN oder WAN) sein, ein Punkt-zu-Punk-Netzwerk, das von Telefongesellschaften bereitgestellt wird oder eine andere Art von Kommunikationsnetzwerk oder eine Kombination von Netzwerken. Verbraucher der Information und Bereitsteller der Information, auf die im Stand der Technik auch als Clientsysteme bzw. Serversysteme Bezug genommen wird, kommunizieren über das Netzwerk, um Information auszutauschen.
  • Im Beispiel aus 1, in dem die Systemhardware 110 eine Hardware ist, die einem Serversystem zugeordnet ist, kann die Hardware einen Prozessor umfassen, der mit einem oder mehreren Speichergeräten verbunden ist, wie z.B. einem Plattenlaufwerk über ein Kommunikationsgerät, wie z.B. einem Bus. Die Computer hardware 110 kann ferner eines oder mehrere Ausgabegeräte umfassen, wie z.B. einen Monitor, einen Drucker oder eine Graphikanzeige oder ein Druckgerät und eines oder mehrere Eingabegeräte, wie z.B. eine Tastatur, eine Maus oder ein anderes Gerät. Das System 110 hat einen Speicher zum Speichern von Programmen und Daten während des Betriebs des Computersystems. Zusätzlich kann das System 110 eines oder mehrere Kommunikationsgeräte enthalten, die das Computersystem 100 mit einem Kommunikationsnetzwerk verbinden.
  • Ein Baseboard-Management-Controller (BMC) 111 ist ein Mikrocontroller, der die Schnittstelle zwischen der Systemmanagementsoftware 122 und der Systemmanagementhardware verwaltet. Er überwacht Ereignisse und empfängt und protokolliert Ereignisnachrichten in dem Ereignisprotokoll 30.
  • Die Systemsoftware 120 umfasst Anwendungsprogramme, Systemdienstprogramme, eine Eingabeoberfläche, Systemdienste, das Betriebssystem und das BIOS des Systems. Ein typisches Betriebssystem eines Servers ist Windows, ein Produkt der Microsoft Corporation. „BIOS" ist eine Abkürzung für Basic Input/Output System und bestimmt, was das System 100 durchführen kann, ohne Zugriff auf Programme von einer Platte. Beispielsweise enthält das BIOS Programmiercode, der benötigt wird, um die Tastatur, den Bildschirm, Plattenlaufwerke, serielle Kommunikationen und eine Anzahl verschiedener Funktionen zu steuern.
  • Das BIOS arbeitet ebenfalls in Verbindung mit dem BMC 111, um Systemereignisse zu protokollieren. Ereignisse werden protokolliert gemäß dem IPMI-Standard, der im einleitenden Teil beschrieben worden ist. Genauer ausgedrückt erzeugt das BIOS Ereignisnachrichten und sendet sie an den BMC 111, der sie in dem Ereignisprotokoll 30 einträgt.
  • „Systemmanagementsoftware" 122 ist ein generischer Ausdruck, der hier verwendet wird, um zu beschreiben welche Programmsoftware auch immer das Er eignisprotokoll zum Betrachten bereitstellt, indem sie auf das Ereignisprotokoll 30 zugreift und die Ereignisdaten durchsucht. Die jeweilige Aufgabe der Systemmanagementsoftware 122, die das Ereignisprotokoll liest und eine betrachtbare Anzeige für ein Ereignis bereitstellt, wird im Folgenden als „Ereignisbetrachter" bezeichnet. Im Beispiel aus 1 ist der Ereignisbetrachter unten im Softwarestapel gezeigt. Das Betrachten eines Ereignisses kann jedoch alternativ durch Highlevel-Software durchgeführt werden, die fortgeschrittene Merkmale zur Ereignisverwaltung aufweist.
  • Als eine Schnittstelle auf dem Niveau der Hardware befindet sich das IPMI 121 am Boden eines Softwarestapels für eine typische Systemverwaltung. Das IPMI arbeitet unabhängig vom Betriebssystem, wodurch es Systemadministratoren möglich ist, auf Systeme zuzugreifen und sie wiederherzustellen, selbst wenn das Betriebssystem nicht antwortet oder das System heruntergefahren ist. In anderen Ausführungsbeispielen könnte eine andere Schnittstelle zur Ereignisverwaltung das IPMI ersetzen.
  • 2 ist ein Beispiel eines Teils eines Ereignisprotokolls 30, das zur Betrachtung durch den Ereignisbetrachter 122 erzeugt worden ist. Vier Ereignisse sind eingetragen worden, es gibt daher vier „Ereigniseinträge". IM Beispiel aus 2 betreffen alle vier Ereigniseinträge primäre Ereignisse. Gemäß dem IPMI wird jeder Eintrag mit einer vorbestimmten Anzahl von Datenfeldern eingetragen. Die Felder und Daten, die zur Betrachtung zur Verfügung stehen, werden durch die Software zum Protokollieren eines Ereignisses und zum Betrachten bestimmt, die als ein Teil der Systemmanagementsoftware bereitgestellt wird. Im Beispiel aus 2 sind die betrachteten Felder die Erzeuger-ID 21, der Ereignistyp 22, der Lesetyp 23 und drei Datenfelder 24.
  • Das Feld 21 für die Erzeuger-ID beschreibt den Ursprung des Ereignisses. Beispiele sind IDs für das BIOS und den BMC 111. Wenn das Ereignis von Software erzeugt worden ist, ist dies die Software-ID.
  • Das Feld 22 mit dem Ereignistyp enthält Daten, die den Typ des Auslösers für das Ereignis beschreiben. Das Feld kann ebenfalls die Klasse des Ereignisses anzeigen, wie z.B. „Schwellwert geht hoch". Beispiele sind der Speicher, der Prozessor, kritisch, OEM etc.
  • Das Feld 23 über den Lesetyp des Ereignisses enthält Daten, die einen Lesestatus eines Sensors anzeigen. Beispiele sind Schwellwert, diskret, generisch oder OEM-spezifiziert.
  • Die Datenfelder 24 für das Ereignis werden verwendet, um zusätzliche Informationen über das Ereignis bereitzustellen. Drei Datenbyte werden Ereignisdaten zugeordnet. Das erste Byte ist vordefiniert, so dass nur zwei „freie" Datenbytes übrig bleiben. Eine Ausnahme besteht, wenn der Anwender als ein OEM eingelogged ist. In diesem Fall kann es mehr zur Verfügung stehende Bits geben.
  • Für viele Ereignisse sind die Datenfelder 24 für das Ereignis unzureichend in ihrer Größe, um sinnvolle Information über das Ereignis bereitzustellen. Beispielsweise sollte ein Ereignis, das sich auf den PCI-Expressbus bezieht, den Bus identifizieren, die Nummer der Gerätefunktion, das Fehlerregister und die Werte in diesen Registern.
  • Wie durch die Ereignisse 2 und 4 in dem beispielhaften Ereignisprotokoll aus 2 dargestellt gibt es nur Platz für die Nummer des Busses und der Gerätefunktion, wenn die Datenfelder 24 für das Ereignis nur zwei „freie" Datenbytes bereitstellen. Diese Information unterstützt nicht bei der Diagnose eines Problems, da sie keine Information über Register und Inhalte bereitstellt.
  • 3 erläutert ein Beispiel eines verbesserten Ereignisprotokolls 30 in Übereinstimmung mit der Erfindung. 3 erläutert sowohl primäre als auch sekundäre Ereigniseinträge. Konventionelle Verfahren und Formate werden verwendet, um primäre Ereignisse zu speichern. Nach einem primären Ereignis können jedoch, wie dargestellt, eines oder mehrere sekundäre Ereigniseinträge gespeichert werden. Ein sekundärer Ereigniseintrag wird nicht als ein „vollständiges" Ereignis protokolliert. Stattdessen wird damit zusätzliche Information über ein primäres Ereignis protokolliert.
  • Im Beispiel aus 3 sind die Ereignisse 1, 2, 3 und 4 primäre Ereignisse und entsprechen den Ereignissen aus dem Ereignisprotokoll in 2. Die Ereignisse 2 und 4 haben sekundäre Ereignisse. Die primären Ereigniseinträge beschreiben, welches Gerät den Fehler verursacht hat, gefolgt von einem oder mehreren sekundären Ereignissen. In dem Beispiel aus 3 stellen das oder die sekundären Ereignis(se) die Information über ein Register bereit, das Fehlerwerte oder Statusdaten enthält.
  • Auf jedes primäre Ereignis kann daher nacheinander eines oder mehrere sekundäre Ereignisse folgen. Nach einem primären Ereignis protokolliert der Ereignisprotokollierer sekundäre Ereignisse mit der gleichen Erzeuger-ID, wie das zugeordnete primäre Ereignis.
  • Um das Ende der Ereignisspur zu bestimmen, sucht der Ereignisbetrachter 120 nach einem anderen primären Ereignis mit der gleichen Erzeuger-ID. Da gleichzeitige Ereignisse mit einer ineinander verschränkten Weise protokolliert werden können, markiert ein anderes primäres Ereignis mit einer anderen Erzeuger-ID nicht notwendigerweise das Ende der Ereignisspur. Die Ereignisspur bleibt „offen" zum Protokollieren von zusätzlichen sekundären Ereignissen bis zum Auftritt eines neuen primären Ereignisses von dem selben Ereigniserzeuger.
  • Einen Wert in dem Feld 22 über den Ereignistyp identifiziert den Eintrag als einen sekundären Ereigniseintrag. Auf diesen Wert wird im Folgenden als „Bezeichnung für einen sekundären Ereigniseintrag" Bezug genommen. Im Beispiel dieser Beschreibung ist dieser Wert 0xC1, der sich aus dem OEM-Wertebereich im IPMI-Standard ergibt. Andere Werte könnten verwendet werden.
  • Für die Ereignisse 2 und 4 hat der Ereignisprotokollierer 111 die sekundären Ereignisse protokolliert unter Verwendung eines Pointers auf ein Ereignisregister (bzw. Event-Register-Pointer, ERP). Ein Wert im Feld 23 für den Lesetyp definiert den ERP. Im Beispiel dieser Beschreibung ist der Ereignislesetyp 0x7E aus dem IPMI-OEM-Bereich von Werten. Es können aber auch andere Werte verwendet werden. Der ERP bildet ein 12-Bit-Register-Offset in den Raum ab, der von seinem primären Ereignis bereitgestellt wird. Der Registerraum kann vom Typ des PCI-Registers sein, ein Speicher oder I/O und wird durch das primäre Ereignis bestimmt.
  • Nach einem primären Ereignis gibt es möglicherweise keine sekundären Ereignisse oder es gibt viele sekundäre Ereignisse. Im Ereignisprotokoll 30 erscheinen ERPs nacheinander nach dem primären Ereignis und haben dieselbe Erzeugungs-ID. Ein weiteres primäres Ereignis mit derselben Generator-ID bezeichnen das Ende der ERP-Spur. Dies stellt sicher, dass auf alle sekundären Informationen zugegriffen wird und sei betrachtet werden kann, und sie nach dem entsprechenden primären Ereignis betrachtet werden.
  • Verschiedene Arten von sekundären Ereignissen können protokolliert werden. Ereignisse, die besonders für die Verwendung als sekundäre Ereigniseinträge geeignet sind, sind Ereignisse, die den Adressenraum angeben, wie z.B. die oben beschriebenen Ereignisse, die PCI und PCI-Expressbusse betreffen. Diese „Adressraum"-Ereignisse können wie oben beschrieben mit ERPs implementiert werden. Sekundäre Ereignisse, die sich nicht auf Adressräume beziehen, können im Feld 23 für den Lesetyp andere Daten verwenden.

Claims (20)

  1. Verfahren zum Protokollieren von Ereignissen in einem Ereignisprotokoll eines Computersystems, aufweisend: Speichern eines primären Ereigniseintrags für jedes Ereignis; wobei jeder Ereigniseintrag das gleiche Format hat mit vorbestimmten Datenfeldern; Speichern eines sekundären Ereigniseintrags für eines oder mehrere der Ereignisse, wobei das sekundäre Ereignis als ein sekundäres Ereignis identifiziert wird durch die Verwendung einer vorbestimmten sekundären Ereignisbezeichnung, die in eines der Felder für den Ereigniseintrag geschrieben wird; wobei Ereignissen Ereignisgeneratoren zugeordnet sind, die jeweils eine Erzeuger-ID aufweisen und wobei sekundäre Ereignisse für ein primäres Ereignis eingetragen werden, bis ein neues Ereignis detektiert wird, das dieselbe Erzeuger-ID für ein Ereignis aufweist.
  2. Verfahren nach Anspruch 1, wobei das Format des Ereigniseintrags in Übereinstimmung ist mit dem IPMI-Standard.
  3. Verfahren nach Anspruch 1, wobei die Bezeichnung für das sekundäre Ereignis in ein Feld für einen Ereignistyp geschrieben wird.
  4. Verfahren nach Anspruch 1, wobei der Schritt des Eintragens wiederholt wird für zusätzliche sekundäre Ereignisse für dasselbe primäre Ereignis.
  5. Verfahren nach Anspruch 1, wobei dem Ereignis ein Adressraum zugeordnet ist.
  6. Verfahren nach Anspruch 5, wobei der Eintrag für das sekundäre Ereignis einen Zeiger auf den Adressraum umfasst.
  7. Verfahren nach Anspruch 1, wobei das Ereignis einem Systembus zugeordnet ist.
  8. Verfahren nach Anspruch 1, wobei das Computersystem ein Serversystem ist.
  9. Verfahren zum Speichern von Adressraumereignissen in einem Ereignisprotokoll eines Computersystems, aufweisend: Eintragen eines primären Ereigniseintrags für jedes Ereignis; wobei jeder Ereigniseintrag das gleiche Format hat mit vorbestimmten Datenfeldern; Speichern eines sekundären Ereigniseintrags für eines oder mehrere der Ereignisse; wobei dieser Schritt des Eintragens durchgeführt wird, so dass das sekundäre Ereignis als ein sekundäres Ereignis mit einer vorbestimmten Bezeichnung für ein sekundäres Ereignis identifiziert wird, die in eines der Felder für den Ereigniseintrag geschrieben wird; und wobei der Eintrag für das sekundäre Ereignis ferner einen Zeiger auf einen Adressraum aufweist, der dem Ereignis zugeordnet ist.
  10. Verfahren nach Anspruch 9, wobei das Computersystem ein Serversystem ist.
  11. Verfahren nach Anspruch 9, wobei Ereignisse Ereigniserzeugern zugeordnet sind, von denen jeder eine Erzeuger-ID aufweist, und wobei sekundäre Ereignisse für ein primäres Ereignis eingetragen werden, solange bis ein neues Ereignis mit der selben Erzeuger-ID für ein Ereignis detektiert wird.
  12. Verfahren zum Protokollieren von Adressraumereignissen in einem Ereignisprotokoll eines Computersystems, das dem IPMI-Standard entspricht, aufweisend: Eintragen eines primären Ereigniseintrags für jedes Ereignis; wobei jeder Ereigniseintrag das IPMI-Format hat mit vorbestimmten Datenfeldern; Speichern eines sekundären Ereigniseintrags für eines oder mehrere der Ereignisse; wobei dieser Schritt des Speicherns durchgeführt wird, so dass das sekundäre Ereignis als ein sekundäres Ereignis mit einer vorbestimmten Bezeichnung für das sekundäre Ereignis identifiziert wird, die in eines der Felder für Ereigniseinträge geschrieben wird; und wobei der Eintrag für das sekundäre Ereignis ferner einen Zeiger auf einen Adressraum enthält, der dem Ereignis zugeordnet ist.
  13. Verfahren nach Anspruch 12, wobei die Bezeichnung für das sekundäre Ereignis in das Feld für den Ereignistyp geschrieben wird.
  14. Verfahren nach Anspruch 12, wobei das Ereignis einem Adressraum zugeordnet ist.
  15. Verfahren nach Anspruch 14, wobei der sekundäre Ereigniseintrag einen Zeiger auf den Adressraum aufweist.
  16. Verfahren nach Anspruch 15, wobei der Zeiger in das Feld des Lesetyps des Ereigniseintrags geschrieben wird.
  17. Verfahren nach Anspruch 12, wobei Ereignisse Ereigniserzeugern zugeordnet werden, die jeweils eine Erzeuger-ID haben und wobei sekundäre Ereignisse für ein primäres Ereignis eingetragen werden, bis ein neues Ereignis mit derselben Erzeuger-ID für ein Ereignis detektiert worden ist.
  18. Ein informationsverarbeitendes System, aufweisend: eine Hardware-Plattform mit zumindest einem Prozessor und einem Speicher zum Ausführen von Anweisungen; einem Ereignisprotokollierer, der in der Lage ist, Ereignisse, die der Hardware-Plattform zugeordnet sind, zu speichern; wobei der Ereignisprotokollierer sowohl primäre als auch sekundäre Ereignisse speichert, wobei jedes primäre Ereignis, das in einem Feld für einen Ereigniseintrag gespeichert wird, ein vorbestimmtes Format aufweist und wobei jedes sekundäre Ereignis als ein Eintrag nach einem primären Ereignis gespeichert wird, aber vor jedem nächsten primären Eintrag; wobei der Ereignisprotokollierer ferner sekundäre Ereignisse einträgt durch das Bezeichnen des Ereignisses als ein sekundäres Ereignis in einem vorbestimmten Datenraum des vorbestimmten Formats.
  19. System nach Anspruch 18, wobei das vorbestimmte Format das IPMI-Standardformat ist für Einträge von Ereignissen.
  20. System nach Anspruch 18, wobei der Ereignisprotokollierer ferner Software-Ereignisse einträgt.
DE102005049055.7A 2004-10-15 2005-10-13 Verfahren, um Ereignisse in einem Systemereignisprotokoll in eine Reihenfolge zu bringen Active DE102005049055B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/966658 2004-10-15
US10/966,658 US20060085690A1 (en) 2004-10-15 2004-10-15 Method to chain events in a system event log

Publications (2)

Publication Number Publication Date
DE102005049055A1 true DE102005049055A1 (de) 2006-05-24
DE102005049055B4 DE102005049055B4 (de) 2018-11-15

Family

ID=35451790

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102005049055.7A Active DE102005049055B4 (de) 2004-10-15 2005-10-13 Verfahren, um Ereignisse in einem Systemereignisprotokoll in eine Reihenfolge zu bringen

Country Status (14)

Country Link
US (1) US20060085690A1 (de)
JP (1) JP2006114046A (de)
KR (1) KR20060054026A (de)
CN (1) CN1761212B (de)
AU (1) AU2005222564A1 (de)
BR (1) BRPI0504440B1 (de)
DE (1) DE102005049055B4 (de)
FR (1) FR2880443A1 (de)
GB (1) GB2419203B (de)
HK (1) HK1093820A1 (de)
IT (1) ITTO20050735A1 (de)
MY (1) MY139659A (de)
SG (2) SG121977A1 (de)
TW (1) TWI367415B (de)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6378014B1 (en) 1999-08-25 2002-04-23 Apex Inc. Terminal emulator for interfacing between a communications port and a KVM switch
US7089250B2 (en) * 2003-10-08 2006-08-08 International Business Machines Corporation Method and system for associating events
US9183106B2 (en) * 2006-01-13 2015-11-10 Dell Products L.P. System and method for the automated generation of events within a server environment
US8427489B2 (en) 2006-08-10 2013-04-23 Avocent Huntsville Corporation Rack interface pod with intelligent platform control
US8009173B2 (en) * 2006-08-10 2011-08-30 Avocent Huntsville Corporation Rack interface pod with intelligent platform control
US20080294665A1 (en) * 2007-05-25 2008-11-27 Dell Products L.P. Methods and Systems for Handling Data in a Storage Area Network
DE102007033346A1 (de) * 2007-07-16 2009-05-20 Certon Systems Gmbh Verfahren und Vorrichtung zur Administration von Computern
US7783928B2 (en) * 2007-08-31 2010-08-24 International Business Machines Corporation Description of activities in software products
TW201007469A (en) * 2008-08-15 2010-02-16 Asustek Comp Inc Computer with remote mangement system
US20100073160A1 (en) * 2008-09-25 2010-03-25 Microsoft Corporation Alerting users using a multiple state status icon
FR2964280B1 (fr) * 2010-08-27 2012-09-28 Eads Defence & Security Sys Procede de centralisation d?evenements pour systeme d?information hierarchique multi-niveaux
CN102455969B (zh) * 2010-12-15 2014-07-16 中标软件有限公司 一种Linux串口通信日志记录的方法
JP5429243B2 (ja) * 2011-08-04 2014-02-26 日本電気株式会社 情報処理装置、情報処理システム、メッセージ制御方法およびプログラム
US9086945B2 (en) 2011-09-01 2015-07-21 Dell Products, Lp System and method to correlate errors to a specific downstream device in a PCIe switching network
US9501441B2 (en) 2013-12-16 2016-11-22 Dell Products, Lp Mechanism to boot multiple hosts from a shared PCIe device
US9712382B2 (en) * 2014-10-27 2017-07-18 Quanta Computer Inc. Retrieving console messages after device failure
CN106484639A (zh) * 2016-10-10 2017-03-08 郑州云海信息技术有限公司 一种通过ipmi协议获取CPU寄存器信息的方法
CN106789195A (zh) * 2016-12-02 2017-05-31 华为技术有限公司 一种事件处理方法及网管设备、服务器
US10783044B2 (en) * 2018-09-24 2020-09-22 Salesforce, Inc. Method and apparatus for a mechanism of disaster recovery and instance refresh in an event recordation system
CN110018949B (zh) * 2019-03-22 2023-03-10 烽火超微信息科技有限公司 一种基于ipmi协议的通用日志管理方法及系统

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5592664A (en) * 1991-07-29 1997-01-07 Borland International Inc. Database server system with methods for alerting clients of occurrence of database server events of interest to the clients
JP2661551B2 (ja) * 1994-07-13 1997-10-08 日本電気株式会社 無線lanシステム
US6125392A (en) * 1996-10-11 2000-09-26 Intel Corporation Method and apparatus for high speed event log data compression within a non-volatile storage area
US6009256A (en) * 1997-05-02 1999-12-28 Axis Systems, Inc. Simulation/emulation system and method
US6148338A (en) * 1998-04-03 2000-11-14 Hewlett-Packard Company System for logging and enabling ordered retrieval of management events
US6167549A (en) * 1998-07-10 2000-12-26 Kye Technology Corporation Memory access control device, and its control method
CA2351478A1 (en) * 1998-11-18 2000-05-25 Lightbridge Inc. Event manager for use in fraud detection
US6430616B1 (en) * 1998-12-04 2002-08-06 Sun Microsystems, Inc. Scalable system method for efficiently logging management information associated with a network
JP2001175500A (ja) * 1999-12-17 2001-06-29 Nec Ic Microcomput Syst Ltd インサーキットエミュレータのトレース方法、トレース手順を記録した記録媒体およびトレース回路
US7127722B2 (en) * 2001-06-18 2006-10-24 Intel Corporation Method and apparatus for avoiding multiple processing of the same IPMI system event
US6989745B1 (en) * 2001-09-06 2006-01-24 Vistascape Security Systems Corp. Sensor device for use in surveillance system
US20030130969A1 (en) * 2002-01-10 2003-07-10 Intel Corporation Star intelligent platform management bus topology
JP4318643B2 (ja) * 2002-12-26 2009-08-26 富士通株式会社 運用管理方法、運用管理装置および運用管理プログラム
US7966389B2 (en) * 2003-04-22 2011-06-21 Hewlett-Packard Development Company, L.P. System and method for application programming interface for extended intelligent platform management

Also Published As

Publication number Publication date
US20060085690A1 (en) 2006-04-20
CN1761212B (zh) 2010-05-05
GB0520965D0 (en) 2005-11-23
DE102005049055B4 (de) 2018-11-15
TWI367415B (en) 2012-07-01
AU2005222564A1 (en) 2006-05-04
FR2880443A1 (fr) 2006-07-07
GB2419203B (en) 2007-03-21
BRPI0504440B1 (pt) 2017-05-16
JP2006114046A (ja) 2006-04-27
ITTO20050735A1 (it) 2006-04-16
SG141467A1 (en) 2008-04-28
BRPI0504440A (pt) 2006-06-27
SG121977A1 (en) 2006-05-26
HK1093820A1 (en) 2007-03-09
GB2419203A (en) 2006-04-19
TW200627141A (en) 2006-08-01
KR20060054026A (ko) 2006-05-22
IE20050696A1 (en) 2006-05-17
MY139659A (en) 2009-10-30
CN1761212A (zh) 2006-04-19

Similar Documents

Publication Publication Date Title
DE102005049055B4 (de) Verfahren, um Ereignisse in einem Systemereignisprotokoll in eine Reihenfolge zu bringen
DE69911681T2 (de) Verfahren zum Verfolgen von Konfigurationsänderungen in Netzwerken von Rechnersystemen durch historische Überwachung des Konfigurationsstatus der Vorrichtungen im Netzwerk
DE60220287T2 (de) System und verfahren zur überwachung von software-warteschlangenanwendungen
DE10113577A1 (de) Verfahren, Computerprogrammprodukt und Computersystem zur Unterstützung mehrerer Anwendungssysteme mittels eines einzelnen Datenbank-Systems
WO2008071448A1 (de) Computerimplementiertes system zur analyse, verwaltung, beherrschung, bewirtschaftung und überwachung einer komplexen hardware-/softwarearchitektur
DE102005008520A1 (de) Verfahren zum Überwachen eines Verzeichnisses in einem Computersystem, Computerprogramm-Produkt und Computersystem zum Ausführen dieses Verfahrens
DE112010004565T5 (de) System, Verfahren und Programm zur Prüfung der Konsistenz von Zeigern in einer Hierarchischen Datenbank
DE112012004247T5 (de) Passives Überwachen virtueller Systeme unter Verwendung einer erweiterbaren Indexierung
DE19617976A1 (de) Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen
DE10119876A1 (de) Verfahren, System und Computerprorammprodukt zur Bereitstellung einer Jobüberwachung
DE112013006588T5 (de) Verwaltungssystem zum Verwalten eines Computersystems und Verwaltungsverfahren hierfür
DE10220886A1 (de) Datenspeichersysteme mit verbesserten Netzwerkschnittstellen
DE60002618T2 (de) Verfahren und Analysewerkzeug zur Fehlerortung in einem Rechner
DE112018004138T5 (de) Asynchrone aktualisierung von metadatenspuren in reaktion auf einen mittels einer e/a-operation über eine busschnittstelle erzeugten cachetreffer
DE112013000751T5 (de) Datenverarbeitung, Datensammlung
EP2752724B1 (de) Verfahren zur Kontrolle von Feldgeräten, Steuergerät, Programmelement und computerlesbares Medium
EP2073136B1 (de) System und Verfahren zum Erzeugen von Auswertedaten
DE10213009A1 (de) Verfahren zum elektronischen Testen von Speichermodulen
DE10259794A1 (de) Verfahren und Vorrichtung für das Event Management
DE112018002837B4 (de) Überwachung für gemeinsam angeordnete container in einem hostsystem
DE102004041707A1 (de) Kopiermaschine zum Erzeugen oder Aktualisieren eines identischen Speichers in redundanten Computersystemen
DE112012002268B4 (de) Modifizieren von Paketen zum Einsparen von Speicherplatz
DE10028870A1 (de) Elektronische Wagenprüfkarte
DE602004012108T2 (de) Fernkonfigurationsmanagement eines Datanverarbeitungssystems
EP0893770B1 (de) Verfahren zur schnellen Kommunikation in einem parallelen Computersystem und mit diesem Verfahren betriebenes paralleles Computersystem

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final