Java Magazin 06/08

Java Performance Tools, Teil 2

Autor:

Der Markt bietet viele Profiling-, Diagnose- und Monitoring-Werkzeuge, mit teilweise stark unterschiedlichen Funktionen. Der Artikel beleuchtet einige dieser Tools, zeigt deren Unterschiede auf und gibt Hinweise für die Auswahl geeigneter Tools.

Sobald Anwendungen für geschäftskritische Prozesse eingesetzt werden, ist die Performance und Verfügbarkeit eine wichtige nicht-funktionale Anforderung. Für die Sicherstellung der Performance im gesamten Lebenszyklus einer Anwendung, kommen unterschiedliche Tools zum Einsatz. Aber auch innerhalb der diversen Werkzeugkategorien gibt es große Unterschiede in der Funktionsweise und Bedienung. Ob und wie gut ein Werkzeug funktioniert, hängt nicht zuletzt auch von den Anforderungen an das Tool ab. Die nachfolgende Betrachtung unterschiedlicher Tools soll daher keinen „Sieger“ ermitteln, sondern unterschiedliche Ansätze und Funktionen beispielhaft beschreiben, um so die Auswahl und Bewertung von Performance-Werkzeugen zu erleichtern.

Im ersten Teil dieser Artikelserie zu Java Performance Tools [1] wurden die Grundlagen und Technologien beschrieben, die Basis fast aller hier erwähnten Werkzeuge sind. Die Java-Performance- Werkzeuge wurden anhand des Einsatzgebiets in die drei Kategorien Profiler, Diagnose- und Monitoring-Tools unterteilt. Im Folgenden sollen Funktionen und Anforderungen an diese Tools beschrieben und anhand von ausgewählten Produkten beispielhaft erläutert werden. Ziel ist nicht die Tools untereinander zu vergleichen oder Vor- und Nachteile aufzuzeigen, sondern die gebotenen Möglichkeiten moderner Performance- Werkzeuge zu beschreiben, um so eine anstehende Tool-Auswahl zu erleichtern.

JProfiler Call-Tree

Profiler

Der Profiler ist das Werkzeug für den Entwickler, um Performance- und Stabilitätsprobleme zu analysieren. Ein Profiler bietet Funktionalität um das Laufzeitverhalten und die Nebenläufigkeit einer Anwendung zu untersuchen sowie das Speicherverhalten im Bezug auf referenzierte Objekte und die Garbage Collection zu analysieren. Gerade bei der Analyse des Speichers wird durch Einsatz eines Profilers ein großer Overhead erzeugt, der außerhalb der Entwicklung nicht toleriert werden kann. Im Bereich der Performance-Analyse arbeiten Profiler heute auch mit Bytecodeinstrumentierung und bieten Optionen zur Reduktion des Overheads mithilfe von Filtern. Filter spezifizieren dabei, welche Methoden, Klassen oder Pakete instrumentiert werden sollen. Profiler arbeiten in der Regel auf der Basis von dedizierten Messungen und so genannten Snapshots. Diese Snapshots enthalten die relevanten Daten der Messung, können gespeichert und über die Benutzerschnittstelle der Profilers ausgewertet werden. Das Erzeugen eines Snapshot kann auf unterschiedliche Arten durchgeführt werden:

  • Manuell über die Benutzerschnittstelle des Profilers oder über ein Kommandozeileninterface
  • Mithilfe so genannter Trigger, Trigger Events, die das Starten und Stoppen einer Messung auslösen können. Ein Trigger kann der Eintritt oder das Verlassen einer Methode sein, aber auch ein Schwellwert, der erreicht wird. Erweiterte Funktionen bei Triggern wie bestimmte Aufrufparameter von Methoden oder die Aufrufhäufigkeit sind sinnvolle Funktionen, um Messungen detailliert steuern zu können. Trigger haben nichts zu tun mit Alerting-Funktionen wie sie im Montoring- Bereich verwendet werden.
  • Mithilfe einer API. Einige Profiler bieten eine eigene API an, mit deren Hilfe die Funktionen des Profilers gesteuert werden können. So lassen sich beliebige Messpunkte definieren und der Entwickler hat die maximal mögliche Flexibilität – allerdings muss bei dieser Variante der Sourcecode angepasst werden.
  • Mithilfe von Ant Tasks. Zur Automatisierung von Messungen bieten einige Profiler Ant Tasks an, mit deren Hilfe Messungen gestartet und gestoppt werden können. Meist arbeiten die Tasks in Kombination mit den oben genannten Triggern. Die Automatisierung innerhalb eines Continuous-Integration-[2] Build-Prozesses reduziert die Zeit für die Erhebung der Performance-Daten und etabliert den Profiling-Prozess innerhalb der Entwicklung am effektivsten.
  • Einige Profiler arbeiten auch in einem „always on“-Modus, das heißt, jede Aktion wird aufgezeichnet und der Benutzer kann größtenteils im Nachhinein entscheiden, welche Daten gespeichert werden sollen.

Neben diesen allgemeinen Funktionen ist auch die Integration in die Entwicklungsumgebung ein wichtiges Kriterium für die Auswahl eines Tools. Die meisten Profiler haben eine eigene Benutzerschnittstelle, bieten aber Integrationen in die IDEs, um z.B. die Startkonfigurationen von Eclipse automatisch zu übernehmen. Eine weitere mögliche Integration ist die Verlinkung der Sourcen, sodass von einem gefundenen Hotspot direkt an die richtige Stelle im Code gesprungen werden kann. Open Source Profiler wie Eclipse TPTP [3] oder Netbeans Profiler [4] sind hingegen Plugins für Ihre entsprechende IDE und somit vollständig integriert.

dynaTrace

Für die Laufzeitanalyse bieten die Profiler unterschiedliche Sichten an. Die gängigsten sind:

  • der Call-Tree, der die aufgerufenen Methoden in Abhängigkeiten der Aufrufhierarchie in einem Baum darstellt, um so die kritischen Pfade schnell identifizieren zu können. Abbildung 1 zeigt einen Call-Tree in JProfiler [5].
  • der Call-Graph, der die Aufrufe in einem gerichteten Graphen darstellt und so eine schnelle Analyse des kritischen Pfades erlaubt. Die Methodenliste, die alle Methoden in einer Liste darstellt, um diese dann nach den Hotspots sortieren zu können bzw. nach bestimmten auffälligen Parametern zu untersuchen.

Neben der Darstellung sind natürlich auch die erfassten Daten von besonderem Interesse. So bieten die meisten Profiler-Daten über die Durchlaufzeiten von Methoden an und unterscheiden zwischen Clock Time und CPU Time. Clock Time ist dabei die tatsächlich gemessene Durchlaufzeit der Methode und die CPU Time die Zeit in der die CPU für diese Methode gearbeitet hat. Clock Time abzüglich der CPU Time ist also die Zeit, in der die Methode auf andere Ressourcen gewartet hat. Neben diesen Daten bieten viele Profiler auch Daten über die GC-Zeit, die Anzahl erzeugter Objekte, Methodenparameter oder aber auch zusätzliche Informationen bezüglich bestimmter Technologien an. dynaTrace Diagnostics [6] arbeitet beispielsweise mit der PurePath-Technologie, die prinzipiell alle Daten eines Aufrufpfades zu einem definierten Eintrittspunkt sammelt. Der PurePath wird dabei auch über JVM-Grenzen hinweg erfasst und ermöglicht so Performance Messungen in verteilten, mehrschichtigen Architekturen. Neben Java wird auch .NET unterstützt, sodass auch die Interaktion zwischen diesen Technologien analysiert werden kann. Der PurePath selbst wird, wie in Abbildung 2 zu sehen ist, als Call Tree dargestellt und enthält neben den beschriebenen Daten auf Wunsch auch Informationen über Methodenparameter und Rückgabewerte, HTTP-Requestparameter, Header- bzw. Sessionattributwerte, SQL-Statement-Parameter oder die Größe serialisierter Daten bei Remote-Aufrufen. Mithilfe von so genannten Sensor Packs werden die erfassten Daten für bestimmte Technologien definiert und in das Tool integriert. dynaTrace Diagnostics liefert bereits eine große Anzahl Sensor Packs für die unterschiedlichsten Java-Technologien und Frameworks mit, ermöglicht aber auch die Erstellung eigener Sensor Packs. Um Synchonisations- und Deadlock- Probleme zu analysieren, benötigt man Informationen über Wait- und Synchronisationszeiten, die bereits bei der Laufzeitanalyse beschrieben wurden. Einige Profiler bieten aber auch erweiterte Analysefunktionen, um gerade diese Problemstellungen im Detail analysieren zu können. JProfiler bietet beispielsweise eine historische Übersicht über alle Threads inklusive deren Status (Runnable, Waiting, Blocked, Net I/O) über den Zeitverlauf. Mithilfe der Current- Monitor-Usage-Ansicht kann man sich einen schnellen Überblick über die Monitore machen, die Threads auf bestimmte Klassen halten und sieht dazu auch die Threads, die auf die Freigabe des Monitors warten. JProfiler zeigt zu den blockierenden und wartenden Threads auch die Stack Traces an, die zur synchronisierten Ressource geführt haben – so können die Synchronisierungsprobleme und Deadlocks schnell identifiziert werden.

JXInsight

JXInsight [7] verfügt beispielsweise zusätzlich über einen Timeline Graph, um so genannte „Concurrent Workload Patterns“ zu identifizieren. Abbildung 3 zeigt so ein Pattern in dem man zwei Phasen erkennen kann, in denen die Antwortzeit des Systems zeitweise sehr schlecht ist – erkennbar wird dies durch die roten Balken im oberen Teil der Grafik.

Im unteren Bereich werden die Requests inklusive der Updates (blaue Balken) und Selects (gelbe Balken) auf Datenbanktabellen dargestellt. Es wird schnell deutlich, dass der parallele Zugriff mehrerer Threads auf dieselbe Datenbankressource zu Table Locks geführt hat und so die erhöhten Antwortzeiten erklärt werden können.

Neben der Analyse von Laufzeiten und Nebenläufigkeit ist die Analyse des Speichers und der Garbage Collection eine wichtige Funktion von Profilern. Um so genannte Cycling Objects zu identifizieren, das heißt, ein hohes Aufkommen an temporären Objekten, die sich negativ auf die Garbage Collection auswirken, verfügen Profiler über die Möglichkeit, alle Objekte, die während einer Messung angelegt werden, aufzuzeichnen. Dabei wird in der Regel zwischen Objekten unterschieden, die von der Garbage Collection aufge- räumt wurden und denen, die sich noch referenziert im Speicher befinden. Profiler wie JProbe [8] und JProfiler bieten zudem die Möglichkeit, die Allocation Trees zu den erzeugten Objekten anzuzeigen – das heißt, man kann die Allocation HotSpots schnell im Code identifizieren. Um Java Memory Leaks zu identifizieren, benötigt man unterschiedliche Funktionen. Wichtig ist, dass man Memory Snapshots, die zu unterschiedlichen Zeitpunkten erzeugt wurden, vergleichen kann, um einen ersten Hinweis zu erhalten, welche Objekte auf dem Heap hinzugekommen sind. Der Overhead bei der Erfassung der Objekte auf dem Heap ist enorm, deshalb bieten die meisten Tools die Möglichkeit, Snapshots zu erzeugen, die keine Informationen über die Referenzen zwischen den Objekten haben. Mithilfe dieser Snapshots und der Möglichkeit, diese zu vergleichen, erhält man eine Liste möglicher Memory- Leak-Kandidaten. Um die genaue Ursache des Memory Leaks analysieren zu können, benötigt man einen Heapdump, der alle Objekte des Heaps inklusive der Referenzen zwischen den Objekten erfasst. Einige Tools bieten zudem die Möglichkeit auch die Inhalte der Objekte zu erfassen, sodass man Informationen ähnlich wie die in einem Debugger erhält. Neben der Analyse von Memory Leaks können mit diesen Tools auch die Größen von Objekten berechnet werden – dies ist z.B. hilfreich, wenn man genauere Daten über Session- oder Cache- Größen benötigt. Der Overhead für die Erzeugung eines Heapdump ist sehr hoch, sodass eine Analyse in produktiven Umgebungen meistens nicht möglich ist.

Wie im ersten Teil dieser Artikelserie beschrieben, bieten moderne JVMs die Funktion automatische Heapdumps zu erzeugen, wenn ein OutOfMemoryError auftritt. JProbe und JProfiler bieten die Mögichkeit, diese Heapdumps einzulesen (JProbe für IBM und JProfiler für Sun Hotspot) und in das Profiler-spezifische Format zu konvertieren. So lassen sich Memory Leaks aus dem Betrieb mit den Funktionen des Profilers analysieren. Es gibt verschiedene Methodiken und Herangehensweisen um Memory Leaks zu identifizieren. Die Profiler unterstützen meistens eine automatische Berechnung des Pfades zu den GC Roots, um die möglichen Referenzpfade, die ein Memory Leak verursachen, zu identifizieren. JProbe bietet mit dem Leak Doctor ein Tool an, das auf Basis verschiedener Algorithmen versucht, Memory Leaks zu identifizieren. Mithilfe der Common Parent Analysis wird z.B. analysiert, ob Objekte vom selben Typ gemeinsame Elternobjekte haben. Beispielsweise ist dies der Fall, wenn die Objekte in einem gemeinsamen Cache abgelegt sind und dieser noch die Referenzen auf die Cache-Einträge hält.

dynaTrace diagnostics zeigt Objektallokationen im beschriebenen PurePath an und erlaubt so Memory Leaks auf einzelne Aufrufe zurückzuführen. Die Objekte, die dabei erfasst werden sollen, werden über so genannten Memory Sensoren definiert.

JProbe

Diagnose

In der Qualitätssicherung wird mithilfe von Performance- und Lasttest-Tools getestet, ob eine Anwendung den Anforderungen an Antwortzeitverhalten, Durchsatz, parallele Benutzer und Stabilität gerecht wird. Dieser Test wird Blackbox-Test genannt, da die Ursachen für eine nicht erreichte Anforderung nicht analysiert werden können. Diagnosesoftware schließt diese Lücke und bietet die Möglichkeit auch unter Last Laufzeitanalysen, Nebenläufigkeit und Speicherverhalten zu analysieren. Im Gegensatz zu Profilern erfassen diese Werkzeuge weniger Details und beziehen zusätzliche Systemmetriken mit in die Messung ein. Der Overhead dieser Tools ist ein entscheidender Faktor, um die Lasttestergebnisse nicht zu verfälschen. Viele Hersteller geben den Overhead in Prozent an, wobei die angegebenen Werte nur schwer auf die eigene Umgebung übertragbar sind. Der Overhead eines Tools hängt stark von den eingestellten Filtern und der zu messenden Anwendung ab. Werden z.B. 80% der Antwortzeit eines Requests in der Datenbank verbraucht und die Bytecodeinstrumentierung einen Overhead von 10% erreicht, so sind nur 20% der Antwortzeit davon betroffen und der sichtbare Overhead liegt damit bei nur 2%. Werden allerdings Millionen von Methoden aufgerufen und diese alle erfasst, so ist der Overhead sicherlich sehr viel höher. Die Filter können bei einigen Tools zur Laufzeit angepasst und aktiviert werden, dabei kommt die Dynamic-Bytecode-Instrumentierung von Java 5 zum Einsatz. Neustarts der Systeme werden bei dieser Technologie minimiert. Neben dem Zeit- Overhead ist auch immer ein Speicher- Overhead vorhanden – das heißt, um Performance Overhead zu vermeiden, werden die gemessenen Daten von den meisten Tools im Speicher vorgehalten und in regelmäßigen Intervallen asynchron an den zentralen Datenserver versendet. Oft bedeutet deshalb ein geringerer Performance Overhead auch mehr Speicherverbrauch. Aus diesen Gründen ist es schwierig, Diagnose- und auch Monitoring-Tools im Bereich Overhead zu vergleichen – in der Realität kann nur ein Proof of Concept zeigen, ob ein Werkzeug in der speziellen Umgebung und für die eigene Anwendung geeignet ist und funktioniert.

Diagnosewerkzeuge arbeiten in den meisten Fällen auf Basis einer Agententechnologie. Dabei werden die zu testenden Systeme mit einem Agenten ausgestattet, die die Daten an einen zentralen Datenserver versenden. Die Agenten sind dabei nur die Datensammler, jegliche Verarbeitungslogik passiert auf dem Server. Die Auswertung der Daten erfolgt mithilfe eines eigenen Clients, der sich zum Datenserver verbindet und die angeforderten Daten grafisch zur Analyse aufbereitet. Bei den heute üblichen verteilten Architekturen ist es wichtig, dass Diagnosewerkzeuge JVM-übergreifend Daten erfassen, um Call-Graphen zusammenhängend analysieren zu können. In einer verteilten EJB oder Web-Service-Umgebung müssten die Daten sonst manuell zusammengeführt werden.

PerformaSure

Bei Diagnose-Tools sind zwei unterschiedliche Ansätze bei der Erfassung der Diagnosedaten zu finden. Die meisten Tools arbeiten mit statistischen Werten und erfassen so genannte Samples der eingehenden Requests. Die Daten werden dann in bestimmten Zeitintervallen aggregiert und entsprechende Minimal-, Maximal und Durchschnittswerte gebildet. Mithilfe dieses Verfahrens können die kritischen Requests, Klassen, SQLs und Methoden analysiert werden – einzelne Ausreißer können allerdings nicht identifiziert werden. Quest PerformaSure [9] ist ein typisches Beispiel für ein Diagnose- Tool, das auf diesem Verfahren basiert.

Der dynaTrace-Diagnostics-PurePath- Ansatz erfasst standardmäßig jeden einzelnen eingehenden Request. Mit diesem Verfahren lassen sich auch einzelne Ausreißer identifizieren. Mithilfe der Kontextdaten des PurePath (z.B. Request Parameter, Methodenparameter) kann zudem analysiert werden, von welchen Parametern der Ausreißer möglicherweise abhängt. Bei Regelverletzungen innerhalb eines PurePaths können zudem der gesamte betroffene PurePath oder auch PurePaths im Folgezeitraum zur Analyse archiviert werden.

Neben den Instrumentierungsdaten sind in der Diagnose aber auch weitere Daten wichtig, um mögliche Ressourcenengpässe zu analysieren. So sind z.B. Systemdaten (z.B. CPU, Memory, I/O), Application-Server-Statistiken (z.B. Datasourcen- und Threadpool-Auslastung) und JVM-Statistiken (z.B. Heap, GC, Threads) wichtig, um mögliche Engpässe zu identifizieren. PerformaSure erlaubt es beispielsweise, die gesammelten Metriken in Korrelation zu den Requestantwortzeiten zu stellen – so kann z.B. auf einen Blick eine Verbindung zwischen Auslastung einer DataSource und einer schlechten Antwortzeit hergestellt werden. Eine wichtige Funktion ist, dass die Ergebnisse an die Entwicklung weitergeben werden, damit identifizierte Probleme schnell analysiert und beseitigt werden können. dynaTrace Diagnostics ermöglicht die Speicherung jedes einzelnen Pure- Path. Dieser kann von den Entwicklern geöffnet werden und mithilfe eines Eclipse Plug-ins direkt in die Sourcen verlinken. So kann das Problem eines Ausreißers oder schlechter Antwortzeiten schnell identifiziert werden. Vorteil dieses Ansatzes ist, dass ein Problem auch ohne Reproduktion in der Entwicklungsumgebung analysiert werden kann. PerformaSure nutzt eine Integration mit JProbe für die Kommunikation mit der Entwicklung. Für kritische Klassen oder Pakete können direkt Launcher- Dateien (Parameterinformationen) für JProbe exportiert werden, die entsprechende Filter enthalten, um das Problem im Profiler zu analysieren. Monitoring Im Bereich der Monitoringwerkzeuge findet man ganz unterschiedliche Ansät- ze und Architekturen. Grundlegend kann man aber Tools unterscheiden, die einen End-To-End-Monitoring-(Quest Foglight 5 [10], IBM ITCAM [11]) Ansatz haben und Tools bei denen die Java-Plattform als zentrale Integrationskomponente heutiger Anwendungen überwacht wird (CA/Wily Introscope [12], dynaTrace Diagnostics). End-To-End-Monitore überwachen nicht nur Java sondern auch andere Systemkomponenten wie Netzwerkinfrastruktur, Datenbank, SAP, Siebel bis hin zu Mainframe Anwendungen unter CICS oder IMS. Vorteil dieses Ansatzes ist, dass Probleme in der gesamten Infrastruktur erkannt werden können. Foglight 5 ermöglicht es, zusätzlich zu den unterstützen Systemen, eigene Agenten zu schreiben und diese in die Monitoring-Infrastruktur zu integrieren. So lassen sich z.B. selbst entwickelte C++ Server in das Monitoring integrieren. Die Java Monitoring Tools konzentrieren sich auf die Java-Komponenten und integrieren sich in Monitoring- Infrastrukturen wie Tivoli oder HP OpenView über das Simple-Network- Management-Protokoll (SNMP) oder stellen Ihre Daten über andere Schnittstellen bereit. Java-Monitoring-Lösungen müssen im Prinzip zwei primäre Anforderungen erfüllen:

  • Überwachung und Protokollierung des Betriebs
  • Fehleridentifikation und Analyse

Gerade in Umgebungen, in denen geschäftskritische Anwendungen betrieben werden, ist es wichtig eine lückenlose Überwachung des Systems gewährleisten zu können. Fällt ein System aus, so muss der Administrator dies möglichst vorher erkennen können und bei einem Ausfall sofort informiert werden. Hierfür bieten Monitoring Tools unterschiedliche Funktionen an. Mithilfe so genannter Dashboards kann der Status des Systems visuell angezeigt werden. Dabei funktionieren die Dashboard nach einem Drill-down- Prinzip. Auf oberster Ebene werden die Anwendungen oder Server angezeigt und der Status des Systems nach dem Ampelprinzip dargestellt. (grün: alles in Ordnung, gelb: kritisch, rot: sehr kritisch oder Ausfall) Auf Basis der gesammelten Daten, kann der Status einer Komponente konfiguriert werden. So könnte man z.B. definieren, dass ein System grün ist, wenn die CPU-Auslastung < 70% ist, gelb zwischen 70% und 90% und ab 90% rot. Diese so genannten Threshholds oder Incidents können bei den meisten Tools auch auf Antwortzeiten von Transaktionen oder Requests festgelegt werden. Die Dashboards sind hierarchisch aufgebaut, sodass die oberste Ebene immer den kritischsten Zustand einer Unterkomponente annimmt. Wird ein System rot oder gelb, kann der Administrator über die Dashboards tiefer ins Detail gehen, bis er die kritische Komponente identifiziert hat. Die Dashboard-Technologien sind völlig unterschiedlich, Wily Introscope setzt auf einen Java Client, während Foglight 5 eine moderne, AJAX-basierte Weboberfläche anbietet (Abb. 6). Beide Tools ermöglichen die Erstellung eigener Dashboards per Drag&Drop. Mithilfe dieser Funktion können auch “Business Dashboards” erzeugt werden, die Statistiken für das Management aufbereiten. So genannte Derived Metrics ermöglichen dem Ad- ministrator in Foglight 5 zudem aus unterschiedlichen Metriken neue Metriken abzuleiten, die beispielsweise für eine Trendanalyse verwendet werden können. Auf Basis der Metriken und Incidents, erlauben es die meisten Monitoring-Tools- Aktionen zu steuern. Diese Aktionen können z.B. eine E-Mail oder SMS versenden, wenn ein bestimmter kritischer Status erreicht wird. In bestimmten Fällen kann aber auch aktiv auf den Status reagiert werden. So könnte z.B. ein zusätzlicher Server automatisch gestartet werden oder eine weniger wichtige Anwendung gestoppt werden, damit eine höher priorisierte Anwendung störungsfrei weiterlaufen kann.

Foglight 5

Im Bereich Monitoring ist zudem die Dauer der Datenhaltung wichtig. Monitoring- Daten müssen in der Regel über Monate hinweg vorgehalten werden – nur so kann eine Trendanalyse funktionieren. Zudem werden im Betrieb häufig Service Level Agreements (SLA) mit dem Auftraggeber vereinbart. Monitoring Tools können die-se SLAs überwachen und entsprechende SLA Reports generieren. Die Datenhaltung kann in den meisten Fällen nicht dauerhaft ohne Datenaggregation erfolgen – die Datenmenge würde einfach zu groß werden. Deshalb werden die Monitoring- Daten stufenweise aggregiert. So werden beispielsweise alle Details für 24 Stunden gespeichert, um sie dann innerhalb konfigurierbarer Zeitintervalle zusammenzufassen. Je älter die Daten, desto größer wird dieses Zeitintervall. Es ist wichtig, dass Monitoring Tools in diesem Bereich eine hohe Flexibilität erlauben, um z.B. auch einzelne Werte oder Anwendungen unterschiedlich behandeln zu können.

Neben diesen Funktionen bieten einige auf Java spezialisierte Monitoring-Lösungen auch Funktionen für die Diagnose von Fehlern und Performance-Engpässen während des Betriebs an. dynaTrace Diagnostics erfasst beispielsweise den Pure- Path von jedem eingehenden Request beziehungsweise Java- und .NET-Aufruf und liefert dazu die beschriebenen Daten der Sensoren. Dieser hohe Detailgrad reduziert die Zeit bis zur Fehlerbehebung dramatisch. Jede Exception und jeder Error Log Eintrag wird von den Sensoren erfasst und inklusive des passenden Pure- Path gespeichert. Das bedeutet, dass bei einem Fehler in der Produktion der entsprechende PurePath vom Betrieb an die Entwicklung weitergegeben werden kann. Der PurePath enthält den gesamten Call Tree des entsprechenden Aufrufs inklusive der Request- und Methodenparametern, sodass eine Reproduktion des Fehlers einfach möglich ist – ohne diese Technologie erfordern solche Fehler oft Tage, um in der Entwicklung nachgestellt zu werden. Gleiches gilt für Performanceoder Ressourcenengpässe – die PurePathes der entsprechenden Aufrufe werden alle einzeln erfasst und können Online oder Offline analysiert werden.

CA Wily Customer Experience Manager und Foglight End User Management sind Beispiele für Speziallösungen im Bereich Monitoring, um das Antwortzeitverhalten einer Anwendung aus Sicht der Benutzer zu messen. Gerade diese Daten liefern wichtige Informationen, ob geschäftskritische Prozesse reibungslos bearbeitet werden können. Beide Tools bieten zudem die Möglichkeit, die angezeigten Webseiten der Benutzer zu speichern, um diese dem Support bereitzustellen. Mithilfe synthetisch erzeugter Transaktionen kann so aber auch sichergestellt werden, dass die Anwendung die geforderten SLAs aus Sicht der Anwender erfüllt.

Die verschiedenen Ansätze der Tools zeigen, dass die Anforderungen der wichtigste Treiber für die Auswahl eines Monitoring Tools sind. Oftmals deckt ein einziges Tool nicht alle Anforderungen ab, sodass eine Kombination aus verschiedenen Monitoring Tools gewählt werden muss.

dynaTrace

Fazit

Der Artikel hat einen kurzen Überblick über die Funktionen der Profiler, Performance- Diagnose- und Monitoring-Tools gegeben. In Umgebungen, in denen geschäftkritische Anwendungen entwickelt, getestet und betrieben werden, sind diese Tools wichtig. Sie helfen im Falle von Performance- Engpässen, Stabilitätsproblemen oder Produktionsfehlern, schnell eine Lösung für das Problem zu finden. Vor allem vermeiden die Werkzeuge ein unnötiges Finger-pointing zwischen den unterschiedlichen Organisationseinheiten, weil die Blackbox-Java-Anwendung für alle Beteiligten verständlicher wird.

Links & Literatur

[1] Mirko Novakovic, Marc van den Bogaard: Java Performance Tools, Teil 1, in Java Magazin 12/2007

[2] Continuous Integration: martinfowler.com/ articles/continuousIntegration.html

[3] Eclipse TPTP: www.eclipse.org/tptp/

[4] Netbeans Profiler: www.netbeans.org/products/ profiler/

[5] JProfiler: www.ej-technologies.com/products/ jprofiler/overview.html

[6] dynaTrace Diagnostics: www.dynatrace.com

[7] JInspired JXInsight: www.jinspired.com/

[8] Quest JProbe: www.quest.com/jprobe/

[9] PerformaSure: www.quest.com/performasure/

[10] Quest Foglight: www.quest.com/foglight/

[11] IBM Tivoli Composite Application Manager: www.ibm.com/software/info/tivoli/itcam/de

[12] CA Wily Introscope: www.wilytech.com/ solutions/products/Introscope.html

Zurück zu den Publikationen

Vollständiger Artikel