Definition „Beobachtbarkeit“ Was ist Observability?

Observability ist der Fachbegriff dafür, das Verhalten eines Systems mithilfe von außen erkennbaren Faktoren zu verstehen. Microservices bedeuten dabei jedoch eine besondere Herausforderung. Datenerhebung und ihre Analyse sind kompliziert.

Der Begriff Observability geht ursprünglich auf den Ingenieur Rudolf E. Kalman zurück. Dieser brachte ihn im Rahmen einer Arbeit zur Steuerungstheorie in linearen dynamischen Systemen auf. Dabei definierte er ihn als den Wert dafür, wie gut die inneren Zustände eines Systems durch von außen erkennbare Resultate abgeleitet werden können.

Vereinfacht gesagt: Lässt sich durch externe Messungen feststellen, ob ein Fehler vorliegt? Lässt sich möglicherweise sogar sagen, worum es sich handelt? Der Vorteil liegt auf der Hand: Das System muss nicht „blind“ aufgebohrt werden, um ein Problem zu beseitigen.

Observability und Software

Diese grundlegende Definition gilt bis heute für alle Bereiche. Sie wurde von Yuri Shkuro zudem um eine einfache Abgrenzung zum Monitoring ergänzt: Jenes ist demnach die Messung von Funktionen, die im Voraus entwickelt wurden. Bei der Observability geht es hingegen darum, Dinge zu ermitteln, die über das eigene System bislang unbekannt waren.

Oder, um es verkürzt und vereinfacht zu sagen: Das Monitoring informiert über ein Fehlverhalten. Die Observability fragt nach dem „Warum?“ hinter dem Problem. Im Software-Bereich gilt sie deshalb als Qualitätskriterium - ähnlich wie z.B. die Usability. Und in monolithischen Systemen ist der Umgang auch verhältnismäßig einfach.

Die SLIs (Service-Level-Indikatoren, die Funktionsgrad eines Dienstes bemessen) lassen sich leicht identifizieren. Fällt ein Wert ab, ist zugleich der Grund gefunden. Als Beispiel: Erfüllt ein Textverarbeitungsprogramm nicht mehr alle Funktionen, liegt ein Fehler im Code vor, wo es zum Ausfall kommt. Da es zu den SLOs (Service Level Objectives, Ziele zum Funktionsgrad eines Dienstes) gehört, dass alle Funktionen funktionieren, wird der Fehler ausgemerzt.

Observability und Microservcies

Monolithische Systeme werden allerdings immer seltener. An ihre Stelle treten Microservices. Diese werden oft gemeinsam von unterschiedlichen Cloud-Diensten bereitgestellt. Eine Flut von Daten entsteht. Es ist häufig schwierig, deren Herkunft und ihren genauen Zweck zu bestimmen. Oft werden deshalb deutlich zu viele Informationen für die Observability erhoben. In anderen Fällen sind es viel zu wenige.

Als Beispiel sei eine Smartphone-App genannt, die mit einem Cloud-Dienst verbunden ist. Zugleich nutzt die Cloud des Anbieters des Betriebssystems, um den Nutzer zu authentifizieren und um mit dem Rest des Geräts zu interagieren. Folgende Probleme sind nicht ungewöhnlich, aber bereiten für die Zuordnung von Daten zur Observability große Probleme:

• Soll die Login-Zeit gemessen werden, obwohl der Nutzer typischerweise nicht ausgeloggt wird?

• Bestimmte Funktionen, die über das Betriebssystem bereitgestellt werden (z.B. Copy and Paste) funktionieren nicht in der App - wie soll dies berücksichtigt werden?

• Die Ladezeiten der App unterscheiden sich zwischen Nutzern stark, obwohl diese das identische Gerätemodell nutzen - was bedeutet dies?

• Logfiles werden nicht vollständig erhoben oder liefern nicht die zuständigen Informationen?

Observability-Werkzeuge in den Microservices

Um dieses Problem zu lösen, ruhen Observability-Werkzeuge auf drei Säulen, die in den Microservices arbeiten. Sie fließen zusammen, sollen aber für das einfache Verständnis getrennt genannt sein.

Erstens werden Metriken genutzt – alles, was gemessen werden kann, wird auch gemessen. Zweitens werden aber zudem Traces als Teil des Application Performance Managements ermittelt. Vereinfacht gesagt werden die „Spuren“ als Wege nachgezeichnet, die Funktionen nehmen. Die Messpunkte werden auf diesen vermerkt. Drittens werden die Logs ausgewertet. Dies sind die Protokolle bisheriger Aktionen.

Durch diese Säulen lässt sich im Rahmen der Microservices auswerten wie gut ein Dienst funktioniert, wo er abläuft, wie er sich in der Vergangenheit verhalten hat und mit wem er zusammenspielt. Der Bedarf an Rechenleistung ist allerdings so hoch, um diesen Prozess dauerhaft durchzuführen, dass er im Alltag praktisch nur durch die Entwickler selbst geschehen kann.

(ID:47305636)