Mehr aus IT-Anwendungen herausholen

Application Performance Management

Stefan Berreth

Geschwindigkeit ist im Internet Trumpf. Wenige Mausklicks genügen – und Reisen, Bücher und Dienstleistungen wechseln den Besitzer. In der Praxis jedoch vergrault so manche Website potenzielle Kunden durch lange Antwortzeiten und Fehlermeldungen beim Bestellvorgang. Oft geschieht dies unbemerkt von den Administratoren, denn im Java-Code stecken keine allzu offensichtlichen Fehler. Wenn Dienste nicht performant, unzuverlässig und fehlerhaft sind oder gar komplett ausfallen, entstehen schnell immense Kosten für den Geschäftsbetrieb. Das zu verhindern ist nicht einfach, und mit der steigenden Komplexität von Webanwendungen und IT-Umgebungen wird diese Aufgabe nicht einfacher. Um komplexe, geschäftskritische Systeme erfolgreich im Griff zu behalten, kann Application Performance Management von zentralem Nutzen sein.

Application Performance Management (APM) ist dabei nicht mit System-Management im herkömmlichen Sinne gleichzusetzen. Unter einem End-to-End-System-Management versteht man grundsätzlich die zentralisierte Verwaltung der gesamten IT-Infrastruktur. APM hingegen überwacht speziell die Qualität der Benutzertransaktionen aus Sicht des Application Layer und beantwortet die Frage, welche Komponenten einen Transaktions-Request annehmen, welche Wege die Transaktionen innerhalb der Java Virtual Machine (JVM) nehmen, welche Backend-Systeme mit welchen Transaktionen und Ausführungsszeiten von der JVM aus angesprochen werden und wo Probleme, Engpässe oder Fehler auftreten. Wichtig ist, welche Ressourcen dabei verbraucht werden und wann, wie häufig und warum das passiert. Dabei ist das Zusammenspiel der einzelnen Java EE-Komponenten innerhalb einer einzigen oder mehrerer JVMs genauso wichtig wie das Verhalten der eingebundenen Backend-Systeme aus der Sicht der Applikation.

Die wirklich schwierig einzugrenzenden Probleme in Produktionsumgebungen sind diejenigen, die nur unter echtem Benutzerverhalten, sprich: bei dauerhaften und vielen gleichzeitigen Zugriffen mit hoher Last und mit echten Produktionsdaten, auftreten. Es ist eine echte Herausforderung, die dazu nötige Sichtbarkeit im Produktionssystem mit minimalem Overhead zu gewinnen. Zwar lässt sich durch sorgfältige Arbeit im Integrations- und Lasttestsystem eine gewisse Annäherung an das echte Produktionssystem herstellen, aber selbst wenn dort lastinduzierte Fehler auftreten, lassen sich diese ohne die entsprechende Einsicht ins System nicht eingrenzen. Am Ende muss sichergestellt sein, dass das echte System, das den Dienst tatsächlich liefert, fehlerfrei und performant läuft. Es nützt nichts, wenn Test-Scripts mit Testdaten auf QA-Systemen erfolgreich laufen, jedoch der echte Benutzer eines wichtigen Dienstes eine schlechte Qualität erhält.

Entworfene Test-Scripts in produktionsnah abgebildeten QA-Systemen sind unentbehrlich, wenn es um die Lösung und Identifizierung möglichst vieler Probleme vor einem Produktionsgang eines Software-Releases geht. Jedoch können sie per Definition nur solche zu Tage fördern, die im QA-System mit QA-Daten im Backend und QA-Scripts auftreten. Es gibt immer einen oftmals nicht unbeträchtlichen toten Winkel zwischen echtem Benutzerverhalten, echten Produktionsdaten und der tatsächlichen Produktionsumgebung, der von allen Tests in QA nicht erfasst wird. Dieser Bereich wird erst in der Produktion, während echter Benutzertransaktionen, sichtbar. Deshalb darf, so wichtig sie ist, die Überwachung und Messung der Qualität also nicht bei der QA aufhören, sondern muss über die Integrations- und Lasttest-Umgebung hinaus bis in die Produktion erfolgen.

Bei vielen Arten von Webanwendungen kommt es auf die Performance der echten Benutzertransaktionen an. Im Optimalfall lässt sie sich rund um die Uhr und bis auf die Methodenebene einsehen. Dazu gehört der Zugriff auf historische Daten, ohne das System zu destabilisieren und einen minimalen Overhead zu garantieren.

Wann braucht man Application Performance Monitoring?

Es gibt eine Reihe von charakteristischen Anzeichen in IT-Projekten, die auf fehlendes APM hindeuten. Typisch ist beispielsweise, dass Application-Support-Teams nur noch reaktiv handeln, also von Problem zu Problem stolpern und eine Art „Brandherdbekämpfung“ betreiben. Ab diesem Zeitpunkt gibt es keine sinnvolle Priorisierung mehr, alles hat höchste Wichtigkeit.

Performance-Einbrüche oder -Ausfälle treten aus heiterem Himmel auf. Oft gibt es keine Erklärung für das Problem, und niemand kann eine genaue Aussage treffen, wie lange es dauern wird, bis ein Fehler behoben ist. Fast skurril mutet es an, dass die Teams, die darauf spezialisiert sind, solche Probleme zu beheben, nach außen hin mehr und mehr inkompetent erscheinen. Und das völlig unabhängig davon, wie erfahren die Teams sind.

Von außen betrachtet erscheinen die Ressourcen, die für die Problemlösungsversuche in Anspruch genommen werden, verschwendet oder zumindest ineffizient zu sein. Bei andauernden Problemen verhärtet sich deshalb im Management oft die Einschätzung, dass die IT-Abteilung nicht in der Lage ist, die Probleme in den Griff zu bekommen. Der Druck auf die Projektteams steigt, und es kommt häufig zum so genannten Blame Game oder Finger Pointing zwischen Mitarbeitern des Projekt-Teams oder ganzen Abteilungen: Jeder beschuldigt den anderen.

Die Ursache der gerade skizzierten Dynamik resultiert aus der mangelnden Sichtbarkeit dessen, was tatsächlich bei den Benutzertransaktionen auf Applikationsebene passiert. Und das gilt nicht nur für die Produktionsumgebung, sondern auch für Lasttests und Integration. Viele der in der Produktion auftretenden Probleme würden bei entsprechender Sichtbarkeit in der Lasttest- und Integrationsumgebung entdeckt werden, bevor das System in Produktion geht.

Performance-Daten aus Applikationen gewinnen

Wie erhält man also detaillierte Performance-Daten aus einer Applikation? Generell gibt es drei Ansätze: Logging, Profiling und Bytecode-Instrumentierung.

  • Logging: Logging-Daten erhält man, indem man entsprechende Log-Einträge in den Sourcecode der Applikation einfügt. Üblicherweise werden dazu Frameworks wie log4j benutzt. Logging ist im Allgemeinen sehr flexibel, weil man praktisch über alles, was an der Stelle des Log-Codes erreichbar ist, Log-Einträge schreiben kann. Logging ist vor allem wegen seiner Flexibilität beliebt, weshalb es auch gerne bei der Entwicklung beziehungsweise in der Kommunikation zwischen QA und Development beim Debugging von funktionalen Fehlern eingesetzt wird. Logging ist zwar technisch grundsätzlich in der Lage, Performance-Daten zu erheben, eignet sich hier aber nicht besonders gut. Zum einen muss immer der Sourcecode geändert werden, wenn man einen anderen Parameter einsehen will. Das bedeutet in der Folge, dass erst ein kompletter Zyklus von QA und Integration durchlaufen werden muss, um solche Änderungen zu sehen. Weiterhin lässt sich nur aus den Programmteilen loggen, zu denen man auch den Sourcecode hat. Wenn man betrachtet, wie viele Codezeilen, die man nicht im eigenen Sourcecode Repository aufgelistet hat, auf dem Stack liegen, wird schnell klar, auf was man per Logging eben keinen direkten Zugriff hat. Nicht zu vergessen sind außerdem die nicht unerheblichen I/O-Kosten, die ausgiebiges Logging mit sich bringen kann.
  • Profiling: Entsprechende Tools nutzen zum Profiling die von der JVM angebotenen Interfaces, wie zum Beispiel JDK 1.4 JVMPI oder JDK 1.5 JVMTI. Darüber hinaus werden umfassende Messdaten über die Ausführung der Applikation in der JVM ausgelesen: Ausführungszeiten aller Methoden, CPU-Zeit von Methodenaufrufen, der gesamte Referenzbaum im Heap, Speicherverbrauch der Objekte und Details über die Garbage Collection. Der Vorteil liegt auf der Hand: Man erhält umfassende Informationen und Details über den Speicherverbrauch. Der Nachteil liegt in riesigen Mengen an Informationen, die in der Regel einen immensen CPU- und RAM-Overhead zeigen und eine Destabilisierung der JVM mitbringen. Folglich eignen sich Profiler für funktionales Debugging im Development und QA hervorragend, während sie für den Einsatz bei lastabhängigen Performance-Analysen mit hoher Concurrency und Last in Integrationsumgebungen und Produktion wegen der starken Nebenwirkungen nicht ratsam sind.
  • Bytecode-Instrumentierung (BCI): hat sich in den vergangenen Jahren als der Ansatz der Wahl etabliert, um ohne Destabilisierung bei minimalem Overhead eine größtmögliche Sichtbarkeit im Produktionsbetrieb zu erhalten. Haftete BCI in der Vergangenheit oft noch ein etwas verwegenes Image an, weil damit der Bytecode der Klassen erweitert wird, ist BCI mittlerweile per JSR 163 in Java 5 standardisiert und hat sich in der Praxis überall durchgesetzt, sodass damit auch professionelles Application Performance Management betrieben werden kann. Was kann mit Bytecode-Instrumentierung dargestellt werden? Im Wesentlichen ist es alles, was auch per Logging oder Profiling dargestellt wird, allerdings ohne die Manipulation der JVM per JVMPI. Typische Performance-Metriken, die man per BCI erhält, sind durchschnittliche Antwortzeiten von Methoden, Invocation Rate, Concurrent Invocation Counter oder Stalled Thread Counter, um nur einige zu nennen. Der Vorteil von BCI ist, dass praktisch alles im Produktionssystem transparent abgebildet wird – selbst die Komponenten, zu denen der Sourcecode nicht bekannt ist. Weil BCI auf der Bytecode-Ebene ansetzt, ist es vollkommen plattformunabhängig, immerhin muss jede spezifikationstreue JVM den Bytecode gleich korrekt ausführen. BCI funktioniert deshalb auf nahezu allen Plattformen auf die gleiche Art – von Windows über Linux, Solaris, AIX, HP UX bis zu AS 400, z/Linux und z/OS. Richtig implementiert bietet BCI Sichtbarkeit bis auf Methodenebene bei minimalem Overhead – und das alles, ohne die Ausführung zu destabilisieren. Der größte Nachteil von BCI ist, dass man ohne weiteres keine Informationen über den absoluten Speicherverbrauch einzelner Objekte erhält.

Welcher Application-Performance-Management-Ansatz ist nun der beste? Das kommt ganz auf die Anforderungen des Unternehmens an. Welche Performance-Management-Ziele hat das Unternehmen aufgestellt? Kann man überall da, wo man Einsicht in die Applikation nehmen möchte, den Sourcecode modifizieren? Wie viel Overhead ist akzeptabel? Welche Datenmengen werden durch einen Ansatz generiert, und wie findet man sich in den gesammelten Daten zurecht und behält den Überblick?

BCI für tiefe Sichtbarkeit in Produktionssystemen

Wenn ein Unternehmen auf tiefe Sichtbarkeit im Application Layer in Produktionssystemen angewiesen ist, kommen BCI-basierte Application-Performance-Management-Produkte mit ihrem Visibility/Overhead-Verhältnis in Betracht. Das IT-Team sollte sich vorher bei Anbietern von Application-Performance-Management-Lösungen informieren, ob das gewählte APM-Tool einen echten Mehrwert bietet. Allzu häufig werden in vermeintlichen APM-Tools schlichtweg Application-Server-Daten oder über für Produktionssysteme unbrauchbare Development-Schnittstellen wie JVMPI oder JVMTI ausgelesen, die bereits in der Konsole des Application Server vorgelegen hätte. Bevor man sich für ein Tool entscheidet, sollte man sich deshalb unbedingt im eigenen System an der eigenen Software den Mehrwert vorführen lassen. Nicht selten werden in den PowerPoint-Slides Dinge versprochen, die sich in der Praxis als wenig stichhaltig erweisen.

Kostenersparnis mit Application Performance Management

Nicht selten rechnet sich eine Investition in APM schon dadurch, dass Hardware durch entsprechende Optimierung effizienter genutzt wird und anstehende IT-Investitionen niedriger ausfallen oder erst deutlich später anfallen. Allgemein ist der Einsatz eines APM-Tools immer dann sinnvoll, wenn es darum geht, komplexe und geschäftskritische Dienste zuverlässig zu betreiben. Ist die Applikation nicht komplex, können mögliche Performance-Probleme durch Profiling in der Entwicklungsumgebung behoben werden. Ist die Anwendung nicht geschäftskritisch, ist es nicht zwingend notwendig, sie performant und verfügbar zu halten. Erst wenn sie komplex und geschäftskritisch ist, lohnt sich APM.

Die indirekten und direkten Einsparungen können dabei mitunter beträchtlich sein. Indirekte Einsparungen ergeben sich dadurch, dass kritische Situationen, in denen die Applikation nicht oder nicht erwartungsgemäß läuft, deutlich weniger häufig auftreten beziehungsweise erheblich kürzer Mitarbeiter-Ressourcen binden als ohne APM. Die Projektrisiken werden verringert und wieder kalkulierbar. Darüber hinaus gibt es nicht selten konkrete, direkte Einsparungen, wenn in irgendeiner Art und Weise nutzungsabhängige Betriebskosten gesenkt werden können. Zwei Beispiele aus der Praxis sollen dies kurz verdeutlichen:

Nachdem eine führende europäische Versicherungsgesellschaft eine APM-Lösung eingeführt hat, verkürzte sich die durchschnittliche Problem-Bearbeitungszeit um 10 bis 20 Prozent. In einem anderen Fall waren rund 800 Sachbearbeiter regelmäßig für Stunden von ihrer Applikation ausgeschlossen, da eine Anmeldung aufgrund von Timeouts nicht mehr möglich war. Eine Analyse des Systems hat in kurzer Zeit gezeigt, dass hier lediglich ein Konfigurationsproblem vorlag und das Problem vor Feierabend noch gelöst werden konnte. Erst ein Einblick in das laufende Produktionssystem hat diese Analyse ermöglicht. Eine genaue Angabe, welche Kosten 800 Sachbearbeiter erzeugen, die arbeitsunfähig sind, ist leider nicht möglich, allerdings verliert ein Unternehmen dadurch bares Geld.

In einem weiteren Fall betreibt eine führende deutsche Bank eine der weltweit größten WebSphere-Installationen. Durch die Einführung von Application Performance Management konnten die anfallenden Mainframe-Kosten dramatisch reduziert werden. Unnötig lang laufende Einzeltransaktionen konnten sofort konkret identifiziert werden. Allein durch die Identifizierung eines CPU-hungrigen JSPs wurde der Ressourcenverbrauch der Applikation um 25 bis 30 Prozent reduziert. Als direkte Folge davon konnte das Unternehmen seinen Verbrauch an CPU-Sekunden entsprechend reduzieren, was zu einer Ersparnis von schätzungsweise 150.000 bis 200.000 Euro pro Monat geführt hat. Durch die kontinuierliche Ermittlung und Bereitstellung solcher Daten können nun auch schneller Aussagen über die Effizienzsteigerung von Architekturänderungen getroffen werden, als dies bisher möglich war. Ebenso werden Testszenarien (Use Cases) und Ähnliches jetzt näher an die Wirklichkeit gebracht und damit Tests effektiver und aussagekräftiger.

Fazit

Application Performance Management zahlt sich oft sehr schnell aus, wenn es bei komplexen, geschäftskritischen Applikationen angewendet wird. Wenn Unternehmen darüber hinaus ihre Prozesse von einem rein reaktiven Performance-Management hin zu einem proaktiven Performance-Management entwickeln, können kritische Ausfälle oder Performance-Einbrüche in Produktionssystemen im Idealfall ganz vermieden und die Qualität des Dienstes mit kalkulierbaren Kosten und Risiken erreicht werden.

Stefan Berreth ist Presales Consultant bei CA | Wily Technology Division. Mit seiner mehr als 10-jährigen Erfahrung im IT Sektor in den Bereichen Entwicklung, Systemintegration, Presales Consulting und Business Development ist er zurzeit in verschiedene Accounts in EMEA zuständig für den Bereich Application Performance Management. Kontakt: stefan.berreth at ca.com.
Geschrieben von
Stefan Berreth
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.