Windows Vista

Neue Tools für die Ereignisverwaltung in Windows Vista

Val Menn

 

Kurz zusammengefasst:

  • Neue Ereignisinfrastruktur
  • Ereignistypen
  • Strukturierte Ereigniseigenschaften
  • Verwenden von XPath-Ausdrücken

Viele Leute halten die Ereignisprotokollierung und Ablaufverfolgung für langweilig. Andere wiederum beschweren sich, dass Ablaufverfolgungen und Ereignisse viel zu häufig lediglich Nebenprodukte sekundärer Aktivitäten (wie Debugging und Selbstüberwachungsfunktionen) sind und dass den Ereignis- und Ablaufverfolgungsfunktionen nicht genug Bedeutung zugemessen wird.

Microsoft® Windows Vista™ zielt darauf ab, diese Eindrücke zu korrigieren, und bietet einen Riesenfortschritt in der Unternehmensverwaltung. Microsoft hat einige Kernkomponenten einschließlich der zugehörigen Benutzeroberflächen überholt. Der Ereignisprotokolldienst wurde speziell im Hinblick auf das Unternehmen vollständig überarbeitet, und die Ablaufverfolgung wurde schneller und sicherer gemacht.

Stellen Sie sich vor, Sie hätten bessere Tools zur Erkennung und Behebung von Problemen in unternehmenswichtigen Systemen. Oder wie wäre es mit Funktionen, mit denen ein Supporttechniker mühelos verdächtige Ereignisse und Ablaufverfolgungsinformationen aus dem System eines Benutzers erfassen kann? Was hielten Sie davon, wenn Entwickler anhand von Ablaufverfolgungsinformationen, die von Benutzern gesendet wurden, Probleme in einem bereitgestellten System im Handumdrehen diagnostizieren und lösen könnten? Stellen Sie sich vor, es gäbe einfachere und leistungsfähigere Wege, Informationen zu sammeln und schnell Fehler zu beheben – wäre das nicht von Interesse?

Was sind Ereignisse?

Eine Computeranwendung ist wie eine „Black Box“, die eine oder mehrere Funktionen erfüllt. In dieser Box geht vieles vor; da Sie aber nicht hinein sehen können, ist es äußerst schwierig, ihr Innenleben zu verstehen. Anwendungen kommunizieren jedoch mit der Außenwelt – nämlich mit anderen Programmen und mit Benutzern. Diese kommunikativen „Ereignisse“ gewähren Ihnen einen Einblick in die Anwendung.

Was Software betrifft, so wird ein Ereignis in der Regel als ein Vorfall innerhalb eines Softwaresystems definiert, der an die Außenwelt (also Benutzer oder andere Programme) übermittelt wird. Bei einem solchen Ereignis handelt es sich normalerweise um eine Zustands- oder Konfigurationsänderung. Das Ereignis kann den aktuellen Zustand oder die aktuelle Konfiguration des Softwaresystems sowie die Gründe für die Änderung vermitteln.

Im weiteren Sinne wird der Begriff Ereignis auch verwendet, um sich auf die Art und Weise zu beziehen, in der diese Vorfälle offen gelegt werden. Es gibt zahlreiche Beispiele für ein solches offen gelegtes Ereignis:

  • Ein für die Kommunikation zwischen Prozessen (IPC) verwendetes Win32®-Objekt
  • Ein für vorübergehende (nicht-persistente Benachrichtigungen) verwendetes WMI -Ereignis
  • Ein EWT (Event Tracing for Windows)-Ablaufverfolgungsereignis, das in Ablaufverfolgungsdateien gespeichert wird
  • Ein Ereignisprotokollereignis, das in Liveprotokollen des Ereignisprotokolls gespeichert und eventuell in Ereignisprotokolldateien archiviert wurde
  • Ein Ereignis, das mithilfe einer benutzerdefinierten Infrastruktur in Dateien gespeichert wurde

Die drei zuletzt aufgeführten Beispiele gehören zu der Art von Ereignissen, mit denen sich dieser Artikel beschäftigt.

Verwendungsweise von Ereignissen

Bei einer Ablaufverfolgung oder einem protokollierten Ereignis handelt es sich um die Aufzeichnung eines Vorfalls in einem Programm oder Betriebssystem. Diese Ablaufverfolgungen und Ereignisprotokolle sind nicht nur für Entwickler bestimmt. Sie sind unerlässliche Hilfsmittel für IT- und Supportmitarbeiter und bieten einen Einblick in den Zustand und die Funktionsweise der von Ihnen ausgeführten Anwendungen.

Mithilfe dieser Protokolle ist es möglich, den allgemeinen Systemzustand zu überwachen. Anhand des Ereignisprotokolls können Sie nach Ereignissen suchen, die auf Probleme hinweisen. Beispielsweise könnte es sein, dass Sie im Anwendungsprotokoll aus der Quelle „CertificateServicesClient“ den Fehler 6 mit der folgenden Meldung finden: „Die automatische Zertifikatregistrierung für das lokale System ist fehlgeschlagen (0x80070576). Es besteht ein Zeit- und/oder Datumsunterschied zwischen dem Server und dem Client.“ Gleichermaßen können Sie auch den Übergang aus einem fehlerhaften Zustand zurück in den normalen Betrieb feststellen. So könnte es nach Behebung des Datums- und Zeitunterschieds sein, dass dieselbe CertificateServiceClient-Quelle im Anwendungsprotokoll das Informationsereignis 19 mit der folgenden Meldung veröffentlicht: „Ein Zertifikat AutoenrolledWindowsSystemComponentVerification von der Zertifizierungsstelle <Name der Zertifizierungsstelle> wurde von der Zertifikatregistrierung für <Benutzername> erfolgreich empfangen.“ Derartige Informationen sind extrem nützlich, um Konflikte und andere Konfigurationsprobleme erkennen und beheben zu können.

Darüber hinaus dienen diese Informationen zur Diagnose von Problemen. Sie können nach Programm- und Systemaktionen suchen, die zu einem Problem führen, und Details herausfinden, die Ihnen bei der Ermittlung der Grundursache behilflich sind. Zugleich lassen sich anhand dieser Informationen auch Leistungsprobleme beurteilen und beheben.

Darüber hinaus bieten Ereignisprotokolle wertvolle Informationen, mit deren Hilfe Sie für eine verbesserte Sicherheit der Umgebung sorgen können. Sie können damit Eindringversuche erkennen, das Verlaufsprotokoll des Systems prüfen, Nichtabstreitbarkeit sicherstellen sowie nicht ordnungsgemäß konfigurierte Ressourcen ausfindig machen.

Ereignisse in Windows Vista

Was die Ereignisprotokollierung und Ablaufverfolgung anging, so wiesen frühere Versionen von Windows® zahlreiche Mängel auf. Dazu zählten die beschränkte Skalierbarkeit des Ereignisprotokolls (bei dem die Gesamtgröße aller Protokolle auf den Umfang des verfügbaren Arbeitsspeichers begrenzt war), die Leistung bei der Veröffentlichung von Ereignissen (bei der beispielsweise die Anzahl von Ereignissen, die auf einem aktiven Domänencontroller veröffentlicht werden konnten, eingeschränkt war) sowie die begrenzte Sicherheit der Ablaufverfolgungsereignisse.

Windows Vista behebt viele dieser Probleme mit einer neuen Infrastruktur für Ereignisprotokollierung und Ablaufverfolgung namens Windows Eventing 6.0. Diese Infrastruktur erweitert die Funktionalität der seit Windows 2000 eingesetzten Ereignisablaufverfolgung für Windows (Event Tracing for Windows, ETW) und ersetzt den Ereignisprotokolldienst sowie die Ereignisanzeige. Das neue Windows Eventing ist speziell zur Handhabung von Ereignissen konzipiert, die für zukünftige Untersuchungen dauerhaft in Protokolldateien geschrieben werden. (Es ist nicht für vorübergehende Ereignisse wie IPC und Benachrichtigungsmechanismen bestimmt.)

Durch das Bereitstellen von Sicherheits- und Skalierbarkeitslösungen sollten benutzerdefinierte Implementierungen der Ereignisprotokollierung und Ablaufverfolgung an Bedeutung verlieren. Beachten Sie, dass parallel zu diesen neuen Erweiterungen vollständige Kompatibilität mit dem bestehenden Ereignisprotokoll und den ETW-APIs gewahrt wird, d. h., dass alle vorhandenen Anwendungen auch weiterhin unverändert funktionieren.

Neue Methoden zur Anzeige von Ereignissen

Die bestehende Ereignisanzeige wird in der IT-Community bereits als eines der beliebtesten Windows-Programme angesehen. Die neue Ereignisanzeige wurde vollständig umgeschrieben. Da sie in Microsoft Management Console (MMC) 3.0 integriert ist, hat sich ihr Erscheinungsbild ebenfalls geändert, ist jedoch noch vertraut genug, um einen relativ mühelosen Übergang zu ermöglichen.

Es gibt immer noch eine hierarchische Struktur und eine Ereignisliste. Unter dem Knoten „Windows-Protokolle“ ist auch weiterhin der Zugriff auf die vertrauten Anwendungs-, System- und Sicherheitsprotokolle möglich. Allerdings wurden dem Stamm einige neue Knoten hinzugefügt, und unter dem Knoten „Windows-Protokolle“ befindet sich jetzt das neue Protokoll „ForwardedEvents“, das weiter unten besprochen wird.

Das auffälligste neue Feature ist der Vorschaubereich unterhalb der Ereignisliste. Er umfasst die Eigenschaften des aktuell ausgewählten Ereignisses. Das heißt, Sie müssen nicht mehr auf ein Ereignis doppelklicken, um seine Eigenschaften anzuzeigen, und auch nicht mehr mit Fenstern jonglieren, um sowohl die Ereignisliste als auch das Dialogfeld „Ereigniseigenschaften“ anzuzeigen. Eigenschaften können im Dialogfeld nach wie vor durch Doppelklicken auf ein Ereignis angezeigt werden. Das neue Dialogfeld ist jedoch nicht modal, sodass mehrere Dialogfelder für Ereigniseigenschaften gleichzeitig geöffnet sein können.

Mithilfe der neuen Ansichten lassen sich mit nur wenigen Mausklicks alle Ereignisse darstellen, die für Sie von Interesse sind. Ereignisse können für eine oder mehrere Protokolldateien gesammelt werden und sich schwerpunktmäßig auf bestimmte IDs, Levels (Schweregrad) oder Zeitrahmen beziehen.

Unter dem Knoten „Benutzerdefinierte Ansichten“ werden administrative Ereignisse angezeigt (siehe Abbildung 1). Hier finden sich alle Fehler und Warnungen aus den verschiedenen Protokolldateien, die für Administratoren von Interesse sind.

Figure 1 Administrative Ereignisse

Figure 1** Administrative Ereignisse **(Klicken Sie zum Vergrößern auf das Bild)

Wie genau wurde bestimmt, welche Protokolle und Ereignisse für Administratoren interessant sind? Microsoft hat fünf separate Ereignistypen und die jeweils damit in Bezug stehenden Benutzer bestimmt. Diese werden in Abbildung 2 im Einzelnen dargestellt. Hierbei handelt es sich um eine sehr allgemeine aber dennoch effektive Aufteilung sämtlicher Ereignisse von Ereignisprotokoll und Ablaufverfolgungen, die für verschiedene Gruppen von Interesse sein können.

Figure 2 Ereignistypen und ihre Zielgruppen

Ereignistyp Beschreibung Verwendet von
Administrativ Ereignisse vom Typ „Administrativ“ dürften für die meisten Administratoren ausreichend sein. Hierbei handelt es sich um äußerst wichtige Ereignisse, die oftmals genügend Informationen bieten, um ein Problem festzustellen und seine Lösung zu ermitteln. Zumindest sollten administrative Ereignisse angeben, wenn ein Problem auftritt oder wenn sich eine Anwendung, eine Komponente oder das System als Ganzes in einem fehlerhaften Zustand befindet oder daraus wiederhergestellt wurde. Die meisten administrativen Ereignisse sind Fehler oder Warnungen und erfordern in der Regel eine Aktion. Administratoren, Supportmitarbeiter sowie Überwachungs- und Analyseprogramme
Operationell Wie administrative Ereignisse ermöglichen operationelle Ereignisse ebenfalls eine Problemdiagnose. Operationelle Ereignisse bestehen aus mehr als nur Fehlern und Warnungen. Sie informieren Benutzer zudem über den normalen Betrieb einer Anwendung oder Betriebssystemkomponente. Das Aufkommen dieser Art von Ereignissen ist relativ gering gehalten, sodass operationelle Ereignisse aktiviert werden können, ohne dass hierdurch die Systemleistung beeinträchtigt wird. Operationelle Ereignisse – wie auch administrative Ereignisse – werden von Supportmitarbeitern, Überwachungsprogrammen und einigen Administratoren genutzt. Erfahrene Administratoren, Supportmitarbeiter sowie Überwachungs- und Analyseprogramme
Audit Auditereignisse stellen Aufzeichnungen aller Zugriffe auf Ressourcen oder von Benutzern durchgeführten Aktionen bereit. Diese Ereignisse an sich stellen nicht den Fehlschlag oder Erfolg des Programms dar, sondern geben an, ob die Aktion erfolgreich war oder fehlgeschlagen ist. Auditereignisse können entweder ganz deaktiviert oder selektiv mit verschiedenen Granularitätsstufen aktiviert werden. Sicherheitsüberprüfungen auf Betriebssystemebene werden unterstützt (die Ereignisse sind im Sicherheitsprotokoll des Ereignisprotokolls zu finden). Erfahrene Administratoren, Sicherheitsprüfer und forensische Experten
Analytisch Analytische Ereignisse unterscheiden sich nicht sehr von operationellen Ereignissen und werden im Rahmen des normalen Betriebs von Anwendungen und Komponenten aufgezeichnet. Jedoch treten analytische Ereignisse in höherem Umfang als operationelle Ereignisse auf und umfassen mehr Details, daher besteht die Möglichkeit einer Beeinträchtigung der Systemleistung. Aus diesem Grund werden analytische Ereignisse in der Regel deaktiviert. Um analytische Ereignisse zu nutzen, sollten sie vor einer Sitzung zu diagnostischen Zwecken aktiviert und dann vor Auswertung der Ablaufverfolgung deaktiviert werden. Supportmitarbeiter, Überwachungs- und Analyseprogramme
Debug Debugereignisse treten ebenfalls in sehr hohem Umfang auf und sind in der Regel deaktiviert. Sie werden hauptsächlich von Entwicklern genutzt und selten von IT-Experten angesehen. Entwickler

Jedes Protokoll in Windows Eventing hat einen festgelegten Typ. Alle Ereignisse im jeweiligen Protokoll weisen denselben Typ auf wie das Protokoll selbst. Die Ansicht in Abbildung 1 wurde anhand dieser Typeninformationen definiert – es werden dort alle Fehler- und Warnungsereignisse aus Protokollen des Typs „Administrativ“ angezeigt.

Die Architektur von Windows Eventing

Die Infrastruktur von Windows Eventing setzt sich aus Softwarekomponenten zusammen, mit denen Ereignisobjekte von Programmen veröffentlicht und an Protokolldateien zugestellt werden können. Der Transport zur Übertragung der verschiedenen Ereignistypen von den Ereignisherausgebern an die jeweiligen Ziele wird von ETW bereitgestellt. ETW wurde in Windows Vista ebenfalls überarbeitet und bietet jetzt bessere Leistung und erhöhte Sicherheit. Das Veröffentlichen von Ereignissen über ETW ist ein asynchroner Prozess und beeinträchtigt daher nicht die Leistung des veröffentlichenden Programms. Wenn vom System ein neues Ereignis empfangen wird, werden Informationen über den aktuellen Benutzerkontext und den Veröffentlichungsprozess gesammelt und an das Ereignis angehängt.

Im Anschluss an die Veröffentlichung von Ereignissen werden verschiedene Typen jeweils auf unterschiedliche Weise verarbeitet. Da analytische und Debugereignisse in der Regel sehr häufig vorkommen, müssen sie mit minimalem Verarbeitungsaufwand in einer Datei gespeichert werden, um so eine Beeinträchtigung der Systemleistung zu vermeiden. Daher werden diese Ereignisse umgehend in einer Ablaufverfolgungsdatei gespeichert.

Administrative und operationelle Ereignisse treten selten genug auf, um einen zusätzlichen Verarbeitungsaufwand zuzulassen, ohne die Systemleistung zu beeinträchtigen. Diese Ereignisse werden an den Ereignisprotokolldienst übergeben, der sie in Live-Ereignisprotokollen speichert und sie optional an Echtzeitabonnenten zustellen kann. Abonnenten können mithilfe einer Abfragesprache, die weiter unten behandelt wird, Ereignisse auswählen, die ihnen zugestellt werden sollen.

Es gibt zwei Abonnenten, die von besonderem Interesse für die IT-Community sind. Dabei handelt es sich um den in hohem Maße verbesserten Windows Vista-Taskplaner sowie die Ereignisweiterleitung, mit der Ereignisse an eine Remoteereignissammlung gesendet werden können.

Strukturierte Ereignisse

Eine häufige Beschwerde über Ereignisprotokolle ist, dass sie eine Menge unnötige Informationen enthalten. Das heißt, sie sind voll von Ereignissen, die wenig oder keine Bedeutung haben und dazu neigen, die wichtigen Ereignisse zu verbergen oder zu verschleiern. Während bestimmte Ereignisse kaum informativ sind, können manche Informationen, die von einem Benutzer als völlig überflüssig angesehen werden, für einen anderen Benutzer extrem wertvoll sein.

Windows Vista bietet die Möglichkeit, uninteressante Ereignisse hinauszufiltern, sodass Sie sich auf die Ereignisse konzentrieren können, die Ihnen wichtig sind. Hierzu wird eine protokollübergreifende Abfragesprache verwendet, die vom Ereignisprotokolldienst unterstützt wird. Damit dies funktionieren kann, müssen alle Ereignisse einer klar definierten Struktur folgen.

In vorherigen Versionen des Ereignisprotokolls gab es eine gewisse Strukturierung von Ereignissen, jedoch war diese Struktur nicht klar definiert und lediglich für die Win32-API sichtbar. In Windows Vista weisen alle Ereignisse eine klar definierte Struktur auf. Genau genommen werden Ereignisse extern unter Verwendung von XML mit einem veröffentlichten Schema dargestellt. Dadurch können Abfragen erstellt werden, die die für Sie interessanten Ereignisse sammeln, während nicht relevante Ereignisse herausgefiltert werden. Da XML verwendet wird, wurde XPath als Grundlage für die Ereignisabfragesprache gewählt. Der Einsatz von strukturierten Ereignissen eröffnet selbstverständlich neue Möglichkeiten für die Automatisierung, wie sich an der neuen Taskplaner-Integration erkennen lässt.

Der Ereignisvorschaubereich umfasst jetzt eine Registerkarte „Details“. Dieselbe Registerkarte ist auch im Dialogfeld „Ereigniseigenschaften“ verfügbar. Bei Auswahl der Registerkarte „Details“ im Dialogfeld „Ereigniseigenschaften“ wird die XML-Darstellung des Ereignisses angezeigt. Bei dem in Abbildung 3 gezeigten Beispiel handelt es sich um ein operationelles Ereignis aus dem Taskplaner. Es umfasst zwei Teile. Der Teil „System“ besteht aus den allgemeinen Ereignisinformationen, die allen Instanzen dieses Ereignisses gemein sind, sowie bestimmten Systemparametern, die bei Veröffentlichung dieser Instanz erfasst wurden. Der erweiterbare Bereich „EventData“ weist strukturierte Informationen aus der Anwendung auf.

Figure 3 XML-Darstellung eines Ereignisses

Figure 3** XML-Darstellung eines Ereignisses **(Klicken Sie zum Vergrößern auf das Bild)

Jede Ereignisprotokolldatei wird als eine Abfolge solcher strukturierten Ereigniselemente behandelt. Auf diese Weise wird eine logische und überschaubare Ansicht von Ereignisprotokoll- und Ereignisarchivdateien geboten. Die Daten werden intern in einem binären Format gespeichert, das dazu konzipiert ist, für einen Ausgleich zwischen Kompaktheit, Zuverlässigkeit und Suchleistung zu sorgen.

Ereignisattribute

Im Bereich „System“ der XML-Daten wird der Zeitpunkt angegeben, an dem das Ereignis eingetreten ist, sowie die Prozess-ID, die Thread-ID, der Computername und die Sicherheitskennung (Security Identifier, SID) des Benutzers. In früheren Versionen von Windows wiesen Ereignisse lediglich zwei Attribute auf – „EventID“ und „Category“. Die XML-Datei bietet zudem weitere Details, darunter die Eigenschaften „EventID“, „Level“, „Task“, „Opcode“ und „Keywords“. Im Folgenden werden diese etwas näher betrachtet.

EventID und Version: Ein Ereignis wird durch die Kombination seiner EventID (eine Zwei-Byte-Zahl) und seiner Version (eine Ein-Byte-Zahl) eindeutig definiert. Alle Ereignisse vom gleichen Ereignisanbieter, die dieselbe EventID und Version aufweisen, haben eine identische Struktur.

Level: Dieser Wert gibt den Schweregrad bzw. den Ausführlichkeitsgrad eines Ereignisses an. Allgemein werden die vordefinierten Werte 1 (Kritisch), 2 (Fehler), 3 (Warnung), 4 (Information) und 5 (Ausführlich) verwendet, jedoch kann ein Anbieter seine eigenen Werte bis zu einem Höchstwert von 255 definieren. Je höher der Wert, desto ausführlicher das Ereignis.

Task: Mit der Task-Eigenschaft wird in der Regel der allgemeine Funktionsbereich eines Ereignisses angegeben (z. B. Drucken, Netzwerk oder Benutzeroberfläche). Sie kann sich auch auf die Unterkomponente eines Programms beziehen. Diese Eigenschaften werden in hohem Maße von Sicherheitsüberwachungsereignissen eingesetzt. Jeder Ereignisherausgeber kann für diese Zwei-Byte-Zahl eine eigene Gruppe von Werten festlegen. Es ist zu beachten, dass die Bedeutung des Attributs „Task“ oftmals in semantischer Hinsicht dem Attribut „Category“ aus früheren Windows-Versionen entspricht und diesem übergeordnet ist. Aus diesem Grund wird dieser Wert in der Ereignisanzeige in einer Spalte namens „Aufgabenkategorie“ angezeigt.

Opcode: Dies ist ein Ein-Byte-Wert, der normalerweise für eine bestimmte von der Software durchgeführte Aktion bzw. Teilaktion steht. Dieser Wert wird oft in der Ablaufverfolgung aktivitätsbasierter Prozesse verwendet (z. B. bei Webdiensten, bei denen es sich bei der Aktivität um eine spezifische, vom Webdienst erhaltene Anforderung handelt). Es gibt einige vordefinierte Werte; die gängigsten sind 1 (Start) und 2 (Stopp).

Keywords: Hierbei handelt es sich um eine Maske mit 56 Flags, die vom Programm zur leichteren Gruppierung gleichartiger Ereignisse gesetzt werden können. Für jedes Ereignis können mehrere Flags gesetzt werden, wodurch angegeben wird, dass das Ereignis zu mehreren Gruppen gehört.

Grundlagen zu Herausgebern und Ereignissen

Es ist schwierig, proaktiv zu sein, wenn Sie nicht von vornherein alle Typen von Informationen kennen, die in Ereignisprotokollen und Ablaufverfolgungsdateien auftreten können. Daher bestand eines unserer Hauptziele für die neue Ereignisinfrastruktur darin, Dokumentation für jeden Ereignisherausgeber bereitzustellen, einschließlich von Informationen zu der jeweiligen Gruppe von Ereignissen und ihren Zielorten.

Um dies zu erreichen, muss jeder Herausgeber sämtliche Ereignisse auflisten, die je eventuell von ihm veröffentlicht werden, zusammen mit der jeweiligen Struktur dieser Ereignisse. Diese Informationen werden kompiliert, codiert und mit der Binärdatei des Herausgebers (einem Programm oder einer DLL) gespeichert.

Es ist jetzt möglich, sämtliche beim Ereignissystem registrierten Herausgeber sowie die Konfiguration der einzelnen Herausgeber zu ermitteln. Dazu müssen eine vollständige Liste aller potenziellen Ereignisse, die von einem Herausgeber aufgezeichnet werden können, die Struktur dieser Ereignisse sowie die zugehörigen Meldungen angezeigt werden – und zwar bevor diese Ereignisse überhaupt eingetreten sind. Abbildung 4 veranschaulicht, wie Anbieterinformationen mithilfe des Befehlszeilenprogramms „wevutil“ angezeigt werden können. Mit dem abgebildeten Befehl werden sämtliche Informationen dargestellt, die im System über den Ereignisherausgeber namens Microsoft-Windows-Video For Windows bekannt sind.

Figure 4 „Wevtutil“ wird zum Anzeigen von Anbieterinformationen verwendet

Figure 4** „Wevtutil“ wird zum Anzeigen von Anbieterinformationen verwendet **(Klicken Sie zum Vergrößern auf das Bild)

Funktionsweise der Abfragesprache

Wie bereits erwähnt, machte es die strukturierte Beschaffenheit der Ereignisse in der neuen Infrastruktur möglich, Unterstützung für eine Abfragesprache bereitzustellen, die auf XPath-Standardausdrücken basiert. Vorausgesetzt, ein Ausgangsort (ein XML-Element) ist vorhanden, kann ein XPath-Ausdruck im Allgemeinen auf eine beliebige Stelle innerhalb des Elements verweisen. (Eine vollständige Beschreibung der XPath-Sprache finden Sie in der offiziellen Referenz unter w3.org/TR/xpath). Üblicherweise verweist ein XPath-Ausdruck jedoch auf ein anderes Element oder Attribut, das im Ausgangselement vorhanden ist. Da es sich beim Ereignisprotokoll im Grunde um eine Abfolge von Ereigniselementen handelt, können Sie davon ausgehen, dass jedes Protokoll in etwa wie folgt aussieht:

<root>
<Event>... </Event>
...
<Event>... </Event>
</root>

Das Stammelement hat keinen Namen – es wird einfach als Kontext für alle XPath-Ausdrücke verwendet. Nur Vorwärtsachsen sind definiert, was bedeutet, dass ein XPath-Ausdruck auf Ereigniselemente, deren Unterelemente sowie ihre Attribute verweisen kann. Wenn ein XPath-Ausdruck ein bestehendes Element auswählt, wird dies als „True“ ausgewertet. Betrachten Sie das Beispiel eines sehr simplen XPath-Ausdrucks, der auf dem in Abbildung 3 angeführten Beispiel basiert:

*/System[Provider/@Name='Microsoft-Windows-TaskScheduler' and Level <= 2]

Mit diesem Ausdruck werden alle Ereigniselemente („alle“ wurde durch das Sternchen angegeben) aus dem Ereignisanbieter „Microsoft-Windows-TaskScheduler“ mit Level 2 oder geringer (d. h. alle kritischen oder Fehlerereignisse) ausgewählt.

Während Ereignisse aus einem einzigen Protokoll mithilfe eines einfachen XPath-Ausdrucks ausgewählt werden können, ermöglicht eine einfache, jedoch leistungsstarke XML-basierte Abfragesprache die Auswahl bzw. den Ausschluss von Ereignissen aus allen Protokollen und externen Ereignisarchiven. In der Tat ist die Abfragesprache überall im Ereignissystem von Windows Vista anzutreffen. So basiert beispielsweise „Benutzerdefinierte Ansichten“ auf Abfragen. Auch können Sie mithilfe der Abfragesprache angeben, welche Ereignisse aus bestimmten Protokollen in der Ereignisliste der Ereignisanzeige dargestellt werden sollen. Sie können die Sprache nutzen, um Ereignisse zu abonnieren, ausgewählte Ereignisse zu archivieren und Aktionen im neuen Taskplaner auszulösen.

Die eigentlichen XML- oder XPath-Ausdrücke müssen über das Befehlszeilenprogramm des Ereignisprotokolls eingegeben werden. Nicht jeder ist mit dem Definieren solcher Abfragen vertraut, daher verfügt die Ereignisanzeige über eine einfache Benutzeroberfläche zur Erstellung gängiger Abfragen. Mit dem in Abbildung 5 dargestellten Dialogfeld „Benutzerdefinierte Ansicht erstellen“ kann beispielsweise eine Ansicht für alle Taskplaner-Ereignisse erstellt werden. Beachten Sie, dass alle Dialogfelder zur Erstellung von Abfragen über eine Registerkarte „XML“ verfügen, auf der Sie den Text der Abfrage anzeigen und direkt bearbeiten können.

Figure 5 Benutzeroberfläche für das Erstellen von gängigen Abfragen

Figure 5** Benutzeroberfläche für das Erstellen von gängigen Abfragen **(Klicken Sie zum Vergrößern auf das Bild)

Gängige Verwendungszwecke für Abfragen

Abfragen können auf vielerlei Weise eingesetzt werden. Doch naturgemäß sind bestimmte Verwendungszwecke üblicher als andere. So werden Abfragen beispielsweise oft eingesetzt, um bestimmte Ereignisse in der Ereignisanzeige oder sogar im Befehlszeilenprogramm des Ereignisprotokolls anzuzeigen.

Mit dem Windows-Taskplaner können Sie einer Abfrage eine Aufgabe anhängen. Jedes Mal, wenn ein Ereignis veröffentlicht wird, das der Abfrage entspricht, wird dann die entsprechende Aufgabe vom Taskplaner gestartet. Beachten Sie, dass diese Funktion Abonnements verwendet und auf alle neu eingehenden Ereignisse reagiert. Sie können lediglich administrative und operationelle Ereignisse abonnieren; analytische und Debugereignisse werden direkt in die Ablaufdateien geschrieben und können bei ihrem Eintreten nicht vom System untersucht werden.

Abfragen können zum Archivieren ausgewählter Ereignisse eingesetzt werden. Ereignisse können aus Liveprotokollen jeder Art, älteren Ereignisarchiven (EVT-Dateien), externen Ablaufverfolgungsdateien oder Windows Vista-Ereignisarchivdateien ausgewählt werden. Archivdateien können in der Ereignisanzeige geöffnet, in sekundären Speichern gesichert oder zu Zwecken der Problemdiagnose an Supportmitarbeiter gesendet werden. Alle Ereignisbeschreibungen sowie andere, mit Ereignissen verknüpfte Zeichenfolgen können dem Archiv in einer Sprache hinzugefügt werden, die während des Archivbetriebs gewählt wurde. In diesem Fall stehen die Ereignisse dann mit vollständigen Beschreibungen auf allen Rechnern in der gewählten Sprache zur Verfügung.

Schließlich können Abfragen auch dazu eingesetzt werden, Ereignisse an ein System weiterzuleiten, dessen Aufgabe die Sammlung von Ereignissen ist. Bei diesem Feature kommt der neue Ereignissammlungsdienst zum Einsatz, mit dem ein Administrator Ereignisabonnements für Remotecomputer erstellen kann. Diese Abonnements bleiben auf dem Sammlungscomputer bestehen und können mithilfe eines konfigurierbaren Zeitplans wiederholt werden. Die Ereignissammlung verwendet das Industriestandardprotokoll „WS-Management“, um Abonnements auf den Remotecomputern zu erstellen, und das Protokoll „WS-Eventing“, um die Ereignisse zu übertragen. (Beide Protokolle sind sicher und firewallfreundlich.) Die von der Ereignissammlung empfangenen Protokolle werden im lokalen Ereignisprotokoll gespeichert.

Schlussbemerkung

Die Änderungen an Windows Eventing sind drastisch und von großer Tragweite – in diesem Artikel werden sie nur oberflächlich besprochen. Mit der Funktion zur Ereignisweiterleitung allein ließe sich ein ganzer Artikel füllen.

Das Ereignissystem weist Verbesserungen hinsichtlich Leistung, Skalierbarkeit, Zuverlässigkeit und Sicherheit auf. Doch sollte nicht vergessen werden, dass das Hauptziel darin bestand, die Verwaltbarkeit von Windows zu verbessern. Mithilfe der Abfragesprache sowie mit den Ansichten der Ereignisanzeige lassen sich Probleme leichter feststellen. Die enge Zusammenarbeit mit dem Taskplaner eröffnet Möglichkeiten zur einfachen Überwachung, automatischen Problembehebung sowie zur schnellen Benachrichtigung bei aufkommenden Problemen. Und die Ereignisweiterleitung ermöglicht das Archivieren von Ereignissen sowie die agentenlose Überwachung von Servern und Desktops.

Alle diese Features werden ohne Einbußen bei der Rückwärtskompatibilität implementiert, was bedeutet, dass vorhandene Lösungen auch weiterhin funktionieren. Die Verbesserungen am Ereignissystem sollten letztendlich dazu beitragen, dass Unternehmen ihre Systeme auf effizientere Weise verwalten können.

Val Menn arbeitet für die Management Infrastructure-Gruppe bei Microsoft und fungiert dort als Programm-Manager für das Ereignisprotokoll. Zuvor war er als Softwareingenieur und Systemadministrator bei einer Reihe von neu gegründeten Firmen tätig.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.