Die innere Struktur
Der bei weitem größte Teil eines Ereignis-Eintrags entfällt auf Daten in einer binären Darstellung von XML. Ich werde die Interna dieser komplexen Struktur in einer Serie von Beiträgen erklären. Heute beginne ich mit einer Übersicht über das XML Schema.
Glücklicherweise ist die XML Struktur nicht vollständig undokumentiert. Das Microsoft Developer Network bietet sogar eine recht ausführliche Dokumentation des XML Schemas. Die folgende Abbildung zeigt den groben Aufbau einer Protokolldatei in ihrer Textform:
<Events>
<Event>
<System> . . . </System>
<EventData> . . . </EventData>
</Event>
<Event>
<System> . . . </System>
<UserData> . . . </UserData>
</Event>
<Event>
...
</Event>
</Events>
Das "Events" Element umfasst die gesamte Datei. Es dient dabei als Container für die einzelnen "Event" Elemente. Jedes von ihnen enthält die Informationen über genau ein Ereignis. Jeder "Event" beginnt mit einem "System" Element, das durch den Ereignisprotokolldienst mit einigen grundlegenden Informationen wie einem Zeitstempel, der Ereignis-Nummer und dem meldenden Subsystem gefüllt wird. Das System-Element wird übrigens später eine wichtige Rolle spielen, wenn es um die Rekonstruktion von Daten aus Protokoll-Fragmenten geht.
Eine der "EventData", "UserData", "BinaryEventData", "DebugData" oder "ProcessingErrorData" Strukturen kann dem "System" Element folgen. Am häufigsten ist dabei "EventData" zu beobachten.
Die textuelle Darstellung lässt sich durch einen dreistufigen Prozess in die binäre Form der Protokolldateien überführen:
- XML Sprachelemente werden in Token umgewandelt
- ein Substitutionsverfahren trennt Struktur und Inhalt
- für wiederholt auftretende XML Strukturen werden Vorlagen definiert
Diese Transformation hilft, Speicherplatz und Rechenzeit zu sparen. Details zu den drei Schritten werde ich in den nachfolgenden Beiträgen behandeln.
