Observability ist ein Maß dafür, wie gut interne Zustände oder Bedingungen eines Systems ausschließlich von der Kenntnis seiner externen Ausgaben abgeleitet werden können. Je besser ein System beobachtbar ist, desto schneller und genauer kann bei einem festgestellten Leistungsproblem auf dessen eigentliche Ursache geschlossen werden, und zwar ohne zusätzliche Tests oder weitere Codierung.

In der IT und im Cloud-Computing bezieht sich das Konzept Observability auch auf Software-Tools und Verfahren zum Aggregieren, Korrelieren und Analysieren eines stetigen Stroms von Leistungsdaten aus einer verteilten Anwendung sowie der Hardware und des Netzes, auf der bzw. in dem die Ausführung erfolgt. Es geht darum, die Anwendung und das Netz effektiver zu überwachen, nach Fehlern zu suchen und die gefundenen Fehler zu beheben, um Erwartungen an das Kundenerlebnis, Service-Level-Agreements (SLAs) und andere geschäftliche Anforderungen zu erfüllen.

Als vergleichsweise neues Thema in der IT wird Observability oft fälschlicherweise als überbewertetes Schlagwort oder als „Rebranding“ für die Überwachung des Systems, die Überwachung der Anwendungsleistung (Application Performance Monitoring, APM) und das Management der Netzleistung (Network Performance Management, NPM) bezeichnet. In Wirklichkeit ist Observability eine logische Weiterentwicklung von APM- und NPM-Datenerfassungsmethoden, die dem Wesen der immer schnelleren, verteilten und dynamischen cloudnativen Anwendungsbereitstellungen besser Rechnung trägt. Observability ersetzt keineswegs die Überwachung – sie ermöglicht vielmehr bessere Überwachung sowie eine bessere Überwachung der Anwendungsleistung (APM) und ein besseres Management der Netzleistung (NPM).

Der Begriff „Observability" stammt aus der Regelungstheorie, einem Bereich der Technik, der sich – basierend auf Rückmeldungen des Systems – mit der Automatisierung der Steuerung eines dynamischen Systems befasst, wie z. B. dem Durchfluss von Wasser in einer Leitung oder der Geschwindigkeit eines Autos bei Steigungen und Gefällen.

In den letzten 20 Jahren haben sich IT-Teams überwiegend auf APM verlassen, um Anwendungen zu überwachen und Fehler zu beheben. Bei APM, der Überwachung der Anwendungsleistung, werden in einem als Telemetrie bezeichneten Verfahren in regelmäßigen Abständen Stichproben von jenen Anwendungs- und Systemdaten entnommen, die erfahrungsgemäß in Zusammenhang mit Problemen der Anwendungsleistung stehen. APM analysiert die Telemetrie mit Bezug auf wichtige Leistungsindikatoren (Key Performance Indicators, KPIs) und stellt die Ergebnisse in einem Dashboard zusammen, um Betriebs- und Support-Teams auf Unregelmäßigkeiten aufmerksam zu machen, die zur Lösung oder Vermeidung von Problemen untersucht werden sollten.

APM ist hinreichend effektiv, wenn es um die Überwachung und Fehlersuche bei monolithischen Anwendungen oder traditionellen verteilten Anwendungen geht, bei denen neuer Code regelmäßig freigegeben wird und Workflows sowie Abhängigkeiten zwischen Anwendungskomponenten, Servern und zugehörigen Ressourcen bekannt oder aber ohne großen Aufwand nachzuverfolgen sind.

Heutzutage führen Unternehmen jedoch zügig moderne Entwicklungsverfahren ein – agile Entwicklung, Continuous Integration und Continuous Deployment (CI/CD), DevOps, mehrere Programmiersprachen – und cloudnative Technologien wie z. B. Microservices, Docker-Container, Kubernetes und serverlose Funktionen. Infolgedessen bringen sie mehr Services schneller denn je auf den Markt. Dabei werden neue Anwendungskomponenten jedoch so oft, an so vielen Orten, in so vielen verschiedenen Sprachen und über so unterschiedliche Zeiträume (über Sekunden oder Sekundenbruchteile im Fall von serverlosen Funktionen) bereitgestellt, dass die einmal pro Minute erfolgende Datenerfassung von APM nicht mithalten kann.

Gefragt sind qualitativ hochwertigere Telemetriedaten, und das in sehr viel größerem Umfang, die zur Erstellung eines hochpräzisen kontextreichen, vollständig korrelierten Datensatzes jeder Anforderung oder Transaktion eines Anwendungsbenutzers verwendet werden können. Und genau da kommt die Observability ins Spiel.

Observability Plattformen decken kontinuierlich Leistungstelemetriedaten auf und erfassen diese, indem sie sich in die bestehende, in Anwendungs- und Infrastrukturkomponenten integrierte Instrumentierung einfügen und indem sie Tools zum Hinzufügen von Instrumenten zu diesen Komponenten bereitstellen. Observability konzentriert sich auf vier Haupttypen von Telemetrie:

• Protokolle. Protokolle sind differenzierte, mit einem Zeitstempel versehene vollständige und unveränderliche Aufzeichnungen von Anwendungsereignissen. Protokolle können unter anderem verwendet werden, um eine hochpräzise, auf die Millisekunde genaue Aufzeichnung von jedem Ereignis zusammen mit Umgebungskontext zu erstellen, die Entwickler zur Fehlersuche und Fehlerbehebung quasi „abspielen“ können.
• Metriken. Metriken (gelegentlich auch „Zeitreihenmetriken“ genannt) sind grundlegende Messgrößen für den Anwendungs- und Systemzustand über einen bestimmten Zeitraum hinweg und geben beispielsweise an, wie viel Speicher- oder CPU-Kapazität eine Anwendung über einen Zeitraum von fünf Minuten belegt oder wie hoch die Latenz einer Anwendung bei einer Auslastungsspitze ist.
• Traces. Traces zeichnen den „Reiseverlauf“ jeder Benutzeranforderung durchgängig von der Benutzerschnittstelle (UI) oder mobilen Anwendung durch die gesamte verteilte Architektur und zurück zum Benutzer auf.
• Abhängigkeiten (auch Abhängigkeitszuordnungen genannt) zeigen auf, wie jede Anwendungskomponente von anderen Komponenten, Anwendungen und IT-Ressourcen abhängig ist.

Nach der Erfassung dieser Telemetrie korreliert die Plattform sie in Echtzeit, um DevOps-Teams, Site Reliability Engineering-Teams (SRE-Teams) und IT-Personal vollständige Informationen mit Kontext bereitzustellen – das Was, Wo und Warum eines Ereignisses, das auf ein Problem bei der Anwendungsleistung hinweisen, es verursachen oder zur Behebung dieses Problems genutzt werden könnte. 

Viele Observability Plattformen erkennen automatisch neue Telemetriequellen, die innerhalb des Systems auftauchen können (wie etwa ein neuer API-Aufruf für eine andere Softwareanwendung). Da sie mit so viel mehr Daten arbeiten als eine APM-Standardlösung, verfügen viele Plattformen über AIOps-Funktionen (künstliche Intelligenz für den Betrieb), die die eigentlichen Signale – Hinweise auf reale Probleme – vom Rauschen (Daten ohne Bezug zu Problemen) trennen.

Der übergeordnete Vorteil der Observability lässt sich wie folgt zusammenfassen: Bei ansonsten gleichen Bedingungen ist ein besser beobachtbares System einfacher zu verstehen (im Allgemeinen und im Detail), es ist einfacher zu überwachen, es lässt sich einfacher und sicherer mit neuem Code zu aktualisieren und es ist einfacher zu reparieren als ein weniger beobachtbares System. Genauer gesagt, liefert Observability die direkte Unterstützung der Agile-/DevOps-/SRE-Ziele, qualitativ hochwertigere Software schneller bereitzustellen, indem sie einem Unternehmen Folgendes ermöglicht:

• Erkennung und Behebung von „nicht bekannten Unbekannten“ – d. h. von Problemen, von deren Existenz man nichts weiß. Eine wesentliche Einschränkung bei Überwachungstools ist, dass sie nach „bekannten Unbekannten“ Ausschau halten – nach Ausnahmebedingungen, die man bereits auf dem Schirm hat. Observability erkennt Bedingungen, die man vielleicht nie kennen oder nach denen man nie suchen würde, verfolgt dann deren Beziehung zu bestimmten Leistungsproblemen und stellt den Kontext zur Identifizierung der eigentlichen Ursachen bereit, um die Problemlösung zu beschleunigen.
• Erkennung und Lösung von Problemen in einem frühen Stadium der Entwicklung. Observability integriert die Überwachung in die frühen Phasen des Softwareentwicklungsprozesses. DevOps-Teams können Probleme in neuem Code erkennen und beheben, bevor sie sich auf das Kundenerlebnis oder auf SLAs auswirken.
• Automatische Skalierung der Observability. Sie können beispielsweise die Instrumentierung und Datenaggregation als Teil der Konfiguration eines Kubernetes-Clusters festlegen und Telemetriedaten ab dem Hochfahren des Clusters bis zu seinem Herunterfahren erfassen lassen.
• Aktivierung der automatischen Korrektur und automatische Fehlerbehebung der Anwendungsinfrastruktur. Durch Kombination von Observability mit maschinellem Lernen und Automatisierungsfunktionen von AIOps können Probleme basierend auf Systemausgaben vorhergesagt und ohne Eingriff durch das Management behoben werden.