Verteilte Systeme Projekt 2005/2006

Verteilte Systeme Projekt
2005/2006
Eine ARM 4.0-Instrumentierung für
Tomcat
Andy Pelzer und Waldemar Echler
Gesamt-Überblick
ARM 4.0 Standard
Tomcat 5.5
Unser Projekt
Demo
Ausblick
2
ARM 4.0
Überblick
Einführung
Features und deren Nutzen
Transaktionskonzept
Errorhandling
Implementierungen
Tang-ARM Paket
3
ARM 4.0
Einführung
Motivation
Funktionalität einer Anwendung ist nicht alles!
„Zeit ist Geld“ (speziell bei QoS)
Anwendungen werden zunehmend komplexer
Management von Anwendungen gewinnt an Bedeutung
Administratoren / Analysten benötigen Informationen über eine Anwendung
und Werkzeuge zur Analyse dieser Daten
Instrumentierung von Anwendungen (Aspektorientierte Programmierung)
zum Zweck der Steuerung / Überwachung von Anwendungen (dynamisch
oder manuell)
4
ARM 4.0
Einführung
Application Response Measurement Standard der Open Group
Mark Johnson, IBM
Bill Furnas, Hewlett-Packard
Marcus Thoss, tang-IT Consulting GmbH
Geschichte
1996 (Vers. 1.0): C-API zur Messung von Antwortzeiten und Status von
Transaktionen
1997 (Vers. 2.0): Korrelation von Transaktionen und zusätzliche Messungen
1998 (Vers. 3.0): Java-Interface
2004 (Vers. 4.0): Unterstützung von Threads, Einheitliche Schnittstelle für C/Java,
Callback-Mechanismus zur Fehler-Behandlung
5
ARM 4.0
Einführung
Was definiert ARM?
Schnittstelle zwischen Agent und
instrumentierter Anwendung (Library)
Unterstützung von verteilten Anwendungen
und mehreren Instanzen
Universelles Konzept zur Instrumentierung
jeglicher Art (mehr als Response
Measurement)
Was lässt ARM offen?
Aufgaben des Agents (Verwendung,
Persistenz und Darstellung der Messdaten)
Architektur des Agents
Welche Daten zusätzlich zur Zeitmessung
und zum Status gesammelt werden
6
ARM 4.0
Features und Nutzen
Zeitmessung und Status von selbst definierten Transaktionen
Assoziation beliebiger Kenngrößen / Daten der Anwendung mit
Transaktionen (Metrics, Properties)
Verbesserung des Antwortzeitverhaltens von Anwendungen durch Aufspüren von
Bottlenecks (Profiling)
Nachweis einer gewissen QoS (Abrechnung)
Steuerung der Anwendung (z.B. Bereitstellung von zusätzlichen Ressourcen bei
steigender Last)
Informationen über den Umfang einer Transaktion und dadurch bessere
Rückschlüsse über die Performanz (z.B. wie viele MB wurden gesichert?)
Informationen über zur Verfügung stehende Ressourcen, die die Dauer von
Transaktionen beeinflussen (z.B. Länge von Warteschlangen, CPU-Nutzung)
Detaillierte Fehlermeldungen der Anwendung und dadurch schnellere Reaktion
Zwei Arten der Messung
ARM-Agent misst die Zeit (ermöglicht „Heartbeats“ und entlastet den
Programmierer)
Anwendung misst die Zeit und übermittelt diese an den ARM-Agent (vereinfacht
Migration auf ARM-Standard und unterstützt Messungen von verteilten
Anwendungen, unabhängig von der ARM-Implementierung)
7
ARM 4.0
Transaktionskonzept
Quelle: Technical Standard
Application Response
Measurement (ARM)
Issue 4.0, Version 2 – Java
Binding, The Open Group
8
ARM 4.0
Transaktionskonzept
Quelle: Technical Standard
Application Response
Measurement (ARM)
Issue 4.0, Version 2 – Java
Binding, The Open Group
9
ARM 4.0
Errorhandling
Philosophie: Programmierer und Administratoren müssen über Fehler
bescheid wissen, das Programm muss es nicht!!!
ARM-Objekte werfen keine Exceptions
(Ausnahmen: java.lang.Error, java.lang.RuntimeException)
Es werden immer syntaktisch korrekte Objekte erzeugt
(können im Fehlerfall „Datenmüll“ beinhalten)
Gute ARM-Implementierung loggt Fehler zentral und löst sie wenn möglich auf
Wie KANN eine Instrumentierte Anwendung ARM-Fehler behandeln?
Rückgabewert von ARM-Methoden prüfen (nur teilweise möglich)
getErrorCode() / getErrorMessage() für ARM-Objekte aufrufen
Als zentraler ARM-Error-Handler registrieren(<Factory-Object>.setErrorCallback())
und ArmErrorCallback Interface implementieren (errorCodeSet())
10
ARM 4.0
Implementierungen
Referenzimplementierung der Open Group
Open Source
Lediglich Ausgabe auf stdout oder in ein Logfile
Enthält „null-SDK“ (leere Methoden)
Tang-ARM (Tang-IT Consulting GmbH)
Kommerzielle Lizenz
Übernimmt keine Steuerungsaufgaben
Grafisches Frontend „ARM-Manager“ (sehr hilfreich zur Sichtung der Daten)
Granularität im Nanosekunden-Bereich
Unterstützung unterschiedlicher Backends für Messdaten
Bietet C++ Interface zur Bereitstellung gemessener Daten
(Möglichkeit der Steuerung oder anderer Datenverarbeitung)
11
ARM 4.0
Tang-ARM Architektur
Quelle: www.arm.tang-it.com
12
Tomcat 5.5
Überblick
Einführung
Was ist der Apache Tomcat?
Entwickler / Hersteller
Architektur
Überblick
Digester
Connectoren
Listener
13
Tomcat 5.5
Einführung
Was ist der Apache Tomcat?
Servlet Container
Vollständiger HTTP Server (Webserver)
Aus Gründen der Performanz hauptsächlich für die Entwicklung eingesetzt
JSP Compiler (Jasper)
Referenzimplementierung der Java Servlet und Java Server Pages Technologien
Laufzeitübersetzung von JSP Seiten in Servlets
Unterstützt noch zwei weitere J2EE APIs: JNDI und JMX
14
Tomcat 5.5
Einführung
Entwickler / Hersteller
Gestartet von James Duncan Davidson als Implementierung der Java
Servlet / JSP Standards (bei Sun Microsystems)
Wurde 1999 von Sun an die Apache Software Foundation übergeben, ab
da Teilprojekt von Apache Jakarta (Version 3.0).
Seit 2005 eigenes Apache Projekt, nicht länger zu Jakarta zugehörig
(Version 5.5.x).
Entwickelt von Freiwilligen weltweit (u.a. auch weiterhin Sun Mitarbeiter)
Herausgegeben unter der Apache Software Lizenz als Open Source
15
Tomcat 5.5
Architektur
Überblick (1 / 3)
16
Tomcat 5.5
Architektur
Überblick (2 / 3)
Server
Repräsentiert den Tomcat selbst
Kontrolliert einen Steuerungsport, um den
Tomcat zu stoppen
Service
Gruppiert eine Engine mit ihren Connectoren
Engine
Repräsentiert die Catalina Servlet Engine
Ermittelt das Ziel (Host / Context) eines
Requests anhand des HTTP-Headers und leitet ihn entsprechend weiter
Oberste Ebene der Requestverarbeitung
Host
Repräsentiert eine Gruppe von Webanwendungen
Umsetzung des „virtueller Host“ Konzepts des Apache HTTP Servers (mehrere
virtuelle Server auf einem System, unterschieden über ihre Adressen)
Ermittelt das Ziel (Context) eines Requests und leitet ihn entsprechend weiter
Context
Repräsentiert / Kapselt eine einzelne Webanwendung
17
Tomcat 5.5
Architektur
Überblick (3 / 3)
Multithreaded ab den Connectoren
Schachtelung der Container folgt dem „Chain of Responsibility“ Pattern,
d.h. ein Request wird weitergereicht, bis er an dem, für seine endgültige
Verarbeitung zuständigen, Container angelangt ist.
Sehr flexible Konfiguration durch Digester-Konzept
18
Tomcat 5.5
Architektur
Digester (engl. für Kocher, Kochtopf)
Zusammenstellung der Komponenten des Tomcat durch XMLKonfigurationsdateien
Werden beim Start des Tomcat vom sog. Digester geparst
Enthalten Satz von Regeln zum Zusammenbau des Tomcat
Digester erzeugt entsprechend der Regeln neue Objekte (z.B. Container)
Oder ruft Methoden existierender auf (z.B. Registrierung von Listenern)
Dadurch hohe Anpassungsfähigkeit an Anwendungssituation
Und Flexibilität bei der Konfiguration von Listenern, Valves etc.
19
Tomcat 5.5
Architektur
Connectoren (engl. für Anschluss, Verbinder)
Verbindung der Servlet Engine mit der „Außenwelt“
Umsetzung der protokollspezifischen Requests in ein Paar von
ServletRequest- und ServletResponse Objekten (Kapselung der
Netzwerkprogrammierung)
Verwaltung des Thread Pools
Verteilung der Client-Anfragen auf die Threads
Standardmäßig gibt es drei Connectoren:
AJP: Apache JServ Protocol
Coyote für das HyperText Transfer Protocol (HTTP 1.1)
SSL: Secure Socket Layer
Weitere Connectoren (z.B. für eigene Protokolle) möglich
20
Tomcat 5.5
Architektur
Listener (engl. für Empfänger, Zuhörer)
Java Klassen, implementieren bestimmte Interfaces
Konfiguration über XML-Dateien
Prinzip des Observer-Patterns:
Werden beim Start des Tomcats registriert (durch den Digester)
Benachrichtigung, sobald das überwachte Ereignis eintritt
Wichtigste Typen von Listenern:
Lifecycle Listener (Server, Engine, Host, Context)
Instance Listener (Ereignisse einer Servlet-Instanz)
Servlet Request Listener (Ereignisse eines Requests)
Servlet Context Listener (Ereignisse eines Contexts)
Und noch einige mehr…
21
Unser Projekt
Überblick
Aufgaben / Anforderungen
Konfiguration
Instrumentierungspunkte
Konzept
Correlatoren
Verbindung zum Apache
22
Unser Projekt
Aufgaben/Anforderungen
Einarbeitung in ARM
Einarbeitung in Tomcat
Konzept zur ARM-Instrumentierung von Tomcat mit tang-ARM 4.0
Implementierung
Beispielszenario zur Demonstration
Versionsübergreifende Instrumentierung
Flexibel konfigurierbar zur Laufzeit des Servlet Containers
Threadsicherheit
23
Unser Projekt
Konfiguration
Konfiguration der Instrumentierung
Erfolgt, wie auch die Tomcat-Konfiguration, über eine XML-Datei namens
„instrumentation.xml“
Wird bei jedem Request auf Änderungen geprüft und ggf. neu geladen
Konfigurationsänderungen so ohne Neustart des Tomcat möglich
Implementierung der Konfiguration
Parsen der XML-Datei durch Java XML Processing API (ereignisgetriebene
Variante; kein Modell der XML-Datei im Speicher)
Kapselung der Konfiguration in einer Klasse (enthält Parser, Update-Methode und
Abfrage-Methoden für Listener)
Update-Methode prüft Timestamp der Datei und parst nur bei Änderungen erneut
(Performanz); Aufruf pro Request durch den ServletRequestListener
Listener nutzen Abfrage-Methoden um zu prüfen, ob gemessen/geloggt werden soll
24
Unser Projekt
Konfiguration
Konfigurationsmöglichkeiten:
Instrumentierung ein/ausschalten
Filtern:
Nach Servlet
Nach Context (Webapplikation)
Nach Context UND Servlet filtern
Nicht filtern
Debug-Ausgaben ein/ausschalten
25
Unser Projekt
Instrumentierungspunkte
Warum haben wir Listener verwendet?
Wesentlich robuster gegenüber Veränderungen (neue Tomcat Versionen), als
direkte Instrumentierung des Tomcat-Codes
Daher relativ zukunftssicher (solange Listener API des Tomcat stabil)
Einfach hinzukonfigurierbar, Tomcat muss für die Instrumentierung nicht neu
übersetzt werden, ein einzelner Neustart reicht aus
Durch Vorgabe der Hinzukonfigurierbarkeit auf Listener
beschränkt
Mögliche Instrumentierungspunkte:
Request erreicht / verlässt Webapplikation
Beginn / Ende der service() Methode eines Servlets
Beginn / Ende einer HTTP-Session
Lebenszyklus eines Containers (Server, Engine, Host, Context)
26
Unser Projekt
Instrumentierungspunkte
Gewählte Instrumentierungspunkte
Generische Instrumentierung der eingebetteten
Anwendungen im Vordergrund
Request erreicht / verlässt Webapplikation
Ermöglicht die Messung der Dauer der gesamten Verarbeitung innerhalb
dieser Webapplikation
Beginn / Ende der service() Methode eines Servlets
Erlaubt es die Ausführungsdauer jedes einzelnen Servlets der Webapplikation
zu messen
27
Unser Projekt
Konzept
Request
Context
Instrumentation.xml
Servlet X
Config
Logfile
(stdout/stderr)
WebApp
Lifecycle
Listener
Global
Servlet
Request
Listener
Global
Instance
Listener
Servlet Y
Servlet Y
Servlet Z
bedingte Aufrufe/Zugriffe
constante Aufrufe
Normaler Fluss eines
Requests im Thread
28
Events
Unser Projekt
Correlatoren
Weitergabe der Correlatoren
Hierarchische Verknüpfung der beiden Transaktionen durch
Korrelatoren
Effiziente und thread-sichere Weitergabe der Correlatoren dem
natürlichen Informationsfluss folgend (als Attribut im ServletRequest)
Ergänzung des ServletRequest-Objektes um folgende Objekte:
Stack mit Korrelatoren (Notwendig für Beziehungen der Transaktionen)
Stack mit Transaktionen (Notwendig zum Stoppen der Transaktionen)
ARMTransactionFactory (Zum Anlegen der Transaktionsobjekte benötigt)
ARMApplication (Zum Anlegen der Transaktionsobjekte benötigt)
29
Unser Projekt
Correlatoren
30
Unser Projekt
Verbindung zum Apache
Weitergabe von Servlet-Requests von Apache (Webserver) an Tomcat
(Servlet Container) z.B. über mod_jk (AJP) weit verbreitet
Instrumentierung des ganzen interessant und sinnvoll
Apache wurde bereits instrumentiert (Verteilte Systeme Projekt von
Fr. Küppers)
Vorhandene Apache-Instrumentierung übergibt den Correlator bereits im
Request (über mod_arm4, kodiert)
Unsere Aufgabe: Auspacken und Dekodieren des kodierten Correlators
um Apache- und Tomcat-Transaktionen zu verknüpfen
31
Demo
JMeter
Windows
HTTP
Apache
Tomcat
AJP
Connector
Tomcat
Linux
AJP
mod_jk
mod_arm4
instrumentation
tangitArmManager
armtcpd
TCP
armtcpd
Request-Fluss
sqliteDB
Response-Fluss
ARM Aufrufe
ARM-interne Aufrufe
32
Ausblick
Einsatz unserer Instrumentierung
Apache ist bereits instrumentiert (Verteilte Systeme Projekt von
Fr. Küppers)
Aktuelle Diplomarbeit: Instrumentierung des JBoss
J2EE-Applikationsserver
JBoss nutzt Tomcat als Servlet Container und Apache als Webserver
Verbindung der Diplomarbeit mit unserer Arbeit nahe liegend (und
Grundlage für unser Projekt?)
Verknüpfung im Anschluss an dieses Semester geplant
Veröffentlichung der Gesamtarbeit als Open Source
Promotion für tangIT-ARM
33
Quellen
Technical Standard Application Response Measurement (ARM)
Issue 4.0, Version 2 – Java Binding, The Open Group
http://www.opengroup.org/management/arm/
Chopra, Bakore, Eaves, Galbraith, Li, Wiggers – „Professional Apache
Tomcat 5“, Wiley Publishing, 2004
Moczar – „Tomcat 5 Unleashed“, Sams Publishing, 2005
http://de.wikipedia.org/wiki/Apache_Tomcat
Homepage des Apache Tomcat: http://tomcat.apache.org/
Homepage von tang-IT ARM:
http://arm.tang-it.com/
34
Vielen Dank!
Fragen?
35