Observability in Zeiten von Microservices

Autor: Wolfgang Klimt*

Die Jagd nach Problemen im IT-Betrieb ist kostspielig und mühsam. In den letzten Jahren hat daher das Thema „Observability“ in der IT zunehmend an Bedeutung gewonnen. Trotz dessen Popularität ist vielen noch nicht ganz klar, wie genau der Ansatz Unternehmen hilft. Consol klärt auf.

Für einen stabilen Betrieb verwenden Administratoren in der Praxis eine Kombination verschiedener Verfahren, um ein möglichst hohes Level an Observability zu erreichen. Die gängigsten sind Logging, Tracing und das Sammeln von Metriken. Sie tragen auf unterschiedliche Art dazu bei, die Observability eines Softwaresystems zu erhöhen.

Logging

Gutes Logging ist ein Kernthema der nicht-funktionalen Softwareentwicklung. Über aussagekräftige Logs und konsistente Log-Level können Administratoren vor allem den fachlichen Zustand der Applikation oder der Instanz nach außen sichtbar machen und damit eine fachliche Observability herstellen. Da Programmierer das Logging allerdings bereits während der Entwicklungsphase implementieren, ist es leider in der Regel primär auf deren Bedürfnisse ausgerichtet. Daher dient es oft hauptsächlich dem Debugging, während die Anforderungen des produktiven Betriebs unbeachtet bleiben. Für Entwickler ergibt sich aus Betriebssicht daher die folgende Wunschliste:

  1. Loggt fachlich relevante Identifier.
  2. Loggt ein- und ausgehende Requests möglichst vollständig.
  3. Loggt eindeutige Request Identifier und reicht sie bei ausgehenden Requests an die aufgerufene Schnittstelle weiter.
*Wolfgang Klimt, Site Reliability Engineer bei Consol, klärt über die verschiedenen Ansätze für Observability auf.

Metriken

Viele Infrastrukturkomponenten liefern einen umfangreichen Satz von Metriken aus. Da diese Schnittstellen in vielen Fällen standardisiert sind, können Administratoren sie mit Hilfe von Tools ohne großen Aufwand sammeln und etwa in Time-Series-Datenbanken speichern, analysieren, graphisch aufbereiten und für das Monitoring verwenden. Im Sinne einer hohen Observability sollten sie diese Aufgabe allerdings auch tatsächlich ernst nehmen, sonst fallen Probleme in der Infrastrukturkomponente erst auf, wenn sie nicht mehr funktioniert. Das erschwert die Diagnose der Ursache unnötig oder macht sie im Nachhinein gar unmöglich. Im Zweifelsfall sollten übrigens alle verfügbaren Metriken gesammelt werden. Sonst stellt der Administrator spätestens bei der dritten Analyse fest, dass genau die Metrik fehlt, die er jetzt am dringendsten benötigt.

Tracing

Das Tracing hilft dabei, Probleme zu finden, die im Zusammenspiel vieler Instanzen auftreten. Mit der Umstellung monolithischer Applikationen zu Microservices-Applikationsverbünden erhält es eine besondere Bedeutung. In solchen Architekturen entwickelt sich das Finden der für einen Fehler verantwortlichen Instanz ohne gutes Tracing zur Suche nach der Stecknadel im Heuhaufen. Die Observability einer Microservices-Applikation ist also nicht nur durch die Observability der einzelnen Instanzen definiert, sondern auch durch die Traceability von Requests über die Servicelandschaft hinweg.

Zentrale Sammlung und Auswertung

All diese Informationen müssen Administratoren an einer Stelle sammeln, aufbereiten und auswerten. Dafür verwenden sie Systeme wie Kibana ­– im Verbund mit Elasticsearch und Logstash/Fluentd ­– oder Splunk. Die Auswertbarkeit aller gesammelten Daten und Metriken an einer Stelle schafft eine hohe Observability und erlaubt die fortlaufende Verbesserung der Systemverfügbarkeit und -stabilität. Graphische Dashboards machen auf einen Blick sichtbar, ob sich das System im gewünschten Zustand befindet oder sich irgendwo ein Problem abzeichnet. Monitoring auf Basis der eingehenden Daten erzeugt Alarme für das Betriebsteam, wenn diese zu weit vom Erwartungswert abweichen oder von einer Komponente gar keine Daten mehr ankommen. Tritt doch einmal eine Störung auf, helfen die Daten bei der Post-Mortem-Diagnose und der Erstellung zusätzlicher Monitore, die ein erneutes Auftreten des Problems beim nächsten Mal rechtzeitig anzeigen.

Die „Extrameile“ verhindert Kosten und Ärger

Eine hohe Observability ihrer IT-Landschaft erreichen Unternehmen nur durch den kombinierten Einsatz von Logging, Tracing und dem Sammeln von Metriken. Vernachlässigen sie eine Komponente, ergeben sich blinde Flecken, wodurch die Qualität der Systemüberwachung sinkt. Metriken sind in der Regel vorhanden, doch geht viel vom Kontext verloren, wenn Administratoren sie nicht passgenau für ihren Use Case nutzen. Während das Tracing relativ einfach Tool-gestützt erfolgen kann, müssen Unternehmen das Logging als integrale Aufgabe in den Entwicklungsprozess integrieren und regelmäßig optimieren. Die laufende Auswertung der gewonnenen Daten und die Pflege des Monitorings sowie Alertings ist eine kontinuierliche, den Betrieb begleitende Mammutaufgabe.

Das Potential moderner Observability-Frameworks für die Untersuchung von Problemen in der Produktion ist immens, aber auch unübersichtlich. Die Ausstattung einer Software mit hilfreichen Metriken und Tools ist daher nichts, was IT-Abteilungen „nebenher“ machen sollten. Im Zweifel sollten Unternehmen Fachpersonal konsultieren, das sich mit dem sensiblen Zusammenspiel der einzelnen Observability-Komponenten auskennt. Experten entwerfen anhand des jeweiligen Use Cases ein zielgerichtetes Konzept für die zu sammelnden Informationen und implementiert es. Viele Projektleiter, die diese „Extrameile“ gegangen sind, waren am Ende erstaunt, wie hilfreich gut konzipierte Metriken bei der Fehlersuche sind.

*Wolfgang Klimt ist Site Reliability Engineer bei Consol


Bildquelle / Lizenz Aufmacher:

Photo by Christopher Gower on Unsplash


Creative Commons Lizenz CC BY-ND 4.0

Sie dürfen:

Teilen — das Material in jedwedem Format oder Medium vervielfältigen und weiterverbreiten und zwar für beliebige Zwecke, sogar kommerziell.

Der Lizenzgeber kann diese Freiheiten nicht widerrufen solange Sie sich an die Lizenzbedingungen halten.


Unter folgenden Bedingungen:

Namensnennung — Sie müssen angemessene Urheber- und Rechteangaben machen, einen Link zur Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden. Diese Angaben dürfen in jeder angemessenen Art und Weise gemacht werden, allerdings nicht so, dass der Eindruck entsteht, der Lizenzgeber unterstütze gerade Sie oder Ihre Nutzung besonders.

Keine Bearbeitungen — Wenn Sie das Material remixen, verändern oder darauf anderweitig direkt aufbauen, dürfen Sie die bearbeitete Fassung des Materials nicht verbreiten.