Was es bedeutet, mit AppDynamics zu arbeiten – und anderen APM Werkzeugen

Seit vielen Jahren arbeite ich mit Application Performance Management (APM) Werkzeugen im Java-Umfeld. Im Vergleich zu anderen Performance-Optimierungs-Werkzeugen wie z.B. Profilern, erfüllen APM-Werkzeuge sowohl Monitoring- als auch Analyse-Aufgaben. Sie bieten einen besseren Überblick über verteilte Anwendungen und können eine direkte Verbindung zwischen Anwender-Aktionen, den Performance-Erfahrungen der Anwender und den zugrunde liegenden technischen Prozessen liefern.

Meiner Erfahrung nach gibt es einige häufigere Fehlwahrnehmungen darüber, was an vorbereitenden aber auch dauerhaft anfallenden Arbeiten vor einem liegt, um möglichst vollständig von einem APM-Werkzeug zu profitieren. In diesem Blog möchte ich diese Fehlwahrnehmungen und die Aufgaben illustrieren, die mit einem APM-Werkzeug verbunden sind.

Meine Erfahrungen beruhen hauptsächlich auf der Arbeit mit AppDynamics, aber auch mit Dynatrace, im Monitoring, der Analyse und Optimierung der Performanz von Java Anwendungen. Während beide Werkzeuge zumindest teilweise auf fundamental unterschiedlichen Konzepten basieren, ist ihr Erscheinungsbild, ihr Nutzen und ihre Benutzung aus Sicht der Anwender ähnlich. Während ich mich im Folgenden auf AppDynamics beziehe und entsprechende Beispiele wähle, gelten die besprochenen Themen ebenso für Dynatrace und höchstwahrscheinlich auch weitere APM-Werkzeuge.

1. Einrichtung der Infrastruktur

Um mit AppDynamics zu arbeiten, muss der sog. „Controller“ installiert werden, die zentrale Einheit, die die Performanz-Daten sammelt, analysiert und darstellt. Entsprechend der Anzahl der Systeme, die überwacht werden sollen, und der Menge an Transaktionen, die von ihnen erzeugt werden, muss der Controller dimensioniert werden, d.h. es muss ausreichend ausgestattete Hardware bereitgestellt werden, damit der Controller seine Pflichten ordentlich erfüllen kann. AppDynamics-Agenten müssen auf den zu überwachenden Systemen installiert werden und die Kommunikation zwischen allen Komponenten muss eingerichtet werden.

Da all dies notwendige Voraussetzungen sind, um mir einem APM-Werkzeug arbeiten zu können, ist es offensichtlich, dass Arbeitskraft, Zeit und Hardware investiert werden müssen, um das neue APM-Werkzeug aufzusetzen und in Betrieb nehmen zu können.

Im Fall von AppDynamics ist dies auch schon alles, das gemacht werden muss, um dieses schicke – und in der Tat auch äußerst nützliche – zentrale Dashboard sehen zu können, die sog. „Flow Map“:

AppDynamics Main Application Dashboard

Die Architektur der Anwendung, die zuvor oft eher mysteriös war, liegt nun offen und transparent vor einem, und das einzige, was dazu nötig gewesen ist, war, das APM-Werkzeug zu installieren. Fast scheint es, als sei die Arbeit bereits halb erledigt. Das Einzige, das noch zu tun bleibt, ist…

3. Dashboards und Alarmierung

Der Haupt-Einsatzzweck eines APM-Werkzeuges ist die Performanz-Überwachung einer Anwendung. Gewünscht sind umfassende Dashboards, die auf einen Blick zeigen, wie es um die Performanz einer Anwendung steht. AppDynamics bietet exzellente Dashboards „out of the box“, die genau dies tun. Ein Beispiel ist erneut das zentrale Dashboard im obenstehenden Bild. Rechts und unterhalb der Flow Map findet man Graphen und Tabellen, die übersichtlich die wesentlichen Performance-Daten abbilden. Desweiteren bietet AppDynamics viele Möglichkeiten, spezielle, nach den eigenen Wünschen und Bedürfnissen maßgeschneiderte Dashboards zu entwerfen.

AppDynamics bringt weiterhin einen Satz an sehr nützlichen Regeln mit, um Auffälligkeiten im Performanz-Bereich zu melden. Die meisten Nutzer werden diese Regeln feintunen und ergänzen wollen, um sich ein für sie passendes Alarmierungssystem zu schaffen.

AppDynamics Health Rules

Hat man auch diesen Schritt erledigt, kann man leicht annehmen, man habe alle notwendigen Arbeiten durchgeführt: Das APM-Werkzeug läuft und versorgt einen mit allen notwendigen Informationen zur Performanz der überwachten Anwendung und man wird alarmiert, falls entsprechende Schwierigkeiten auftreten.

Falsch. Ganz falsch. An dieser Stelle aufzuhören bedeutete, auf den Großteil des Mehrwerts zu verzichten, den ein APM-Werkzeug liefern kann. Um z.B. die Hauptstärken von AppDynamics nutzen zu können, darf man Folgendes nicht vergessen…

2. Definition von Business Transactions

Die Nummerierung ist Absicht. Die Definition und Konfiguration von Business Transactions sollte vor der Einrichtung eigener Dashboards und einer eigenen Alarmierung erfolgen, da man sehr wahrscheinlich dabei auf Business Transactions zurückgreifen wollen wird.

Meiner Meinung nach sind Business Transaction das eigentliche Herzstück von AppDynamics und wahrscheinlich der meisten APM-Werkzeuge. Eine Business Transaction ist eine Aktion eines Nutzers der überwachten Anwendung, also ein Request an diese Anwendung, der verfolgt und aufgezeichnet wird, während er sich auf seinem verschlungenen Pfad durch die überwachte, verteilte Anwendung schlängelt. Als Ergebnis erhält man eine durchgehende Performance-Messung dieses Requests, in der die Java-Systeme aufgeführt sind, durch die er gelaufen ist, sowie die entfernten Services und Systeme die aufgerufen wurden.

AppDynamics Snapshot of a Business Transaction

AppDynamics bietet eine Erkennung von Business Transactions out of the box, aber für viele produktive verteilte Anwendungen wird dies nur ein erster Ansatz sein. Oft sieht man zu viele Business Transactions und dennoch nicht diejenigen, die man konkreten Nutzer-Aktionen zuordnen kann. Je nach der zugrunde liegenden Architektur kann es einiges an Arbeit bedeuten, die richtigen Business Transaktionen zu identifizieren und sie geeignet einzurichten – manchmal benötigt man dafür die Kooperation sowohl von den Nutzern der Anwendung als auch von der Entwicklungsseite. Aber als Ergebnis der Mühen erhält man einen zuvor nicht gekannten Einblick in die innere Mechanik einer Anwendung – und eine direkte Verknüpfung zur Performance-Erfahrung der Anwender.

Genau darauf möchte ich aufmerksam machen: Auf den Nutzen von Business Transactions sowie auf den notwendigen Aufwand, sie aufzuspüren und einzurichten.
Die Definition sinnvoller Business Transactions ist auch eine Voraussetzung, um im folgenden Schritt den vollen Nutzen aus einem APM-Werkzeug zu ziehen:

4. Performance Fehlersuche und Performance Optimierung

Eine der wichtigsten Eigenschaften von Business Transactions – und von APM-Werkzeugen insgesamt – ist ihre Unterstützung bei der Identifikation der Ursachen von Performance-Problemen. Wenn Nutzer einer Anwendung z.B. lange Antwortzeiten bei bestimmten ihrer Aktionen bemerken, ist es ohne APM häufig so, dass man bzgl. der Ursache im Dunkeln tappt und eigentlich nur raten kann. Kennt man dagegen die Business Transaction, die zu der betreffenden Nutzer-Aktion gehört, hat man einen direkten Ansatz, das Problem zu analysieren. Sehr oft kann man in wenigen Schritten zu der Java-Methode oder dem Aufruf eines entfernten Systems (Datenbank, Webservice etc.) gelangen, die die Performance-Schwierigkeiten verursacht.

AppDynamics Waterfall View

AppDynamics Hot Spots

Dies ist eine recht technische Aufgabe. Man muss die Anwendung und die Systeme wirklich gut kennen und ein wenig Erfahrung in der Entwicklung von Java-Anwendungen ist ebenfalls hilfreich. Daher kann es durchaus eine Herausforderung sein, qualifiziertes Personal hierfür zur Verfügung zu stellen. Aber diesen Bereich von APM zu ignorieren, würde bedeuten, auch auf mit den größten Nutzen zu verzichten, den ein APM-Werkzeug bieten kann.

Um alles zusammenzufassen: Nutzen Sie APM! Es wird Ihnen einen enormen Einblick in ihre verteilten Anwendungen verschaffen und kann die Verbindung zwischen Technik und Anwender-Erfahrung herstellen. APM ist wahrscheinlich sogar mächtiger, als Sie es sich zuvor vorgestellt haben. Aber dieses Potenzial hat seinen Preis. Höchstwahrscheinlich müssen mehr Zeit, Arbeitskraft und andere Ressourcen investiert werden und mehr Aufgaben erledigt werden, als anfangs geschätzt. Seien Sie sich dessen einfach bewusst!