Observability: Monitoring, Logging & Tracing

Den Fehlern auf der Spur mit ConSol

Moderne Applikationen sind komplex. Als Folge generieren sie eine Vielzahl von Mess- und Analysedaten. Diese geben Auskunft über die Gesundheit der Applikation. Und sie helfen im Fehlerfall das Problem zu beheben. Für den Betrachter ergibt sich so jedoch eine kaum überschaubare Datenflut. Observability – Beobachtbarkeit – ist die Fähigkeit, IT-Anwendungen ganzheitlich zu überwachen und so dieser Datenflut Herr zu werden. Dazu gehört, durch die Applikation geeignete Mess- und Analysedaten bereitzustellen. Und Entwickler und Betriebsteams müssen passende Werkzeuge an die Hand bekommen, um im Fehlerfall schnell und zielgerichtet agieren zu können.

Sämtliche Applikationen und die darunter liegende Infrastruktur produzieren Metriken, Logs und, wo sinnvoll, auch Traces. Diese werden von bewährten Open-Source-Tools wie Prometheus (Metriken), Loki (Logs) oder Jaeger (Traces) gesammelt und aufbereitet. Anschließend werden diese Daten zentral in Grafana-Dashboards visualisiert. An dieser Stelle erhält der Nutzer einen Überblick über für ihn freigegebene Applikationen und Infrastruktur-Komponenten. Zur Langzeitspeicherung der Daten können zusätzlich Datenbanken wie InfluxDB zum Einsatz kommen.

Observability – Auf der Jagd nach „Mister X“

Observability setzt sich im Wesentlichen aus drei Bausteinen zusammen: Monitoring, Logging und Tracing. Das Monitoring gibt uns Auskunft, wenn ein definiertes Service Level oder Qualitätskriterium unterschritten wird. Die Anwendungsentwickler definieren hierfür entsprechende Metriken, welche wiederum direkt aus der Applikation heraus bereitgestellt werden. In den Logs finden wir die Fehlermeldungen der einzelnen Softwarekomponenten. Sie zeigen, an welcher Stelle in den jeweiligen Services der Fehler auftritt. Den Weg, den ein Aufruf zwischen den Services zurückgelegt hat, bevor er zu einem Problem geführt hat, können wir im Tracing nachvollziehen. All diese Informationen können wir mittels Korrelations-IDs gemeinsam in einem zentralen Dashboard betrachten. So bewahren wir auch in komplexen Anwendungen den Überblick und spüren die Fehlerquelle schnell auf.

Observability Tools

Die von uns favorisierten Applikationen für Observability sind Open-Source-Lösungen. Gegenüber kommerziellen Lösungen gibt es hier keinerlei Nachteil. Wir haben sie seit etlichen Jahren sowohl bei unseren Kunden als auch bei uns selbst im produktiven Einsatz. Ihr Funktionsumfang ist beachtlich.

Prometheus ist der De-facto-Standard für Cloud-native Monitoring und Alerting. Es bietet eine einfache Konfiguration, wo und wie Metriken gesammelt werden können. Die meisten Anwendungen unterstützen den Export von Metriken nach Prometheus. Und auch für selbst geschriebene Applikationen gibt es für alle gängigen Programmiersprachen und Frameworks sehr gute Unterstützung des Exports von Metriken nach Prometheus.

Mit Loki können Logs einfach importiert und indiziert werden. Die Konfiguration ist an die von Prometheus angelehnt. Das Ziel ist es, schnell Logs für bestimmte Kriterien zu finden. Daher darf nur ein sehr kleiner Index geschrieben werden. Durch starkes Parallelisieren von Auswertungen können Abfragen selbst bei großen Datenmengen schnell ausgeführt werden.

Grafana wird für das Visualisieren von Metriken verwendet. Es bietet eine sehr gute Integration von Prometheus, Loki und Jaeger. Hiermit lassen sich in Graphen neben Metriken auch Traces anzuzeigen. Es ist außerdem möglich zu einzelnen Traces zu springen und für bestimmte Metriken auch Logs zu diesen Metriken zu zeigen. Neben einer großen Auswahl an vordefinierten Dashboards mit verschiedenen Metriken kann der Benutzer auch selbst Dashboards erstellen.

Jaeger unterstützt den OpenTracing-Standard. Hierdurch ist eine einfache Integration von Applikationen in Jaeger möglich. Für selbst geschriebene Applikationen gibt es, ähnlich wie bei Prometheus, eine breite Unterstützung von Programmiersprachen und Frameworks. Weitere Vorteile von Jaeger, neben der großen Verbreitung, sind die einfache Installation und Skalierung selbst bei großen Datenmengen.

Wichtige Begriffe & Erläuterungen

Logging wird genutzt, um spezielle Events oder problematische und fehlerhafte Situationen zu protokollieren, so dass bei Schwierigkeiten die Fehlerkonstellation nachvollzogen werden kann. Es liegt in der Verantwortung der Entwickler, wie aussagekräftig diese sind. Es gibt für die meisten Programmiersprachen Logging-Frameworks, die für standardisierte Log-Formate sorgen. Dies ist dann wichtig, wenn Logs zentral gesammelt werden und nach bestimmten Kriterien wieder gefunden werden sollen. Insbesondere in den flüchtigen Containern ist es zwingend notwendig die Logs zentral zu sammeln. Denn lokale Log-Files gehen mit Restart des Containers verloren.

In heutigen verteilten Systemen und insbesondere in Microservice-Architekturen reicht das einfache Logging nicht mehr aus. Hier muss der Ablauf über verschiedene Services oder Methoden hinweg nachverfolgbar sein, da häufig gerade das Zusammenspiel zwischen Microservices zu Problemen oder Performance-Bottlenecks führt. Dazu ist es erforderlich, dass neben den End-User-Aufrufen noch zusätzliche Information über die Service-Aufrufe weitergegeben und in speziellen Tracing-Log-Events hinterlegt wird. Darüber hinaus müssen diese Tracing-Logs auch für alle beteiligten Services zentral gespeichert werden, damit die Aufrufhierarchien dargestellt werden können. Bei Verwendung von externen Bibliotheken oder Services stellt dies zusätzliche Anforderungen an diese.

Über OpenTracing stehen Frameworks für viele Programmiersprachen zur Verfügung, die über sogenannte Spans oder Korrelations-IDs die End-User-Aufrufe über die verschiedenen Services hinweg einfach zuweisbar machen. Dieser Standard wird schon von vielen Open-Source-Libraries unterstützt.

Metriken sind numerische Repräsentationen von Zuständen (z.B. Anzahl von offenen Connections) oder Durchsätzen (z.B. Schreibvolumen auf einer Festplatte seit einem bestimmten Zeitpunkt, Aufruf einer bestimmten Funktionalität). Sie unterscheiden sich damit von Logs und Tracing-Daten, die sich auf einzelne Events beziehen.

Metriken können über sogenannte Exporter oder Metrik-Endpunkte zu Standardapplikationen (z.B. NGINX, DBs oder Objekten in Kubernetes) abgefragt werden. Die kundenspezifischen Applikationen sollten so instrumentiert werden, dass man damit die SLAs messen lassen und weitere Information über die Nutzung (z.B. Anzahl und Antwortzeiten von kritischen Aufrufen) für detaillierte Performance-Betrachtungen gewinnen kann.

Das aktuell verbreitete Metrikformat wurde von Prometheus eingeführt und wurde über OpenMetrics standardisiert. Metrikpunkte setzen sich dabei wie folgt zusammen:

  • Metrikname: Beschreibt, was repräsentiert wird. Z.B. server_open_connection_count
  • Labels: Anhand von Labeln kann man verschieden vermessene Instanzen unterscheiden. Z.B. Instance=127.0.0.1:8080.
  • Zeitstempel: Zu welchem Zeitpunkt war dieser Wert aktuell?
  • Wert: der numerische Wert

Damit kann die Performance und ggf. auch die Anzahl der Fehler oder spezieller Zustände kompakt repräsentiert und z.B. in Grafana grafisch visualisiert werden.

Auf diesen numerischen Werten können Regeln definiert werden, welche eine Aussage liefern, ob das System Grenzwerte überschritten hat – z.B. wenn über 10 Minuten mehr als 90 % der verfügbaren Connections belegt waren oder in 5 Minuten im Durchschnitt mehr als 2 % der Anfragen zu Fehlern führten. Ein Monitoring Tool für Metriken wie Prometheus speichert die Metriken, prüft solche Bedingungen und kann daraufhin die Verantwortlichen darüber informieren.

Unter Monitoring versteht man die Überwachung von Applikation und Infrastruktur. Bei fehlerhaften Zuständen oder Performance-Engpässen werden die zuständigen Betriebsteams benachrichtigt, idealerweise bevor die Nutzer der Applikation größere Probleme feststellen.

State-of-the-art Monitoring-Systeme wie Prometheus sind metrikbasiert. Das heißt, dass sie auf Basis der Metriken Problemzustände ermitteln und Alerts auslösen. Darüber hinaus speichern sie die Metriken über einen längeren Zeitraum, so dass sie über Visualisierungstools wie Grafana auch nachträglich noch zur Analyse von Problemsituationen verwendet werden können.

OpenShift Service Mesh basierend auf Istio

Microservice Management: Sichere und fehlerfreie Interservice-Kommunikation garantiert durch eine Zwischenlayer in Ihrer Applikation, deren Performance wir dadurch optimieren. Das bedeutet weniger Code für Ihre Entwickler, die sich so ganz auf den Business Value der App konzentrieren können. Hier geht’s zur Demo-Anfrage.

artikelbild_webcast4.jpg
Webcast

Webcast-Reihe: The Day After Tomorrow“: Tag 2 bei Cloud Native Applications

So geht der Regelbetrieb für alle Beteiligten stressfrei vonstatten

7 Säulen für Change Management in Integrationsprojekten
IT Know-how

7 Säulen für Change Management in Integrationsprojekten

Best Practices aus zahlreichen Software-Integrations-Projekten, wie Sie Ihre Lead Time for Changes beschleunigen

Review: Webcasts "CrisisProof IT & Automation hand in hand"
Webcast

Review: Webcasts "CrisisProof IT & Automation hand in hand"

3 Talks mit Partner NGINX unter dem Motto "Drive speed, scalability & cost reduction". Die Aufzeichnung gibt`s hier!

Wie bewährt sich Jenkins X? Das sind moderne, Cloud-native CI/CD Tools
Whitepaper

Wie bewährt sich Jenkins X? Das sind moderne, Cloud-native CI/CD Tools

Neues zu Jenkins X und Continuous Integration & Delivery für die Cloud

ConSol stellt vor: 7 Grundprinzipien für agile Integrationsprojekte
IT Know-how

ConSol stellt vor: 7 Grundprinzipien für agile Integrationsprojekte

Customer first, Agile Mindset, DevOps & mehr: Wie Kunden von agilen Methoden in all unseren Integrationsprojekten profitieren

ConSol Labs – unser Open Source Blog
IT Know-how

ConSol Labs – unser Open Source Blog

We love IT – und Coding & Hacking. Unser IT-Know-how teilen wir auf ConSol Labs.

Local Integration Gateway (LIG) auf Basis von Microservice-Lösung
Success Story

Local Integration Gateway (LIG) auf Basis von Microservice-Lösung

Migration bei Telekommunikationskonzern: LIG baut Brücke zwischen externen Usern & internen Backend-Systemen

Iterative & inkrementelle Evolution der Architektur von (Alt-)Software
Leitfaden

Iterative & inkrementelle Evolution der Architektur von (Alt-)Software

Um Alt-Software zu modernisieren & fit für die Zukunft zu machen, ist meist ein schrittweises, agiles Vorgehen Pflicht

SQL, NoSQL, NewSQL — die Wahl der richtigen Persistenz-Technologie
Leitfaden

SQL, NoSQL, NewSQL — die Wahl der richtigen Persistenz-Technologie

Überblick der größten Unterschiede zwischen SQL, NoSQL und NewSQL – denn keine Datenbank ist für alle Use Cases geeignet.

Ihr Ansprechpartner

Christoph Ehlers

Tel.: +49-89-45841-100