Forschung > Projekte > Trace Framework

Trace Framework (TFW)

Beteiligte an der Hochschule

  • Prof. Dr. Reinhold Kröger
  • Dipl.-Inform. (FH) Holger Machens

Kooperationspartner

  • Siemens AG, München

Laufzeit

Beginn: 15.03.2002
Ende: 30.10.2002

Finanzierung

  • 100% Siemens AG

Veröffentlichungen

  • Machens, Holger; Kröger, Reinhold: "Trace Framework - Tracing in heterogenen Umgebungen", Technischer Bericht, Fachbereich Informatik, Fachhochschule Wiesbaden, November 2002 (BibTeX)

Kurzbeschreibung

Inzwischen existieren mehrere Ansätze zum Tracing verteilter Anwendungen, denen jedoch unterschiedlichste Trace-Plattformen und unterschiedliche Tracing-Ziele (z.B. Verfolgung von Kommunikationsvorgängen, Performance-Monitoring) zugrunde liegen (z.B.: IIOP-Tracer, PI-Tracer, ObjectTrace (Object Software), UTE (IBM), ARM (Open Group), , etc). Eine allgemeine Lösung für das Verfolgen von Vorgängen in Anwendungen, die in heterogenen Umgebungen (Programmiersprachen, Middlewareplattformen, etc.) und auf verschiedenen Kommunikationsplattformen agieren, wie es in eBusiness-Anwendungen bzw. Internet-Anwendungen der Fall ist, steht weiterhin aus.
Ziel dieses Projekts war es, eine Trace Framework zu entwerfen, das Tracing verteilter Anwendungen in heterogenen Umgebungen für unterschiedliche Tracing-Ziele erlaubt. Hierzu war es notwendig, ein Trace-Modell zu entwerfen, das den Anforderungen der verschiedenen Umgebungen gerecht wird und das Zusammenführen von Trace-Ereignissen aus einer verteilten Anwendung, auch bei geschachtelten Kommunikationsvorgängen, über die Grenzen der jeweiligen Umgebung hinweg erlaubt. Basierend auf dem Trace-Modell wurde anschließend eine Trace-Plattform entwickelt, diesen Anforderungen genügt.
Das Trace-Modell ist untergliedert in ein Komponentenmodell und ein Ereignismodell. Das Komponentenmodell ist ein Metamodell zur Beschreibung von Anwendungskomponenten (Host, Prozess, Objekt, etc.) und hierarchischen Strukturen zwischen solchen Anwendungskomponenten (Prozess - Objekt, Parent-Prozess - Child-Prozess, etc.). Das Ereignismodell gründet auf einem eigens entworfenen Metamodell zur Beschreibung von Trace-Ereignissen. Trace-Ereignisse sind in diesem Zusammenhang alle Ereignismeldungen, die in einem Trace vorkommen können. Hierzu gehören beispielsweise Ereignisse zum Lebenszyklus, zu Interaktionen zwischen Anwendungskomponenten, etc. Eine Menge bereits definierter Standardereignisse, die auf dem Metamodell basieren, bildet die Minimalkonfiguration des Trace Frameworks.
Systemarchitektur
Bei der Entwicklung der Trace-Plattform wurde neben den oben bereits aufgeführten Anforderungen auf ein günstiges Performance-Profil und geringe Interferenz mit der Anwendung geachtet. Diese Anforderungen führten zu folgender Architektur:
  • Trace Service: Auf einem beliebigen Host in der verteilten Umgebung befindet sich in der einfachsten Betriebsform der Trace-Plattform ein Trace Service als zentrale Komponente. In ihm laufen alle Traces aus der überwachten Anwendung zusammen, und es werden Dienste und Informationen für alle Komponenten der Trace-Plattform bereitgehalten.
  • Trace Daemon: Auf jedem Host, auf dem sich eine Komponente der überwachten Anwendung befindet, läuft ein Trace Daemon, der als Vermittler zwischen Anwendung und Trace Service dient. Er kommuniziert mit der Anwendung über ein Shared Memory Segment und entkoppelt sie so von der aufwendigeren TCP/IP-Kommunikation mit dem Trace Service.
  • Trace-Generatoren: In der überwachten Anwendung befinden sich ein oder mehrere Trace-Generatoren, die als Instrumentierungsbibliothek hinzugebunden werden oder eigenständige Programme wie z.B. Log-Reader darstellen. Sie übernehmen die Kommunikation mit dem Trace Daemon.
Der Trace Service wurde als modulare, erweiterbare Komponente konzipiert. Ein Plug-in-Mechanismus erlaubt das Einfügen zusätzlicher Module zur Entgegennahme (Frontend) oder Weiterverarbeitung (Backend) der Trace-Ereignisse. Neben der generischen Variante des Frontends können so eigene Module in den Trace Service integriert werden, die z.B. proprietäre Protokolle unterstützen oder spezielle Korrelations- oder Puffereigenschaften realisieren. Die Frontends geben empfangene Ereignismeldungen an einen Merger weiter. In ihm treffen die Ereignismeldungen zusammen und können durch integrierte Dienste wie Korrelation oder logische Sortierung bezüglich Inhalt oder Reihenfolge nachbearbeitet werden. Für solche Dienste stellt der Merger einen Interceptoren-Mechanismus zur Verfügung. Einmal registriert, bekommen die Interceptoren alle eingehenden und abgehenden Ereignismeldungen zur Nachbearbeitung zugestellt. Nach dem Zusammenführen werden die Ereignisse an die Backends verteilt, die sie an spezielle Auswertungs- oder Analyse-Tools weiterreichen.
Zur Evaluierung des entworfenen Trace Frameworks wurde ein Prototyp implementiert. Auf Anwendungsseite kamen ein Apache-HTTP-Server, ein C++-basiertes CGI-Programm, und eine C++-basierte, verteilte CORBA-Anwendung zum Einsatz. Als Analyse-Tool wurde Siemens TMT gewählt. Zur Instrumentierung wurde eine C-Bibliothek entwickelt, die zu Apache und CGI-Programm hinzugebunden wurde. Die CORBA-Kommunikation wurde durch eine erweiterte Version des PI-Tracers mit einem speziellen Backend aufgenommen. Für Instrumentierungsbibliothek und PI-Tracer-Backend wurden die entsprechenden Frontends realisiert. Analog wurde für TMT ein Backend im Trace Service integriert, das die eintreffenden Ereignisse in einen TMT-Log konvertiert. Von der Trace-Plattform wurden Merger, Modulverwaltung und Trace Daemon implementiert.
Der Prototyp belegt die angestrebte Flexibilität des Designs zum Trace Framework. Sowohl die Generierung der Trace-Ereignisse in den verschiedenen Umgebungen wie HTTP-Server, CGI-Programm und CORBA-Anwendung lässt sich ebenso einfach realisieren wie die Konvertierung ins TMT-Format. Auch die Definition neuer Ereignistypen wurde testweise durchgeführt, was weder bei der Übertragung noch bei der Weiterverarbeitung ein Problem für die Komponenten der Trace-Plattform darstellte.