Drei Fragen und Antworten: Reibungsloser IT-Betrieb dank Observability
Während sich klassisches IT-Monitoring auf das Überwachen beschränkt, gewährt Observability umfassendere Einblicke – erfordert aber auch eine neue Denkweise.
(Bild: iX)
Monitoring gilt im Bereich der IT-Operations als Methode der Wahl, wenn es darum geht, den reibungslosen Betrieb aller Systeme sicherstellen zu wollen. Während sich Monitoring jedoch häufig auf das simple Überwachen beschränkt, verspricht Observability eine umfassendere Beobachtbarkeit, die insbesondere auch Entwicklerinnen und Entwicklern tiefgreifende Einblicke in ihre Anwendungen eröffnet. Welche neuen Möglichkeiten sich damit ergeben, aber auch welche Anforderungen Observability an Developer stellt, erläutert Renke Grunwald, Head of Cloud Solutions bei Open Knowledge, im Gespräch mit iX.
Was genau steckt hinter dem Begriff Observability und wie unterscheidet es sich vom klassischen Monitoring-Ansatz?
Observability hat sich im Zuge von Microservices-Architekturen etabliert, da klassisches Monitoring angesichts der gesteigerten Komplexität verteilter Systeme nicht mehr ausreicht. Den für Operations verantwortlichen Teams liefert Monitoring lediglich Hinweise auf Störungen im Betrieb – etwa durch Fehlermeldungen oder überdurchschnittlich lang dauernde Datenbankabfragen. Mit der engeren Zusammenarbeit von Entwicklungs- (Dev) und Betriebsteams (Ops) nach dem DevOps-Ansatz, verfolgt Observability das Ziel, tiefere Einblicke in das Verhalten von Anwendungen zu gewinnen, um die Ursache etwaiger Fehler zu finden.
Dazu setzt Observability in der Regel auf den drei Säulen Logs, Metriken und Tracing auf. Während Logs vor allem die Arbeitsweise einer Anwendung protokollieren, liefert Tracing – als eine Art strukturiertes Logging – auch über Netzwerkgrenzen hinaus Informationen zur Anwendungsausführung. Es orientiert sich an den logischen Abschnitten der Apps und Services, also beispielsweise Funktionsaufrufen, HTTP-Anfragen oder SQL-Queries. Ergänzend dazu liefern Metriken Entwicklerinnen und Entwicklern weitere Informationen über konkrete Messwerte rund um ihre Anwendungen. Das kann etwa die Zahl der HTTP-Anfragen in einem bestimmten Zeitraum sein oder die Dauer einer Datenbankabfrage. Die Kombination all dieser Informationen, die sich über eine Vielzahl von Tools erheben lassen, liefert ein umfassendes Bild des gesamten Softwaresystems.
Lässt sich Observability also schon mit einer geeigneten Auswahl an Werkzeugen erfolgreich umsetzen?
Observability-Tools sind bereits beim Entwickeln des Anwendungscodes eine wertvolle Hilfe. Die meisten Werkzeuge erlauben über ihre Dashboards zudem unterschiedliche Ansichten der gesammelten Informationen und liefern dabei den Betriebsteams vor allem technische, den Produktteams eher inhaltliche Einblicke. Mit den Tools allein ist es aber nicht getan, sondern es braucht auch eine passende Denkweise. Im Sinne des kooperativen DevOps-Gedankens zielt auch Observability auf eine engere Zusammenarbeit aller Beteiligten ab, um ein besseres gegenseitiges Verständnis zu erreichen.
Wenn Entwicklerinnen und Entwickler von Beginn an Observability-Daten im Blick behalten und analysieren, sind sie viel eher in der Lage, aussagekräftigere Logs zu schreiben, sinnvollere Metriken zu finden und um passende Traces zu erweitern. Welche Synergien sich aus der umfassenderen Kooperation der Teams ergeben können, lässt sich am Beispiel eines Webshops verdeutlichen: Scheitert das Abschicken von Bestellungen in einem Shop, und Entwicklerinnen und Entwickler haben dafür keinen passenden Fehlercode gesetzt, dann kann eine rein technische Metrik dieses Problem nicht anzeigen. Eine inhaltliche Metrik hingegen, die die Bestellabschlüsse pro Stunde anzeigt, macht den Fehler schnell deutlich.
Ist Observability der Königsweg zu einer optimalen Anwendungsentwicklung und -bereitstellung – oder sind dafür noch andere Hürden zu meistern?
Derzeit werden die drei Säulen von Observability häufig noch isoliert voreinander betrachtet. Allmählich setzt sich jedoch die Erkenntnis durch, dass enorme Mehrwerte entstehen, wenn Metriken, Traces und Logs miteinander korreliert werden können. Erst dann wird ein ganzheitlicher und tiefer Blick in das Innere von Systemen möglich, der es erlaubt, deren Verhalten besser zu verstehen und idealerweise auch vorherzusagen.
Allen Beteiligten sollte jedoch speziell beim Verwenden von Metriken und Traces stets bewusst sein, dass sie in der Regel nur als Stichprobe in den Observability-Tools ankommen (Sampling) – es wird also nicht jede Messung oder jedes Trace tatsächlich ausgewertet, weil die zu erfassende Datenmenge viel zu groß und damit zu teuer wäre. Das Sampling reduziert die Datenmenge, um immer noch aussagekräftige Ergebnisse zu liefern – allerdings mit einer gewissen Fehlertoleranz.
Observability eröffnet den DevOps-Teams aber schon heute einen vielversprechenden Weg, der über die Fehlererkennung hinaus reicht. Sie hilft auch Fehler grundsätzlich vermeiden zu können, entweder durch frühzeitiges Erkennen oder durch Beheben der eigentlichen Ursachen. Die Ursachen als solche erkennen zu können, zählt zu den eigentlichen Stärken der Observability.
Vielen Dank für die kurze Einführung in das Thema Observability, Renke Grundwald. Mehr Details dazu finden sich in den Artikeln des neuen Sonderheftes iX Developer – Cloud Native. Als Leseprobe des Hefts erscheint eine ausführliche Einführung in das Thema Observability kostenlos auf heise online.
In der Serie "Drei Fragen und Antworten" will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.
(map)