© melissandra / 123RF.com

Anfang 2024 hat Suse Stackstate, den Hersteller einer Observability-Plattform, geschluckt. Es dauerte ein wenig, bis man den Begriff erklären konnte.

Wer in der Umgebung von Katzen lebt, fühlt sich gelegentlich beobachtet. Nicht nur der gängige Haustiger, sondern gerade die Streuner nebenan erweisen sich oft als äußerst aufmerksam und beharrlich, wenn es um das Monitoring der Dosenöffner geht. Bei seinem Aufenthalt im Ferienhaus musste der Autor feststellen, dass die galizische Katzenkolonie hinter dem Haus offensichtlich einen Schichtplan erstellt hatte, um durch Küchen-, Wohn- und Schlafzimmerfenster zu beobachten, was der seltsame Deutsche in seiner Ferienwohnung so trieb – beispielsweise einen Artikel über Observability schreiben.

Vier Katzen teilten sich den anstrengenden Job des 24/7-Monitorings mit gelegentlichem Gähnen in der Novembersonne auf dem Schieferdach. Passierte etwas Außergewöhnliches wie das Abendessen, ging die Wächterin stiften oder holte Verstärkung. Selbstverständlich ausschließlich, um dann gemeinsam zu gaffen, “Kuck mal”. Klassisches Monitoring, Push und Pull inklusive.

Beobachtbarkeit

Seit einigen Jahren jedoch kursiert im Marketing des Monitoring-Umfelds ein weiterer Begriff: Observability [1], im Deutschen Beobachtbarkeit. Im Beispiel der galizischen Ferienwohnung ist die mehr als ausreichend gegeben, weil die Wohnung landestypisch die traditionell großen Fenster hat und der Ausguck den haarigen Kleintieren einen zentralen und umfassenden Überblick über die Aktivitäten des zu Beobachtenden verschafft. Anders als bei großen Unternehmensnetzen sind dafür in dem einfachen Beispiel außerdem keine Agenten oder Clients im Haus notwendig.

Wir halten fest: Observability ist eine Eigenschaft von Systemen, Werkzeuge wie Stackstate (Abbildung 1) dienen (wie auch das klassische Monitoring) der Automatisierung der Sicherheit, vor allem aber der Zuverlässigkeit von Systemen. Techniker und Devops-Experten übernehmen die damit verbundene die Arbeit. Ähnlich wie das innenliegende, vor den Katzenblicken geschützte Badezimmer des Feriendomizils ist die Entscheidungsfindung moderner LLMs für Monitoring völlig intransparent. Zur Beobachtbarkeit trägt das selbstverständlich nicht bei.

Die viel beschworenen angeblichen Schwierigkeiten, den Begriff Observability zu erklären, hat sich die Branche selbst eingebrockt. Weil das Monitoring immer komplexerer Systeme analog immer komplexer wurde, brauchte man eben einen neuen schicken Begriff der “alte von neuen Ideen zu separieren half”, schreibt beispielsweise die Wikipedia. Doch das ist nur die halbe Wahrheit. Observability ist ein Maß für die Überwachbarkeit.

Abbildung 1: Die Stackstate Observability-Plattform bei der Arbeit: Metadaten (1), Aktionen (2), Ressourcen (3), Monitore (4), Metriken (5) sowie Gesundheits- (6) und Event-Historie (7) des Ingress-Diensts in einem Kubernetes-Cluster. Quelle: Suse-Dokumentation, https://docs.stackstate.com/get-started/k8s-getting-started

Technische Definition

Technisch-wissenschaftlich stammt der Begriff aus der Kontroll- und Regelungstheorie, die Observability als Messlatte dafür definiert, wie gut sich der innere Zustand eines Systems über Informationen aus seinen Ausgaben herleiten lässt – analog zu deren Kontrollierbarkeit. Eingeführt hat das Konzept der Ungarisch-amerikanische Mathematiker Rudolf Emil Kálmán [2], manchen in der IT bekannt von den nach ihm benannten Kalman-Filtern [3] (bei denen die ungarischen Akzente offensichtlich auf der Strecke blieben) und der Kalman-Dekompositon. Mit deren Hilfe schätzt man nicht direkt messbare Größen auf Basis von bekannt fehlerbehafteten Outputs. Versucht, die Fehler quasi herauszurechnen und erhofft sich, so ein besseres Bild der beobachtbaren Zustände eines komplexen Systems zu bekommen. All das ist nicht neu, Kálmáns Arbeiten stammen teilweise aus den 1960er Jahren, seit den 70ern wurde der Stanford-Professor immer wieder für seine Arbeit mit Awards und Preisen ausgezeichnet, zuletzt im Jahr 2009 von Präsident Barack Obama mit der National Medal of Science.

O11y

Mit zunehmender Komplexität der Softwarewelt hielt der Begriff Observability in der IT Einzug, wobei viele ihn anfangs generell mit Monitoring gleichsetzten oder verwechselten. Ein Nerd-Kürzel gibt es ebenfalls: O11Y (sprich “Olli”), ähnlich wie K3s und K9s.

Vor allem in Clustern und ähnlichen Technologien des verteilten Rechnens fällt es nicht immer leicht, die inneren Zustände der komplexen Systeme von außen zu erfassen – KI- und LLM-Experten können davon ein Lied singen. Für Unternehmen wichtig wird Observability als ein Teil des Site Reliability Engineering (SRE) [4], einer eng mit Devops verwandten Strategie zur Schaffung zuverlässiger und skalierbarer Softwaresysteme, die Entwicklung und Betrieb zu kombinieren sucht.

Was messen?

Wer die Beobachtbarkeit messen will, braucht Kriterien. Bei vernetzten Computersystemen sind das Telemetriedaten. Drei Arten davon, Metriken, Systemprotokolle und Ablaufverfolgung (Metrics, Logs und Traces), gelten als die “Säulen” der Observability. Je mehr davon ein System hinterlässt, um so besser kann man auswerten, was passiert ist – eigentlich eine Binsenweisheit, die keinen Administrator überraschen wird. “Metriken alarmieren uns, Logs sagen uns, was passiert, und Traces zeigen uns, wie wir das Problem beheben können”, erklärt Lisa Jung, Senior Developer Advocate bei Grafana im Einführungsvideo [5].

Aus den Metriken kann der Admin Profile erstellen, die beispielsweise die Definition dessen enthalten, was “normales” Verhalten wäre. Auch das ist nichts Neues, Monitoring und Vorhersagen mit Prometheus lassen grüßen. Die Katzen im Beispiel oben könnten vielleicht aus dem veränderten Aussehen des Menschen Rückschlüsse darauf ziehen, was im Badezimmer passiert ist. Aber vielleicht ist das zu viel erwartet.

Neu ist dagegen, dass (auch die KI-)Algorithmen der letzten Jahre verstärkt dabei helfen können, diese Schritte zu automatisieren. Systeme lernen dann im Idealfall automatisch, was “normaler” Betrieb heißt und was nicht (mehr). Spannend wird das, wenn sich so automatisierte Observability-Stacks gegenseitig überwachen und herausfinden (wollen), was denn akzeptable Betriebsbedingungen sind, und ihre Vorhersagen machen.

Der Markt laut Gartner

So weit die Theorie. Auf dem Markt der Observability-Anwendungen haben sich seit Jahren etwa dieselben Player etabliert, die man vom Monitoring kennt. Grafana, Splunk, Dynatrace, Honeycomb, Chronosphere, aber auch IBM (Instana), Amazon, Microsoft und Oracle finden sich in Gartners Magic Quadrant für Observability Platforms. Red Hat und Canonical verfügen über eigene Plattformen, und 2024 erwarb Suse passend zur Susecon den niederländischen Experten Stackstate, um seiner neu vorgestellten Suse AI ein geeignetes Observability-Produkt zur Seite zu stellen [6].

Marktforscher und Berater Gartner weiß außerdem: “Observability-Plattformen wandeln Telemetriedaten in Einsichten und Handlungen um.” Ah ja. Dazu kämen verstärkt Analysen, Visualisierung, Automatisierung und zunehmend auch KI zum Einsatz. Die meisten Plattformen bringen auch Monitoring-Tools mit, aber das reine Applikationsüberwachen (Application Performance Management, APM [7]) genüge für Observability eben nicht mehr. Das richte sich hauptsächlich an vier Zielgruppen im Unternehmen: Operations, Engineering, Entwicklung und Business-Analysten. Und eine Observability-Plattform sollte mindestens drei Features besitzen: Sie muss Telemetriedaten, Logs und Traces verarbeiten können, Veränderungen selbstständig erkennen und darauf reagieren können sowie die angezeigten Daten eigenständig durch Kontext und Daten aus anderen Quellen anreichern und veranschaulichen können.

All das und viel mehr findet sich in Gartners Report zum “Magic Quadrant for Observability Platforms” [8]. Der “Hype Cycle for Monitoring and Observability 2024” zeugt dagegen gleich auf den ersten Seiten von Schwierigkeiten bei den Begriffsbestimmungen. Die Trends “AIOps platforms”, “Service operations” und “Native cloud monitoring” mussten umbenannt werden, aber dennoch seien vier von sieben Indikatoren auf dem aufsteigenden Ast. Auch nach einigen Jahren befindet sich das Thema Observability immer noch im Aufwärtstrend.

Fazit: Muss rein

Anfang des Jahres hat Suse den niederländischen Observability-Experten Stackstate übernommen und mittlerweile in Rancher Prime integriert, seine Management-Plattform für Kubernetes [9]. Für Andreas Prins, Ex-CEO von Stackstate und jetzt bei Suse für Observability zuständig, ist das Thema dann auch eine der sechs Säulen im Rancher-Container-Management und reiht sich ein neben Security, Lifecycle, Application Collection, Storage und Virtualization. Stackstate soll da Einblicke in die komplexe Welt der Container-Clouds bringen. “Full Stack Visibility” des gesamten “Native Cloud Estate”, die Buzzwords fliegen nur so, sollen frühzeitige Alarmierung und schnelle Reaktion ermöglichen. Man will weg von den Datensilos, Metriken automatisch korrelieren und so Entscheidungsgrundlagen bieten, möglichst automatisiert.

In Suse AI, der KI-Plattform für Kunden der Nürnberger Open-Source-Firma, soll Stackstate künftig als Suse Observability überwachen, was vor sich geht. “Die Katze hinter Ihnen ist quasi der Techniker, der seine Ziele erreicht. Mit Suse Observability fügen wir der Suse AI die Observability hinzu”, erklärt Prins. “Was zählt, ist Zuverlässigkeit, sonst nichts. Und wir machen die nachvollziehbar in Rancher und der Suse KI.”

Weil die Stoßrichtung der grünen KI ja in Richtung Compliance, Sicherheit und Nachvollziehbarkeit gehen soll, passt Stackstate auf den ersten Blick gut. Obgleich bei Suses KI-Produkt der Kunde selbst verantwortlich ist, etwa für Auswahl und Betrieb geeigneter KI-Modelle, möchte der Distributor eine sichere und zertifizierbare Plattform zur Verfügung stellen. Wie Stackstate sich da integriert und wie es Kubernetes-Admins, Management und Teams helfen kann, ihre Arbeit besser zu erledigen, hat Prins in zahlreichen Blogposts auf [10] beschrieben. Die Suse-Doku erläutert bereits umfangreich, wie man die Observability-Tools in Rancher Prime einbindet – selbstverständlich via Helm-Charts. (csi)