Keine Zeit für Monitoring?

Das Monitoring großer, verteilter Java-Landschaften hilft vor allem, die Kontrolle über zunehmend komplexe Applikationen zu behalten. Aber viele Administratoren sparen den Aufwand, ein Monitoring überhaupt einzurichten: Keine Zeit. Nun ist eine zeitsparende Abhilfe in Sicht!

„Wir sind eh zu 100% ausgelastet. Wir brauchen eine Lösung, die uns hilft schneller und effektiver zu arbeiten und nicht etwas, das uns mit Glück die Zeit spart, die es selber kostet um es einzurichten und am Laufen zu halten.“
Diese oder ähnliche Aussagen höre ich oft von Administratoren. Mit dem Effekt, dass Lösungen für das Application Performance Monitoring (APM) nur von Experten als „Feuerlöscher“ eingesetzt werden.

Was wird also gebraucht? Eine Lösung, die mit minimalem Konfigurationsaufwand eine große Menge an Applikationen überwacht und im Problemfall rasch die Ursache identifiziert.

Tatsächlich habe ich inzwischen ein Tool gefunden und getestet, dass diese Anforderungen erfüllt. AppDynamics hat ein Produkt entwickelt, das nicht zuletzt durch seine sehr einfache Bedienung überzeugt. Mit hoher Skepsis bin ich an die Lösung herangegangen, habe jedoch in den bisherigen Installationen keine Enttäuschung erlebt. Fast schon wie eine iPhone- oder Android-App: Einfach benutzen.

Die 3 Schritte zur 24×7 Überwachung

Betrachten wir das Aufsetzen eines typischen Application-Monitorings Schritt für Schritt und welche Vorteile dabei die Lösung von AppDynamics bringt.

1. Was messe ich?  – Messpunkte

Die Definition der Messpunkte stellt die erste Herausforderung dar. Die meisten APM-Lösungen im Bereich Java und .NET verwenden BCI (Bytecode Instrumentierung), um an Performance Daten heran zu kommen. Die Messpunkte müssen sinnvoll definiert werden, damit der Einfluss der Messung auf das Ergebnis gering gehalten wird (Overhead), da ja zusätzlicher Code ausgeführt wird. Dieser Schritt erfordert mindestens einen Experten, in der Regel einen Entwickler oder Architekten, der die Applikation im Detail kennt. Und das für jede Applikation, die  überwacht werden soll.

Wird agil entwickelt ist das ein anstrengendes Unterfangen, da sich die Klassen täglich ändern können, bzw. neue dazu kommen. Ein “Trial and Error”-Verfahren verbietet sich in Produktion, da dazu die Applikationsserver meist neu zu starten sind und evtl. der Overhead zwischendurch so stark erhöht wird, dass die     Nutzer davon merklich betroffen werden.
AppDynamics wendet hier ein zum Patent angemeldetes Verfahren an, welches mit minimaler BCI auskommt und trotzdem bis auf Methodenebene Auskunft geben kann, welche Komponente einer Applikation “trödelt”. Und das ohne jeglichen Konfigurationsaufwand. Der Architekt / Entwickler darf also weiterhin seiner eigentlichen Tätigkeit nachgehen.

2. Wie verschaffe ich mir einen Überblick? – Visualisierung

Für den Überblick bieten sich Dashboards an, welche die Architektur (wer spricht mit wem wie oft) und die Fachlichkeiten (welche Business Transaktion braucht wie lange und warum?) für alle Applikationen veranschaulichen.

Die meisten Hersteller benutzen zur Visualisierung “Customizable Dashboards”, also jenes “Allheilmittel”, mit dem man individuelle Ansichten für jeden Benutzer erstellen kann. Und genau das ist dann auch in allen Details und für jede Applikation zu tun – quasi „Mustomizable Dashboards“. Neuerlicher Aufwand entsteht, sobald sich etwas in der Umgebung oder an den Fachlichkeiten ändert.

AppDynamics Dashboards erstellen sich dagegen automatisch und ermitteln die Business Transaktionen im laufenden Betrieb basierend auf den “inneren” Werten einer Applikation (z.B. Struts Actions, URL Pattern oder HTTP Parametern). Sollten die Definitionen nicht passen, können sie mit wenigen Klicks angepasst werden und das System ist fertig eingestellt.

AppDynamics - Application Overview

AppDynamics Application Flow Map

3. Alarm! Da läuft was schief! – Schwellwerte

Was ist ein Problem in der Produktion? In der Regel etwas, dass außerhalb der Reihe passiert. Z.B. der Login eines Anwenders dauert 3-mal so lange wie normal zu dieser Tageszeit in Applikation X oder eine JVM hat einen starken CPU Verbrauch. Solche Auffälligkeiten werden durch zuvor definierte Schwellwerte erkennbar, deren Überschreitung einen Alarm auslöst.

Jetzt sehe ich in der Praxis oft 100 Applikationen mit diversen fachlichen Transaktionen die unterschiedliche “normale” Laufzeiten haben: Mal ist 2 Sekunden gut (Kostenkalkulation in der Versicherung), mal sind 200 ms Antwortzeit schon eine Katastrophe (Platzierung einer Wette in einem Online Wettsystem). Oder es liegen gar keine genau definierten nicht-funktionalen Anforderungen vor, so dass ins Blaue Werte festgelegt werden, die anschließend aufwändig anzupassen sind. Denn gehen wir mal nur von 50 Applikationen mit jeweils 50 fachlichen Transaktionen aus, sind das schon satte 2.500 Schwellwerte, die ich anpassen muss! Regelmäßig. Und wir betrachten hier nur Antwortzeiten…

Mit AppDynamics fällt dieser Aufwand zum großen Teil weg, da ein schlaues Baselining und statistische Methoden wie die Standardabweichung verwendet werden. Hier kann ich die Werte individuell einstellen, aber mehr als 95% der Schwellwerte sind mit den Standardregeln schon abgedeckt. Sogar Tageszeit-bezogene Unterschiede (Montag morgens dauert der Login doppelt so lange aufgrund der Last wie 2 Stunden später) werden dabei berücksichtigt.

4. Und was ist mit der Root Cause-Analyse? (Bonusschritt)

Alarmierungen bei Problemen sind gut und schön, man weiß dann, dass etwas schief ging, aber wer ist jetzt zu benachrichtigen? Möglichkeiten zur Triage und Root Cause Analyse vervollständigen die Überwachung. Also die Verantwortlichen für die Problemlösung identifizieren und ihnen dann auch gleich die Detaildaten übergeben, um schnell wieder Normalität einkehren zu lassen.

Ich habe vorher ausgeführt, dass AppDynamics nur sehr wenig Bytecode instrumentiert. Wie komme ich dann an die erforderlichen Details? Hierzu verwendet AppDynamics so genannte Snapshots, welche einem Callstack gleichen, mit Transaktionsdetails angereichert sind und im Bedarfsfall erzeugt werden. Bedarf besteht dann, wenn etwas außerhalb der Norm passiert, bzw. immer mal wieder zur Stichprobe zwischendurch. Dadurch wird ein Operator nicht mit Unmengen an Daten belastet, sondern erhält genau die richtigen Informationen, wenn sie benötigt werden.

In den nächsten Wochen werden wir hier im Blog auch noch auf verschiedene typische Performance-Probleme und deren Diagnose eingehen.

Einfach und effektiv

Zusammenfassend hat AppDynamics eine einfach zu benutzende und effektive Lösung auf den Weg gebracht in der ich endlich das verwirklicht sehe, was in den letzten sieben Jahren zwar angedacht aber nie umgesetzt wurde. Es ist ein einfach zu bedienendes System, welches spezifisch auf die Produktionsüberwachung ausgerichtet wurde.

Ist das revolutionär? Eher evolutionär. AppDynamics hat die Lehren aus bisherigen Lösungsansätzen verschiedenster Anbieter gezogen und vor allem über die Automatisierung nachgedacht. Das Ziel wird in den Zahlen “2-3-100” zusammen gefasst: 2 Administratoren können in 3 Tagen 100 Applikationen in die Überwachung nehmen.

Hatten die ersten Anbieter von APM Lösungen (für Java und .NET) das vordringliche Ziel,  überhaupt Daten zu bekommen und die Blackbox zu öffnen, erweiterte die zweite Generation das Ganze auf Transaktionen, um auch moderne, dynamische SOA/SBA Applikationen vernünftig zu durchleuchten. Was auf der Strecke blieb war bis jetzt die Usability. Wie bekomme ich ohne Aufwand Ordnung in meine Messdaten und mache daraus wertvolle Informationen?

Auf in die nächste Generation des APM!

Also: Agent in die Anwendung einbinden (siehe AppDynamics Lite Screencast von Fabian ), an den zentralen Controller Daten schicken lassen und kurz warten, bis sich die ersten Werte einstellen.