W-JAX Blog

Loggen, Visualisieren und Überwachen: Applikationen richtig monitoren

Stefan Fleiter

©Shutterstock / Vasin Lee

In seiner Session „Fault-Tolerant System Design – Fehler gehören dazu“ auf der W-JAX 2015 (Mittwoch, 4. November 2015 – 9:00 bis 10:00) beleuchtet Stefan Fleiter (1&1) das Thema Verfügbarkeit in allen Facetten: von den häufigsten Problemursachen, über die Messung bis hin zu Maßnahmen zur Erstellung von robusteren Systemen. In seinem Blog-Beitrag beschreibt er Maßnahmen, reduzierte Verfügbarkeiten schneller zu erkennen und ihre Ursachen zu finden.

Applikationen richtig monitoren

Fehler in verteilten Systemen zu finden gestaltet sich oft schwierig. Je mehr Systeme zusammenspielen müssen, um eine Funktionalität zur Verfügung zu stellen, desto mehr Expertise ist nötig, um ein Problem zu analysieren und die Ursachen zu finden. Oft ist diese Expertise über verschiedene Personen, Teams, Firmen oder gar Länder mit unterschiedlichen Zeitzonen verteilt. Das kann zusätzliche Latenzen generieren bis alle notwendigen Wissensträger zusammen an der Problemlösung arbeiten können. Deshalb ist es zur schnellen Analyse notwendig, die richtigen Informationen parat zu haben. Das lässt sich mit den Säulen Logging, Visualisierung wichtiger Kennzahlen sowie Alarmierung erreichen.

Logging mit Kontext

Gute Logfiles sind eine wichtige Grundlage – nicht nur –, um manuelle zu betrachten, was in einem System passiert oder welche Fehler dort auftreten. Über eine automatisierte Verarbeitung lassen sich schnelle Abfragen ermöglichen und auch wichtige Kennzahlen ermitteln. Dafür sind aber ein paar Aspekte zu beachten.

So ist es notwendig, dass die wichtigen Informationen auch den Weg ins Logfile finden. Alle Aufrufe des Systems von außen und alle Aufrufe anderer Systeme sollten inklusive Angabe des beteiligten Systems, Aktion, Dauer und bei Bedarf Parameter sowie Ergebnis auf dem Standard Loglevel INFO erfasst werden. Unerwartete Fehler sollten zusätzlich mindestens die genauen Daten zum Endpunkt (z. B. URI) sowie den Stacktrace inklusive Cause enthalten und dem Level ERROR zugeordnet werden. Interne Aufrufe anderer Klassen können auf DEBUG Level gemeldet werden, um die entsprechenden Logger bei Bedarf aktivieren und die Interaktionen analysieren zu können.

Weiterhin sollte immer der Kontext einer Aktion festgehalten werden. Zum Kontext gehören je nach Umfeld die Version der Applikation, der Name der aufrufenden Applikation und deren Version, der User für den die Aktion durchgeführt wird, und eine Request-Id. Mithilfe der Request-Id, die initial erstellt und bei Aufrufen anderer Systeme mitgegeben wird, lassen sich Log-Meldungen über Systemgrenzen hinweg einer Aktion zuordnen. Diese Kontext-Informationen lassen sich in einem zum Logging-Framework passenden Mapped Diagnostic Context (MDC) festhalten. Dies erfolgt idealerweise an allen Methoden der externen API über generische Mechanismen wie Interceptoren. Damit müssen die Kontext-Informationen nicht bei jedem Logger-Aufruf angeben werden und sind auch dann enthalten, wenn eine loggende Komponente wie Hibernate diese Informationen gar nicht kennt. Die Keys, für die im MDC ein Wert abgelegt wird, werden dann in der Logger‑Konfiguration referenziert, sodass der MDC Value, sofern vorhanden, in jeden Log‑Eintrag eingesetzt wird. Die Verwendung des MDC zusammen mit logback ist in dessen Dokumentation im Detail beschrieben, einen allgemeinen Ratgeber zum Thema Logging hat Ernest Mueller in Form des Artikels Logging for Success erstellt.

Wichtige Kennzahlen visualisieren

Um sich aktiv einen groben Überblick über den aktuellen Zustand eines Systems zu verschaffen, gibt es Kennzahlen, die dabei helfen können. Hilfreich können dazu generelle technische Werte wie die Anzahl verwendeter und vorhandener Elemente in Pools (DB, Remoting und Threads), die Anzahl und das Alter von Einträgen in Queues oder Maschinenwerte wie CPU- und Speicherauslastung sein. Zusätzlich sind individuelle spezifische Kennzahlen wie die Aufrufzahlen der Methoden der externen API des Systems pro Zeiteinheit, die jeweilige Dauer und die Anzahl der zurückgegebenen Fehler gruppiert nach Typ sowie die gleichen Daten für die Aufrufe anderer Systeme interessant.

All diese Kennzahlen sind aber oft nur im Vergleich aussagekräftig. Was heißt es, wenn die Abfrage von Foo auf System Bar 300 ms dauert? Ist das eine lange Zeitspanne? Wie war die Antwortzeit in der Vergangenheit? Wie oft wird es aktuell aufgerufen und sind es mehr oder weniger Aufrufe geworden? Ohne einen historischen Vergleich ist es meist schwierig zu erkennen, ob ein Messwert ein Problem darstellt. Die ad‑hoc‑Ermittlung der Daten ist besonders unter dem Druck einer akuten Fehlfunktion aufwendig und dauert zu lange. Zusätzlich bietet die Visualisierung der Kennzahlen die Möglichkeit, auch abseits von konkreten Problemen Entwicklungen frühzeitig zu erkennen und diesen bei Bedarf entgegenzuwirken.

Die Visualisierung kann auf Basis direkter Generierung von Zeitseriendaten erfolgen, die zum Beispiel an Graphite übertragen und in Grafana dargestellt werden können. Eine andere Möglichkeit ist es, die Logfiles des Systems als Datenquelle zu verwenden. Sind die wichtigen Daten dort in einem auswertbaren Format, lassen sich die Logfiles mittels des populären ELK Stacks importieren, indizieren, durchsuchbar machen und auswerten. Zusätzlich lassen sich auf Basis formulierbarer Abfragen Diagramme und Graphen erstellen. Mithilfe der Kontextdaten können ad hoc alle Log-Meldungen aller Systeme zu einer Aktion abgefragt werden, ohne manuell verschiedene Logfiles durchsuchen und korrelieren zu müssen.

Bei Verwendung des Hystrix Resilienz Frameworks können einige wichtige Kennzahlen bereits in dessen eigenem Dashboard betrachtet werden. Dieses spiegelt allerdings nur die letzten zwei Minuten wieder. Bei Ausleitung der Daten über das dafür bereits benötigte Hystrix-Metrics-Event-Stream-Modul in Logstash und Ablage in Graphite oder Elasticsearch kann auch die Historie dieser Kennzahlen einfach in Grafana oder Kibana visualisiert werden.

Lösungen zum Application Performance Management (APM) wie AppDynamics, dynaTrace und New Relic arbeiten generisch mittels Instrumentierung der JVM und verfolgen die Aktionen eines Systems rekursiv inklusive aller entfernter Operationen. Dabei ermitteln sie Kennzahlen wie Aufruf-Frequenz, Fehlerrate und Ausführungszeiten. Zusätzlich zeichnen sie fehlerhafte und langsame, getaktet auch erfolgreiche Aktionen, in Form von Snapshots auf.

Alle Daten werden in eigenen Dashboards zur Verfügung gestellt. In diesen können die Operationen des Systems und deren Kennzahlen betrachtet werden. Für die aufgezeichneten Snapshots stehen alle Parameter, Ergebnisse, Stacktraces, SQL-Statements und Teil-Ausführungszeiten zur Verfügung. Das kann insbesondere zur Analyse von langsamen oder fehlerhaften Operationen hilfreich sein.

Überwachung ist die Basis

Bevor eine Analyse von Problemen starten kann, müssen diese erst einmal erkannt werden. Dies geschieht in Monitoring-Lösungen automatisiert und basiert auf der Prüfung von Schwellwerten unterschiedlicher Kennzahlen. Werden diese über einen definierten Zeitraum über- oder unterschritten, so wird auf das Problem hingewiesen und ggf. ein Operator alarmiert.

Die Basis stellen hier die Erreichbarkeit des Rechners (ping) und Systemparameter wie Speicher-, CPU Auslastung oder offene File-Handles dar. Schon spezifischer können Daten des Applikations-Containers herangezogen werden. Beispiele sind auch hier die Auslastung von Pools (Threads, DB, Remoting), die Anzahl und das Alter von Einträgen in Queues sowie die Erreichbarkeit von Datenbanken und verwendeter Remote-Services.

Oft vernachlässigt werden bei der Überwachung hingegen die Kennzahlen der Applikationen. So können Veränderungen von Fehleranteil und Ausführungszeit der Methoden der externen API sowie der Aufrufe anderer Systeme frühzeitig auf Probleme hinweisen und zudem zusätzliche Fehlerquellen erfassbar machen. Hier können ggf. die für die Visualisierung erstellten Daten oder Abfragen wieder verwendet und mit Grenzwerten versehen werden.

Application Performance Management Lösungen ermöglichen nicht nur die Konfiguration von Schwellwerten für Fehleranteil und Ausführungszeit für die Alarmierung, sondern bieten teilweise auch dynamische Erstellung von Performance-Profilen aller Aktionen über den Wochenverlauf. Dadurch können Regressionen schnell erkannt werden. Durch die graphische Darstellung der langsamen Aktion und aller durch sie ausgelösten entfernten Operationen mit einer großen Menge an Detailinformationen kann schnell erkannt werden, in welchem System die Ursache liegt.

Fazit

Um eine schnelle Analyse von Problemen durch den IT-Betrieb zu ermöglichen, ist einige Vorarbeit nötig. Für alle vorgestellten Teilaspekte gibt es verschiedene Lösungsansätze. Die Entscheidung für einen Ansatz sollte unter Einbeziehung der beteiligten Organisationseinheiten und im Kontext der Anforderungen an die betreuten Systeme getroffen werden. Auch die Umsetzung kann je nach Ansatz besonders für bereits bestehende Systeme einigen Aufwand erfordern.

Ein einheitliches Vorgehen und Tooling ermöglicht es, unterschiedliche Systeme mit reduziertem Einarbeitungsaufwand zu betrachten, die Zusammenarbeit innerhalb von Operationen greifbar zu machen, und erleichtert so das Auffinden von Fehlerquellen – ein lohnendes Ziel!

Aufmacherbild: CCTV Camera or surveillance technology on screen display von Shutterstock / Urheberrecht: Vasin Lee

Geschrieben von
Stefan Fleiter
Stefan Fleiter
Stefan Fleiter ist seit 2008 als Architekt bei der 1&1 tätig. Neben dem Design von Softwaresystemen ist ihm auch deren Umsetzung wichtig, die er durch Beratung und Mitarbeit in zentralen Projekten unterstützt. Besonderes Augenmerk legt er dabei auf die Berücksichtigung der nicht funktionalen Anforderungen. Seine Spezialgebiete sind Java, Concurrency, Java EE, Tests, Linux sowie horizontale Skalierung und Verfügbarkeit.
Kommentare

Hinterlasse einen Kommentar

2 Kommentare auf "Loggen, Visualisieren und Überwachen: Applikationen richtig monitoren"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Tom
Gast

Sehr interessanter und hilfreicher Blog. In Bezug auf die Aussage „alle Aufrufe des Systems von außen … sollten … auf dem Standard Loglevel INFO erfasst werden“, frage ich mich gerade, auf welcher Ebene man das am Bestem macht. Zum Beispiel in Bezug auf einen JAX-RS-Aufruf sollte man die aufgerufene URL auf INFO logger und den daraus resultierenden Resource-Aufruf in Java auf DEBUG oder vice versa oder sogar beide auf INFO?