Übersicht über Ereignismetadaten

Dies ist eine Übersicht darüber, was für die End-to-End-Journey eines Ereignisses für jede der vier von Microsoft entwickelten Ablaufverfolgungstechnologien zu erwarten ist: TraceLogging, manifestbasiert, WPPund MOF. Sie nähert sich dem Problem sowohl in Bezug auf die Nutzlast eines einzelnen Ereignisses als auch auf die zugehörigen Metadaten, die seine Struktur beschreiben, sodass das Ereignis später in sinnvolle Datenteile decodiert werden kann. Das Verständnis des Wegs der einzelnen Ereignisse ist wichtig, wenn Sie auswählen, welche Ablaufverfolgungstechnologie für ein Projekt geeignet ist. Es gibt keine lösungsorientierte Lösung für die Ablaufverfolgung.

Ereignisnutzlasten

Bei allen von Microsoft bereitgestellten Ablaufverfolgungstechnologien werden beim Aufrufen des Write-Befehls (z. B. EventWrite für manifestbasiertes oder TraceLoggingWrite für TraceLogging) die daten, die zur Laufzeit für das Ereignis bereitgestellt werden, in ein zusammenhängendes binäres Blob, das als Ereignisnutzlast bezeichnet wird, aufgeteilt. Dies ist getrennt vom Ereignisschema oder den Ereignismetadaten (weiter unten erläutert), in dem das Layout dieses binären Blobs für Decodierungstools beschrieben wird. Wie genau die Generierung der Ereignisnutzlast erfolgt, hängt von der verwendeten Ablaufverfolgungstechnologie ab und letztendlich davon, ob das Ereignis klassisch (TraceEvent-Stil) oder modern (EventWrite-Stil) ist.

Bei klassischen Ereignissen wird das Flag in EVENT _ TRACE _ HEADER an TraceEvent übergeben, das bestimmt, wie dies geschieht:

- Wenn WNODE _ FLAG USE MOF _ _ _ PTR angegeben ist, folgt ein Array von _ MOF-FELDERN dem _ EREIGNISABLAUFVERFOLGUNGSHEADer _ im Arbeitsspeicher. Die ETW-Runtime verkettet die Ereignisdaten wie in diesen Feldern angegeben, um die Ereignisnutzlast zu bilden.

- Wenn WNODE _ FLAG USE MOF _ _ _ PTR nicht angegeben ist, wird die Ereignisnutzlast vom Benutzer direkt im Arbeitsspeicher nach dem EVENT TRACE _ _ HEADERerstellt.

MOF und WPP sind klassische Anbieter. Die WPP-Implementierung übernimmt jedoch all dies für Sie.

Bei nicht klassischen Ereignissen wird eine Reihe von EVENT _ _ DATA-DESKRIPTOREN an EventWriteübergeben. Die ETW-Runtime verkettet die Ereignisdaten wie in diesen Deskriptoren angegeben, um die Ereignisnutzlast zu bilden.

Sowohl manifestbasierte als auch TraceLogging-Technologien sind im Allgemeinen moderne Anbieter. Wenn Sie manifestbasiert mc.exe Protokollierungscode für Sie generieren lassen (Um- oder Km-Switch), wird die Nutzlastgenerierung für Sie erledigt. Die Nutzlastgenerierung wird immer durch TraceLogging durchgeführt.

Das Endergebnis ist, dass eine Nutzlast für ein Ereignis zur Laufzeit generiert wird. Alle Nutzlasten sind grundsätzlich ähnlich, da sie binäre Blobs von Daten sind, die nur die Felddaten für dieses bestimmte Ereignis enthalten, unabhängig von der verwendeten Ablaufverfolgungstechnologie und den Feldtypen, die von dieser Ablaufverfolgungstechnologie unterstützt werden. Ohne die Ereignismetadaten ist die Ereignisnutzlast bedeutungslos und nicht lesbar.

Die AUFGABE der ETW-Runtime besteht dann darin, dieses Ereignisblob vom Anbieter an den Consumer zu übertragen, wo es den Metadaten neu zugeordnet wird und decodierbar wird. Die ETW-Runtime fügt einige zusätzliche Metadaten hinzu, die die Umstände der Nutzlast angeben, z. B. Zeitstempel, Thread-ID und Schlüsselwörter des Ereignisses. Diese Informationen sind relevant für die Weiterleitung des Ereignisses durch die Laufzeit und sind auch nützlich, um die Identität und den Kontext des Ereignisses zum Zeitpunkt der Decodierung zu verstehen. Sie wird schließlich als Teil der _ EREIGNISABLAUFVERFOLGUNG oder DES _ EREIGNISDATENSATZES für den Consumer ausgegeben.

Ereignismetadaten

Die Journey für Ereignismetadaten unterscheidet sich je nachdem, welche Ablaufverfolgungstechnologie verwendet wird, und es ist einer der größten Überlegungen beim Vergleich der einzelnen Technologien.

MOF

Ereignismetadaten werden vom Ersteller des Ereignisses in Form eines speziellen MOF-Schemas in einer MOF-Datei von Hand erstellt. Das erstellte Schema muss mit der Nutzlast übereinstimmen, die protokolliert wird, damit das Ereignis von Consumern ordnungsgemäß decodiert werden kann. Ereignisdecoder erfordern, dass die MOF-Datei mit mofcomp.exeauf dem System registriert wird. Weitere Informationen zum Veröffentlichen von MOF-Schemas finden Sie unter Veröffentlichen ihres Ereignisschemas für einen klassischen Anbieter.

Wpp

Ereignismetadaten werden automatisch generiert und in der PDB-Datei Ihrer Binärdatei gespeichert, indem während des Buildprozesses tracewpp.exe. Diese Metadaten können später in Form einer eigenständigen TMF-Datei mittels tracepdb.exe extrahiert werden. Ereignisdecoder erfordern in der Regel entweder die PDB- oder tmf-Datei. Weitere Informationen zu tracepdb.exe finden Sie unter Übersicht über Tracepdb.Weitere Informationen zu tracewpp.exe finden Sie unter TraceWPP-Aufgabe.

Manifestbasiert

Ereignisdefinitionen werden in einer MAN-Datei erstellt. Ereignismanifeste werden über den Manifestcompiler (mc.exe) ausgeführt und generieren die Header, die für die Quellkompilierung erforderlich sind, sowie mehrere binäre BIN-Ressourcendateien. Diese Ressourcendateien müssen dann als Ressourcen in eine Binärdatei kompiliert werden, und die resultierende Binärdatei muss auf dem System platziert werden, das Ereignisse von diesem manifestbasierten Anbieter decodieren möchte. Darüber hinaus muss das Manifest auf dem System mit wevtutil.exe installiert werden. Die Attribute resourceFileName und messageFileName im XML-Anbieterelement im installierten Ereignismanifest müssen den vollständigen absoluten Pfad zur Binärdatei, in der die Ressourcendateien platziert wurden, ordnungsgemäß identifizieren. Beachten Sie, dass diese Pfade zur Manifestinstallationszeit mithilfe der wevtutil.exe Switches /rf und /mf überschrieben werden können. Ein System, das diese Schritte nicht ordnungsgemäß und vollständig ausgeführt hat, kann keine Ereignisse von diesem Anbieter decodieren. Ereignisdecoder erfordern daher ein installiertes Manifest und die Binärdatei mit den zugeordneten Ressourcen, die an dem von Ressourcen- und Nachrichtendateipfaden angegebenen Speicherort installiert sind. Weitere Informationen zum Veröffentlichen manifestbasierter Schemas finden Sie unter Veröffentlichen ihres Ereignisschemas für einen manifestbasierten Anbieter.

TraceLogging

Alle TraceLogging-Ereignisse sind selbstbeschreibend. Die ereignismetadaten, die zum Decodieren des Ereignisses erforderlich sind, werden automatisch generiert und zusammen mit der Nutzlast in einem kompakten Binärformat übertragen. Ereignisdecoder benötigen nur das TraceLogging-Ereignis und ein Verständnis des TraceLogging-Metadatenformats.

Konfigurieren von TDH für die Decodierung

Es gibt viele Decodierungstools. Es wird jedoch empfohlen, nach Möglichkeit TDH zu verwenden, da alle Ablaufverfolgungstechnologien mit einer einheitlichen API decodiert werden. Je nach Typ der Ablaufverfolgung, die Sie decodieren möchten, erfordert TDH möglicherweise eine explizite Konfiguration.

MOF

TDH verwendet MOF-Decodierungsdaten, die auf dem System mithilfe mofcomp.exe registriert sind. Weitere Informationen finden Sie unter Veröffentlichen des Ereignisschemas für einen klassischen Anbieter.

Wpp

TDH muss entweder auf die PDB-Datei oder die zugeordnete TMF-Datei für den WPP-Anbieter gezeigt werden, den Sie decodieren möchten. Dies kann durch Aufrufen von TdhSetDecodingParametererfolgen. Andernfalls wird die Decodierungs-Engine auf die Umgebungsvariable TRACE _ FORMAT _ SEARCH PATH _ zurückgreifen.

Manifestbasiert

TDH verwendet alle manifestbasierten Anbieter, die mit wevtutil.exe auf dem System registriert sind.

TraceLogging

Die neuesten Versionen von TDH erkennen und decodieren TraceLogging-Ereignisse automatisch ohne zusätzliche Schritte.