In einer Anwendung ist es von zentraler Bedeutung zu wissen, wenn etwas schief geht. Tracing heißt das Mittel der Wahl, um an diese Informationen zu gelangen. Mit dem .NET Framework 4.5 wurde das Event Tracing für Windows erheblich vereinfacht.
Die Gründe, Tracing in der eigenen Anwendung zu ermöglichen beziehungsweise einzubauen, sind vielfältig. Zu dem Hauptgrund gehört sicherlich die nachträgliche Analyse von Fehlersituationen, die in einer Anwendung auftreten können. Allerdings ist es nicht immer möglich, diese Anwendungen im Debug-Modus laufen zu lassen, um so an die benötigten Informationen zu gelangen.
Diese sind aber wichtig, um den Fehler reproduzieren und letztendlich ausmerzen zu können. Zudem ändern sich die Anforderungen an das Tracing im Laufe der Zeit. Anwendungen werden immer häufiger auf Server beziehungsweise in die Cloud verlagert.
Mit dem .NET Framework in Version 4.5 baut Microsoft die Unterstützung des Event Tracings für verwaltete Anwendungen aus.
Event Tracing für Windows
Aber was ist dieses ominöse Event Tracing überhaupt? In der englischen Literatur wird es gerne einfach als Event Tracing for Windows - oder kurz ETW - bezeichnet.
Dahinter verbirgt sich ein hoch performantes Tracing-System, das direkt in Windows integriert ist. Im Kern handelt es sich um ein aus vier Teilen zusammengesetztes System, wozu ETW selbst, Provider, Controller und Verbraucher gehören. Durch die Tatsache, dass es sich um ein komplett auswechselbares Systems handelt, können alle vier Teile ausgetauscht werden. Also auch das ETW an sich.
Implementiert ist ETW direkt im Windows Kernel und erlaubt daher, Tracing-Mechanismen sowohl für Anwendungen im User-Mode als auch im Kernel-Mode zu registrieren. Zusätzlich kann die Protokollierung zur Laufzeit aktiviert sowie deaktiviert werden. Neustarts oder gar neue Programmversionen sind nicht notwendig.
Eingeführt wurde ETW zuerst mit Windows 2000 und hat sich seither in vielen Bereichen des Betriebssystems und anderen Anwendungen etabliert. Microsoft bezeichnet es als eine der Schlüsselkonzepte zur Überwachung von Anwendungen auf der Windows-Plattform. Änderungen in .NET 4.5
Die Hauptkomponenten, auf denen sich .NET 4.5 konzentriert, sind die Provider, Controller und Verbraucher. Bisher war es recht mühsam, ETW in Anwendungen mit verwaltetem Code einzusetzen.
Die größten Änderungen konzentrieren sich auf die neue Klasse EventSource und ein Code-First System, dass es auf einfache Weise erlaubt, streng typisierte Traces anzulegen. Das war in der Vergangenheit deutlich komplexer, was die Einstiegshürde unnötig nach oben setze.
public class MinimalEventSource : EventSource { public static readonly MinimalEventSource Source = new MinimalEventSource();
Obiger Code zeigt ein minimales Beispiel für eine eigene EventSource-Klasse. Wichtig ist, dass von der Klasse EventSource abgeleitet wird, die im Namensraum System.Diagnostics.Tracing vorhanden ist. Die statische Eigenschaft Source speichert eine Instanz der eigenen EventSource. Darüber können Events mittels Methodenaufrufe ausgelöst werden. Beispielsweise in der Art:
Innerhalb der selbst geschriebenen Methoden muss WriteEvent aufgerufen werden, um das Event letztendlich auszulösen. Die Zahl gibt die eindeutige ID an. Über das Event-Attribut können den Methoden noch weitere Informationen übergeben werden. Zum Beispiel Schlüsselwörter, ein definiertes Event-Level und ein eigener Meldungstext. Bevor ein Event über WriteEvent geschrieben wird, ist es ratsam, mittels der Eigenschaft IsEnabled zu prüfen, ob die darunterliegende EventSource überhaupt aktiviert ist. Ist das nicht der Fall, kann direkt aus der Methode gesprungen beziehungsweise der Code übersprungen werden.
Alles in Allem ist es das aber auch schon an ETW-Magie. Aus der EventSource wird automatisch das Manifest erzeugt. Die Methoden werden beispielsweise zu Event-Namen.
Wichtig ist noch, dass sich leider nicht alle Daten als Event-Parameter eignen. Erlaubt sind nur primitive Typen, Zeichenketten, GUIDs und Enums. Arrays und Strukturen sind außen vor. Tooling
Um die Events aufzeichnen und anzeigen zu können fehlt nur noch das passende Werkzeug. PerfView gehört dazu und kann kostenfrei heruntergeladen werden.
Über den Menüeintrag Collect | Collect sind die Einstellungen erreichbar, die für eine Event-Aufzeichnung notwendig sind. Abbildung 1 zeigt dazu einen Screenshot. Die erweiterten Optionen müssen erst über die Schaltfläche Advanced Options eingeblendet werden.
Essentiell ist es, die eigene EventSource im Feld Additional Providers einzutragen. In diesem Fall also *MinimalEventSource. Damit wird PerfView angewiesen, nach einer EventSource Ausschau zu halten, die aus dem angegebenen Namen generiert wurde. Das ist deutlich einfacher, da ansonsten eine EventSource über eine eindeutige GUID angesprochen wird.
Ein Klick auf Start Collection startet die Aufzeichnung. Währenddessen werden alle Events, die von der eigenen Anwendung ausgelöst werden protokolliert und gespeichert. Stop Collection beendet die Aufzeichnung entsprechend wieder und bereitet die Ergebnisse auf. Dieser Prozess kann einige Zeit in Anspruch nehmen. Anschließend stehen die Daten in der Datei PerfViewData.etl zur Verfügung, die über PerfView geöffnet werden kann.
Dort gibt es den Eintrag Events, der wiederum alle Ereignisse auflistet, die während der Aufzeichnung protokolliert wurden. Hier sind jetzt auch die Einträge zu finden, die von der eigenen Anwendung, beziehungsweise von den eigenen EventSource-Klassen, erzeugt wurden.
Fazit
Mit der Version 4.5 des .NET Frameworks wurden viele Vereinfachungen in Bezug auf das Event Tracing für Windows eingeführt. Insbesondere die hier vorgestellte EventSource-Klasse ist sehr simpel und schnell in eigene Anwendungen integriert. Dadurch stehen verschiedene und durchaus mächtige Möglichkeiten bereit, Statusinformationen laufender Anwendungen zu ermitteln. Auch für Programme in produktiven Umgebungen und nicht nur in Testszenarien.
Etwas mangelhaft sind die vorhandenen Tools. PerfView ist schön und gut, könnte aber durchaus durch eine neuere Version ersetzt werden, die benutzerfreundlicher ist. Trotzdem handelt es sich bei ETW um eine ernstzunehmende Technologie und Alternative zu bekannten Tracing-Techniken, die für die eigene Anwendung in Betracht gezogen werden sollte.
Der Autor: Fabian Deitelhoff lebt und arbeitet in Dortmund, der Metropole des Ruhrgebiets. Er studiert derzeit den Masterstudiengang Informatik mit dem Schwerpunkt Biomedizinische Informatik an der Hochschule Bonn-Rhein-Sieg in Sankt Augustin. Seine Schwerpunkte liegen in der Entwicklung von Visual Studio Erweiterungen, der Analyse und Beschreibung von Open Source Frameworks sowie im Rapid Prototyping. Beruflich ist er als freier Autor, Trainer, Sprecher und Softwareentwickler im .NET Umfeld tätig. Sie erreichen Ihn über seinen Blog www.fabiandeitelhoff.de, per E-Mail unter Fabian@FabianDeitelhoff.de oder auf Twitter als @FDeitelhoff.
