Application-Performance-Management
Dem System geht es doch gut!
Die Webifizierung der Anwendungen in Unternehmen erfordert einen neuen Ansatz im Performance-Management. IT-Teams benötigen den Überblick über die End-to-End-Transaktionen. Nur dann sind sie in der Lage, eine hohe Service-Qualität sicherzustellen.
Der Endanwender vor dem Bildschirm verhält sich nicht anders als jeder Autofahrer: Wenn die
Anwendung respektive das Auto unzureichend funktioniert oder aus einem ersichtlichen Grund
ausgebremst wird, reagieren beide mit Stress. Eine Studie, die CA in Zusammenarbeit mit Foviance –
einem führenden Consulting Unternehmen im Bereich Kundenerfahrung – durchgeführt hat, belegt den "
Web-Stress" beim Versuch eines Online-Einkaufs nachdrücklich. "Konsumenten haben hohe Erwartungen
in Bezug auf Web-Anwendungen und Websites – diese müssen immer verfügbar sein und sofort reagieren"
, so Verhaltenspsychologin Catriona Campbell, Direktorin und Gründerin von Foviance. Die im Rahmen
des Experiments durchgeführten Gehirnwellenanalysen zeigten, dass die Teilnehmer sich bei der
Benutzung von schlecht funktionierenden Websites bis zu 50 Prozent mehr konzentrieren mussten.
Niemand muss über prophetische Gaben verfügen, um jetzt folgern zu können, dass dies schlecht
für das Geschäft ist. Denn die Reaktionen auf zu lange Lade- oder Antwortzeiten sowie
Fehlermeldungen beim Aufruf bestimmter Funktionen und Transaktionen spüren die Administratoren
tagtäglich. Ein sarkastischer Ausbruch – "Klasse! Ich wollte mir eh gerade einen Kaffee holen!" –
zählt da noch zur mildesten Kritikform seitens der Endanwender. Neben dem Imageproblem droht der
wirtschaftliche Verlust – sei es durch Strafzahlungen aufgrund der vertraglich zugesicherten, nun
nicht eingehaltenen SLAs (Service Level Agreements), sei es wegen ausbleibender Bestellungen im
Web-Shop.
Das Aufspüren der Störungsursache ist schwierig. Denn in der Natur Web-basierender Anwendungen
liegt die starke Vernetzung, die sich vom Client-System des Endanwenders über Router und Firewalls
des Netzwerkzugangs bis zu den Anwendungs-Frontends (Web-Server und Portal) und den beteiligten
Backend-Anwendungen einschließlich Middleware spannt. Performance-Probleme können auf der gesamten
Bearbeitungsstrecke auftreten. Dabei muss nicht einmal die einzelne beteiligte Komponente gegen die
Vorgaben in Bezug auf Leistung oder Verfügbarkeit verstoßen. Im Zusammenspiel werden dagegen sehr
wohl SLAs gefährdet, wie sich durch Berechnen der Ausfallwahrscheinlichkeit (Multiplizieren der
Verfügbarkeitsraten der Einzelkomponenten) schon theoretisch belegen lässt.
In der Praxis folgt auf die Beschwerden der Anwender häufig die wechselseitige Schuldzuweisung
zwischen IT-Mitarbeitern: Jeder macht die Komponente des jeweiligen anderen für das Problem
verantwortlich. Eine solche Reaktion ist zwar menschlich verständlich, löst jedoch nicht das
Problem und ändert nichts an der wachsenden Verstimmung des Endanwenders. Allerdings muss keine
bestimmte Hardware oder Software für die Störung verantwortlich sein. Sie kann einfach aufgrund
einer nicht aufeinander abgestimmten Konfiguration im Gesamtsystem eintreten.
Im Klartext: Die Administratoren benötigen Echtzeitinformationen über Applikations- und
Transaktionsleistung, um Probleme rasch zu erkennen und zu priorisieren. Für den Fall einer Störung
müssen leistungsstarke Diagnose- und Analysemöglichkeiten bereitstehen, um die Ursache(n) schnell
zu ermitteln. Besser noch: Eine Rund-um-die-Uhr-Überwachung des Produktivbetriebs sollte bereits im
Vorfeld potenzielle Engpässe identifizieren, um so unerwartete SLA-Verletzungen vermeiden zu
helfen. Das Ziel ist daher ein Anwendungs-Performance-Management (APM), das die 360-Grad-Sicht auf
End-to-End-Transaktionen, Infrastruktur und Anwendungen unterstützt.
Dieser Anspruch reicht natürlich über die Möglichkeiten traditioneller Management-Werkzeuge mit
ihrer isolierte Sicht auf die einzelnen Elemente einer komplexen Netzanwendung weit hinaus.
Gleiches gilt für Tools, die mittels aktiver Agententechnik am Desktop (Roboter) in regelmäßigen
Abständen simulierte Transaktionen auslösen. Dieses synthetische Black-Box-Messverfahren, das gerne
als End-to-End-Management angepriesen wird, spiegelt weder die reale Kundenerfahrung vollständig
wider, noch bietet es einen Hinweis auf die exakte Fehlerquelle im Störungsfall. Sein Einsatz
empfiehlt sich, um in ruhigeren Geschäftszeiten Performance- und Verfügbarkeitstests für eine
Web-Anwendung durchführen – zum Beispiel im Fall von Applikations-Upgrades. Ein solcher Ansatz ist
hilfreich, reicht aus den genannten Gründen jedoch nicht, um die zuverlässige Bereitstellung der
Onlineanwendungen zu garantieren. Ebenso wenig bietet er einen Ausweg aus dem skizzierten
Schwarze-Peter-Spiel.
Ein belastbares APM muss im Kern zwei Eigenschaften aufweisen: Es verfolgt zum einen auf
Anwenderseite das Prinzip des Customer-Experience-Managements (CEM), die Messung der Leistung
aufgerufener Transaktionen und Services aus Nutzersicht. Zum anderen erhellt es die Black Box,
indem es gezielt Informationen über das Zusammenspiel der Komponenten einer Applikation von innen
heraus ermittelt und dabei die tatsächlich ablaufenden Transaktionen misst.
Idealerweise ist CEM in Form einer (passiven Agenten-)Appliance realisiert, die schicht den
HTTP/HTTPS-Verkehr und den anwendungsbezogenen TCP-Datenstrom überwacht. Die Appliance arbeitet
direkt hinter der Firewall, um die tatsächlich vorgenommenen Transaktionen auf Anwenderseite in
Echtzeit "mitzulesen" und auszuwerten. Nach dem Ampelprinzip kann so anzeigt werden, ob alles
(noch) im grünen Bereich ist. In dem Augenblick, in dem sich etwas verlangsamt oder eine Funktion
hakt, erhält der Administrator eine Benachrichtigung und kann eingreifen, bevor gravierende
Störungen des Betriebs auftreten. Probleme lassen sich dabei nach betriebswirtschaftlicher
Bedeutung priorisieren.
Um nun bei der Problemlösung gegenseitige Schuldzuweisungen zu unterbinden, ist es erforderlich,
das Innenleben der Produktionsumgebung zu kennen. Das APM steht deshalb vor der Herausforderung,
aus Sicht der Anwendungsebene durchgängige Transparenz zu schaffen: Welche Komponenten der
vernetzten Java- und Dotnet-Anwendungen des Web-Produktivsystems haben den Transaktions-Request
angenommen? Über welche Route liefen die Transaktionen innerhalb der JVM (Java Virtual Machine)
oder der CLR (Common Language Runtime)? Wie beeinflussen Backend-Anwendungen, Datenbanksysteme etc.
die Ausführungszeiten? Unter welchen Bedingungen treten Engpässe oder Fehler auf?
Aus den genannten Gründen ist es entscheidend, stets das Zusammenspiel aller beteiligten
Komponenten einschließlich der eingebundenen Backend-Systeme in Blick zu behalten. Denn
Performance- und Verfügbarkeitseinbrüche von Web-Anwendungen können vielfältiger Natur sein. So
kann der "500 Internal Service-Error" darauf hinweisen, dass vergessen wurde, einen Portlet-Service
einzubinden. Der Grund kann allerdings auch der kurzfristige Ausfall einer zuliefernden
Mainframe-Anwendung im Backend sein. Oder eine Performance-Störung aus Anwendersicht rührt aus der
früher ausreichenden, jetzt aber zu gering dimensionierten Threads-Anzahl einer synchronisierten
Datenbankanwendung.
Ohne Transparenz des "Innenlebens" kann es gerade in dynamischen Umgebungen Tage dauern, bis die
Störungsursache identifiziert ist. Eine solche Sichtbarkeit könnte außerdem bereits im Rahmen von
Last- und Integrationstests hilfreich sein, potenzielle Problemstellen noch vor Produktionsstart zu
identifizieren.
Um sich die geforderte Transparenz zu verschaffen, "öffnet" eine APM-Lösung das Innenleben der
Anwendung mihilfe der Bytecode-Instrumentierung (BCI, siehe Kasten). Dabei wird der Bytecode der
Anwendung zur Laufzeit gezielt mit Messpunkten über die Methoden, die Laufzeit und die Anzahl der
Methodenaufrufe angereichert. Ein Agent liest die Messpunkte, so genannte "Probes", aus und sendet
sie an eine zentrale Verarbeitungskomponente.
Blick ins Innenleben
Das Monitoring auf Bytecode-Ebene ermöglicht schnell, Aussagen über die "schuldige" Komponente
zu treffen. Im Rahmen der HTTP-Analyse kann die Anwendung im Anschluss detailliert untersucht
werden. Aus der Dauer der Requests lässt sich beispielsweise ableiten, welche Komponenten – Server,
Netzwerk etc. – die meiste Bearbeitungszeit beansprucht, ob die Reihenfolge der Requests wie
geplant abgearbeitet wird, welche Services welche Leistung verlangen oder welche Requests nicht
ausgeführt wurden.
Dem APM-System liegt technisch eine Agenten-Manager-Architektur zugrunde. Für die
Standardüberwachungsszenarien ist ein Agent pro Maschine mit aktivem Server in der Web-Komponente
notwendig. Dieser vorkonfigurierte Agent erfasst wie beschrieben nun die Messdaten der Komponenten
innerhalb der laufenden Web-Anwendung als auch der zu überwachenden Web- und Applikations-Server.
Die Messdaten werden von dem Manager der EPM-Umgebung eingesammelt, der diese vergleichbar zu einem
Flugschreiber speichert. Auf diese Weise erhält das Administrationsteam im Lauf der Zeit tiefe
Einblicke in die Auswirkungen von Änderungen an Programmcodes, Konfigurationseinstellungen der
Komponenten (zum Beispiel der Anwendungs-Server) oder Verbindungen zum Backend. Die Funktion des
Transaction Tracers ermöglich zusätzlich, auffällige Transaktionen im aktuellen Produktionssystem
zu isolieren und gezielt zu überwachen.
Mit diesem kombinierten Blick auf das Außen- und Innenleben schaffen EAM-Lösungen (Enterprise
Application Management) die Voraussetzungen für ein an den betriebswirtschaftlichen Prozessen
ausgerichtetens Service-Qualitäts-Management. Registriert beispielsweise eine Appliance vermehrt
Antwortzeiten, die das Service-Level einer kritischen Anwendung ernsthaft gefährden, sendet sie
automatisch ein Ticket über den Vorfall an den zuständigen Service-Desk und stößt zugleich die "
Innen"-Prüfung der Black Box an. Den Support-Mitarbeitern stellt das APM-System alle Informationen
in der gebotenen Feinheit zur Verfügung, um den Auslöser der Störung zu identifizieren und der
Ursache auf den Grund zu gehen.
Der zentrale Ansatz für ein durchgängiges APM stellt einen wichtiger Eckpfeiler für den Einstieg
in ein umfassendes unternehmensweites, proaktives IT- und Service-(Qualitäts)-Management dar. Durch
die Integration in bestehende System-Management-Verfahren und -Werkzeuge werden die
Support-Abteilungen in die Lage versetzt, einen effektiven und notwendigen Prozess zur Aufdeckung
und Lösung von Performance-Problemen zu schaffen. Beispielsweise hilft die Integration von
Mainframe-Monitoring-Tools, das APM zu vervollständigen, da so die Leistungsfähigkeit der
Mainframe-Ressourcen in die End-to-End-Betrachtung einer Transaktion einbezogen wird. Ebenso
profitiert das Service-Assurance-Management vom Zusammenspiel eher ressourcenorientierter Werkzeuge
mit dem APM. Das Netzwerk-Management weiß beispielsweise, wenn einer von vier Portal-Servern
ausgefallen ist; das APM merkt wiederum nur, dass die Leistung für Portal-Services abfällt. Durch
den wechselseitigen Informationsaustausch kann das Netzwerk-Management nun die Bedeutung des
Servers für das Unternehmen einordnen, und das APM kennt die Ursache des schlechter werdenden
Antwortzeitverhaltens. Das Schwarze-Peter-Zuschieben tritt in der Administration erst gar nicht
mehr auf. Und ebenso entfallen Stressfaktoren für den Anwender, da sich im Idealfall drohende
Störungen in kritischen Produktionssystemen im Vorfeld beheben lassen.
BCI - Der Blick ins Innere
Die Bytecode-Instrumentierung (BCI) stellt die nützliche Technik dar, um das Innenleben einer
Java-Anwendung zu erhellen. Denn im Unterschied zum Logging-Verfahren (Log-Eintrag im Sourcecode)
muss die JVM-Ablaufumgebung hier nicht manipuliert werden, da BCI – wie der Name nahelegt – direkt
auf der Bytecode-Ebene ansetzt. Geschickt implementiert lassen sich mit BCI aussagekräftige
Performance-Metriken bis auf Methodenebene der Java-Klassen bei minimalem Overhead gewinnen, ohne
dass die Ausführung destabilisiert wird. Für den Prüflauf werden diese Metriken "on the fly"
geladen und nach festen Rhythmen abgefragt, deren Daten korreliert und als Ergebnis des
Anwendungsverbunds dargestellt.
Das Monitoring auf Bytecode-Ebene macht so das Geschehen in den laufenden Java-Anwendungen
sichtbar und erlaubt es, schnell Aussagen über die "schuldige" Komponente einschließlich der
Ursache einer Störung zu treffen. Im Grunde erhält man mit BCI also Informationen wie beim Logging,
ohne jedoch in den Sourcecode einzugreifen.
Profiling-Tools, die direkt auf Schnittstellen wie JVMPI oder JVMTI der JVM aufsetzen,
manipulieren zwar die Java-Programmsourcen ebenso wenig. Im Vergleich zu BCI liefern sie jedoch
enorme Informationsmengen, was wiederum einen erheblichen Overhead nebst Destabilisierung der JVM
bewirkt. Die Entwicklung von BCI wurde ursprünglich von CA vorangetrieben. Mittlerweile hat sich
das Konzept in der Praxis durchgesetzt und ist im Rahmen des JRS-Prozesses (Java Specification
Request) standardisiert.
Lesen Sie mehr zum Thema
