Erhebung und Analyse von Kennzahlen aus dem fachlichen Performance-Monitoring

Transkript

1 Erhebung und Analyse von Kennzahlen aus dem fachlichen Performance-Monitoring Diplomarbeit im Fach Informatik vorgelegt von Stefan Eberlein geb. in angefertigt am Department Informatik Lehrstuhl für Informatik 2 Programmiersysteme Friedrich-Alexander-Universität ErlangenNürnberg (Prof. Dr. M. Philippsen) Betreuer: Norbert Tausch, Norbert Oster, Michael Philippsen und Matthias Buchholz (Capgemini) Beginn der Arbeit: Abgabe der Arbeit:

2

3 Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäÿ übernommen wurden, sind als solche gekennzeichnet. Der Universität Erlangen-Nürnberg, vertreten durch die Informatik 2 (Programmiersysteme), wird für Zwecke der Forschung und Lehre ein einfaches, kostenloses, zeitlich und örtlich unbeschränktes Nutzungsrecht an den Arbeitsergebnissen der Diplomarbeit einschlieÿlich etwaiger Schutzrechte und Urheberrechte eingeräumt. Erlangen, den Stefan Eberlein

4

5 Diplomarbeit Thema: Erhebung und Analyse von Kennzahlen aus dem fachlichen Performance- Monitoring Aufgabenstellung: Die Sicherstellung von nichtfunktionalen Anforderungen (NFA) bezüglich der Performance stellt einen wichtigen Bestandteil innerhalb der Qualitätssicherung von Software dar. Um diese Anforderungen zu erfüllen, sollten bereits früh im Sotwareentwicklungsprozess Performancedaten ermittelt und ausgewertet werden. Neben dem feingranularen technischen Monitoring fokussiert das fachliche Monitoring auf die Performancedaten, sodass diese mit den Use-Cases in Bezug gesetzt werden können. Gestützt auf wohldenierte Messpunkte im Client- und Server-Code lassen sich hiermit ohne ein aufwändiges Proling-Framework sinnvolle Aussagen über die Laufzeit von fachlichen und querschnittlichen Teilaspekten der Anwendung ableiten. Aus diesen Gründen bietet das fachliche Monitoring eine gute Kontrollmöglichkeit zur Einhaltung der geforderten NFAs. Die Arbeit gliedert sich in einen analytischen und einen praktischen Teil. Im analytischen Teil soll der industrielle und wissenschaftliche Status Quo aufgezeigt werden. Anhand der aktuellen Landschaft aus Werkzeugen, Schnittstellen und der Publikationslage soll gezeigt werden, welche Messgröÿen für relevant und sinnvoll erachtet werden und wie die nötigen Messdaten technisch erhoben werden. Weitere Teilaspekte des Monitorings, wie die Speicherung der gewonnenen Daten und deren Auswertung, sollen kritisch analysiert werden. Im Projektbezug sollen die Fähigkeiten und Grenzen des bereits existierenden Monitoringwerkzeugs erfasst werden. Im praktischen Teil werden die konsolidierten Ergebnisse aus Forschung und Projekterfahrung in ein geeignetes Monitoringwerkzeug integriert oder innerhalb einer eigenen Softwarekomponente realisiert. Dazu wird ein beispielhaftes JEE Projekt aufgesetzt, bei welchem die Monitoringfunktionalität ergänzt wird. Techniken zur Erhebung der Daten, deren Speicherung und eine anschlieÿende Analyse werden hierdurch in der Praxis erprobt. Die Einwirkung des Monitorings auf die Laufzeit des Beispiel Frameworks soll ebenfalls quantiziert werden. In Kooperation mit: Capgemini (Nürnberg) Meilensteine: Erarbeiten von Einleitung, Theorie und Motivation Sichtung von Literatur Ermittlung theoretischer Grundlagen

6 Abgrenzung des Themengebiets Hospitieren in Projekten Besuchen von Projekten und Durchführung der Interviews Evaluierung der Standards Ermittlung der Standards Ausarbeitung der Bewertungskriterien für die Marktanalyse Durchführung der Marktanalyse Prototypische Umsetzung Planung des Beispielprojekts Anforderungsanalyse für das Beispielprojekt Implementierung der Software Verfeinerung der Arbeit Norbert Tausch, Norbert Oster, Michael Philippsen und Matthias Buch- Betreuung: holz Bearbeiter: Stefan Eberlein

7 Abstract Die Sicherstellung von Performance als nichtfunktionale Anforderung stellt einen wichtigen Bestandteil innerhalb der Qualitätssicherung von Software dar. Es sollten daher bereits früh im Softwareentwicklungsprozess Performancedaten ermittelt und ausgewertet werden. Neben dem feingranularen technischen Monitoring fokussiert das fachliche Monitoring auf die Ermittlung von Performancedaten, sodass diese mit Anwendungsfällen in Bezug gesetzt werden können. Gestützt auf wohldenierte Messpunkte im Anwendungscode lassen sich hiermit ohne ein aufwändiges Prolingwerkzeug Aussagen über die Laufzeit von fachlichen und technischen Komponenten der Anwendung ermitteln. Aus diesen Gründen dient das fachliche Monitoring dem ezienten Überprüfen und Nachvollziehen von nichtfunktionalen Anforderungen, welche sich auf die Performance beziehen. Diese Arbeit gliedert sich in einen analytischen und einen praktischen Teil. Der analytische Teil zeigt den industriellen und wissenschaftlichen Status Quo. Anhand der aktuellen Werkzeuglandschaft, Schnittstellen und der Publikationslage wurden relevante Messgröÿen und Verfahren zu deren technischer Erhebung ermittelt. Die Analyse weiterer Teilaspekte des Monitorings hat Praktiken zur Speicherung der gewonnenen Daten und deren Auswertung ergeben. Die Leistungsfähigkeit und Grenzen bereits existierender Monitoringwerkzeuge wurden im Projektbezug erfasst. Auch Techniken, einem Aufruf seinen fachlichen Kontext zur Verfügung zu stellen, sind im Rahmen dieser Arbeit entwickelt worden. Üblicherweise wird das Monitoring erst gegen Ende des Erstellungszyklus einer Software integriert und zur Erhebung und Analyse des Laufzeitverhaltens des Systems genutzt. Da bereits zu Beginn eines Softwareprojekts nichtfunktionale Eigenschaften wie Antwortzeiten bekannt sind, wurde ein Vorgehen ausgearbeitet, welches das Monitoring früh in die Softwareentwicklung integriert. Hierfür werden die für Monitoring relevanten Anforderungen in das fachliche Modell der Software übernommen. Aus diesem Modell ist ein Technisches zu generieren, in welchem die Komponenten der zu überwachenden Anwendungsfälle gekennzeichnet sind. Durch modellgetriebene Softwareentwicklung ndet eine Generierung von groÿen Teilen des Quellcodes der Anwendung statt und das Monitoring ist bereits während der Implementierung des Systems zu nutzen. Dies liefert eine Vorgehensweise zur Integration eines fachlichen Monitorings. Die Umsetzbarkeit dieses Verfahrens und die geringen Auswirkungen auf die Systemperformance wurden in einem Java Enterprise Edition(JEE) Beispielprojekt nachgewiesen. i

8

9 Inhaltsverzeichnis 1 Einleitung Struktur der Arbeit und Vorgehensweise Motivation Architekturen und Aufbau der betrachteten Softwaresysteme Was ist Monitoring? Dierenzierung von technischem und fachlichem Monitoring Technische Aspekte des Monitorings Aufbau eines Monitoringwerkzeugs Codeintegration Zeitpunkte der Instrumentierung Manuelle Integration Integration durch Generierung Integration mittels Stellvertreter Integration mittels Interceptoren Integration mittels aspektorientierter Programmierung Auswertung der Integrationsstrategien Datenspeicherung Orte der Datenspeicherung Art der Speicherung Kombinationen der Speicherverfahren Analyse Messwerte Fachliche Messwerte Technische Messwerte Gemessene Werte Zusammenfassung Fachliche Aspekte des Monitorings Das fachliche Monitoring im Softwareerstellungszyklus Bereitstellung des fachlichen Kontextes im Monitoring iii

10 Inhaltsverzeichnis Der fachliche Kontext im ThreadLocal-Objekt Fachlicher Kontext im Threadnamen Durchreichen des fachlichen Kontextes durch Messagewrapping Ermittlung des Anwendungsfalls durch Methodennamen Der fachliche Kontext in Methodensignaturen Auswertung der Bereitstellung des fachlichen Kontextes Kennzahlen des fachlichen Monitorings Zusammenfassung Marktanalyse Die verwendete Beispielsoftware Anforderungen an die untersuchten Werkzeuge Bewertungskriterien Evaluierung der Werkzeuge Kieker ARM 4.0 SDK Version JAMon Zusammenfassung Prototypische Umsetzung Anforderungen und Zieldenition Vorgehen Konstruktion der Generatoren Softwareentwicklungszyklen der prototypischen Umsetzung Analysephase Spezikationsphase Designphase Realisierungsphase Analyse der prototypischen Umsetzung Resümee und Schlussfolgerungen 79 7 Ausblick 83 8 Verwandte Arbeiten 85 A Fragenkatalog 87 B Bewertungsmatrix 91 iv

11 Inhaltsverzeichnis C Performancemessungen 93 v

12

13 Abbildungsverzeichnis 1.1 Der schematische Aufbau eines Systems Die verschiedenen Ebenen der Modelle nach OMG [52] Die Phasen der Softwareentwicklung Aufbau eines Monitoringwerkzeugs Das UML-Diagramm des Stellvertreter-Entwurfsmusters [69] Darstellung des Interceptor-Entwurfsmusters [56] Aufbau des Interceptor-Entwurfsmusters Das Prinzip der dezentralen Datenspeicherung Das Prinzip der zentralen Datenspeicherung Verarbeitungskette eines Analysewerkzeugs Beispiel für die Visualisierungen einer Transaktion durch Aufrufbaum, Aufrufdiagramm und textueller Ausgabe Beispiel für die Änderung von EOI und ESS in einem Sequenzdiagramm Beispiel für das Wrapping mittels Stellvertreter Bereitstellung des fachlichen Kontextes durch eine Kombination verschiedener Verfahren Anwendungsfalldiagramm der Beispielsoftware [61] Architektur der Beispielsoftware [61] Beispielcode einer Kieker Messsonde Sequenzdiagramm einer Kieker Messsonde Sequenzdiagramm der Analyse mit Kieker Konguration des AnalysisControllers Klassendiagramm einer Kieker Analyse [36] Auswertung des ConsumerAvg-Plugins Textuelle Ausgabe des Ergebnisses des ConsumerAvg-Plugins Der Ablauf einer ARM Messsonde Ablauf einer Messsonde in JAMon Der Arbeitsablauf (engl. Workow) bei der Integration des fachlichen Monitorings Das Anwendungsfalldiagramm mit Markierungen Ausschnitt des Navigationsdiagramms mit Markierung vii

14 Abbildungsverzeichnis 5.4 Durchschnittliche Laufzeiten der Anwendungsfälle bei verlängerter Methodenlaufzeit Durchschnittliche Laufzeiten der Anwendungsfälle bei normaler Methodenlaufzeit A.1 Der Fragenkatalog beim Hospitieren der Projekte A.2 Erster Teil der Ergebnisse der Interviews A.3 Zweiter Teil der Ergebnisse der Interviews B.1 Die Bewertungsmatrix mit den Bewertungen der Werkzeuge C.1 Ergebnisse der Performancemessungen viii

15 Tabellenverzeichnis 5.1 Tabelle der NFAs ix

16

17 1. Einleitung Diese Arbeit beschäftigt sich mit dem fachlichen Performance-Monitoring. Es werden technische und fachliche Aspekte eines solchen Verfahrens beleuchtet. Eine Einbindung in den Softwareentwicklungszyklus wird ebenfalls betrachtet. Die Marktanalyse untersucht die aktuelle Landschaft von Werkzeugen (engl. Tool) auf die Verwendbarkeit für das fachliche Monitoring. Die praktische Anwendung der gewonnenen Erkenntnisse in einem Beispielprojekt liefert ein einheitliches Vorgehen zur Integration in eine Software Struktur der Arbeit und Vorgehensweise In diesem Abschnitt ndet sich eine Beschreibung des Aufbaus dieser Arbeit und eine Erläuterung des Vorgehens zur Ermittlung der Ergebnisse. Kapitel 1 beschäftigt sich mit den Vorteilen, die sich durch die Nutzung ein fachliches Monitorings ergeben. Denitionen von Begrien, die für das Verständnis dieser Arbeit notwendig sind, nden sich in Abschnitt 1.3. Des Weiteren ndet eine Abgrenzung des fachlichen Monitorings zu ähnlichen Verfahren statt. In Kapitel 2 werden die technischen Grundlagen des Monitorings erläutert und bewertet. Dort nden sich Details zum Aufbau eines Monitoringwerkzeugs und dessen Komponenten. Einige Realisierungsmöglichkeiten dieser Komponenten werden dort erörtert. Es wird beschrieben, wie das Monitoring in die Software einzufügen ist und welche die gängigsten Verfahren zur Speicherung der gewonnenen Informationen sind. Auch die Analyse der gewonnenen Daten wird geschildert. Die wichtigsten Messwerte für das fachliche Monitoring werden ebenfalls vorgestellt. Kapitel 3 beschreibt, wie das Monitoring in den Softwareerstellungszyklus integriert werden soll. Auÿerdem werden Realisierungsmöglichkeiten zur Bereitstellung des fachlichen Kontextes einer Transaktion vorgestellt. Diese werden miteinander verglichen und bewertet. Wichtige Kennzahlen, die aus den gesammelten Messwerten für das fachliche Monitoring zu errechnen sind, werden ebenfalls aufgezeigt. Die vorgenommene Marktanalyse wird in Kapitel 4 beschrieben. Hier ndet sich eine kurze Vorstellung der verwendeten Beispielsoftware und eine Denition der Anforderung an die getesteten Werkzeuge. Auch die Kriterien der Werkzeugbewertung werden erläutert. Im Anschluss nden eine detaillierte Analyse und eine Bewertung von den 1

18 1. Einleitung drei Werkzeugen Kieker, ARM 4 SDK und JAMon statt. Das Kapitel schlieÿt mit dem Vergleich der Werkzeuge. Kapitel 5 schildert die praktische Umsetzung der erarbeiteten Ergebnisse. Hier wird beschrieben, wie ein fachliches Performance-Monitoring in eine Beispielsoftware integriert werden kann. Es werden die Anforderungen und das Vorgehen für dieses Projekt erläutert. Anschlieÿend wird die konkrete Realisierung beschrieben. Eine Bewertung dieses Beispielprojekts und eine Performanceanalyse des Monitorings schlieÿen das Kapitel ab. Den Schluss dieser Arbeit bilden ein Resümee der vorherigen Kapitel, ein Ausblick über mögliche Erweiterungen und Verbesserungen des Vorgehens und verwandte Arbeiten auf dem Gebiet des Monitorings. Zur Erarbeitung der Ergebnisse dieser Arbeit wurden drei Groÿprojekte der Firma Capgemini, mit je mehr als 50 Mitarbeitern, besucht. In diesen Projekten wird Software für einen Automobilhersteller, eine Versicherung und für eine Bundesbehörde entwickelt. Um die Umsetzung des fachlichen Monitorings in der Praxis zu untersuchen, fand ein Interview mit Verantwortlichen dieser Projekte statt. Ziel dieser Interviews war die Beantwortung von allgemeinen, technischen und fachlichen Fragen zum Monitoring in den Projekten. Hierfür wurde ein Fragenkatalog (siehe Anhang A) erstellt. Neben dem Hospitieren in den Projekten fanden sich Ergebnisse dieser Arbeit in verschiedener Literatur, eigenen Ideen und daraus gezogenen Schlussfolgerungen Motivation Moderne Softwaresysteme werden in Zukunft umfangreicher und deshalb komplexer. Dadurch wird die Lokalisierung von Fehlerquellen und Performanceproblemen eine wachsende Herausforderung. Durch ausgiebiges Testen einzelner Programmteile sind Performanceprobleme behebbar, etliche bleiben jedoch bis zur Inbetriebnahme unerkannt. Es sollte angestrebt werden, mögliche Ursachen für Performanceprobleme frühzeitig zu erkennen, da es sehr zeitaufwändig ist, die problematischen Codestellen in den späteren Phasen der Entwicklung oder im laufenden Betrieb zu nden. Zur Erhebung von Kennzahlen bezüglich der Performance einer Anwendung werden standardmäÿig in deren Entwicklung und Betrieb Monitoringwerkzeuge eingesetzt. Durch eine regelmäÿige Überwachung von Vorgängen in einem System lassen sich kritische Programmteile identizieren. Die Ursachen von Problemen werden hierdurch auf kleinere Bereiche des Systems eingeschränkt. Dies gilt hauptsächlich für Performanceprobleme, kann jedoch auch bei fehlerhaften Zuständen in Software und kritischen Fehlern sehr hilfreich sein. Die Handhabung dieser Monitoringwerkzeuge ist kompliziert und 2

19 1.2. Motivation zeitintensiv, da die Werkzeuge oft sehr komplex sind und ein fachlicher Bezug zu den technischen Kennzahlen fehlt. Die Überwachung der technischen Teilsysteme ndet gröÿtenteils mithilfe eines technischen Monitoringverfahrens statt. Wird das Monitoring jedoch um einen fachlichen Kontext erweitert, bietet dieser Ansatz eine Vielzahl weiterer Vorteile für die Entwickler der Software, Organisationseinheiten wie Betrieb, Fachbereich und viele weitere Interessengruppen. Das fachliche Monitoring unterstützt die Softwareentwickler vor dem Debuggen der Software, da sie technische Daten zu fachlichen Anwendungsfällen (engl. Use-Cases) geliefert bekommen. Durch die Korrelation dieser Daten verringert sich beispielsweise der zeit- und Knowhow-intensive Prozess des traditionellen Prolings auf ein Minimum. Die ausschlieÿliche Messung von fachlich relevanten Vorgängen im System führt zu einer Reduzierung des entstehenden Datenvolumens. Dies und der fachliche Kontext der Daten erleichtern die Analyse von Performance und Fehlern erheblich. Auÿerdem führt die fachliche Eingrenzung der Messungen die Nutzer des Monitorings schneller zu den für sie relevanten Daten, Programmstellen oder fachlichen Komponenten. Durch den fachlichen Kontext von Transaktionen werden Zeitmessungen konkreten Anwendungsfällen zugeordnet. Dies erlaubt es, die in der Spezikation vorgegebenen Antwortzeiten nachzuweisen. Die Messung dieser Antwortzeiten bietet dem Hersteller und dem Auftraggeber der Software schon sehr früh im Entwicklungsprozess und über den restlichen Lebenszyklus der Software hinweg einen guten Indikator für das Qualitätsmerkmal Ezienz der ISO Das fachliche Monitoring erlaubt es zusätzlich Nutzerprole zu erstellen, mithilfe derer das Verhalten der Endnutzer analysiert und nachvollzogen werden kann. Die Analyse zeigt, ob Funktionen der Software richtig genutzt werden oder bei welchen Funktionen die Endnutzer Schwierigkeiten haben. Verbesserungsvorschläge von Endnutzern, die mit der fertigen Software arbeiten und nicht mit deren technischer Infrastruktur vertraut sind, können durch den fachlichen Bezug zu technischen Daten ebenfalls besser umgesetzt werden. Aus den Ergebnissen können die Produktverantwortlichen Maÿnahmen ableiten, um das System weiterzuentwickeln und die Benutzbarkeit zu verbessern. Die Analyse von Nutzerprolen kann auch helfen, Schulungen für die Verwendung des Systems zu verbessern. Trotz des Nutzens und der Wichtigkeit eines fachlichen Monitorings sind bis heute kaum Literatur, Konzepte, Erfolgsmethoden (engl. Best Practice) und Implementierungen vorhanden. Der Grund hierfür liegt in einer Konzentration auf das technische Monitoring und dem fehlenden Bewusstsein für die Vorteile, die das fachliche Monitoring bietet. 3

20 1. Einleitung 1.3. Architekturen und Aufbau der betrachteten Softwaresysteme Bevor näher auf das technische und fachliche Monitoring eingegangen werden kann, ist es wichtig, einige Rahmendetails bezüglich Architektur und Softwareentwicklung zu de- nieren und einzuführen. Eine Denition häug verwendeter Begrie in dieser Arbeit wird an dieser Stelle ebenfalls vorgenommen. Die hier aufgeführten Begrie und Denitionen sind so detailliert, wie es für das Verständnis dieser Arbeit nötig ist. Es existiert zwar viel Literatur [31][51][50][10] zu den in diesem Abschnitt genannten Begrien, doch sie sollen so verstanden werden, wie sie hier deniert sind. Im Folgenden wird ein Softwaresystem kurz System genannt. Bei allen im Rahmen dieser Arbeit betrachteten Systemen handelt es sich um komplexe betriebliche Informationssysteme. Die in dieser Arbeit beschriebenen Techniken können jedoch zum gröÿten Teil auch auf andere Softwaresysteme angewendet werden. Betriebliche Informationssysteme Betriebliche Informationssysteme setzen häug komplexe und unternehmenskritische Prozesse und Verfahren um und werden meist von Entwicklerteams erstellt, die oft eine Gröÿe von 25 Personen überschreiten (siehe Anhang A). Deshalb ist es wichtig, in allen unter Softwareentwicklungszyklus beschriebenen Phasen strukturiert und vorausschauend vorzugehen. Dies geschieht, um eine eziente Entwicklung zu ermöglichen und um die Wart- und Erweiterbarkeit des Systems zu verbessern. Neben den funktionalen Anforderungen an das System existieren auch nichtfunktionale Anforderungen. Funktionale Anforderungen setzen konkret geforderte fachliche Aufgaben der Software um. Nichtfunktionale Anforderungen (im Folgenden NFAs genannt) sind Anforderungen, die rund um die Software zu erfüllen sind [31]. NFAs sind häug schwer messbare Eigenschaften der Qualitätsanforderungen des Systems wie beispielsweise Wartbarkeit, Ezienz, Skalierbarkeit, Wiederverwendbarkeit und Performance. Es gibt aber auch konkret denierte NFAs wie Antwortzeiten, die Erstellung von Logdateien oder Benutzerprolen. Die Schichtenarchitektur Die Softwarearchitektur beschreibt den strukturierten Aufbau des Systems. Eine Softwarearchitektur identiziert Komponenten und regelt deren Zusammenspiel, sodass sowohl die funktionalen als auch die nichtfunktionalen Anforderungen erfüllt sind [2]. Eine sehr bewährte Architektur ist die Schichtenarchitektur. Bei dieser Architektur werden Funktionen der Software in Schichten (engl. Layer) zusammengefasst. Eine Schicht bietet der darüberliegenden Schicht Dienste an und nutzt dabei die Dienste der Darunterliegenden. Eine wichtige Voraussetzung für die sinnvolle Verwendung der Schichtenarchitektur 4

21 1.3. Architekturen und Aufbau der betrachteten Softwaresysteme ist eine klare Denition von Schnittstellen der einzelnen Schichten. Eine Schnittstelle beschreibt die Dienste, welche die jeweilige Schicht anbietet. Die drei wichtigsten Schichten eines Systems sind: Präsentationsschicht (engl. Presentationlayer): Die Präsentationsschicht hat die Aufgabe, Dienste für den Endbenutzer anzubieten und Informationen darzustellen [50]. Geschäftslogik (engl. Businesslogic): Die Umsetzung der fachlichen Anforderungen ist im Allgemeinen das Kernstück einer Anwendung. Diese sind in der Geschäftslogik realisiert. Zu den Aufgaben der Geschäftslogik gehören die Implementierung der funktionalen Anforderungen, die Denition der Steuerung von Benutzeraufrufen und die Integration der für die Geschäftslogik erforderlichen Subsysteme [10]. Datenzugrisschicht (engl. Data Access): Die Datenzugrisschicht kapselt den Zugri der Geschäftslogik auf den Datenspeicher. Auch eine Abbildung von Daten der Geschäftslogik auf deren Repräsentation im Datenspeicher (meist relationale Datenbanken) und umgekehrt wird in dieser Schicht vorgenommen. Dies wird als objektrelationale Abbildung (engl. Object-relational mapping kurz ORM ) bezeichnet. Klassenbibliotheken wie Hibernate [16] oder die Java Persistence API (JPA) [43] setzen diese Funktionalität um. Bei komplexen betrieblichen Informationssystemen handelt es sich meistens um verteilte Systeme. Häug bestehen sie aus mehreren Clientsystemen, welche die Dienste eines oder mehrerer Anwendungsserver nutzen. Der Client realisiert die Präsentationsschicht. Die Server enthalten die Geschäftslogik und Datenzugrisschicht. Ruft ein Client die Geschäftslogik des Servers auf, wird dies im Folgenden als Transaktion bezeichnet. Eine Transaktion kann aus mehreren Einzelschritten bestehen und hat immer einen fachlichen Hintergrund. Ein Beispiel für die Umsetzung einer Schichtenarchitektur ist in Abbildung 1.1 zu nden. Dort sind die Schichten der Schichtenarchitektur zu erkennen. Es wurden zwei weitere Schichten zu den bereits Erwähnten hinzugefügt, um das System besser zu strukturieren. Die Dialogkernschicht wurde zur Abstraktion von der Technik der Präsentationsschicht und zur Kommunikation mit dem Anwendungsserver eingeführt. Die Zugangsschicht regelt die Zugrisberechtigung auf die Funktionen des Servers. Die Aufteilung in Client und Anwendungsserver (Anwendungskern) ist ebenfalls zu erkennen. Für das Mapping der Daten wird die JPA API verwendet. Die Datenspeicherung ndet hier in einer Datenbank (DB) statt. 5

22 1. Einleitung Abbildung 1.1.: Der schematische Aufbau eines Systems Die Komponente Während Schichten ein System horizontal unterteilen, dienen Komponenten dazu, das System vertikal zu strukturieren. Eine Komponente fasst eine oder mehrere Aspekte der Software einer bestimmten technischen oder fachlichen Funktionalität zusammen. Schnittstellen nden neben den Schichten zusätzlich bei den Komponenten Verwendung (siehe Abbildung 1.1). Die Benutzung von denierten Schnittstellen bietet viele Vorteile. Entwickler müssen nichts über die Interna einer Schicht bzw. der Komponenten wissen, um diese zu nutzen. Sie verwenden lediglich die von der Schnittstelle angebotenen Methoden. Dies ermöglicht einen Austausch der Softwareteile, falls dies erwünscht oder nötig ist. Eine Parallelisierung der Arbeit, die Denition von Abhängigkeiten der Komponenten untereinander und eine Konstruktion auf höherer Ebene werden durch die Bildung von Komponenten ebenfalls ermöglicht. Siedersleben deniert eine Komponente durch sechs Eigenschaften: 1. Jede Komponente exportiert eine oder mehrere Schnittstellen. 2. Jede Komponente importiert Schnittstellen, die sie im Betrieb nutzt. 6

23 1.3. Architekturen und Aufbau der betrachteten Softwaresysteme 3. Jede Komponente versteckt ihre Implementierung, dies macht sie austauschbar. 4. Eine Komponente eignet sich als Einheit der Wiederverwendung, da sie die Umgebung, in der sie läuft, nicht kennt 5. Komponenten können andere Komponenten enthalten. 6. Die Komponente ist neben der Schnittstelle die wesentliche Einheit des Entwurfs, der Implementierung und damit der Planung [51]. Das Programmierparadigma Separation of Concerns (kurz SoC ) beschreibt die Trennung von unterschiedlichen Aufgaben des Systems in unterschiedliche Systemteile. Dies sollte auch beachtet werden, wenn die Programmlogik in verschiedene Komponenten aufgeteilt wird (sog. Schneiden). Modellgetriebene Softwareentwicklung Um Ansprüche an Leistungsfähigkeit, Zuverlässigkeit, Sicherheit und Skalierbarkeit von Softwaresystemen zu gewährleisten aber gleichzeitig Kosten- und Termintreue einzuhalten, ist nicht nur ein strukturierter Aufbau der Software, sondern auch ein durchgängiger Fertigungs- bzw. Entwicklungsprozess nötig. Die modellgetriebene Softwareentwicklung (engl. Model Driven Software Development kurz MDSD oder MDD) befasst sich mit der Automatisierung der Softwareherstellung [61]. Eine Implementierungsform von MDSD ist MDA (Model Driven Architecture). Dies beinhaltet eine automatische Generierung von möglichst vielen Artefakten der Software. Unter Generierung versteht man die Erstellung bzw. die Erweiterung eines formalen Modells oder die Erzeugung von Quellcode aus einem formalen Modell. Die Object Management Group (OMG) sieht in ihrer Spezikation [27] von MDA vier Abstraktionsebenen vor [52]. 1. Computational Independent Model (CIM ): Das CIM ist eine umgangssprachliche Beschreibung des Systems. 2. Platform Independent Model (PIM ): Das PIM beschreibt ein Modell, welches das System auf einer plattformunabhängigen Ebene beschreibt. 3. Platform Specic Model (PSM ): Das PSM ist ein plattformabhängiges Modell, welches alle Details für eine spezische Plattform (J2EE, C#, C++,... ), Architektur und Services beschreibt. 4. Implementation Specic Model (ISM ): Das ISM ist der Quellcode der Anwendung oder Teile davon in einer konkreten Programmiersprache. 7

24 1. Einleitung Abbildung 1.2.: Die verschiedenen Ebenen der Modelle nach OMG [52] In der Praxis hat sich eine dreistuge Vorgehensweise durchgesetzt. Aus der fachlichen Spezikation wird ein fachliches Modell erstellt, welches die fachlichen Aufgaben der Software in UML beschreibt. Aus diesem Modell wird ein technisches UML-Modell generiert, in dem alle fachlichen Anforderungen auf technische Artefakte abgebildet werden. Aus diesem technischen Modell lässt sich anschlieÿend der Code für die technischen Schichten bzw. Komponenten und die Methodenrümpfe der fachlichen Komponenten generieren. Softwareerstellungszyklus Die einzelnen Schritte bei der Entstehung der Software werden in dieser Arbeit als Softwareerstellungszyklus bezeichnet. In diese sechs Punkte sollte sich jede Softwareentwicklung gliedern lassen: 1. Analyse: In der Analysephase sind Anforderungen an das zu entwickelnde System zu erheben. Zu dieser Anforderungsanalyse gehört insbesondere eine Klärung und 8

25 1.3. Architekturen und Aufbau der betrachteten Softwaresysteme Konkretisierung der Aufgabenstellung, eine Abgrenzung des zu entwickelnden Systems und die Ermittlung von zu beachtenden Restriktionen [58]. Die Erstellung eines Pichtenhefts gehört ebenfalls zu dieser Phase. 2. Spezikation: In dieser Phase wird auf der Grundlage eines Pichtenhefts ein Fachkonzept erarbeitet. Das Fachkonzept ist eine vollständige Beschreibung der fachlichen Anforderungen an das zu entwickelnde System [58]. Oft wird das Fachkonzept in Form eines fachlichen Modells erstellt. 3. Design: In der Designphase ist das Fachkonzept auf ein IT-Konzept abzubilden. Bei objektorientierter Vorgehensweise gehört hierzu ein vollständiges Objektmodell mit der Spezikation aller benötigten Klassen [58]. Dies wird auch als technisches Modell bezeichnet. Die Umwandlung vom fachlichen in das technische Modell kann sowohl voll-, halbautomatisch als auch manuell erfolgen. Des Weiteren sind in der Designphase für die fachlichen Funktionen Komponenten zu spezizieren und die vertikale und horizontale Architektur festzulegen [58]. 4. Realisierung: Aus dem technischen Modell wird in der Realisierungsphase der Code generiert. Bei einfach zu generierendem technischen Code ist es möglich, ihn komplett automatisch zu generieren. Für Komponenten mit fachlichem Code werden lediglich Klassen- und Methodenrümpfe automatisch erstellt. Der Rest des Codes ist per Hand zu implementieren. Ein wichtiger Teil der Realisierung ist das Testen. Hier ist es wichtig, auch kleine Teile der Software so früh wie möglich zu testen, um Fehler frühzeitig zu erkennen und zu beheben. 5. Integrationsphase: In der Integrationsphase sind die Komponenten zu gröÿeren Einheiten schrittweise zu integrieren, bis als Ergebnis ein lauähiges System entsteht [58]. 6. Konsolidierung: In der Konsolidierungsphase sind noch verbleibende Fehler und Schwachstellen des Softwaresystems im Sinne einer Optimierung zu beseitigen. Als Ergebnis dieser Phase erfolgt die Inbetriebnahme des Systems.[58] Abbildung 1.3.: Die Phasen der Softwareentwicklung 9

26 1. Einleitung 1.4. Was ist Monitoring? Monitoringverfahren werden eingesetzt, um komplexe Vorgänge in beliebigen Systemen zu überwachen und zu analysieren. Das Vorgehen bei solchen Verfahren ist eine regelmäÿige Aufzeichnung relevanter Daten eines Systems und deren Analyse. Dies reicht von der Beobachtung von Geschäftsprozessen in der Wirtschaft, über die Messung der Vitalwerte in der Medizin bis zur Erhebung von Daten über die Entwicklung von Städten in der Soziologie. Im technischen Bereich nimmt das Monitoring eine besonders groÿe Rolle ein. Im Bauwesen z.b. wird die Sicherheit von Bauwerken wie Brücken, Tunnels oder Kraftwerken durch regelmäÿige Aufzeichnung von Belastungen und Verformungen gewährleistet [1]. Der Einsatz des Monitorings ist für viele Bereiche der angewandten Informatik vorteilhaft. Bei Softwaresystemen lässt sich das Laufzeitverhalten dieser überwachen. Die Überwachung erstreckt sich von der Implementierung bis hin zum Betrieb der Software. Traditionell wird Monitoring im Betrieb des Systems eingesetzt, doch bereits bei der Entwicklung lohnt sich ein Einsatz, um Performanceprobleme frühzeitig zu erkennen. Der Fokus dieser Arbeit liegt auf dem fachlichen Monitoring von groÿen betrieblichen Informationssystemen. Die Messungen dieses Verfahrens nden auf einer grobgranularen Ebene des Systems statt. Dies ist nötig, um die Performance des Systems durch die Messungen nicht zu stark zu beeinussen und die Menge an gewonnenen Daten zu reduzieren. Dadurch ermöglicht das fachliche Monitoring die eziente und einfache Eingrenzung von Problemen Dierenzierung von technischem und fachlichem Monitoring Eine wichtige Dierenzierung, die an dieser Stelle getroen werden muss, ist die Abgrenzung von technischem und fachlichem Monitoring. Technisches Monitoring bezieht sich auf die Überwachung der technischen Ressourcen (siehe Anhang A) der Hardware des Systems. Dies beinhaltet Werte wie CPU- Auslastung, Speicherverbrauch und allgemeine Auslastung der Rechner. Feingranulare Messungen auf Funktions- und Methodenebene (sog. Proling) (siehe Anhang A) fallen ebenfalls in das Gebiet des technischen Monitorings. Interessant ist auch das Aufzeichnen von Fehlermeldungen der Anwendung. Es lassen sich Antwortzeiten messen bzw. Roundtrip-Zeiten (die Dauer eines Aufrufs durch das System) berechnen. Aufrufhierarchien (engl. Trace) sind eine geordnete Auistung der bei einer Transaktion durchlaufenen Komponenten oder Methoden. Auch diese Aufrufhierarchien lassen sich vom technischen Monitoring erstellen. Die Interpretation der Daten eines technischen Monitoring 10

27 1.5. Dierenzierung von technischem und fachlichem Monitoring setzt technisches und fachliches Knowhow voraus, da der Bezug zu den fachlichen Aspekten der Anwendung fehlt. Deshalb ist die Suche nach den für die Entwickler und den Support relevanten Daten mit hohem Aufwand (siehe Anhang A) verbunden. Aus diesem Grund ist das technische Monitoring für die Behebung von Performanceproblemen nur bedingt einsetzbar und ist vorrangig für den Betrieb relevant. Oft kann auch diese Form des Monitorings wichtige Hinweise liefern, die zur Lösung von technischen Problemen in komplexen Frameworks oder Softwaresystemen beitragen. Ein hauptsächlich auf Performance ausgerichtetes technisches Monitoring wird oft als Application Performance Monitoring (APM )[56] bezeichnet. Für das technische Monitoring existieren bereits zahlreiche Werkzeuge z.b. Dynatrace [15], IBMs Trivoli [13] oder Vampir [49]. Das fachliche Monitoring setzt auf den Grundlagen des Technischen auf und erweitert dieses. Hier werden technisch gewonnene Daten mit ihrem fachlichen Kontext in Bezug gesetzt. Um dies zu ermöglichen, muss weitere Programmlogik zur Integration des fachlichen Kontextes zum technischen Monitoring hinzugefügt werden. Ziel dieses Verfahrens ist es, konkrete Daten zur Beantwortung fachlicher Fragen (siehe Anhang A) zu liefern. Hiermit sind sowohl Fragen zur Dauer und Aufrufhierarchien von Anwendungsfällen als auch zum Nutzerverhalten gemeint. Konkrete Vorteile, die das fachliche Monitoring bietet, werden an dieser Stelle aufgelistet: schnelle und einfache Beantwortung fachlicher Fragen (z.b. Wie lange dauert die Ausführung von einem bestimmten Anwendungsfall) Unterstützung bei der Entwicklung der Software, es hilft die Fehlerquelle einzugrenzen und weist frühzeitig auf Performanceprobleme hin Ableitungen für Supportmaÿnahmen durch Analyse des Nutzerverhaltens Nachweis von NFAs der Software oder Service Level Agreements (sog. SLAs sind Anforderungen zur Güte von angebotenen Leistungen [60]) Mit Hilfe des fachlichen Monitorings können z.b. einer Transaktion sowohl ein konkreter Anwendungsfall und der zugehörige Benutzer (siehe Anhang A), als auch technische Daten wie die Dauer oder eine Aufrufhierarchie zugeordnet werden. Beim fachlichen Monitoring steht der Gewinn von Performancedaten im Vordergrund. Die Identizierung von Komponenten im System, die von den meisten Transaktionen durchlaufen werden (sog. Hotspots) und Daten zum Nutzerverhalten sind ein praktisches Nebenprodukt dieser Datensammlung. Diese Art des fachlichen Monitorings kann ebenfalls als Application Performance Monitoring bezeichnet werden, jedoch lassen Literatur und Hersteller von APM-Werkzeugen den fachlichen Kontext auÿer Acht. Aus diesem Grund ist die Bezeichnung fachliches Performance-Monitoring treender. 11

28 1. Einleitung Für das fachliche Monitoring sind fertige Werkzeuge sehr selten, da dieses Monitoring immer stark vom fachlichen Kontext der Anwendung und deren Architektur abhängt. Deshalb bietet diese Arbeit technische Realisierungsmöglichkeiten und ein Vorgehen zu Integration dieses Verfahrens. 12

29 2. Technische Aspekte des Monitorings Dieses Kapitel beschreibt den Aufbau eines Monitoringwerkzeugs und die Implementierungsmöglichkeiten der einzelnen Komponenten eines solchen Systems. Diese sind sowohl beim technischen als auch beim fachlichen Monitoring zum gröÿten Teil identisch und in der Literatur [28][29][9] gut beschrieben. Eine Analyse der verschiedenen Realisierungen wird ebenfalls durchgeführt. Auf die für das Monitoring relevanten Messwerte geht Abschnitt 2.5 ein. Anschlieÿend wird eine Zusammenfassung dieser Themenkomplexe gegeben. Ziel dieses Kapitels ist es, die technischen Grundlagen für das Monitoring zu erörtern. Diese sind wichtige Voraussetzungen für die Erstellung oder Verwendung eines Monitoringwerkzeugs Aufbau eines Monitoringwerkzeugs Der Aufbau von Monitoringwerkzeugen ist bei Open-Source [9] oder kommerziellen Anbietern [49] immer gleich. Ein solches Werkzeug kann immer in drei Komponenten aufgeteilt werden. Abbildung 2.1 zeigt die drei grundlegenden Komponenten eines Monitoringwerkzeugs. Die Kreise im Quellcode stellen die Messsonden dar, welche die Daten erheben und an die Datenspeicherung übergeben. Die gespeicherten Daten sind für die Analyse zu nutzen. Abbildung 2.1.: Aufbau eines Monitoringwerkzeugs 13

30 2. Technische Aspekte des Monitorings Die Messsonden sind der erste integrale Bestandteil des Monitorings. Sie enthalten den Code für die Messung und stoÿen die Aufzeichnung der Daten an. Oft werden die Messsonden auch als Messpunkte, Kollektoren oder Datensammler (engl. Probes) bezeichnet. Sie werden in die Anwendung eingefügt, um Messwerte für eine spätere Analyse zu ermitteln. Diesen Vorgang nennt man die Instrumentierung [29] der Software. Die Messsonden bestehen aus zwei Teilen. Im ersten Teil werden z.b. Zeitmessungen gestartet. Der zweite Teil der Messsonde schlieÿt die Messungen ab, analysiert den Aufrufkontext und stöÿt die Aufzeichnung der gewonnenen Daten an [36]. Im zweiten Teil der Messsonden können auch kleine Berechnungen wie z.b. die Dauer des Durchlaufs einer Komponente oder eines Roundtrips stattnden. Auf mögliche Implementierungen und Codeintegrationsverfahren wird in Abschnitt 2.2 eingegangen. Die Messsonden übergeben die gesammelten Daten an die zweite Komponente eines Monitoringwerkzeugs. Diese ist zuständig für die Speicherung der Daten. Die verschiedenen Verfahren zur Datenspeicherung werden in Abschnitt 2.3 erläutert. Um die gewonnenen Daten sinnvoll nutzen zu können, müssen sie anschlieÿend analysiert werden. Dies ist die Aufgabe des Analysators. Diese Komponente bietet eine Vielzahl von Möglichkeiten der Datenaufbereitung an. So werden z.b. Kennzahlen errechnet, die Daten graphisch aufbereitet oder Unregelmäÿigkeiten ermittelt. Eine Beschreibung dieser Komponente enthält der Abschnitt Codeintegration Im folgenden Abschnitt werden verschiedene relevante Verfahren zur Instrumentierung des Quellcodes mit den Messsonden vorgestellt. Von diesen Verfahren hängt der Zeitpunkt der Instrumentierung ab. Die verschiedenen Zeitpunkte der Instrumentierung werden im Folgenden kurz vorgestellt. Anschlieÿend werden die wichtigsten Integrationsverfahren erläutert und bewertet. Das Monitoring zählt zu den Querschnittsbelangen (engl. cross-cutting-concerns) der Software. Unter Querschnittsbelang versteht man Problemfelder, die in verschiedenen Komponenten oder Schichten in ähnlicher Weise auftreten [2]. Da das Monitoring ein Querschnittsbelang des Systems ist, ist es oft schwierig, den Code des Monitorings von dem der Anwendung zu trennen. Die Vermischung vom fachlichen Code der Anwendung und dem Code der Querschnittsbelange wird in der Literatur [64] als Tangling bezeichnet. Das Verstreuen von Code, der nichtfunktionale Eigenschaften des Systems implementiert, über mehrere funktionale Komponenten nennt man Scattering [64]. Starkes Tangling und Scattering sollte vermieden werden, um Wart- und Wiederverwendbarkeit von Komponenten zu erhöhen. 14

31 2.2. Codeintegration Zeitpunkte der Instrumentierung Findet die Instrumentierung des Codes vor der Compilezeit statt, müssen sich die Messsonden zum Zeitpunkt des Kompilierens der Software bereits im Code benden. Ein weiteres Verfahren ist die Integration der Messsonden während des Kompilierens. Hier ist der Compiler für die Instrumentierung des Codes zuständig. Die Messsonden sind bei diesen beiden Verfahren fest im Code der Anwendung integriert. Ein dynamisches Nachladen [32] von Messsonden kann nicht durchgeführt werden. Einige Möglichkeiten dieser Art der Instrumentierung wird im Folgenden vorgestellt. Bei der Instrumentierung zur Laufzeit wird während der Ausführung der Software entschieden, welcher Messsondencode auszuführen ist und ob überhaupt Messsonden zu verwenden sind. Diese Variante ist zwar äuÿerst exibel, kann jedoch auch zu Sicherheitsrisiken führen [32], da es hier möglich ist, Code dynamisch nachzuladen Manuelle Integration Vorstellung des Verfahrens Bei diesem Verfahren wird der Code für die Messung direkt vom Entwickler an den relevanten Stellen im System eingefügt (siehe Anhang A). Zu diesem Zweck steht dem Entwickler ein Monitoringframework zur Verfügung. Dieses wird an den für das Monitoring relevanten Stellen im Code aufgerufen, um Messungen vorzunehmen [28]. Technische Details Bei diesem Verfahren ndet die Instrumentierung des Codes vor der Compilezeit statt. Vor- und Nachteile Die manuelle Integration ist das einfachste Verfahren, die Messsonden in den Code der Anwendung zu integrieren. Durch das Einfügen der Messsonden per Hand entstehen hohe Kosten. Ein weiterer Nachteil beim manuellen Einfügen ist, dass es im Ermessen der Entwickler liegt, an welchen Stellen Monitoringcode eingefügt wird. Dies birgt die Gefahr, dass die Messsonden an wichtigen Stellen vergessen werden können oder dass der Performance-Overhead durch exzessive Verwendung der Messsonden steigt. Das manuelle Einfügen stellt jedoch bei der Instrumentierung von komplexer Logik oder fachlichem Code oft die einzige Möglichkeit der Messung dar. Dies sollte jedoch auf ein Minimum reduziert werden. Ein groÿes Problem bei dem manuellen Einfügen ist, dass hier gegen die Modularisierung der Software verstoÿen wird und es so zu Scattering und Tangling [28] kommt. Dies erschwert eine Änderung der Messsonden, da deren Code über das gesamte System verteilt ist. Auch die Wartbarkeit des Systems wird durch den längeren Code erschwert. 15

32 2. Technische Aspekte des Monitorings Integration durch Generierung Vorstellung des Verfahrens Falls die Software mittels MDSD erstellt wird, ist der Messcode auch generierbar (siehe Anhang A). Hierzu müssen im Modell der Software Markierungen vorgenommen werden, anhand derer der Modell-zu-Text Transformator den Code für das Monitoring generiert. Eine weitere Möglichkeit ist die automatische Generierung bei der Modell-zu- Text Transformation. Hierbei ndet eine automatische Generierung der Messsonden in die Methodenrümpfe statt. Technische Details Der Modell-zu-Text Generator, welcher aus dem Modell den Code erzeugt, ist so zu implementieren, dass die Messsonden nur an bestimmten Stellen im System erzeugt werden. Beispielsweise kann bei der Erstellung von Methoden, die den Zugri auf die Variablen kapseln (sog. Getter- und Settermethoden), auf die Erzeugung von Messsonden verzichtet werden. Die Schichtgrenzen eignen sich ebenfalls für die automatische Integration von Messsonden. Um die Messsonden zu setzen, werden Templates mit dem Messcode im Modell-zu-Text Generator erstellt. Trit der Generator auf eine Markierung für das Monitoring oder auf eine Stelle, an der Monitoring automatisch eingefügt werden soll, wird das Codetemplate an der vorgesehenen Stelle eingefügt. Auch bei diesem Verfahren ndet die Instrumentierung des Codes vor der Compilezeit statt. Vor- und Nachteile Der Aufwand bei der Integration ist durch den MDSD-Ansatz gering. Änderungen lassen sich schnell und einfach durchführen. Hierfür müssen nur die Templates angepasst und die Software neu generiert werden. Bei einer Generierung ist kein Knowhow der Entwickler bezüglich des Monitorings nötig. Doch auch bei diesem Ansatz ndet ein Scattering und Tangling statt, dadurch wird der Code länger und die Lesbarkeit verschlechtert sich. Dies erschwert die Wartung des funktionalen Codes der Anwendung. Bei der Generierung von gesamten Komponenten stellt das Scattering und Tangling keinen Nachteil dar, denn eine Änderung dieser Komponenten wird an einer einzelnen Stelle im Generator vorgenommen Integration mittels Stellvertreter Vorstellung des Verfahrens Um die Messsonden vom funktionalen Code zu trennen, bietet sich die Verwendung des Stellvertreter-Entwurfsmusters (auch Proxy genannt) [28] an. Starke deniert das 16

33 2.2. Codeintegration Stellvertreter-Entwurfsmuster folgendermaÿen: Ein Stellvertreter stellt einen Platzhalter für eine andere Komponente dar und kontrolliert den Zugang zum echten Subjekt [55]. Bei diesem Softwareentwurfsmuster werden die Methoden einer Klasse nicht direkt aufgerufen, sondern die Methoden ihres Stellvertreters. Der Stellvertreter und die eigentliche Klasse besitzen dieselbe Schnittstelle. Der Stellvertreter delegiert den Aufruf weiter an die eigentliche Klasse. Vor und nach der Delegation kann beliebiger Code ausgeführt werden. Dieses Muster bietet sich sehr gut für das Monitoring an. Abbildung 2.2.: Das UML-Diagramm des Stellvertreter-Entwurfsmusters [69] Technische Details Wird eine Erstellung der Software mit MDSD vorgenommen, ist die Generierung der Stellvertreter und deren Code leicht automatisierbar. Hierfür müssen Templates mit dem Messcode für den Modell-zu-Text Generator erstellt werden. Der Generator nutzt die Schnittstellen der Komponenten und die Templates zur Erzeugung der Stellvertreter. Dies verringert den Aufwand und die Fehleranfälligkeit drastisch [28]. Bei diesem Verfahren geschieht die Instrumentierung ebenfalls vor der Compilezeit. Vor- und Nachteile Der Vorteil einer Integration mittels Stellvertretern liegt in der Trennung von Monitoringcode und dem Code der Software. Dies verbessert die Lesbarkeit des Codes und verbessert so die Wart- und Wiederverwendbarkeit der Komponenten. Da bei der Verwendung von Stellvertretern der Quellcode der überwachten Komponenten nicht zwingend vorhanden sein muss, bietet sich dieses Verfahren besonders an Grenzen zu Fremdsoftware oder zu Fremdframeworks an. Werden die Stellvertreter nicht generiert, ist neben der Erstellung auch eine Änderung des Monitorings mit hohem Aufwand verbunden, da es erforderlich ist, jeden Stellvertreter und evtl. auch die Zusammensetzung (sog. Kon- gurationen) der Komponenten zu ändern. Ein weiteres Problem bei der Verwendung von Stellvertretern ohne Generierung ist die Verteilung des Monitoringcodes über viele Komponenten. Dies erschwert eine Änderung der Messsonden. 17

34 2. Technische Aspekte des Monitorings Integration mittels Interceptoren Vorstellung des Verfahrens Ein Interceptor fängt den Zugri auf ein Objekt ab und kann je nach Methodenaufruf bestimmte Aktionen ausführen [59]. Das Interceptor-Entwurfsmuster bietet eine gute Methode zur Lösung von Querschnittsbelangen wie Monitoring (siehe Anhang A). Abbildung 2.3 zeigt, wie der Zugri von Komponente A auf B abgefangen wird. Vor der Ausführung von B kommt es zur Ausführung des Interceptors C. Abbildung 2.3.: Darstellung des Interceptor-Entwurfsmusters [56] Technische Details Die Grundidee dieses Musters ist, dass der Aufruf eines Ziels (engl. Target) nicht direkt ausgeführt wird, sondern über einen Dispatcher läuft. Der Dispatcher erlaubt es, Interceptoren an- und abzumelden, die den Aufruf eines Ziels unterbrechen können. Beim Aufruf eines Ziels prüft der Dispatcher, ob für diesen Aufruf Interceptoren registriert sind. Ist dies der Fall, wird eine Interceptor-Kette mit den passenden Interceptoren in der richtigen Reihenfolge erstellt. Nach der Erstellung stöÿt der Dispatcher die Abarbeitung der Interceptoren an. Erlauben die Interceptoren den Aufruf des Ziels, wird dieses anschlieÿend ausgeführt. Abbildung 2.4.: Aufbau des Interceptor-Entwurfsmusters 18

35 2.2. Codeintegration Das Konzept der Interceptoren ndet sich in vielen Frameworks, Plattformen oder Anwendungsservern. So bietet die Java Enterprise Edition (kurz JEE)[42] mit ihrem Filterkonzept [35] eine Implementierung des Interceptor-Entwurfsmusters. Enterprise- JavaBeans (kurz EJB)[40] ist ein standardisiertes, serverseitiges Komponentenmodell für unternehmensweite Anwendungen [65]. Dieses Modell bietet ebenfalls die Verwendung von Interceptoren an. Diese wird im Folgenden kurz erläutert. Hier kann Interceptor-Klassen oder Methoden, Message-Driven-Beans, ganzen Session-Beans oder deren Geschäftsmethoden zugewiesen werden [65], um sie als Ziele zu kennzeichnen. Die Argumente der Annotation geben die Klassen an, welche die Interceptoren enthalten. Die Interceptormethoden sehen folgendermaÿen public Object b e i s p i e l I n t e r c e p t o r ( InvocationContext ctx ) throws Exception {... } Die Namen dieser Methoden sind beliebig zu wählen. Annotation bedeutet, dass statt des Ziels diese Methode aufgerufen wird. Das Ziel wird über die Methode proceed() des in der Parameterliste der Interceptormethode übergebenen [6] InvocationContext Objekts ausgeführt. Neben Annotation gibt es auch Annotationen für Interceptoren, die den Lebenszyklus oder den Timeout einer Methode überwachen. Auch diese können für ein Monitoring interessant sein. Durch einen Eintrag in der beans.xml Datei lassen sich die Interceptoren einfach und komfortabel deund aktivieren. Vor- und Nachteile Die Vorteile bei der Verwendung von Interceptoren liegen in der Vermeidung von Scattering und Tangling. Lediglich die Annotationen an den Zielen sind über das System verteilt. Durch die Annotationen an den überwachten Methoden oder Klassen ist die Verwendung gut sichtbar und nachvollziehbar. Bei MDSD lassen sich die Annotationen automatisch generieren. Interceptoren sind einfach und ohne viel Knowhow verwendbar. Ein Nachteil der Interceptoren ist, dass sie, abhängig von der Laufzeitumgebung, nicht auf alle Methoden anwendbar sind. Dies erlaubt deren Verwendung nicht überall im System. 19

36 2. Technische Aspekte des Monitorings Integration mittels aspektorientierter Programmierung Vorstellung des Verfahrens Aspektorientierte Programmierung (AOP) ist ein Programmierparadigma für die Objektorientierte Programmierung, um Funktionalitäten generisch über mehrere Klassen hinweg zu verwenden [68]. Um Scattering und Tangling zu vermeiden, können Aspekte der Software und die Stellen deniert werden, an denen sie auszuführen sind. Unter einem Aspekt versteht man einen Bereich der Software, der sich mit einer bestimmten Fragestellung auseinandersetzt und dafür eine Lösung bzw. Implementierung anbietet [28]. Da man das Monitoring als Aspekt vieler Komponenten betrachten kann, bietet die Integration mittels AOP eine gut Möglichkeit der Codeinstrumentierung. Bei dieser Variante der Instrumentierung [9] sind die Messsonden als Aspekte der Komponenten zu realisieren. Technische Details Die Stellen im Programmcode, an denen ein Aspekt wirken soll, werden als Einstichpunkte (engl. pointcut) bezeichnet [70]. Die Stellen, an denen der Aspekt in den Komponentencode tatsächlich integriert wird, nennt man Verbindungspunkt (engl. joinpoint) [12]. Ein Advice gibt an, welche Code vor, nach oder anstelle eines Einstichpunkts ausgeführt werden soll [12]. Eine Kombination aus den Verbindungspunkten und den Advices deniert das genaue Verhalten zur Laufzeit. Die Integration der Aspekte in die Software nennt sich Weben (engl. weaving). Den Zeitpunkt des Einwebens beschreibt das Webverfahren. Die beiden gängigsten Webverfahren sind das Laufzeitweben (engl. load-time weaving) und das Compilezeitweben (engl. compile-time weaving) [14]. Das Compilezeitweben geschieht durch einen Aspect- Compiler, der beim Kompilieren die Aspekte automatisch einwebt. Beim Laufzeitweben werden die Aspekte zur Laufzeit durch einen Loadtime-Weaver in den auszuführenden Code eingewebt. Dieser webt die Aspekte beim Laden durch den Classloader automatisch ein. Neben diesen beiden Webverfahren gibt es noch das Post-compile oder binary weaving, welches Aspekte in die Binärdateien fertig kompilierter Anwendungen einwebt. Vor- und Nachteile Die groÿen Vorteile von AOP sind die hohe Flexibilität bei der Wahl der Verbindungspunkte und die saubere Trennung von Monitoringcode und dem der eigentlichen Anwendung. Hier ndet kein Scattering und Tangling statt. Auÿerdem kann das Monitoring bei einer Laufzeiteinwebung leicht entfernt werden. Doch die Programmierung mit Aspekten hat auch einige Nachteile. Zum Ersten müssen beim Debugging zur Laufzeit alle Aspekte bekannt sein, um das Verhalten des Systems nachvollziehen zu können. Dies ist bei komplexer Software mit vielen Aspekten oder bei Entwicklerteams mit unterschiedlichen Knowhow-Levels oft schwierig. Dazu kann auch eine unsachgemäÿe Verwendung 20

37 2.2. Codeintegration von AOP beitragen. Beispielsweise ist es möglich, Aspekten Methoden anhand deren Namen zuzuweisen. Werden die Methodennamen jedoch nachträglich geändert, kann es leicht vergessen werden, diese Änderungen in der Denition des Aspekts ebenfalls zu ändern. Es ist auch nicht ersichtlich, dass vor diesen Methoden der Aspekt ausgeführt wird. Um dies zu verhindern, bieten sich Annotationen an. Dadurch kann leicht erkannt werden, ob es für die annotierte Methode einen Aspekt gibt. Durch die Monitoring- Annotationen steht zwar wieder Code eines Querschnittsbelangs im Komponentencode. Dieser Code ist jedoch sehr gering und ändert die Lesbarkeit von Methoden kaum, da die Annotation nicht direkt in der Methode steht. Des Weiteren sollten alle Entwickler der Software mit AOP vertraut sein. Trotz dieser Nachteile wird AOP häug für das Monitoring verwendet [29] und bietet eine gute Möglichkeit, die Messsonden zu integrieren. Da zur aspektorientierten Programmierung viel Literatur [70][12] existiert, wird an dieser Stelle nicht weiter auf Beispiele und technische Details eingegangen Auswertung der Integrationsstrategien Das manuelle Einfügen von Messsonden besitzt zwar die höchste Flexibilität, trotzdem sollte darauf weitgehend verzichtet werden, um Code mit unterschiedlichen Funktionalitäten nicht zu vermischen und den Monitoring-Code nicht über das gesamte System zu verteilen. Was die Vermeidung dieser beiden Punkte angeht, haben sich AOP und Interceptoren als beste Lösung herausgestellt. Diese beiden Verfahren lassen sich gut kongurieren, was zu einem sehr leichten Abschalten der Monitoringfunktionalität führt. AOP ist exibler und weitreichender einsetzbar als die Interceptoren, birgt jedoch die Gefahr der unsachgemäÿen Verwendung und ist in der Handhabung etwas komplizierter als die Interceptoren, welche bereits durch das Setzen von Annotationen Ziele markieren. Beim Einsatz von Fremdframeworks, deren Code nicht vorhanden ist, bietet sich die Verwendung von Stellvertretern an [28]. Es sollte jedoch darauf geachtet werden, die Stellvertreter automatisch zu generieren, um den Aufwand und die Fehler gering zu halten. Auf die Generierung in Methoden ist zu verzichten, wenn die Komponenten nicht komplett automatisch erstellt werden. Bei der Generierung von ganzen Komponenten ndet eine Wartung im Generator statt und der Code wird neu erstellt, was mit geringem Aufwand verbunden ist. Wird der Code einer Komponente nur teilweise generiert, führt die Generierung in Methoden zu schlecht les- und wartbarem Code. Viele Anwendungsserver bieten extra Monitoringschnittstellen an. Da sich diese jedoch sehr unterscheiden und abhängig vom jeweiligen Framework sind, wird hier nicht weiter auf diese eingegangen. 21

38 2. Technische Aspekte des Monitorings Die Java Platform Debugger Architecture (JPDA)[3] bietet eine Schnittstelle für die Überwachung von laufenden Java-Programmen. Dies geschieht durch Interaktion mit der Java Virtual Machine (JVM ), auf der das zu überwachende Programm läuft [34]. Mehner hat jedoch gezeigt, dass die Verwendung von JPDA zu einer drastischen Verlangsamung [34] der Software führt. Aus diesem Grund ist JPDA nicht für ein Monitoring zur Laufzeit geeignet. Bei der Integration können verschiedene Verfahren miteinander kombiniert werden. Es gilt, die Vor- und Nachteile der Verfahren in den verschiedenen Einsatzgebieten zu berücksichtigen. Der Einsatz von zu vielen Integrationstechniken kann zu einer unnötigen Komplexität der Software führen Datenspeicherung Die Speicherung der gewonnenen Messwerte kann auf unterschiedliche Arten und an verschiedenen Orten (siehe Anhang A) erfolgen. Einzelne Implementierungsmöglichkeiten werden im Folgenden vorgestellt. Jedes Verfahren zur Datenspeicherung bringt Vor- und Nachteile mit sich, diese werden anschlieÿend gegeneinander abgewogen. In Abschnitt wird auf eine Verknüpfung verschiedener Speicherarten und Orte eingegangen Orte der Datenspeicherung In verteilten Systemen sind unterschiedliche Arten gängig, die Messwerte zu speichern. Die zwei am meisten verbreiteten Verfahren [29](siehe Anhang A) werden hier vorgestellt und bewertet. Dezentrale Speicherung Abbildung 2.5.: Das Prinzip der dezentralen Datenspeicherung 22

39 2.3. Datenspeicherung Vorstellung des Verfahrens Bei der dezentralen Speicherung werden die gesammelten Messwerte lokal auf dem Rechner gespeichert (siehe Anhang A), auf dem sie anfallen. Deshalb ist dies eine sehr einfache Methode der Datenspeicherung. Jedoch muss bei dieser Variante darauf geachtet werden, dass auf allen Rechnern des Systems genügend Platz für die Messdaten vorhanden ist. Die Daten sind asynchron zu speichern, um die Ausführung des überwachten Codes nicht zu verzögern. Eine Puerung und Bündelung der Daten kann bei der dezentralen Speicherung die Schreibzugrie auf das Speichermedium verringern und die Performance verbessern. Als Bündelung bezeichnet man das Zusammenfassen von mehreren Messwertdatensätzen (eine Einheit von allen Messwerten einer Messsonde). Die Korrelation 1 der Messwertdatensätze kann bei einer späteren Analyse durch die Bündelung vereinfacht werden. Die Daten sind nach einem verstrichenen Zeitintervall oder einer erreichten Gröÿe zu löschen, da sonst die gesammelte Datenmenge unaufhörlich zunimmt. Technische Details Für diese Speichermethode bieten sich alle gängigen Logging-Frameworks an. In Java- Anwendungen sind Logger wie Commons Logging, Log4J oder das neuere Logback (siehe Anhang A) sehr verbreitet. Viele Open-Source und kommerzielle Logger sind erprobt und lassen sich ohne viel Aufwand verwenden. Auch Monitoringwerkzeuge wie Kieker [36] oder die ARM 4 SDK [11] nutzen Logger, um ihre Daten zu speichern. Vor- und Nachteile Es hat sich gezeigt, dass für viele Auswertungen nur die lokalen Daten bestimmter Rechner des Systems nötig sind. Dadurch verringert sich die Datenmenge bei einer zentralen Analyse und beschleunigt diese. Dazu müssen die Messwerte von den Rechnern eingesammelt werden. Ein solches Verfahren ist jedoch nicht trivial zu implementieren. Da das Senden der Messwerte über ein Netzwerk häug auf Kosten von Performance und Bandbreite geschieht, schont bei der dezentralen Datenspeicherung ein gelegentliches Einsammeln relevanter Daten Ressourcen (siehe Anhang A). 1 Bei der Analyse sind die Datensätze einer Transaktion miteinander in Verbindung zu bringen, um beispielsweise eine Aufrufhierarchie zu erstellen. Dies wird im Folgenden als Korrelation bezeichnet. 23

40 2. Technische Aspekte des Monitorings Zentrale Speicherung Abbildung 2.6.: Das Prinzip der zentralen Datenspeicherung Vorstellung des Verfahrens Bei der zentralen Speicherung werden alle Messwerte des Systems auf einem zentralen Rechner gespeichert. Zu diesem Zweck muss ein Messwertserver [28] eingerichtet werden. Ein Messwertserver ist als logische Einheit oder Dienst zu betrachten. Er ist für die Verwaltung und das Entgegennehmen der Messdaten zuständig. Auch die Abarbeitung von Abfragen der Messwerte gehört zum Aufgabenbereich eines Messwertservers. Die Bereitstellung eines solchen Dienstes kann auf verschiedene Arten umgesetzt werden. Es ist möglich, den Messwertserver als eigenständigen Anwendungsserver zu implementieren oder als Dienst auf einem bestehenden Anwendungsserver anzubieten. Bei der Übertragung von Messwerten über ein Netzwerk muss auf eine ausreichende Bandbreite zum Messwertserver geachtet werden, da bei einem groÿen System mit vielen Nutzern eine erhebliche Menge an Daten über das Netzwerk eintrit. Auch die Anwendungsserver, auf denen die überwachte Software läuft, müssen genügend Bandbreite besitzen, um die Daten regelmäÿig dem Messwertserver zukommen zu lassen. Vor allem bei Anwendungsservern im System, auf denen viele Nutzer Transaktionen durchführen, kann eine zu geringe Bandbreite zu Problemen führen. Der Messwertserver benötigt genügend Speicherkapazität, um alle eintreenden Daten zu speichern. Die Beispielrechnung 2.1 verdeutlicht die groÿen Datenmengen, die das Monitoring erhebt. Angenommen es arbeiten 1000 Nutzer gleichzeitig auf einem Anwendungsserver, pro Roundtrip, welcher eine Sekunde dauert, fallen vier Messwertdatensätze mit je 100 Zeichen an. Ein Zeichen ist durch acht Byte codiert. In diesem Fall muss der Anwendungsserver zu seinem normalen Datenverkehr zusätzlich ca. 3 MB in der Sekunde versenden. Nimmt der Messwertserver von mehreren solcher Anwendungsserver Daten entgegen, vervielfacht sich der Netzwerkverkehr für den Messwertserver. 24

41 2.3. Datenspeicherung Last pro Sekunde = Byte 1 s = Byte s 3, 05 MB s (2.1) Zur Optimierung des Netzwerkverkehrs bietet es sich an, die Daten zu puern und gebündelt zu übertragen. Durch diesen Vorgang werden die Verbindungen zum Messwertserver erheblich reduziert. Die Korrelation der einzelnen Monitoringdaten einer Transaktion kann bei der Analyse ebenfalls entfallen, wenn die Daten vollständig gebündelt gespeichert (siehe Anhang A) werden. Bei dieser Form der Bündelung sind alle Messwertdatensätze einer überwachten Transaktion zu sammeln und anschlieÿend zu speichern. Es wird empfohlen, die Daten an den Messwertserver asynchron zu senden (siehe Anhang A), da sonst die Kommunikation den Programmablauf verzögert. Technische Details Viele Logging-Frameworks bieten asynchrone Appender zur Speicherung der Daten an oder lassen sich problemlos um eine solche Funktionalität erweitern. Asynchrone Appender bündeln die Daten und schicken sie asynchron bei vollem Puer oder in Ruhephasen des Rechners zu einem zentralen Speicherort. Es ist empfehlenswert, solche fertigen Komponenten einzusetzen, da sie vielfach erprobt sind und den Implementierungsaufwand (siehe Anhang A) senken. Vor- und Nachteile Die zentrale Speicherung hat den Vorteil, dass sich alle benötigten Daten an einem Ort benden und für eine umfassende Analyse nicht erst gesammelt werden müssen. Bei groÿen Systemen ist das Sammeln der Messwerte an einer zentralen Stelle aufgrund des hohen Datenaufkommens nicht immer möglich. Ein weiterer Nachteil der zentralen Datenspeicherung sind die zusätzlichen Kosten, welche durch das Aufsetzen, die Wartung und Pege des Messwertservers entstehen. Auswertung des Orts der Datenspeicherung Ob die Daten nun zentral oder dezentral zu speichern sind, ist abhängig von der Infrastruktur und Gröÿe des jeweiligen Systems. Bei der Planung eines Systems sollten die Vor- und Nachteile der beiden Speicherorte genau abgewägt werden. Kriterien für die Wahl eines Speicherorts können die Kosten für die jeweilige Umsetzung, deren Aufwand zur Realisierung oder Performance bzw. Ressourcengründe sein. 25

42 2. Technische Aspekte des Monitorings Art der Speicherung Neben dem Speicherort muss auch die Art der Speicherung betrachtet werden. Auch hier wurden zwei unterschiedliche Möglichkeiten der Realisierung gefunden. Im nächsten Abschnitt werden zwei Möglichkeiten betrachtet und bewertet. Speicherung in einer Datenbank Vorstellung des Verfahrens Bei diesem Verfahren werden die gewonnenen Daten in einer Datenbank (siehe Anhang A) gespeichert, dies beinhaltet die Installation und Konzeption 2 der Datenbank. Bei der Abschätzung der Gröÿe der Datenbank helfen Hochrechnungen und Erfahrungswerte aus Referenzprojekten. Die Gleichung 2.2 enthält eine einfache Hochrechnung zur Berechnung der Datenmenge pro Tag. volume = users usecase avg size (2.2) volume = Datenmenge pro Tag users = Anzahl der Nutzer usecase = durchschnittliche Anzahl der Anwendungsfälle pro Tag avg = durchschnittliche Anzahl von Messwertdatensätzen pro Anwendungsfall size = Gröÿe eines Datensatzes Eine Besonderheit von Datenbanken zur Speicherung von Monitoringdaten sind die vielen Schreib- und wenigen Lesezugrie, da viele Messwerte in die Datenbank eingetragen werden und eine Auswertung im Gegensatz dazu selten stattndet. Bei nicht gebündelter Übertragung der Messwerte muss die Datenbank mit vielen parallelen Zugrien umgehen. Technische Details Die meisten Monitoringwerkzeuge oder Logger besitzen die Funktionalität oder eine Erweiterung, um Daten direkt in eine Datenbank zu schreiben. Bei einer zentralen Datenspeicherung ist dies Aufgabe des Messwertservers. Vor- und Nachteile Der gröÿte Vorteil einer Speicherung der Daten in einer Datenbank liegt in den exiblen Abfragemöglichkeiten (siehe Anhang A) durch Structed Query Language (SQL) 2 Zur Konzeption einer Datenbank gehört die Erstellung eines Datenmodells, die Verteilung von Rechten für den Zugri, und die Abschätzung der Gröÿe[30]. 26

43 2.3. Datenspeicherung bei der Analyse. Auch die Aggregation der Daten ist einfach mit SQL durchzuführen. Bei groÿen Datenmengen sind die Abfragen durch Indizierung schneller als im Dateisystem. Um spezielle Berichte zu erzeugen, kann die Erstellung einer Sicht (engl. View) beschleunigend wirken. Dies kann per SQL-Statements realisiert werden [30]. Zu den Nachteilen der Datenbankspeicherung zählen der Performanceoverhead zur Laufzeit, die Notwendigkeit von SQL-Werkzeugen zur Auswertung und die Kosten für Betrieb und Wartung. Speicherung im Dateisystem Vorstellung des Verfahrens Bei dieser Methode der Speicherung werden die Messwerte in Dateien im lokalen Dateisystem (siehe Anhang A) gespeichert. Dies ist die einfachste Methode Daten zu persistieren, da Lese- und Schreiboperationen auf dem Dateisystem leicht zu implementieren sind. Es muss lediglich ein einheitliches Format für die Datensätze gefunden werden. Dabei reicht eine Trennung der einzelnen Messwerte durch ein Trennzeichen, beispielsweise ein Komma (Comma-Separated Values kurz CSV ) [29] aus. Zur Trennung der Messwertdatensätze genügt ein einfacher Zeilenumbruch. Es ist ratsam, die Dateien bei einer festgelegten Gröÿe oder beim Überschreiten eines Zeitintervalls zu löschen (rollieren). Technische Details Die Datenspeicherung im Dateisystem wird von allen gängigen Logging-Frameworks unterstützt. Bei der zentralen Datenspeicherung ist der Messwertserver für das Schreiben in die Datei/en verantwortlich. Vor- und Nachteile Der Vorteil der Speicherung im Dateisystem liegt in der einfachen Realisierung und dem geringen Overhead an Ressourcen und Performance. Einfache Abfragen müssen in diesem Fall nicht durch komplizierte Werkzeuge oder extra implementierten SQL-Code realisiert werden. Hierfür kann man die Werkzeuge des Betriebssystems (Bordmittel) benutzten. Doch bei groÿen Datenmengen und komplexen Abfragen reichen Werkzeuge wie grep oder tail nicht mehr aus und es muss oft auf Analysewerkzeuge oder Auswertungsskripte zurückgegrien werden. Dies und die fehlende Indizierung können die Laufzeit bei einer Auswertung stark verlängern. Auch die Korrelation einzelner Messwertdatensätze ist aufwändiger, da es nicht möglich ist, diese gezielt nach bestimmten Kriterien zu suchen. 27

44 2. Technische Aspekte des Monitorings Es besteht die Möglichkeit, die Vorzüge der Speicherung im Dateisystem und der Datenbank zu kombinieren. Zu diesem Zweck werden die Daten zur Analyse in eine Datenbank geladen. Dies kann bei groÿen Datenmengen zwar zeitaufwändig sein, vereint jedoch die Vorteile beider Speichermethoden. Dieses Vorgehen kommt auch in der Praxis zur Anwendung (siehe Anhang A) [29]. Auswertung der Speicherart Auch bei der Speicherart ist, abhängig vom System, zu entscheiden, welche Variante sinnvoller ist. Sowohl die Kosten für die jeweilige Implementierung von Speicherart und Analyse als auch Performancefaktoren sind in diesem Fall gegeneinander abzuwägen. Die Kosten für die Speicherung in einer Datenbank sind gröÿer, da diese mehr Ressourcen verbraucht und aufwändiger zu realisieren und zu pegen ist. Dafür ist die Auswertung im Dateisystem langsamer und unexibler Kombinationen der Speicherverfahren Eine Speicherung in einer Datenbank macht bei einer dezentralen Speicherung wenig Sinn, da auf jedem Rechner des Systems eine eigene Datenbank eingerichtet werden muss, sogar auf den Client-Rechnern, deren Anzahl sehr hoch sein kann. Auch in der praktischen Anwendung kommt diese Kombination nicht zum Einsatz. Alle weiteren Kombinationen sind abhängig von den Rahmenbedingungen des Systems vorstellbar. Es hat sich jedoch gezeigt, dass die zentrale Speicherung in einer Datenbank und die dezentrale Speicherung im Dateisystem die gängigsten Verfahren (siehe Anhang A) darstellen. Ein bestimmtes Speicherverfahren kann nicht bevorzugt werden, da Infrastruktur und Gröÿe des Systems die Güte der Speicherverfahren beeinussen. Es kann vorkommen, dass eines der Verfahren auszuschlieÿen ist, z.b. durch ein zu hohes Aufkommen von Datenverkehr im Netzwerk oder durch die entstehenden oder laufenden Kosten Analyse Die Analyse von technischem und fachlichem Monitoring unterscheidet sich durch ihre Zielstellung. Beim fachlichen Monitoring ist es das Hauptziel, Performancedaten zu fachlichen Vorgängen im System schnell und einfach (siehe Anhang A) zu erhalten. Beim technischen Monitoring steht die Überwachung von Ressourcen im Vordergrund. 28

45 2.4. Analyse Vorgehen In der Anforderung sind bereits im- und explizit Ziele des Monitorings enthalten. Aus diesen und bewährten Zielen vorangegangener Projekte müssen Fragen formuliert werden, welche durch die Ergebnisse der Analyse beantwortet werden. Bestimmten Fragen sind Techniken zur Ermittlung dieser Ergebnisse und deren Visualisierung zuzuordnen. Technischer Aufbau Der Aufbau von Analysewerkzeugen erfolgt immer nach demselben Muster. Ein Analysewerkzeug besteht aus drei Komponenten. Die Komponenten sind für das Einlesen, die Verarbeitung und die Visualisierung [9] der Daten zuständig. Abbildung 2.7.: Verarbeitungskette eines Analysewerkzeugs Das Einlesen der Daten erfolgt aus Dateien oder Datenbanken. Es kann sequenziell oder gezielt nach bestimmten Datensätzen erfolgen. Beim Einlesen der Daten nach bestimmten Kriterien kann die Verarbeitung übersprungen werden. Dies bietet sich vor allem bei der Verwendung einer Datenbank zur Speicherung der Messwerte an. In diesem Fall können Informationen auch durch SQL-Abfragen ermittelt werden, beispielsweise alle Anwendungsfälle, bei denen die Dauer einen bestimmten Wert überschreitet. Beim sequenziellen Einlesen geschieht die Selektion der relevanten Daten in der Verarbeitung. Die Verarbeitung bereitet die Daten auf, um sie besser visualisieren zu können, falls dies nicht bereits beim Einlesen geschehen ist. Die Anforderungen für die Analyse des fachlichen Monitorings sind oft einfach umzusetzen. Dies geschieht meist durch eine Iteration über die Messwertdatensätze und einfache Vergleiche, beispielsweise um die minimale oder maximale Ausführungsdauer eines Anwendungsfalls oder alle Zeitüberschreitungen bestimmter Anwendungsfälle (siehe Anhang A) zu ermitteln. Die Zusammenfassung von Messwerten kann praktiziert werden, um durchschnittliche Laufzeiten von Anwendungsfällen zu bestimmen. Sind Daten statistisch auszuwerten, bieten sich Werkzeuge zur statistischen Analyse, wie ROOT [57] an. Häug enthalten diese Werkzeuge 29

46 2. Technische Aspekte des Monitorings auch Komponenten zur Visualisierung der Ergebnisse. Die Verarbeitung der Messwerte ist stark von den Anforderungen an das Monitoring abhängig. Eine wichtige Anforderung an ein fachliches Analysewerkzeug ist die einfache, schnelle und übersichtliche Beantwortung von fachlichen Fragen. Deshalb spielt die Visualisierung bei der Analyse eine groÿe Rolle. Die Visualisierung kann in graphischer wie in textueller Form geschehen. Um die Aufrufhierarchie zu visualisieren, haben sich Aufrufbäume und Aufrufdiagramme [36] als praktisch erwiesen. Bei Hierarchien mit wenigen Messwerten kann dies auch textuell übersichtlich dargestellt werden. Hier ist darauf zu achten, die Aufrufe abhängig von ihrer Schachtelungstiefe einzurücken, um die Ausgabe lesbarer zu gestalten. Die Ergebnisse der Analyse von Aufrufzeiten können übersichtlich in Listen dargestellt werden. Häug bietet es sich an, diese Listen nach der Länge der Aufrufe zu sortieren. Kritische Werte farbig zu hinterlegen trägt ebenfalls zur Übersichtlichkeit bei. Zur Erstellung von Graphen können Werkzeuge wie GNUPlot [26] oder Business Intelligence and Reporting Tool (BIRT )[18](siehe Anhang A) zur Darstellung und Analyse von Daten verwendet werden. Graphen können mit Graphviz [20] oder anderen Werkzeugen zur Visualisierung angefertigt werden. Die Ausgabe der graphischen Analyse kann als Bilder exportiert werden. Bei textueller Ausgabe ist der Einfachheit halber die Konsole zu verwenden. In graphischen Analyseprogrammen ist die Ausgabe in einem neuen Fenster oder Tab abzubilden. Der Export der Analyse als HTML-Datei ist eine weitere Form der Ausgabe. Abbildung 2.8.: Beispiel für die Visualisierungen einer Transaktion durch Aufrufbaum, Aufrufdiagramm und textueller Ausgabe Einige Monitoringframeworks liefern Werkzeuge für die Analyse [36] mit. Einfache Analysewerkzeuge können auch schnell von Hand implementiert (siehe Anhang A) werden, dies hat den Vorteil, dass die Analyse speziell auf die Anforderungen zugeschnitten ist. Bei einer Implementierung sollte ein pluginbasiertes Analysewerkzeug erstellt werden, um es in späteren Systemen erneut zu verwenden und um weitere Funktionalität einfach hinzufügen zu können. Passende fertige Tools für die Analyse des fachlichen Performance-Monitorings wurden nicht gefunden. 30

47 2.5. Messwerte 2.5. Messwerte Nach der Erarbeitung der für die Analyse relevanten Fragen können auch die Messwerte bestimmt werden. Einige Messwerte lassen sich der Beantwortung von konkreten, fachlich relevanten Fragen zuordnen. Es gibt Messwerte, die immer beim fachlichen Monitoring aufgezeichnet werden müssen (siehe Anhang A). Es ist zum einen darauf zu achten, dass nicht zu viele Messwerte aufgezeichnet werden, um das Datenvolumen gering zu halten. Zum anderen können verschiedene Daten Hinweise auf Fehler oder Performanceprobleme liefern. In diesem Abschnitt sind die wichtigsten Daten aufgeführt. Abhängig vom System können noch weitere Messwerte erhoben werden. Die optionale Aufzeichnung von aufwändig zu erhebenden Daten ist in Erwägung zu ziehen. Optionale Daten sind bei der Suche nach Fehlern zu aktivieren und im normalen Betrieb des Systems zu (siehe Anhang A) deaktivieren. Dies sollte zur Laufzeit kongurierbar sein (siehe 7), um in Problemfällen schnell Daten für eine Analyse zu erheben. Eine Deaktivierung der optionalen Daten kann durch einen Platzhalter im Messwertdatensatz gekennzeichnet sein. Eine Verwendung verschiedener Messwertdatensätze mit verschiedenen Messwerten spart Ressourcen bei der Speicherung, zieht jedoch eine Unterscheidung der Datensätze bei der Analyse mit sich. Die Messwerte lassen sich in drei Kategorien einordnen: Fachliche Daten Technische Daten Gemessene oder berechnete Daten Fachliche Messwerte Die fachlichen Daten enthalten Informationen über den Kontext einer Transaktion. Zu den wichtigsten Daten für das fachliche Monitoring gehört der Anwendungsfall (siehe Anhang A)[33]. Anhand dieses Datums kann einem Aufruf ein konkreter Anwendungsfall zugeordnet werden. Da dies eine Grundvoraussetzung für das fachliche Monitoring ist, ist auf diesen Wert nicht zu verzichten. Der Anwendungsfall kann in Form einer Zahl, welcher der Anwendungsfall zuzugeordnen ist, oder als eindeutige Zeichenkette mit dem Namen des Anwendungsfalls kodiert und aufgezeichnet werden. Bei der Verwendung einer Zeichenkette entfällt eine Übersetzung der Zahl in eine für den Nutzer lesbare Form bei der Analyse. Die Erzeugung des Anwendungsfalls beginnt meist in den Handlern der graphischen Benutzerschnittstelle (engl. GUI )(siehe Anhang A) im Client. Dort wird die Transaktion gestartet. Der Anwendungsfall kann anhand 31

48 2. Technische Aspekte des Monitorings vom Methodennamen des Handlers ermittelt werden, falls dieser dem Anwendungsfall eindeutig zuzuordnen ist. Eine weitere Möglichkeit ist eine fest codierte Zeichenkette, welche den Anwendungsfall eindeutig bestimmt. Ein weiteres wichtiges Datum für das fachliche Monitoring ist eine Benutzer-ID [33]. Durch diese eindeutigen Nummern oder Namen können Transaktionen bestimmte Benutzer zugeordnet werden. Mithilfe der Benutzer-ID lassen sich bei der Analyse Benutzerprole erstellen und das Benutzerverhalten analysieren. Dies ist hilfreich für die Ableitung von Supportmaÿnahmen. Die Speicherung dieses Wertes kann aus rechtlichen Gründen problematisch sein, da die Aktionen der Nutzer im System überwacht werden. Oft ist es bereits von Nutzen, die Rolle oder Gruppe des Benutzers im System zu erfassen. Da die Identität des Nutzers keine Rolle für die Analyse der Daten spielt, kann der Benutzer auch verschlüsselt oder anonymisiert werden. Hierfür kann ein Hashwert wie MD5 (75) verwendet werden. Die Speicherung einer Transaktions-ID ist wichtig, um die einzelnen Messwertdatensätze einer Transaktion miteinander in Verbindung zu bringen (siehe Anhang A). Hier muss für jede fachliche Transaktion eine eindeutige ID bestimmt werden. Die ID ist spätestens vor dem Schreiben des ersten Messwertdatensatzes zu erstellen. Die einfachste Variante hierfür ist ein Zähler im Server, der bei jeder eingetroenen Transaktion erhöht wird. Für die Aufzeichnung auf Clientseite muss eine eindeutige ID vom Client erstellt oder diese vom Server übertragen werden, z.b. mit dem Rückgabewert einer Transaktion. Hierfür können einige der in Abschnitt 3.2 vorgestellten Verfahren eingesetzt werden. Kommen mehrere Rechner zum Einsatz, muss sichergestellt werden, dass die Transaktions-IDs immer noch eindeutig sind. Um dies zu gewährleisten, ist der bereits erwähnte Zähler mit einer 10er Potenz zu multiplizieren und eine Rechnernummer, die den Rechner eindeutig identiziert, zu addieren. Bei diesem Verfahren ist die Anzahl der Rechner im System jedoch auf eine 10er Potenz beschränkt, dafür ist die Generierung der ID und deren Verarbeitung schnell und einfach. Eine weitere Variante für die Transaktions-ID ist ihre Repräsentation als Zeichenkette. Auch hier lässt sich ein Zähler verwenden. Aus dem Zählerwert wird eine Zeichenkette erstellt, an die der Rechnername, die IP-Adresse oder der Benutzername angehängt wird. Die Verarbeitung von Zeichenketten ist jedoch zeitaufwändiger als Operationen auf Zahlen. Neben den vorgestellten Verfahren können auch fertige UUID Bibliotheken zur Generierung von IDs verwendet werden. Beispiele für diese Bibliotheken sind Implementierungen der UUIDS und GUIDS Spezikationen [63] oder das java.util.uuid [8] Packet der Java JDK ab Version 5. Die verschiedenen Biliotheken können starke Laufzeitunterschiede bei der Generierung aufweisen. Auch auf die Einsatzgebiete dieser Bibliotheken muss bei ihrer Verwendung geachtet werden. Gelegentlich geben Parameter oder Rückgabewerte von Funktionen (siehe Anhang A) Informationen über Probleme preis. Eine Rückgabe eines null-wertes kann z.b. eine häuge Fehlerursache sein und zum Abbruch von Transaktionen führen. Durch die 32

49 2.5. Messwerte Aufzeichnung der Rückgabewerte lassen sich Fehler dieser Art schnell nden. Auch Aufrufparameter beinhalten oft wichtige Informationen zur Erkennung von Fehlern oder Performanceproblemen. Ein Beispiel hierfür sind bestimmte Konstellationen von Parametern, die einen Datenbankzugri stark verlängern. Überschreitet die Dauer einer Transaktion in solchem Fall einen in den NFAs festgelegten Wert, sind die gespeicherten Parameter zur Analyse des Problems verwendbar. Um bei der Aufzeichnung der Messwerte sehr exibel zu sein, lässt sich ein generisches Datenfeld (siehe Anhang A) aufzeichnen. In dieses können beliebige Daten eingetragen werden. Denkbar sind beliebige Informationen zu Aufrufen oder Parametern bzw. Rückgabewerten, falls diese Messwerte nicht explizit existieren. Vor allem beim manuellen Einfügen der Messsonden kann dieses Feld sehr vielseitig genutzt werden. Der Nachteil eines generischen Datenfelds gegenüber fest denierten Feldern ist die schwierige Interpretation solcher Felder. Bei der Verwendung dieses Feldes muss bei der Analyse klar sein, welches Datum in dieses Feld eingetragen wurde. Dies ist durch eine vorangestellte Zahl oder Zeichenkette, welche das Datum beschreibt, zu realisieren Technische Messwerte Die technischen Daten enthalten wichtige Messwerte bezüglich der technischen Rahmenbedingungen des Systems und des Aufrufs. Als Information über den Ort der Datenaufzeichnung dient der Rechnername oder die IP-Adresse des Rechners (siehe Anhang A), der den Messcode gerade ausführt. Dies ist interessant, um festzustellen, welche Rechner eine Transaktion durchläuft oder wie viele Methoden bzw. Komponenten auf einem Rechner durchlaufen wurden. Um Aufrufhierarchien zu erstellen, ist es hilfreich, Methoden- und Klassennamen (siehe Anhang A) zu speichern. Durch diese Daten lassen sich Aufrufe einfach rekonstruieren und Messwerte konkreten Klassen und Methoden zuordnen. Stark rekursive Aufrufe können ebenfalls durch diese Messwerte erkannt werden. Diese Werte ermöglichen die Korrelation von Aufrufdauern und Methoden. Da das fachliche Monitoring grobgranularer als das technische ist, genügt oft die Aufzeichnung des Komponentennamens. Durch eine Zählung der Aufrufhäugkeit von Komponenten lassen sich zusätzlich Hotspots ermitteln. In Fehlerfällen wird gelegentlich Code anderer Komponenten durchlaufen als im Fall einer korrekten Ausführung. Dies wirkt sich auf die Ausführungszeit der Transaktionen aus. Die Erstellung von Aufrufhierarchien kann auf dieses Verhalten wichtige Hinweise liefern. Den Threadnamen bzw. dessen ID (siehe Anhang A) aufzuzeichnen ist sinnvoll, da durch diesen Wert Verklemmungen (gegenseitiges Blockieren von Threads) einfach zu 33

50 2. Technische Aspekte des Monitorings erkennen sind. Werden Threads unterschiedliche Prioritäten zugeordnet, lässt sich deren Laufzeitverhalten mit diesen Messwerten ebenfalls genauer betrachten. Die verschiedenen Aufzeichnungsebenen sollten aufgezeichnet (siehe Anhang A) werden, falls eine Unterscheidung verschiedener Ebenen stattndet. Anhand dieser Werte ist eine Aussage zu treen, wie detailliert eine Transaktion aufgezeichnet wurde. Gerade bei Problemfällen kann die Aufzeichnungsebene einen Hinweis geben, an welchen Stellen des Systems oder in welchen Anwendungsfällen das Monitoring detaillierter zu betreiben ist, um die Problemquelle genauer einzugrenzen. Treten in bestimmten Teilen oder Anwendungsfällen Probleme auf, ist die Aufzeichnungsebene in diesen Bereichen oder für diesen Anwendungsfall zu erhöhen. Dies führt zu einer Aktivierung weiterer Messsonden und einer detaillierteren Überwachung des Systems. Die Aufzeichnungsebene sollte ebenfalls zur Laufzeit kongurierbar sein. Zur Erstellung von Aufrufgraphen oder Aufrufhierarchien sollten noch zwei weitere Werte gespeichert werden. Bei diesen Daten handelt es sich um den Execution Order Index (EOI) oder Call Number und die Execution Stack Size (ESS)[9] oder Layer Level. Der EOI wird in jeder Messsonde um eins inkrementiert. Anhand dieses Wertes können die einzelnen Messwerte eines Aufrufs nach ihrer Aufrufreihenfolge geordnet werden. Mithilfe des ESS lässt sich die Schachtelungstiefe eines Aufrufs ermitteln. Beim Eintritt in eine Messung wird dieser Wert um eins erhöht, während er beim Verlassen der Messsonde um eins verringert wird. Abbildung 2.9 zeigt die Änderung des EOI und ESS in einer Aufrufhierarchie. Komponente A ruft die Methode op1() der Komponente B auf. Dies ist der erste Aufruf auf der ersten Schachtelungstiefe. Nach der Rückkehr dieses Aufrufs wird die op2() Methode von B aufgerufen. Hier handelt es sich um den zweiten Aufruf. Die Schachtelungstiefe ist in diesem Fall eins. Komponente B ruft die op3() Methode von C auf. Dies ist der dritte Aufruf. Die Schachtelungstiefe dieses Aufrufs ist zwei. Abbildung 2.9.: Beispiel für die Änderung von EOI und ESS in einem Sequenzdiagramm 34

51 2.5. Messwerte Gemessene Werte Die letzte Kategorie der Messwerte enthält gemessene bzw. berechnete Daten. Auch hier ndet nur eine Auührung der wichtigsten Werte statt. Für einen Nachweis der in den NFAs geforderten Antwortzeiten sind Zeitmessungen notwendig. Zu diesem Zweck müssen Start- und Stoppzeiten (siehe Anhang A) der überwachten Objekte gemessen werden. Alternativ hierzu ist auch die Dauer der Aufrufe (siehe Anhang A) zu speichern. Der Vorteil bei der Aufzeichnung von Dauern ist eine Verringerung des Datenvolumens. Die Aufzeichnung der Zeiten erlaubt es, die Transaktionen bestimmten Tageszeiten zuzuordnen oder die Transaktionen eines Nutzers nach der Reihenfolge zu sortieren. Diese Zuordnung und Sortierung verbessert die Nutzerprole. Bei der Messung von Zeit- und Dauerwerten hat sich eine Genauigkeit von 20 Millisekunden als ausreichend herausgestellt. Genauer wird in der praktischen Anwendung nicht gemessen. Da Aufrufe im Sekundenbereich liegen, ist eine höhere Auösung nicht nötig. Jede Programmiersprache bietet Funktionen zur Messung der Systemzeit, solche Messungen können ungenau sein. Beispielsweise liefert die Java Spezikation keine genauen Angaben über die Auösung der currenttimemillis() Methode [32][13]. Einige Werkzeuge oder Frameworks für das Monitoring bieten ebenfalls Methoden zur Zeitmessung an. Durch die Zeit- und Dauermessungen an den Rechnergrenzen im System lassen sich Netzwerklatenzen in verteilten Systemen berechnen. Eine Uhrensynchronisation 3 der Rechner ist hierfür nicht nötig, da sich durch die Berechnungen der Dauern des jeweiligen Systemteils die Zeitunterschiede von nicht synchronisierten Uhren aufheben. Die Latenz berechnet sich mit der Gleichung 2.5. dt Client = T Client_Return T Client_Call (2.3) dt Server = T Server_Return T server_entrance (2.4) dt Netz = dt Client dt Server (2.5) 3 In verteilten Systemen ist es häug nötig, die Uhren der Rechner zu synchronisieren. Es lassen sich zwei Arten von Uhren unterscheiden: logische und physikalische. Logische Uhren beziehen sich auf die relative Zeit in einem verteilten System. Mit ihnen lassen sich kausale Abhängigkeiten von Ereignissen erfassen. Uhren, die die reale Zeit verwenden, werden physikalische Uhren genannt. Diese Uhren müssen sich regelmäÿig mit einem zentralen Zeitgeber synchronisieren [67]. Die Uhrensynchronisation ist für das fachliche Monitoring nicht relevant, da sich die Reihenfolge einer Aufrufhierarchie durch den EOI bestimmen lässt. Die Transaktionen eines Nutzers lassen sich durch die Clientzeiten ordnen, wenn davon ausgegangen wird, dass auf jedem Client ein Nutzer arbeitet. Die parallel laufenden Transaktionen auf einem Anwendungsserver lassen sich durch dessen Uhrzeit ordnen. 35

52 2. Technische Aspekte des Monitorings Der dt-wert ist die Dauer eines Durchlaufs des indizierten Systemteils (Client, Server oder Netz). Die Indizes Return, Call und Entrance geben an, ob der Zeitpunkt T die Rückkehr, den Start eines Aufrufs oder den Eintritt in den Systemteil beschreibt. Ein Grund für hohe Laufzeiten von Transaktionen ist das Versenden von groÿen Objekten über das Netzwerk. An dieser Stelle hat sich die Messung von Objektgröÿen (siehe Anhang A) als sinnvoll erwiesen. Da diese Messungen bei groÿen Objekten sehr zeitintensiv sind, sollte dies aus Performancegründen sehr selten oder optional durchgeführt werden. Die Speicherung des Verarbeitungsstatus [33] ist ein weiterer wichtiger Wert. Hier bietet es sich an, einige Werte vorzudenieren, um im Fehlerfall weitere Informationen über den Grund des Fehlers zu erhalten. Die Denition von Fehlern als Zahlenwerte verringert das zu speichernde Datenvolumen. Eine Speicherung als Zeichenkette vermeidet eine Übersetzung in eine für Nutzer lesbare Form bei der Analyse. Da die Aufrufdauer einer Transaktion häug von der Last des Servers abhängt, kann auch ein Wert wie die CPU-Auslastung [32] gemessen werden. Die Ermittlung eines solchen Wertes ist nicht immer einfach und gelegentlich zeitintensiv, da sich eine Messung nicht direkt aus der Java Laufzeitumgebung heraus vornehmen lässt. Hierfür ist die Ausführung von plattformspezischem Code nötig. Deshalb sollte die CPU-Auslastung nur optional ermittelt werden. Auch die Messung des verwendeten Speichers [32] kann hilfreich sein. Wird zu viel Speicher belegt, kann es zur Speicherauslagerung auf die Festplatte kommen, was zu einer massiven Verlangsamung des Systems führt. Javasysmon ist ein Framework, welches den Zugri auf Werte wie den Speicherverbrauch des Systems oder die CPU-Auslastung für mehrere Plattformen ermöglicht [25]. Ein weiterer Indikator für die Last des Servers sind die aktiven Benutzer im System. Bei zustandsbehafteten Systemen ist dieser Wert leicht zu ermitteln. Dazu kann bei Anund Abmeldung der Nutzer eines Anwendungsservers ein Zähler erhöht und verringert werden. Ist der Server zustandslos, lässt sich lediglich die Anzahl parallel ausgeführter Aufrufe messen, indem beim Eintreten und Verlassen des Anwendungsservers einer Transaktion ein Zähler in- bzw. dekrementiert wird Zusammenfassung Zu der technischen Realisierung existiert viel Literatur. Dies hängt gröÿtenteils damit zusammen, dass sich technisches und fachliches Monitoring in seiner Realisierung kaum unterscheidet. Es kann keine Empfehlung für bestimmte Integrations- und Speicherverfahren gegeben werden, da eine gute Lösung sehr stark von den Rahmenbedingungen des jeweiligen 36

53 2.6. Zusammenfassung Projekts abhängt. Jedoch haben sich die AOP und das Interceptor-Entwurfsmuster als gute Verfahren herausgestellt, um Scattering und Tangling auf ein Minimum zu reduzieren. Bei technischem Code, der komplett generiert werden kann, bietet sich auch der Einsatz des Stellvertreter-Entwurfsmusters an. Um Messungen direkt im fachlichen Code durchzuführen, stellt die manuelle Integration die einzige Möglichkeit der Integration dar. Bei der Wahl des Speicherverfahrens stellen die lokale Speicherung im Dateisystem und die zentrale Speicherung in einer Datenbank die gängigsten Verfahren dar. Auch hier müssen die Vorteile der einzelnen Verfahren gegeneinander abgewogen werden. Bei sehr groÿen Systemen mit vielen Nutzern kann ein zu hoher Datentransfer zum Messwertserver die Verwendung der zentralen Datenspeicherung verhindern (siehe Anhang A). Wichtig ist, bei allen Verfahren die Daten gepuert und gebündelt zu speichern oder an den Messwertserver zu übertragen, um die Performance des Systems durch das Monitoring nicht zu stark zu beeinussen. Ein asynchrones Schreiben oder Senden verringert den Einuss des Monitorings auf die Laufzeit der Transaktion. Ziel der Analyse ist es, schnell und einfach die für den Nutzer des Monitorings relevanten Informationen aus den erhobenen Daten (siehe Anhang A) zu extrahieren. Zur Erstellung der Analyse werden alle geforderten und bewährten Anforderungen gesammelt. Daraus können die Fragen erarbeitet werden, die das Monitoring durch die Analyse beantworten soll. Anschlieÿend sind die Techniken zur Beantwortung dieser Fragen zu wählen. Die Implementierung eines Analysetools gliedert sich in drei Komponenten, die für das Einlesen, die Verarbeitung und die Visualisierung der Messwerte zuständig sind. Die Implementierung eines Analysewerkzeugs ist einfach, da für viele Funktionen der Analyse bestehende Werkzeuge verwendet werden können. SQL-Abfragen oder Iterationen über die Messwerte führen ebenfalls zur Beantwortung der ausgearbeiteten Fragen. Nach der Erhebung der für das Monitoring relevanten Fragen richtet sich die Wahl der Messwerte. Die Messwerte lassen sich in fachliche, technische und gemessene Werte kategorisieren. Einige dieser Werte müssen aufgezeichnet werden, andere sind optional. Es gilt ein Mittelmaÿ zwischen der Gröÿe der zu erhebenden Datenmenge und den zu gewinnenden Informationen über das System zu ermitteln. Bei der Planung der technischen Realisierung eines Monitorings müssen Architekten und Verantwortliche für das Monitoring Vor- und Nachteile der verschiedenen Verfahren gegeneinander abwägen. Letztendlich führt nur eine sorgfältige Diskussion von Pro und Contras der einzelnen Verfahren zur besten Lösung für das aktuelle System. 37

54

55 3. Fachliche Aspekte des Monitorings Dieses Kapitel beschäftigt sich mit der Fachlichkeit im Monitoringverfahren. Es ist wichtig, das Monitoring sehr früh in den Softwareerstellungszyklus mit einzubeziehen, da bereits zu Beginn der Erstellung fachliche Anforderungen vorhanden sind. Wie dies durchgeführt wird, beschreibt Abschnitt 3.1. Den Messsonden muss neben den technischen Daten auch der fachliche Kontext eines Aufrufs zur Verfügung stehen, um das fachliche Monitoring zu realisieren. Abschnitt 3.2 stellt einige Techniken vor, die den fachlichen Kontext seinem Aufruf zur Verfügung stellen. Die vorgestellten Techniken werden anschlieÿend miteinander verglichen. Aus den durch das Monitoring gewonnenen Daten lassen sich Kennzahlen berechnen, einige von diesen Kennzahlen werden im Abschnitt 3.3 erläutert Das fachliche Monitoring im Softwareerstellungszyklus Häug ndet eine Integration des fachlichen Monitorings erst in den Generatoren des Quellcodes oder während der Implementierung zum ersten Mal (siehe Anhang A) statt. Dieses späte Vorgehen verringert die Nachvollziehbarkeit der Anforderungen. Dies kann dazu führen, dass wichtige Aspekte des fachlichen Monitorings nicht berücksichtigt werden und Probleme in der Realisierung und Auswertung bewirken. Es ist wichtig, das Monitoring in die frühen Phasen des Softwareerstellungszyklus zu integrieren. Wird dies nicht beachtet, kommt es zu einer dynamischen Anpassung im Verlauf des Projekts, welches die Kosten für die Integration erhöht, zu Schwierigkeiten bei der Implementierung führt und ein konsistentes Monitoringverfahren verhindert. Da bereits in der Analysephase des Softwareerstellungszyklus wichtige Informationen über die Aufgaben des fachlichen Monitorings in Form von NFAs vorhanden sind, ist es sinnvoll, bereits in dieser Phase das fachliche Monitoring zu integrieren. Wichtig ist an dieser Stelle alle Anforderungen, die das fachliche Monitoring betreen oder die durch das Monitoring festgestellt werden sollen, gesondert in einer Datei schriftlich zu dokumentieren. Dies hat den Vorteil, dass alle Anforderungen explizit zur Verfügung 39

56 3. Fachliche Aspekte des Monitorings stehen und mindert die Gefahr des Vergessens von Teilaspekten des Monitorings. Beispielsweise sind alle geforderten Antwortzeiten mit Nummern zu versehen (im Folgenden NFA-Nummer) und in eine Tabelle einzutragen. Weitere Anforderungen, z.b. an die zu erstellenden Benutzerprole, lassen sich ebenfalls tabellarisch festhalten. In der Spezikationsphase sollten bereits die Ziele des Monitorings ausgearbeitet werden. Hierzu gehört die Festlegung der zu überwachenden Anwendungsfälle. Eine Überwachung aller Anwendungsfälle mit geforderten Antwortzeiten ist sinnvoll, um einen Nachweis für die Erfüllung der Forderungen zu liefern. Die durch das Monitoring zu beantwortenden Fragen sind anhand der Anforderungen und wenn möglich aus Referenzprojekten zu bestimmen. Mithilfe dieser Fragen werden die zu erhebenden Messwerte ermittelt, da zwischen ihnen meist eine Verbindung besteht. Ob Benutzerprole erstellt werden und wie diese auszusehen haben, ist ebenfalls zu klären. Anschlieÿend sind alle Anwendungsfälle, die für das Monitoring relevant sind, im fachlichen Modell zu markieren. Dies geschieht durch das eintragen der NFA-Nummern und Dauern in das Anwendungsfalldiagramm, um die Anwendungsfälle mit ihren zeitlichen Anforderungen zu verknüpfen. In anderen UML-Modellen haben sich Stereotypen [66] für diesen Zweck als übersichtlich und leicht einzufügen erwiesen. Zum einen muss ersichtlich sein, welche Anwendungsfälle überwacht werden, zum anderen sollte vermerkt werden, um welche Anforderungen es sich handelt. In UML-Modellen können den Stereotypen Eigenschaften zugewiesen werden, welche genutzt werden, um die NFA-Nummern in die Markierungen einzutragen. Somit lässt sich ein direkter Bezug zwischen Anforderungen wie z.b. Antwortzeiten und dem fachlichen Modell herstellen. Dies ist zum einen für die nächsten Schritte des Softwareerstellungszyklus nötig, zum anderen als eine weitere Form der Dokumentation zu verstehen. Die graphische Form in den Diagrammen trägt zum besseren Verständnis und zur Nachvollziehbarkeit des fachlichen Monitorings bei. Bei einer Softwareerstellung mittels MDSD kann in der Designphase eine Modellzu-Modell Transformation stattnden. Bei der nicht modellgetriebenen Erstellung des Systems wird keine Transformation durchgeführt. In dieser Phase wird das fachliche auf das technische Modell abgebildet. Dabei müssen auch die in der Spezikation gesetzten Markierungen vom fachlichen in das technische Modell übernommen werden. Die Markierungen sind auf die für das Monitoring relevanten Komponenten des technischen Modells zu übertragen. Wie dies vorgenommen wird, hängt stark von der Transformation ab. Wird der Transformationsvorgang nicht vollständig automatisiert, ist es nötig, einige Markierungen per Hand in das technische Modell einzutragen. Auch die Architektur, die im technischen Modell beschrieben wird, beeinusst die Übernahme der Markierungen, da sie einen direkten Einuss auf die Transformation hat. Die Anwendungsfälle der jeweiligen Markierungen sind lediglich in die Systemteile zu übernehmen, in denen der Anwendungsfall gestartet wird. Andere Komponenten (z.b. potentielle Hotspots) werden meistens von verschiedenen Anwendungsfällen durchlaufen und die Zuordnung eines bestimmten Anwendungsfalls macht an diesen Stellen keinen Sinn. So ist es ausrei- 40

57 3.1. Das fachliche Monitoring im Softwareerstellungszyklus chend, diese Komponenten mit Markierungen zu versehen, welche angeben, dass diese Komponenten zu überwachen sind. Der fachliche Kontext ist während der Laufzeit den Messsonden dieser Komponenten durch die Bereitstellungstechniken (siehe Abschnitt 3.2) bekannt. Die Vorteile dieses Verfahrens sind die Rückverfolgbarkeit bis hin zu den Anforderungsdokumenten und eine voll- bzw. teilautomatische und strukturierte Instrumentierung. Bei der Erstellung des Modell-zu-Text (M2T) Generators in der Realisierungsphase ist die Generierung der Messsonden abhängig von den technischen Aspekten des Monitorings. Spätestens zu diesem Zeitpunkt müssen die technischen Aspekte des Monitorings gewählt werden. Ort und Art der Speicherung, die Integrationsmethode und die zu messenden Daten der einzelnen Messpunkte sind festzulegen. Bei der Instrumentierung mittels AOP oder Interceptoren ist es beispielsweise notwendig, eine Annotation vor die zu überwachende Klasse oder Methode zu schreiben. Die für das Monitoring nötigen Aspekte oder Interceptoren werden später von Hand implementiert. Der Aufwand für diese Arbeit ist sehr gering, da lediglich einige Methoden zu implementieren sind. Wird der Monitoringcode direkt in eine Methode generiert, muss der Generator den Messcode an den Anfang und das Ende der Methode schreiben. Bei einer vollständigen Generierung des Monitorings ist es sofort nach der M2T-Transformation einsetzbar. Die Teile des Monitorings, die per Hand zu implementieren sind, sollten zeitnah zur Generierung fertig gestellt werden, um das Monitoring schnellstmöglich nutzen zu können. Falls nötig, lassen sich während der Implementierung der restlichen Software noch weitere Messsonden in die Software einfügen. Dies ist jedoch so weit wie möglich zu vermeiden, da dies die Nachvollziehbarkeit verschlechtert. Anschlieÿend lässt sich das Monitoring bereits in dieser Phase nutzen. In der Integrations- und Konsolidierungsphase sowie im Betrieb des Systems ist das Monitoring zu nutzen, da dies wichtige Daten über das Laufzeitverhalten des Systems und dessen Teile liefert. Diese Daten können zur Analyse des Nutzerverhaltens, zur Performanceoptimierung und für die Überprüfung der Korrektheit des Systems benutzt werden. In der Integrations- und Konsolidierungsphase ist eine hohe Aufzeichnungsebene zu wählen, um viele Messwerte über das System zu erhalten. Im Betrieb der Software reduziert eine niedrige Aufzeichnungsebene die anfallende Datenmenge und den Einuss des Monitorings auf die Performance des Systems. Bei Performanceproblemen oder fehlerhaftem Laufzeitverhalten des Systems wird die Aufzeichnungsebene angehoben, um die Quelle des Problems zu lokalisieren. 41

58 3. Fachliche Aspekte des Monitorings 3.2. Bereitstellung des fachlichen Kontextes im Monitoring Es gibt verschiedene Möglichkeiten, der Ausführung einer Transaktion ihren fachlichen Kontext zur Verfügung zu stellen (siehe Anhang A). Diese werden im Folgenden vorgestellt. Der fachliche Kontext ermöglicht jeder Messsonde die Aufzeichnung von fachlichen Daten wie z.b. des Anwendungsfalls der Transaktion, der Transaktions-ID und des Benutzers (siehe Anhang A), welcher die Transaktion angestoÿen hat. Der fachliche Kontext kann auch die Information enthalten, ob die Messsonden auszuführen sind. Dies ermöglicht die Konguration des Monitorings über den fachlichen Kontext. Es lässt sich bei der Initialisierung des Kontextes festlegen, ob die Transaktion aufzuzeichnen ist und wie detailliert dies geschieht Der fachliche Kontext im ThreadLocal-Objekt Ein Aufruf kann in einem ThreadLocal-Objekt [5] seinen fachlichen Kontext mitführen (siehe Anhang A). Dieses Konstrukt ordnet einem Thread eigene Daten zu. Die Verwendung dieses Objekts ist jedoch plattform- und sprachspezisch. Bei einer Aufspaltung von Threads kann dieses Verfahren nicht eingesetzt werden. Ein weiteres Problem bei der Verwendung von ThreadLocal-Objekten ergibt sich, wenn die Umgebung, in der die Software läuft, diese Objekte nicht unterstützt. Beispielsweise gibt es für einen WebSphere Anwendungsserver keine konsistente ThreadLocal Politik, da zwischen Methodenaufrufen ein Threadwechsel durchgeführt werden kann. Doch auch für diesen Anwendungsserver existieren Hilfskonstrukte, die ThreadLocal-ähnlich zu verwenden sind. Ein Problem stellen auch entfernte Aufrufe (z.b. mit Remote Method Invocation [45] kurz RMI ) dar. Hier wird das ThreadLocal-Objekt nicht automatisch übertragen. In der Praxis wird dieses Verfahren trotzdem verwendet. Ein Vorteil bei der Verwendung solcher Objekte liegt in der Vielfältigkeit der Daten, die sich im ThreadLocal-Objekt halten lassen. So können neben den fachlichen Daten auch technische Aufrufdaten wie EOI und ESS zur Verfügung gestellt werden. Diese Objekte erlauben das einfache Sammeln von fachlichen transaktionsbezogenen Daten (siehe Abschnitt 2.3.1) Fachlicher Kontext im Threadnamen Enthält der fachliche Kontext wenig Daten und kann als Zeichenfolge kodiert werden, lässt sich der Kontext auch im Threadnamen speichern. Dies ist eine sehr einfache Methode zur Kodierung des fachlichen Kontextes. Auch hier ist darauf zu achten, ob die Umgebung die Änderung des Threadnamens ohne Seiteneekte unterstützt. Die Aufspaltung des Threads stellt ebenfalls ein Problem dar. Wird der Threadname für die Kodierung des fachlichen Kontextes verwendet, lässt er sich nicht mehr anderweitig 42

59 3.2. Bereitstellung des fachlichen Kontextes im Monitoring nutzen. Bei entfernten Aufrufen ist dieses Verfahren nicht anwendbar. Wegen der vielen Nachteile und der geringen Mächtigkeit sollte dieses Verfahren höchstens in kleinen überschaubaren Teilen des Systems, z.b. in einfachen Clients, verwendet werden Durchreichen des fachlichen Kontextes durch Messagewrapping Beim Wrapping des Kontextes werden die Daten des fachlichen Kontextes in einen Methodenparameter oder ein Rück- bzw. Übergabegabeobjekt eingebettet (siehe Anhang A). Auch die Übergabe eines Kontext-Objekts, welches den Kontext und die Parameter bzw. Rückgabewerte enthält, ist eine Realisierungsmöglichkeit des Wrappings. Um die Programmlogik von der Übergabe des Kontextes zu entkoppeln, kann das Stellvertreter- Entwurfsmuster verwendet werden. In den Stellvertretern wird der Kontext ein- bzw. ausgepackt. Die Stellvertreter lassen sich leicht generieren, da sie lediglich eine Schnittstelle implementieren und der Code für das Wrapping immer gleich ist. Auch die aspektorientierte Programmierung kann für dieses Verfahren verwendet werden, da AOP eine Manipulation der Aufrufparameter und Rückgabeparameter einer Methode erlaubt. Hierfür müssen Aspekte deniert werden, um vor und nach dem Methodenaufruf den Kontext zu ent- bzw. verpacken. Vor allem bei entfernten Aufrufen, z.b. durch RMI, stellt diese Methode eine gute Möglichkeit dar, den Kontext zu übermitteln. Die Sammlung von Messwerten besteht bei diesem Verfahren ebenfalls. Dies verursacht evtl. Overhead, z.b. wenn viele Messwerte verschickt werden. Ein groÿes Problem beim Wrapping stellt das Verpacken des Kontextes bei Methodenaufrufen dar, da dieses von der eigentlichen Programmlogik entkoppelt sein sollte, um Scattering und Tangling zu vermeiden. Aus diesem Grund ist es sinnvoll, Aufrufe über Stellvertreter vorzunehmen, welche Aufrufe delegieren. Da dies nicht immer möglich oder häug zu aufwändig ist, sollte das Wrapping lediglich bei Aufrufen von entfernten Systemen verwendet werden. In der Praxis kommt das Wrapping häug beim Übertragen des Kontextes an entfernte Systeme vor. Abbildung 3.1 zeigt ein Beispiel für das Wrapping mit Stellvertretern. Der Aufrufer möchte dem Ziel das Objekt übergeben. Zwischen dem Aufruf liegen die beiden Stellvertreter und die Rechnergrenze. Der Stellvertreter A fügt den Kontext und das Objekt in ein Übergabeobjekt ein und verschickt es an Stellvertreter B. Dieser entpackt den Kontext und gibt das Objetk an das Ziel weiter. 43

60 3. Fachliche Aspekte des Monitorings Abbildung 3.1.: Beispiel für das Wrapping mittels Stellvertreter Ermittlung des Anwendungsfalls durch Methodennamen Geht aus einem Methodennamen (siehe Anhang A) eindeutig der Anwendungsfall hervor, kann dieser für das Monitoring genutzt werden. Oft ist dies bei Beginn eines Aufrufs, z.b. in den GUI-Handlern oder beim Eintreen einer Transaktion im Server möglich. Gerade beim Start einer Transaktion ist dieses Verfahren gut zur Initiierung des fachlichen Kontextes geeignet. Im weiteren Verlauf einer Transaktion sollte der Methodenname jedoch nicht mehr zur Ableitung des fachlichen Kontextes verwendet werden, da lediglich der Anwendungsfall abzuleiten ist. So ist es bei diesem Verfahren oft nicht möglich, den Benutzer der Transaktion zu identizieren. Eine korrekte Korrelation der Messwerte wird dadurch erschwert oder verhindert, da wichtige Daten wie Transaktions-ID, EOI oder ESS nicht übermittelt und das Sammeln von Messwerten nicht praktiziert werden kann. Bei der Planung der Software ist darauf zu achten, dass Methodennamen eindeutig sind und der Anwendungsfall ableitbar ist, falls dieses Verfahren eingesetzt wird. Die vielen schwerwiegenden Nachteile dieses Verfahrens führen zu der Schlussfolgerung, dass der fachliche Kontext nur am Anfang einer Transaktion aus dem Methodennamen abzuleiten ist Der fachliche Kontext in Methodensignaturen Ein fachliches Kontext-Objekt kann auch direkt in einer Methodensignatur als Parameter übergeben werden. Gerade bei einer Generierung von Methodenrümpfen ist die Einführung dieses zusätzlichen Parameters mit geringem Aufwand verbunden. Das bedeutet, dass das Kontext-Objekt bei jedem Methodenaufruf weitergereicht werden muss. Bei nicht generiertem Code führt dies zu einem höheren Aufwand für die Entwickler und zu Scattering und Tangling. Auÿerdem sind Methodensignaturen mit vielen Parametern unübersichtlicher. Aus diesen Gründen sollte auf die Weitergabe des fachlichen Kontextes in Methodensignaturen weitgehend verzichtet werden. Lediglich bei entfernten Aufrufen, der Kommunikation von Stellvertretern (siehe Anhang A) und vollständig generiertem 44

61 3.2. Bereitstellung des fachlichen Kontextes im Monitoring Code macht dieses Verfahren Sinn, da der Kontext zum gröÿten Teil vor dem Entwickler verborgen bleibt Auswertung der Bereitstellung des fachlichen Kontextes Zu den Verfahren zur Bereitstellung des fachlichen Kontextes werden Verfahren aus der praktischen Anwendung und eigenen Überlegungen vorgestellt. Welche Bereitstellungsmöglichkeiten in Frage kommen, ist stark von der Architektur der Software abhängig. Auch hier gilt es, die Vor- und Nachteile der einzelnen Verfahren gegeneinander abzuwägen. Es gibt Systeme, in denen die Bereitstellung des fachlichen Kontextes nicht nötig (siehe Anhang A) ist. Hier enthält die Transaktion bereits den Anwendungsfallnamen und der Dispatcher des Anwendungsserver wählt mithilfe dieses Namens die zu durchlaufenden Module aus. In diesem Fall ist es lediglich notwendig, am Ein- und Ausgang des Servers und im Dispatcher vor und nach dem Aufruf eines Moduls eine Messsonde zu setzen. Da die eintreende Transaktion den Anwendungsfall enthält und der Dispatcher diese ebenfalls kennen muss, ist es sinnvoll, diese Daten für das Monitoring zu nutzen. In der Praxis kommen auch Kombinationen aus verschiedenen Techniken (siehe Anhang A) zum Einsatz. Beispielsweise kann eine Kombination aus den Verfahren Wrapping von Messages, Ableitung aus Methodennamen, Nutzung der Methodensignatur und Verwendung des ThreadLocal-Objekts angewendet werden. Die Umsetzung dieses Verfahrens ist in Abbildung 3.2 schematisch dargestellt. Im GUI-Handler des Clients wird aus dem Methodennamen der fachliche Kontext abgeleitet, welcher in einem ThreadLocal-Objekt gespeichert wird, um ihn im Client zur Verfügung zu stellen. Beim Senden an den Server wird ein Stellvertreter aufgerufen, der die Kommunikation mit dem Server übernimmt. Dieser Stellvertreter ruft den Stellvertreter des Servers auf, welcher die Schnittstelle des Servers um den zusätzlichen Parameter eines Kontext-Objekts erweitert. Die Aufgabe dieses Client-Stellvertreters ist, die Aufrufe an den Server zu delegieren und das Kontext-Objekt des Clients an die Aufrufparameter anzuhängen. Der Stellvertreter des Servers delegiert die Aufrufe weiter und bettet das Kontext-Objekt in sein ThreadLocal-Objekt ein. Nun ist der fachliche Kontext im Server verfügbar. Beim Verlassen des Servers werden der Rückgabewert der Transaktion und das Kontext-Objekt in ein Rückgabeobjekt verpackt. Der Stellvertreter des Clients entpackt dieses Rückgabeobjekt, aktualisiert den Clientkontext und liefert den Rückgabewert des Servers zurück. Die Stellvertreter sind leicht zu generieren und die Übergabe des Kontextes ist vor dem Entwickler hinter Schnittstellen verborgen. Durch die Verwendung der ThreadLocal-Objekte ist der Kontext überall im Client und Server verfügbar. 45

62 3. Fachliche Aspekte des Monitorings Abbildung 3.2.: Bereitstellung des fachlichen Kontextes durch eine Kombination verschiedener Verfahren Diese beiden Beispiele zeigen, wie unterschiedlich die Bereitstellung des fachlichen Kontextes ausfallen kann. Wichtig ist jedoch, dass der fachliche Kontext immer zur Verfügung steht und auch um Transaktions-ID, EOI und ESS erweiterbar ist. Dies erleichtert die Korrelation der Messwerte eines Aufrufs bei der Analyse Kennzahlen des fachlichen Monitorings Da sich diese Arbeit mit dem fachlichen Performance-Monitoring beschäftigt, werden vorwiegend Performancedaten betrachtet. Als wichtigste Kennzahl hierfür gilt die Dauer eines Durchlaufs einer kompletten Transaktion oder einer Komponente. Die Gleichung 3.1 gibt die Berechnung für die Dauer eines Aufrufs an. dt Call = T Stopp T Start (3.1) 46

63 3.3. Kennzahlen des fachlichen Monitorings Dieser Wert hat sich als Wichtigster für die Prerformancemessungen (siehe Anhang A) herausgestellt. Sind NFAs bzw. SLAs für die Dauern der Aufrufe angegeben, kann berechnet werden, ob Zeitwerte überschritten wurden. Eine weitere Kennzahl ist die Anzahl der überschrittenen Aufrufe eines Anwendungsfalls in Prozent. Dies zeigt auf einen Blick die Häugkeit der Zeitüberschreitungen von Aufrufen eines bestimmten Anwendungsfalls. Das Minimum bzw. Maximum und die Dierenz der Dauern eines Anwendungsfalls sind ebenfalls aufschlussreiche Kennzahlen. Vor allem kann der längste Aufruf wichtige Hinweise über die Gründe von Performanceproblemen liefern. Bei diesem müssen zusätzlich gespeicherte Messwerte analysiert werden. Bei komplexen Aufrufen grenzen die Dauern der durchlaufenen Komponenten Fehler ein. Auch zusätzliche Messwerte wie hohe CPUoder Speicherauslastung können ein Grund für lange Laufzeiten [29] sein. Viele parallele Aufrufe, die auf gemeinsame Ressourcen zugreifen, sind ein weiterer Grund für lange Ausführungsdauern. Um die Ursache für die Überschreitung der Dauer von Transaktionen zu nden, sind Anomalien in den Messwerten zeitüberschreitender Transaktion gegenüber denen mit passabler Dauer festzustellen. Eine Berechnung von Kennzahlen aus Dauer und technischen Messwerten ist wenig aussagekräftig, da sich so keine intuitiven Werte ermitteln lassen. Sinnvoller ist es Ausreiÿer unter den Messpunkten automatisch zu erkennen. Hierfür gibt es statistische Verfahren. Auch eine graphische Aufbereitung der Messwerte z.b. in Graphen oder Boxplots trägt zur Erkennung von Fehlerursachen bei. Um Hotspots im System zu identizieren, können die prozentualen Durchläufe von Komponenten oder Anwendungsfällen in einem Zeitintervall ermittelt (siehe Gleichung 3.2) werden. Hotspot x = Durchläufe x Anzahl aller T ransaktionen (3.2) Je hoher dieser Wert ist, desto wichtiger ist die Optimierung dieser Komponente oder des Anwendungsfalls. Um die Systemteile mit der gröÿten Nutzung zu identizieren, kann eine Rangliste der Komponenten erstellt werden, welche die höchsten Prozentzahlen in einer Woche oder einem Monat erhielten. Ein hohes Zeitintervall liefert ein genaueres Ergebnis, benötigt aber mehr Rechenzeit. Auch das Zählen der Aufrufhäugkeiten von Anwendungsfällen stellt eine wichtige Kennzahl zur Ermittlung von Hotspots und des Benutzerverhaltens dar. Zur Auswertung dieser Kennzahlen werden alle Transaktionen eines bestimmten Anwendungsfalls gezählt und geordnet ausgegeben. Bis auf Performancekennzahlen wie Dauer und Minimum bzw. Maximum eines Durchlaufs wurden in der Praxis (siehe Anhang A) keine weiteren Kennzahlen verwendet. Doch 47

64 3. Fachliche Aspekte des Monitorings gerade Zahlen zur Identikation der Hotspots sind einfach zu errechnen und geben Hinweise zur wirtschaftlichen Optimierung des Systems Zusammenfassung Zur Bereitstellung des fachlichen Kontextes existiert wenig Literatur, doch die verschiedenen Verfahren aus der Praxis bieten gute Lösungsansätze für eine Implementierung. Bei der Auswahl der Verfahren ist auf den Einsatzort im System und die Vor- und Nachteile der einzelnen Verfahren zu achten. Das in Abschnitt vorgestellte Vorgehen lässt sich bei vielen Architekturen gut anwenden und hat keine ersichtlichen Nachteile. Jedoch kann es, abhängig von der Architektur, noch andere Vorgehensweisen geben, die mit weniger Aufwand verbunden sind. Die Kennzahlen hängen von den Anforderungen an das fachliche Monitoring ab. Falls lediglich ein Nachweis der Antwortzeiten gefordert ist, sollte trotzdem eine Korrelation der Aufrufdauern mit technischen Werten wie CPU- bzw. Speicherauslastung oder der Anzahl von parallel ausgeführten Transaktionen stattnden. Denn diese Werte wirken sich direkt auf die Ausführungsdauer von Transaktionen aus. Auch die Identikation der Hotspots sollte in die Analyse des Monitorings einieÿen, da sie wichtige Hinweise über die Stellen im System gibt, an denen eine Optimierung den gravierendsten Eekt hat. 48

65 4. Marktanalyse In diesem Kapitel werden einige auf dem Markt erhältliche Werkzeuge untersucht. Es wird getestet, wie gut sie sich für das fachliche Performance-Monitoring eignen. Die für diesen Zweck aufgesetzte Beispielanwendung, anhand derer die Werkzeuge getestet werden und die Gründe für die Wahl dieser Software sind in Abschnitt 4.1 aufgeführt. Die Anforderungen zur Auswahl der Werkzeuge sind in Abschnitt 4.2 festgelegt. Um die Qualität der Werkzeuge für das fachliche Performance-Monitoring bestimmen zu können, wurde ein Katalog an Bewertungskriterien erstellt. In Abschnitt 4.4 werden die einzelnen getesteten Werkzeuge beschrieben und bewertet. Die darauolgende Auswertung vergleicht die Werkzeuge untereinander. Die gewonnenen Ergebnisse werden am Ende dieses Kapitels zusammengefasst Die verwendete Beispielsoftware Für den Test der Werkzeuge wurde ein JBoss-Server aufgesetzt. Auf diesem Anwendungsserver läuft eine Bibliothekssoftware mit folgenden Anwendungsfällen: Mitglied registrieren Mitglied anmelden Buch suchen Buch ausleihen Buch zurückgeben Ausleihe verlängern Abbildung 4.1.: Anwendungsfalldiagramm der Beispielsoftware [61] 49

66 4. Marktanalyse Die Geschäftslogik des Servers ist als EJB3 Sessionbean [41] implementiert. Die Datenhaltungsschicht wird durch EJB3 Entity Beans realisiert. Java Server Faces (JSF )[48] wird für die Präsentationsschicht verwendet. Die Software wird mit openarchitectureware (OAW ) [38] generiert. Das Anwendungsmodell ist komplett in UML beschrieben. Die Anwendung ist in Form von Klassendiagrammen und einem Aktivitätsdiagramm dargestellt. Die Änderung der UML Modelle wird mittels MagicDraw durchgeführt. Die Ereignis-Handler des JSF reagieren auf die Aktionen des Nutzers und stoÿen die zugehörigen Maÿnahmen in der Geschäftslogik an. Dies geschieht durch einen Zugri via RMI auf die Sessionbean des Servers. Zugrie über RMI sind bei verteilten Systemen üblich. Die Beispielanwendung wurde aus dem Buch Modellgetriebene Softwareentwicklung entnommen, da eine Erstellung einer solchen Software nicht im Rahmen dieser Arbeit liegt. Diese Software ist ausreichend für den Test der Werkzeuge, da sie die Implementierung eines einfachen betrieblichen Informationssystems darstellt. Die geringe Komplexität des Systems erleichtert die Analyse des Monitorings für den Zweck der Marktanalyse. Da die Software generiert wird, kann die Integration des Monitoring auch im MDSD Umfeld durchgeführt werden. Abbildung 4.2.: Architektur der Beispielsoftware [61] 4.2. Anforderungen an die untersuchten Werkzeuge Der Markt bietet viele Werkzeuge für die Performancemessung von Software. Da keine Software unter der Bezeichnung fachliches Performance-Monitoring zu nden ist und auch kein Werkzeug in der Beschreibung explizit auf einen fachlichen Kontext hinweist, werden einige der vielen Standard Performancemessungswerkzeuge untersucht und es wird versucht, sie um die Integration des fachlichen Kontextes zu erweitern. 50