Vortragsfolien - Software Engineering Konferenzen

Instrumentierung zum Monitoring mittels
Aspekt-orientierter Programmierung
– Erfahrungsbericht –
Thilo Focke2 , Wilhelm Hasselbring3 ,
Matthias Rohr3 und Johannes-Gerhard Schute2
2
3
EWE TEL GmbH, Cloppenburger Str. 310, 26133 Oldenburg
Graduiertenkolleg TrustSoft, Abteilung Software Engineering, Universität Oldenburg
http://se.informatik.uni-oldenburg.de, http://www.trustsoft.org
29. März 2007, Hamburg
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
1 / 27
Motivation
Typische Herausforderungen beim Monitoring in Unternehmen wie der
EWE TEL:
Große Anzahl der zu überwachenden Systeme (mehrere Hundert)
Ausfälle/Störungen der Applikationen sind geschäftskritisch
Zusammenhang zwischen Verfügbarkeit und Performanz
Aktivierte Defekte äußern sich oft durch Performanz-Anomalien
„Hardcodiertes“ Monitoring ist schwer wartbar:
Vermischung von Kernfunktionalität und Monitoring-Mechanismen
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
2 / 27
Gliederung
1
Monitoring von Laufzeitverhalten
2
Aspekt-orientierte Programmierung
3
Anwendungsszenario
4
Laufzeit- und Kompilierzeit-Weben
5
Zusammenfassung und Ausblick
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
3 / 27
Monitoring von Laufzeitverhalten
Monitoring von Laufzeitverhalten
Monitoring [IEEE Standards Board 2002]
Erfassen und Aufzeichnen (teilweise auch Analysieren und Überwachen) des
Laufzeitverhaltens von Komponenten, wie beispielsweise
Softwarekomponenten, Diensten oder Betriebssystemprozessen.
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
4 / 27
Monitoring von Laufzeitverhalten
Monitoring von Laufzeitverhalten
Monitoring [IEEE Standards Board 2002]
Erfassen und Aufzeichnen (teilweise auch Analysieren und Überwachen) des
Laufzeitverhaltens von Komponenten, wie beispielsweise
Softwarekomponenten, Diensten oder Betriebssystemprozessen.
Monitoring auf verschiedenen Systemebenen
Applikation
J2EE/Middleware
Monitoring
Java Virtual Machine
Betriebssystem
Hardware
W. Hasselbring (SE Universität Oldenburg)
Durchsatz, Antwortzeit,...
Sessions, Threads, Pools,...
Heap Verbrauch,...
Verfügbarkeit,...
CPU Auslastung,...
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
4 / 27
Monitoring von Laufzeitverhalten
Monitoring von Laufzeitverhalten – Herausforderungen
Identifizieren von relevanten Positionen für Messpunkte
Wo soll was gemessen werden?
Ein Vorgehensmodell für das Performance-Monitoring von
Informationssystemlandschaften ist erforderlich [Focke u. a. 2007]
Instrumentierung der Anwendungen
Manuelle Code Instrumentierung Erweiterung von Applikationscode
Middleware Interception Nutzen von proprietären Schnittstellen
Aspekt-orientierte Programmierung Kapselung von Querschnittsbelangen
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
5 / 27
Monitoring von Laufzeitverhalten
Monitoring als Querschnittsbelang
XML Parsing in Tomcat
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
6 / 27
Monitoring von Laufzeitverhalten
Monitoring als Querschnittsbelang
XML Parsing in Tomcat
Logging in Tomcat
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
6 / 27
Aspekt-orientierte Programmierung
Aspekt-orientierte Programmierung
Aspect-Orientierte Programmierung (AOP) [Kiczales u. a. 1997]:
Trennt Querschnittsbelange von den Kernfunktionen.
Querschnittsbelange werden „Aspekte” genannt und separat von
anderen Teilen des Systems entwickelt.
Ein verbreitetes Werkzeug für AOP in Java stellt AspectJ dar.
AspectJ ist eine Erweiterung zu Java: Java + Aspekte.
AspectJ-Unterstützung existiert für viele IDEs, wie z.B. Eclipse, JBuilder,
Forté (http://www.eclipse.org/aspectj/).
Seit Java Version 5 können Annotationen genutzt werden.
AOP wird auch in Enterprise Frameworks wie Spring und
Enterprise Java Beans (Version 3) unterstützt.
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
7 / 27
Anwendungsszenario
Outline
1
Monitoring von Laufzeitverhalten
2
Aspekt-orientierte Programmierung
3
Anwendungsszenario
4
Laufzeit- und Kompilierzeit-Weben
5
Zusammenfassung und Ausblick
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
8 / 27
Anwendungsszenario
Anwendungsszenario und Anforderungen
Anwendungsszenario
Enterprise Java-basiertes Kundenportal des im norddeutschen Raum
tätigen Telekommunikationsunternehmens EWE TEL
Sprach-, Internet- und Datendiensten werden über dieses Portal durch
die Kunden selbst angepasst
Anforderungen an die Performance-Messung
Der Performance Monitor soll auf verschiedenen Middleware-Systemen
einsetzbar sein (Tomcat, WebLogic, Sun AS, Geronimo)
Die jeweilige Middleware soll im Zuge des Performance Monitoring nicht
modifiziert werden
Die zu überwachenden Applikationen sollen ausschließlich zum Setzen
der Messpunkte modifiziert werden
Der durch die Performance-Messungen entstehende Overhead soll
möglichst gering gehalten werden
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
9 / 27
Anwendungsszenario
Einsatzziele und Architektur
Einsatzziele
Messung der Auslastungsdaten zur langfristigen Ressourcenplanung
Verbesserung der Systemüberwachung (Fehlerdiagnose etc.)
Einfaches Einbringen oder Anpassen von Messpunkten
Ein einheitliches und effizientes Monitoring auf ganzer Systemlandschaft
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
10 / 27
Anwendungsszenario
Einsatzziele und Architektur
Einsatzziele
Messung der Auslastungsdaten zur langfristigen Ressourcenplanung
Verbesserung der Systemüberwachung (Fehlerdiagnose etc.)
Einfaches Einbringen oder Anpassen von Messpunkten
Ein einheitliches und effizientes Monitoring auf ganzer Systemlandschaft
Architektur
Die Monitoring-Infrastruktur besteht im Wesentlichen aus einem
Performance-Monitor und einem Monitoring-Manager
Der Performance-Monitor soll an definierten Messpunkten von
Applikationen Performance-Daten sammeln
Der Monitoring-Manager soll die Performance-Daten mehrerer
Performance-Monitore abrufen, persistent speichern und
Drittanwendungen plattformunabhängig bereitstellen
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
10 / 27
Anwendungsszenario
Architektur des Performance-Monitors
Applikationsserver
Messung der Antwortzeiten von
Operationen
Applikation A
Applikation B
Klasse G
Klasse A
Klasse B
Klasse D
Klasse F
Klasse C
Klasse H
Klasse E
Klasse A
Klasse F
Klasse B
Klasse E
Klasse C
Klasse D
Klasse G
Klasse H
Speicherung in MBeans
Performance Monitor
MBean Server
HTTP Adapter
RMI Adapter
SNMP Adapter
JMX
MC4J
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
JConsole
MyApplication
29. März 2007, Hamburg
11 / 27
Anwendungsszenario
Sammlung der Monitoring-Daten
Applikationsserver A
Applikation A
Applikationsserver B
Applikation C
Applikation B
Klasse G
Klasse A
Klasse B
Klasse D
Klasse F
Applikation D
Klasse G
Klasse C
Klasse H
Klasse E
Klasse A
Klasse F
Klasse B
Klasse E
Klasse C
Klasse D
Klasse A
Klasse G
Klasse B
Klasse C
Klasse F
Klasse D
Klasse H
Klasse F
Klasse E
Klasse H
Klasse A
Performance Monitor
Performance Monitor
MBean Server
MBean Server
HTTP Adapter
RMI Adapter
MC4J
JConsole
W. Hasselbring (SE Universität Oldenburg)
SNMP Adapter
HTTP Adapter
Monitoring Manager
Instrumentierung zum Monitoring mittels AOP
Klasse G
Klasse H
Klasse C
Klasse D
Klasse E
Klasse B
RMI Adapter
SNMP Adapter
JConsole
MC4J
29. März 2007, Hamburg
12 / 27
Anwendungsszenario
Java 5 Annotationen zur Markierungen von
Messpunkten
pointcut probeMethod():
execution(@MonitoringProbe * *.*(..))
:Aufrufende Klasse
:Annotierte Klasse
Jointpoint
Match
1: doSomething(): void
@MonitoringProbe(context=“MyApp“)
public void doSomething() {
…
}
around() : probeMethod() {
// Zeitmessung starten
proceed(); // Eigentliche Methode ausführen
// Zeitmessung stoppen
// Performance-Daten berechnen
// MBean registrieren/aktualisieren
Einweben
2: return
// Mit Programmablauf fortfahren
}
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
13 / 27
Anwendungsszenario
Einweben der Aspekte
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
14 / 27
Laufzeit- und Kompilierzeit-Weben
Web-Verfahren
Kompilierzeitweben (Compile-time weaving, CTW)
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
15 / 27
Laufzeit- und Kompilierzeit-Weben
Web-Verfahren
Kompilierzeitweben (Compile-time weaving, CTW)
Laufzeitweben (Load-time weaving, LTW) (vor erster Benutzung in JVM)
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
15 / 27
Laufzeit- und Kompilierzeit-Weben
Speicherüberlauf bei LTW (1/2)
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
16 / 27
Laufzeit- und Kompilierzeit-Weben
Speicherüberlauf bei LTW (2/2)
Ursache des LTW-Speicherüberlaufes:
Java Virtual Machine registriert für jeden RMI-Aufruf einen Classloader.
Dieser muss Klassen nachladen, die für den verteilten Aufruf auf der
Client- und Server-Seite nötig sind.
Normalerweise ist das ein leichtgewichtiger Prozess, der die Java Virtual
Machine nicht weiter belastet.
Im Anwendungskontext wurde bei jedem RMI-Aufruf ein neuer Load-time
weaving-Vorgang durch AspectJ gestartet.
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
17 / 27
Laufzeit- und Kompilierzeit-Weben
Speicherüberlauf bei LTW (2/2)
Ursache des LTW-Speicherüberlaufes:
Java Virtual Machine registriert für jeden RMI-Aufruf einen Classloader.
Dieser muss Klassen nachladen, die für den verteilten Aufruf auf der
Client- und Server-Seite nötig sind.
Normalerweise ist das ein leichtgewichtiger Prozess, der die Java Virtual
Machine nicht weiter belastet.
Im Anwendungskontext wurde bei jedem RMI-Aufruf ein neuer Load-time
weaving-Vorgang durch AspectJ gestartet.
Dies Problem konnte zusammen mit Mitgliedern des
AspectJ-Entwicklerteams in Verbindung mit RMI-Kommunikation und
LTW in AspektJ 1.5.0 identifiziert werden.
Das Verhalten war den AspectJ-Entwicklern bekannt,
allerdings war das Ausmaß der Konsequenzen bisher nicht bewusst.
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
17 / 27
Laufzeit- und Kompilierzeit-Weben
Speicherverlauf bei CTW
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
18 / 27
Laufzeit- und Kompilierzeit-Weben
Compile-Time Weaving
Vorbereitungsaufwand:
Erweiterung der Applikationsbuild-Skripte aller zu überwachenden
Teil-Applikationen um Aufruf des AspectJ Compilers
Dadurch gewisse AspectJ-Kenntnisse von den Anwendungsentwicklern
benötigt
Rekompilierung und ein Redeployment aller Applikationen bei
Änderungen der Aspekte erforderlich
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
19 / 27
Laufzeit- und Kompilierzeit-Weben
Rollen im Entwicklungsprozess
Rollen
Monitoring-Ingenieur
Anwendungsentwickler
Entwickler-Feedback (Von den Anwendungsentwicklern)
Integrieren von den Messpunkten über (Java 5) Annotationen gestaltete
sich als sehr einfach
Softwareentwickler können ohne vorherigen Lernaufwand Messpunkte
einsetzen und entfernen, da keine Kenntnisse in Aspekt-orientierter
Programmierung erforderlich sind
Positives Akzeptanzkriterium
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
20 / 27
Zusammenfassung und Ausblick
Zusammenfassung
AOP und die verwendete Technologie konnten sich im Praxiseinsatz für
die Instrumentierung mit Performance-Monitoring grundsätzlich
bewähren.
Wartbarkeit:
Markierung durch Java-Annotationen von beteiligten Entwicklern als sehr
einfach empfunden
Keine Kenntnisse über Aspekt-orientierte Programmierung hierfür benötigt
Entwicklungsaufgaben für AOP:
LTW: Anpassung der Middleware (Einbinden des AspectJ Classloaders)
CTW: Einbinden des AspectJ-Compilers in die Applikations-Build-Skripte
Leider war das Load-time weaving in der vorliegenden Version von
AspectJ noch nicht technisch ausgereift und es musste auf Compile-time
weaving ausgewichen werden.
Diese Lösung wird seit Mai 2006 im operativen Betrieb der EWE TEL
eingesetzt.
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
21 / 27
Zusammenfassung und Ausblick
Ausblick: Software-Betriebs-Leitstand
[Giesecke u. a. 2006]
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
22 / 27
Zusammenfassung und Ausblick
Ausblick: Software Leitstand mit Verknüpfung von
Architektur und Performance-Daten
Visualization of
CPU/Memory usage
M
M
:A
:B
:D
:C
:A
:B
:D
:C
M
M
M
M
M
M
M <<Component>>
:A
Software with
Monitoring
<<Component>>
<<Component>>
:A
:B
<<Component>>
<<Component>>
:D
:C
M <<Component>>
:B
Views
M
...
M
<<Component>>
:D
M <<Component>>
:C
Combined Model:
Architecture
+ Monitoring Data
Visualization for
fault localization
Architectural
Model
Insbesondere auch zur Erkennung von Performance-Anomalien
[Rohr u. a. 2007].
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
23 / 27
Zusammenfassung und Ausblick
Ausblick: AOP für weitere Aspekte ?
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
24 / 27
Zusammenfassung und Ausblick
Literatur
[Focke u. a. 2007] F OCKE, Thilo ; H ASSELBRING, Wilhelm ; R OHR, Matthias ; S CHUTE,
Johannes-Gerhard: Ein Vorgehensmodell für Performance-Monitoring von
Informationssystemlandschaften. In: EMISA Forum 27 (2007), Januar, Nr. 1
[Giesecke u. a. 2006] G IESECKE, Simon ; R OHR, Matthias ; H ASSELBRING, Wilhelm:
Software-Betriebs-Leitstände für Unternehmensanwendungslandschaften. In:
Tagungsband Informatik 2006 Bd. P-94, Gesellschaft für Informatik, Oktober 2006,
S. 110–117
[IEEE Standards Board 2002] IEEE S TANDARDS B OARD. IEEE Standard Glossary of
Software Engineering Terminology—IEEE Std 610.12-1990. 2002
[Kiczales u. a. 1997] K ICZALES, Gregor ; L AMPING, John ; M ENHDHEKAR, Anurag ;
M AEDA, Chris ; L OPES, Cristina ; L OINGTIER, Jean-Marc ; I RWIN, John:
Aspect-Oriented Programming. In: Tagungsband ECOOP’97. Springer-Verlag,
1997, S. 220–242
[Rohr u. a. 2007] R OHR, Matthias ; G IESECKE, Simon ; H ASSELBRING, Wilhelm:
Timing Behavior Anomaly Detection in Enterprise Information Systems. In:
C ARDOSO, Jorge (Hrsg.) ; C ORDEIRO, José (Hrsg.) ; F ILIPE, Joaquim (Hrsg.):
Proceedings of Ninth International Conference on Enterprise Information Systems
(ICEIS’07), INSTICC Press, Juni 2007
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
25 / 27
Zusammenfassung und Ausblick
Vorgehensmodell für das Performance Monitoring
[Focke u. a. 2007]
W. Hasselbring (SE Universität Oldenburg)
Instrumentierung zum Monitoring mittels AOP
29. März 2007, Hamburg
26 / 27
Zusammenfassung und Ausblick
Anstieg des Verbrauchs von Startup-Resourcen (bei
LTW)
Startup-Zeiten sowohl des Apache Tomcat 5.5 und Bea Weblogic 9.1 um
etwa 30-40 % länger
Speicherverbrauch während des Startup-Prozesses stieg ebenfalls um
30-40 %
Startup-Zeiten WebLogic 9.1
25
12
22,5
11
Startup-Zeit in Sekunden
Startup-Zeit in Sekunden
Startup-Zeiten Tomcat 5.5
13
10
9
8
7
6
5
4
3
2
20
17,5
15
12,5
10
7,5
5
2,5
1
0
0
Ohne LTW
W. Hasselbring (SE Universität Oldenburg)
Mit LTW
Ohne LTW
Instrumentierung zum Monitoring mittels AOP
Mit LTW
29. März 2007, Hamburg
27 / 27