Was ist Observability?

In den letzten Jahren haben Unternehmen schnell auf Cloud-native Infrastruktur-Services wie AWS in Form von Microservice-, Serverless- und Container-Technologien umgestellt. Soll ein Event in solchen verteilten Systemen zu seinem Ursprung zurückverfolgt werden, sind dazu Tausende von Prozessen notwendig, die entweder in der Cloud oder lokal oder sowohl Cloud-basiert als auch lokal ausgeführt werden. Herkömmliche Monitoring-Verfahren und -Tools haben jedoch Schwierigkeiten, die vielen Kommunikationswege und Abhängigkeiten in diesen verteilten Architekturen zu verfolgen.

Observability ermöglicht Teams ein effektiveres Monitoring moderner Systeme und hilft ihnen, Auswirkungen innerhalb einer komplexen Ereigniskette zu identifizieren, zu verknüpfen und zu ihrer Ursache zurückzuverfolgen. Darüber hinaus gibt sie Systemadministratoren, IT Operations-Analysten und Entwicklern Einblicke in ihre gesamte Architektur.

Monitoring und Observability sind unterschiedliche Konzepte, die voneinander abhängen. Monitoring ist ein Verfahren, das durchgeführt wird, um die Observability eines Systems zu erhöhen. Observability ist eine Eigenschaft dieses Systems, ähnlich wie die Funktionalität oder Testbarkeit.

Genauer gesagt ist Monitoring das Beobachten der Performance eines Systems über einen Zeitraum. Monitoring-Tools sammeln und analysieren Systemdaten und übersetzen sie in verwertbare Erkenntnisse. Grundsätzlich können Sie mit Monitoring-Technologien, wie z.B. Application Performance-Monitoring, feststellen, ob ein System in Betrieb ist oder ob es ein Problem mit der Anwendungsleistung gibt. Das Monitoring der Datenaggregation und -korrelation kann zudem dazu beitragen, weitere gefasste Schlussfolgerungen über das System zu ziehen. Aus der Ladezeit können Entwickler beispielsweise Rückschlüsse auf die User Experience einer Website oder App ziehen.

Observability ist dagegen ein Maßstab dafür, wie gut sich die internen Zustände eines Systems anhand seiner externen Ausgabewerte einschätzen lassen. Dabei werden die durch Monitoring gewonnenen Daten und Erkenntnisse genutzt, um ein umfassendes Bild Ihres Systems, seines Zustands und seiner Leistung zu erstellen. Die Observability Ihres Systems hängt also zum Teil davon ab, wie gut Ihre Monitoring-Metriken die Leistungsindikatoren Ihres Systems interpretieren.

Ein weiterer wichtiger Unterschied zwischen Observability und Monitoring besteht darin, dass man beim Monitoring im Voraus wissen muss, was genau überwacht werden soll. Demgegenüber können Sie durch Observability feststellen, was wirklich wichtig ist, indem Sie die System-Performance über einen Zeitraum beobachten und relevante Fragen dazu stellen.

Observability ist wichtig, da Sie Ihnen mehr Kontrolle über komplexe Systeme gibt. Bei einfachen Systemen gibt es weniger bewegliche Komponenten, wodurch sie sich leichter managen lassen. Meist genügt das Monitoring von CPU-, Arbeitsspeicher-, Datenbank- und Netzwerkzustand, um diese Systeme zu verstehen und bei Problemen entsprechende Maßnahmen zu ergreifen.

Bei verteilten Systemen gibt es viel mehr ineinandergreifende Elemente, wodurch auch die Anzahl und Art möglicher Fehler höher ausfällt. Dazu kommt, dass verteilte Systeme ständig aktualisiert werden und bei jeder Änderung neue Arten von Fehlern entstehen können. In einer verteilten Umgebung ist das Verstehen eines akuten Problems eine enorme Herausforderung, vor allem, weil es mehr „unbekannte Unbekannte“ (unknown Unknowns) gibt als bei einfacheren Systemen. Da Monitoring „bekannte Unbekannte“ erfordert, können Probleme in solch komplexen Umgebungen mit Monitoring-Lösungen nicht adäquat angegangen werden.

Observability ist für die Unvorhersehbarkeit verteilter Systeme besser geeignet. Dies liegt vor allem an der Möglichkeit, beim Auftreten von Problemen Fragen zum Systemverhalten zu beantworten. „Warum ist X defekt?“ oder „Was verursacht momentan Latenz?“ sind zwei Beispiele für die Fragen, die sich durch Observability beantworten lassen.

Observability bei Containern und Microservices zeigt den Zustand von Anwendungen in der Produktion auf, sodass Entwickler Performance-Probleme besser identifizieren und beheben können.

Container-Services (wie Docker, Kubernetes und andere) sowie Microservices sind die Reaktion auf das erhöhte Risiko von Ausfallzeiten und andere Probleme im Zusammenhang mit monolithischer Software, bei der jede Änderung an der zentralen Codebasis die gesamte Anwendung und ihre Abhängigkeiten betrifft. Container und Microservices zerlegen Anwendungen in unabhängige Services und ermöglichen es dadurch Entwicklern, einen bestimmten Service anstelle der gesamten Anwendung zu ändern und neu bereitzustellen.

Eine Container-basierte Architektur bringt jedoch neue Herausforderungen mit sich. Voneinander abhängige Microservices sind üblicherweise auf mehrere Hosts verteilt, und mit zunehmender Skalierung der Infrastruktur steigt auch die Zahl der Microservices in der Produktionsversion. Dies macht es für Entwickler schwierig, den Überblick darüber zu behalten, was gerade in Produktion ausgeführt wird, was dann wiederum zu längeren Bereitstellungszyklen, Ausfallzeiten und anderen Problemen führt.

Observability ist die Lösung für diese Herausforderungen, da sie für Transparenz bei verteilten Systemen sorgt, wodurch Entwickler die Performance und Verfügbarkeit einer App besser einschätzen können. Bei einem Ausfall liefert Observability die notwendige Kontrolle, um das Problem schnell einkreisen und beheben zu können.

Die wichtigsten Datenkategorien für Observability sind Logs, Metriken und Traces. Zusammen werden sie oftmals als „die drei Säulen der Observability“ bezeichnet.

Logs: Ein Log ist eine in Textform vorliegende Aufzeichnung eines Events, das zu einem bestimmten Zeitpunkt stattgefunden hat. Das Log beinhaltet einen Zeitstempel, der den exakten Zeitpunkt des Auftretens des Events angibt, und eine Nutzlast, die Kontext liefert. Bei Logs gibt es drei mögliche Formate: unformatiert, strukturiert und binär. Unformatierter Text ist das gängigste Format, doch strukturierte Logs, die zusätzliche Daten und Metadaten enthalten und sich einfacher abfragen lassen, werden immer beliebter. In der Regel sieht man zuerst in den Logs nach, wenn in einem System ein Problem auftritt.

Metriken: Eine Metrik ist ein Zahlenwert, der über ein Zeitintervall gemessen wird und spezifische Attribute wie Zeitstempel, Name, KPIs und Wert beinhaltet. Im Gegensatz zu Logs sind Metriken standardmäßig strukturiert. Dies macht es einfacher, sie abzufragen und für die Speicherung zu optimieren, wodurch man sie länger aufbewahren kann.

Traces: Traces zeigen den vollständigen Weg einer Anfrage durch ein verteiltes System auf. Während sich eine Anfrage durch das Host-System bewegt, wird jede dafür durchgeführte Operation („Span“ genannt) mit wichtigen Daten kodiert, die sich auf den Microservice beziehen, der diese Operation ausführt. Anhand von Traces, die jeweils einen oder mehrere Spans enthalten, können Sie den Weg durch ein verteiltes System verfolgen und die Ursache eines Engpasses oder Ausfalls identifizieren.

Die Nutzung dieser Datenkategorien ist keine Garantie für Observability, insbesondere wenn Sie sie unabhängig voneinander auswerten oder unterschiedliche Tools für jede Funktion verwenden. Für einen erfolgreichen Observability-Ansatz sollten Sie vielmehr Ihre Logs, Metriken und Traces in eine einzige Observability-Lösung integrieren. Wenn Sie dies tun, verstehen Sie nicht nur, wann Probleme auftreten, sondern können sich sofort auf die Frage konzentrieren, warum die Probleme auftreten.

Um Observability zu erreichen, benötigen Ihre Systeme und Apps die entsprechenden Tools, um die passenden Telemetriedaten zu erfassen. Sie können die Observability verbessern, indem Sie eigene Observability-Tools erstellen, Open-Source-Software nutzen oder eine kommerzielle Observability-Lösung kaufen. In der Regel beinhaltet die Implementierung von Observability vier Komponenten:

• Instrumentierung: Hierbei handelt es sich um Messwerkzeuge, die Telemetriedaten von Containern, Services, Anwendungen, Hosts und anderen Komponenten Ihres Systems erfassen, um für Transparenz innerhalb der gesamten Infrastruktur zu sorgen.
• Datenkorrelation: Die aus Ihrem gesamten System gesammelten Telemetriedaten werden verarbeitet und korreliert. Durch diesen Kontext wird eine automatische oder benutzerdefinierte Datenkuratierung für Zeitreihenvisualisierungen ermöglicht.
• Incident Response: Diese Automatisierungstechnologien haben die Aufgabe, Daten über Ausfälle auf der Grundlage von Bereitschaftsplänen und technischer Qualifikation an die richtigen Personen und Teams weiterzuleiten.
• AIOps: Es werden Machine Learning-Modelle eingesetzt, um Incident-Daten automatisch zu aggregieren, zu korrelieren und zu priorisieren. So können Sie weniger relevante Benachrichtigungen herausfiltern, Probleme erkennen, die sich auf das System auswirken können, und die Incident Response beschleunigen.

Unabhängig davon, ob Sie sich für die Entwicklung einer eigenen Observability-Lösung entscheiden, Open Source oder kommerzielle Lösungen verwenden, sollten alle Observability-Tools folgende Kriterien erfüllen:

Integration mit aktuellen Tools: Wenn Ihre Observability-Tools nicht mit dem aktuellen Stack kompatibel sind, werden Ihre Observability-Bemühungen scheitern. Achten Sie drauf, dass die Observability-Tools die Frameworks und Sprachen in Ihrer Umgebung, die Container-Plattform, die Messaging-Plattform und andere kritische Software unterstützen.

Benutzerfreundlichkeit: Wenn Ihre Observability-Tools schwer zu erlernen oder zu verwenden sind, werden sie nicht in Workflows eingebunden und Ihre Observability-Initiative wird stagnieren.

Echtzeitdaten: Ihre Observability-Tools sollten die relevanten Erkenntnisse mittels Dashboards, Berichten und Abfragen in Echtzeit bereitstellen, damit sich Teams ein Bild von einem Problem, dessen Auswirkungen und den Möglichkeiten zur Lösung machen können.

Unterstützung moderner Event-Handling-Verfahren: Effektive Observability-Tools sollten in der Lage sein, alle relevanten Informationen aus Ihren Stacks, Technologien und Betriebsumgebungen zu erfassen, relevante von nicht relevanten Informationen zu trennen und genügend Kontext hinzuzufügen, damit Teams eine Auswertung vornehmen können.

Visualisieren aggregierter Daten: Observability-Tools sollten Erkenntnisse in gut verständlichen Formaten darstellen, wie z. B. in Form von Dashboards, interaktiven Zusammenfassungen und anderen Visualisierungen, die der Benutzer schnell erfassen kann.

Bereitstellen von Kontext: Bei einem Ereignis sollten Ihre Observability-Tools ausreichend Kontext liefern, damit Sie verstehen, wie sich die System-Performance über die Zeit verändert hat, wie diese Änderung mit anderen Änderungen im System zusammenhängt, welches Ausmaß das Problem hat und welche Abhängigkeiten beim betroffenen Service bzw. der betroffenen Komponente bestehen. Ohne den Kontext, den Observability ermöglicht, kann nicht optimal auf Incidents reagiert werden.

Einsatz von Machine Learning: Ihre Observability-Tools sollten Machine Learning-Modelle beinhalten, die die Datenverarbeitung und -kuratierung automatisieren. Nur so können Sie mithilfe von Observability Anomalien und andere Sicherheitsereignisse schneller erkennen und gezielt darauf reagieren.

Wertschöpfung: Bewerten Sie Ihr Observability-Tool unbedingt anhand von Metriken, die für Ihr Unternehmen wichtig sind, z. B. Bereitstellungsgeschwindigkeit, Systemstabilität und Kundenerfahrung.

Observability ermöglicht es DevOps-Entwicklern, sich zu jedem beliebigen Zeitpunkt ein Bild vom internen Zustand einer Anwendung zu machen, und bietet ihnen genauere Informationen über Systemfehler in verteilten Produktionsumgebungen. Zu den wichtigsten Vorteilen zählen:

Bessere Transparenz: Bei stark verteilten Systemen ist es für Entwickler oft schwierig, den Überblick darüber zu behalten, welche Services sich in Produktion befinden, wie die Anwendungs-Performance aussieht, wer für einen bestimmten Service zuständig ist oder wie das System vor der letzten Bereitstellung aussah. Durch Observability erhalten sie in Echtzeit Visibilität zu Produktionssystemen, was dazu beiträgt, diese Hindernisse zu beseitigen.

Bessere Benachrichtigungen: Observability hilft Entwicklern, Probleme schneller zu erkennen und zu beheben: Dies liegt daran, dass Observability für eine optimierte Visibilität sorgt, die es Entwicklern ermöglicht, schnell zu ermitteln, was sich im System geändert hat, Probleme zu debuggen oder zu korrigieren und festzustellen, ob bzw. welche Probleme diese Veränderungen verursacht haben.

Besserer Workflow: Durch Observability können sich Entwickler den gesamten Weg einer Anfrage ansehen und erhalten relevante kontextualisierte Daten zu einem bestimmten Problem, was wiederum den Untersuchungs- und Debugging-Prozess für eine Anwendung strafft und somit ihre Performance optimiert.

Weniger Zeit in Besprechungen: In der Vergangenheit mussten Entwickler mithilfe von Drittanbietern und Apps herausfinden, wer für einen bestimmten Service verantwortlich war oder wie das System Tage oder Wochen vor der letzten Bereitstellung aussah. Mit effektiver Observability stehen diese Informationen sofort zur Verfügung.

Höheres Entwicklungstempo: Observability sorgt für ein effizienteres Monitoring und Troubleshooting und schafft damit Freiräume für Entwickler. Dadurch führt Observability zu einer höheren Bereitstellungsgeschwindigkeit und mehr Zeit für DevOps-Mitarbeiter, um innovative Ideen zu entwickeln, von denen sowohl das Unternehmen als auch dessen Kunden profitieren.

Welche Vorteile hat Observability für die Softwareentwicklung?

Wie bei DevOps profitieren Softwareentwickler von Observability, da sie Einblicke in die gesamte Infrastruktur erhalten und sehen können, wie sich diese aufgrund eines Problems, durch die Bereitstellung neuer Software oder beim Hoch- bzw. Herunterskalieren verändert.

Einzelne Entwickler und Softwareingenieure profitieren von Observability wegen der optimierten Transparenz innerhalb der gesamten Architektur, egal ob bei eigenen Apps und Services oder bei Produkten von Drittanbietern. Observability ermöglicht ihnen also nicht nur, Probleme leichter zu beheben und letztendlich ganz zu vermeiden, sondern fördert auch ein tieferes Verständnis für die System-Performance und ihren Einfluss auf eine bessere Kundenerfahrung. Sowohl Entwickler als auch Ingenieure haben dank Observability mehr Zeit für strategische Initiativen, die dem Unternehmen Mehrwert generieren.

Auch Teams profitieren von der gemeinsamen Sicht auf die Umgebung, durch die ein vollständigeres Bild ihrer Architektur, ihres Zustands und ihrer Performance über einen längeren Zeitraum entsteht. Observability ermöglicht Entwicklern, Betriebspersonal, Ingenieuren, Analysten, Projektmanagern und anderen Teammitgliedern, auf dieselben Erkenntnisse über Services, Kunden und andere Systemelemente zuzugreifen. Außerdem bewirkt Observability genauere Prüfungen nach einem Incident, da alle Beteiligten dokumentierte Aufzeichnungen über das Echtzeit-Systemverhalten einsehen können, anstatt die Ereignisse aus einzelnen, isolierten Quellen zusammensuchen zu müssen. Konkrete Daten – nicht Meinungen – helfen Ihren Teams zu verstehen, warum bestimmte Ereignisse aufgetreten sind, damit sie zukünftige Incidents vermeiden bzw. besser darauf reagieren können.

Am meisten profitiert jedoch wahrscheinlich Ihr Unternehmen als Ganzes. Observability ermöglicht Ihnen, Änderungen an Ihren Apps und Services vorzunehmen, ohne die Stabilität Ihrer Systeme zu gefährden. Sie bietet Ihnen die nötigen Tools, mit denen Sie verstehen, was funktioniert und was nicht. Außerdem können Sie damit entstehende Probleme erkennen und diese schnell eindämmen oder beheben. Neue Funktionen gekoppelt mit weniger Ausfallzeiten führen zu zufriedeneren Kunden und letztlich auch zu einem besseren Geschäftsergebnis.

Observability ist mehr als ein Buzzword: Sie ist ein wichtiger und nützlicher Ansatz, mit dem Sie sich ein Bild vom Zustand Ihrer gesamten Infrastruktur verschaffen können. Durch die Cloud, Containerisierung, Microservices und andere Technologien sind Systeme heute deutlich komplexer als jemals zuvor. Unter dem Strich ist der Einfluss all dieser Technologien und Tools zwar durchaus positiv, doch die Nutzung, das Troubleshooting und die Verwaltung dieser Systeme sind mit Herausforderungen gespickt. Mehr interaktive Elemente führen zu einem größeren Spektrum an Problemen, die, wenn sie auftreten, schwieriger zu erkennen und zu beheben sind.

Glücklicherweise erzeugen solche verteilten Systeme eine Fülle von Telemetriedaten, mit denen man sich ein klareres Bild von ihrer Performance machen kann, sofern man die Daten sinnvoll nutzt. Effektive Observability-Tools bieten all die Instrumentierung und Analytik, die Sie benötigen, um die Outputs Ihres Systems zu erfassen, zu kontextualisieren und die nötigen Erkenntnisse daraus zu gewinnen. Obervability unterstützt Sie also aktiv dabei, in der Welt der modernen, verteilten Systeme auch in Zukunft erfolgreich bestehen zu können.