Sicherheit und Konnektivität im globalen Massstab zu betreiben heisst, Problemen nachzujagen, die sich selten klar ankündigen. Stattdessen flüstern sie durch subtile Muster: eine leicht erhöhte Ablehnungsrate, ein plötzlicher Anstieg von VPN-Logins oder ein flottenweiter CPU-Spike.

Vor einigen Jahren haben wir diese Signale noch einzeln behandelt. Das funktionierte – bis es irgendwann nicht mehr funktionierte. Zwischenfälle liessen sich nur im Nachhinein rekonstruieren, und grössere Muster blieben oft unbemerkt. Heute sammeln und analysieren wir Signale von rund 10’000 Edge-Geräten zentral. Damit erkennen wir Probleme früher und haben ein klareres Bild des Systems.

Dieser Artikel erzählt die Geschichte dieses Wandels vom klassischen Monitoring hin zur Observability. Ich zeige auf, welche Veränderungen wir vorgenommen haben, wie sie das Leben für Kunden und Ingenieure verbessert haben und wohin uns der Weg als Nächstes führt.

Ziel der Observability: Fehler schnell erkennen und verstehen

Observability gilt oft als Weiterentwicklung des Monitorings. Klassisches Monitoring bedeutete: Logs und Metriken sammeln, Dashboards auf Basis vergangener Incidents aufbauen und bekannte Fehlerbilder überwachen. Das funktioniert gut, solange sich die Geschichte wiederholt – doch sobald etwas Unerwartetes passiert, helfen diese Dashboards wenig. Root-Cause-Analysen beginnen dann bei jedem Vorfall praktisch bei null.

Observability verfolgt einen anderen Ansatz. Statt nur vordefinierte Checks für bekannte Fehler zu haben, ermöglicht sie, im Moment neue Fragen an das System zu stellen. Durch die Korrelation verschiedener Signale (Logs, Metriken, Traces) lassen sich Daten explorativ untersuchen und Zusammenhänge aufdecken.

Das Ziel ist einfach: Wenn ein Incident auftritt, schnell herausfinden, was sich verändert hat und was schiefgelaufen ist. Bei Open Systems konzentrieren wir uns darauf, die Observability-Reife zu erhöhen, um die Mean Time to Resolve (MTTR) zu senken – indem wir sowohl die Mean Time to Detect (MTTD) als auch die Diagnosezeit verkürzen.

Wir betrachten Observability als Gegenstück zur Kontrollierbarkeit. Beispiel: Ein Ofen ist ein System. Wir können dessen Zustand steuern, indem wir die Temperatur am Regler einstellen. Um jedoch den inneren Zustand zu verstehen, müssen wir eine System-Eigenschaft beobachten, etwa das Thermometer.

Skaliert man dieses Prinzip auf eine Webanwendung mit Frontend, Backend und Datenbank, kann das System in die unterschiedlichsten Zustände abgleiten. Als Ingenieur sieht man oft nur: „Ein Nutzer hat geklickt und etwas ist kaputt.“ Observability fragt: Lässt sich der Systemzustand aus den gesammelten Daten rekonstruieren? Wenn nicht, ist das System nicht wirklich beobachtbar – und die Lösung besteht darin, bessere Daten zu erheben.

Ursprung des Observability-Teams

Unser Schritt Richtung Observability war kein Trend, sondern eine Notwendigkeit. Mit der Verlagerung in die Cloud brauchten wir eine Lösung, die Edge-, On-Prem- und virtuelle Deployments gleichermassen abdeckt. Die Komplexität nahm zu: SASE verwischte die Grenzen zwischen Netzwerk und Sicherheit, hybrides Arbeiten vervielfachte die Anzahl der Edges, und Abhängigkeiten von Drittanbietern verschoben sich ständig.

In diesem Umfeld wurde Observability entscheidend. Indem wir heutige mit gestrigen Daten verglichen und sie entlang verschiedener Dimensionen aufschlüsselten, konnten wir den roten Faden zurückverfolgen und Ursachen klar erkennen.

In unserer Mission Control (unserem 24×7 Operations Center) arbeiteten Ingenieure jedoch noch Ticket für Ticket. Sie sahen ein Problem an einem Standort – übersahen aber, dass es gleichzeitig an anderen oder gar weltweit auftrat. Lokales Troubleshooting verdeckte globale Muster. Erst durch zentrale Analysen konnten wir die wahre Stärke der Daten nutzen. Bald war klar: Weniger Zeit für Erkennung und Diagnose bedeutet schnellere Lösungen.

Wir brauchten einen Weg, den Systemzustand von aussen zu verstehen – also Veränderungen anhand von Signalen zu rekonstruieren, die unsere Intuition speisen. Intern beschreiben wir das als Gegenstück zur Kontrollierbarkeit: Wenn Konfigurationsänderungen unsere Möglichkeit sind, auf das System einzuwirken, dann ist Telemetrie unser Mittel, es wahrheitsgetreu auszulesen. Und wenn uns das nicht gelang, wussten wir: Wir müssen bessere Signale sammeln.

Der erste Erfolg: Semantische Konventionen

Unser erster grosser Schritt war die Einführung von OpenTelemetry (OTel) – einem Open-Source-Standard zum einheitlichen Sammeln und Übermitteln von Logs, Metriken und Traces. Zunächst wirkte OTel wie „reine Infrastruktur“: Datenflüsse, Pipelines, Kollektoren. Doch die semantischen Konventionen waren der eigentliche Durchbruch.

There are only two hard things in Computer Science: cache invalidation and naming things.
— Phil Karlton

(Es gibt nur zwei wirklich schwierige Dinge in der Informatik: Cache-Invalidierung und das Benennen von Dingen.)

Die unscheinbaren Details – konsistente Benennungen für Hosts, Services, IPs oder HTTP-Statuscodes – machten den grössten Unterschied. Statt eigene Namensschemata zu erfinden, konnten wir auf eine gemeinsame Sprache zurückgreifen. Korrelationen werden einfacher, und Attribute wie http.response.status_code haben eine klare, dokumentierte Bedeutung.

Mit der Standardisierung von Instrumentierung und Namenskonventionen war der nächste Schritt, diese Daten auch zentral zu verschicken. Der OpenTelemetry Collector wurde unser Herzstück: ein vendorneutrales Agent-Framework, das flexibel Geräte, VMs oder Kubernetes unterstützt und Erweiterungen in Go ermöglicht.

Das Ergebnis: ein zentraler Gateway in Kubernetes, weniger komplexe Spezial-Agenten auf Edge-Geräten – und ein Telemetrie-Backbone, das wir weiterentwickeln können.

Logs, Traces – und der “Aha-Moment”

Als wir OTel bei Open Systems einführten, passierte anfangs – nichts. Die Leitungen standen, aber sie waren leer. Also gingen wir die ersten Schritte bewusst vorsichtig an.

Die ersten Migrationen liefen auf Kubernetes: Logs und Traces wanderten zu OTLP. Das Risiko war überschaubar – wenn etwas kaputtging, traf es Kollegen, nicht Kunden. Mit diesem Vertrauen begannen wir vorsichtig, Telemetrie-Agenten auf Kunden-Geräten auszutauschen – zunächst Syslogs. Als das stabil lief, folgten zwei grosse Schritte: Proxy-Logs und kurz darauf Firewall-Logs. Über Nacht verzehnfachte sich das Datenvolumen – und plötzlich floss fast alles zentral über OpenTelemetry.

Das war der „Aha-Moment“: Wir konnten die gesamte Flotte abfragen, statt Gerät für Gerät abzuklappern. Kubernetes-Autoscaling hielt den Gateway stabil, auch bei Lastspitzen.

Traces waren neu – und von Anfang an OTel-basiert. Die technische Umstellung war einfach, die organisatorische schwerer: Teams mussten ihren Code instrumentieren. Doch sobald der Nutzen sichtbar wurde, nahm die Akzeptanz rasant zu. Ein HTTP-500-Fehler, der wie ein Frontend-Bug aussah, entpuppte sich via Trace als Datenbank-Timeout drei Services tiefer.

Ein besonders schönes Beispiel: Heute reicht dem Frontend-Team oft die Trace-ID eines fehlerhaften Requests, die auf jeder Portal-Seite angezeigt wird. Damit lässt sich ein Problem in Minuten identifizieren – statt langwieriger Ping-Pong-Kommunikation.

Metriken: Der heikle Gebirgspass

Am schwierigsten war die Migration der Metriken. Sie bilden die Grundlage für Alerts, SLOs und Dashboards – kleine Änderungen können hier grosse Folgen haben. Da unser Stack alte und moderne Systeme vereint, war die Brücke zwischen Prometheus (flach) und OTel (verschachtelt) nicht trivial.

Unser Leitsatz: Namen und Label-Kardinalität bleiben stabil – oder wir migrieren nicht. Diese Disziplin bewahrte uns vor kaputten Dashboards und Fehlalarmen.

Zum Glück hat das Ökosystem aufgeholt: Prometheus unterstützt heute native OTLP-Ingestion, und OTel-Prometheus-Bridges sind gereift.

Mission Control: Was sich verändert hat

Die Vorteile für Kunden stellten sich schnell ein. Früher analysierte ein Ingenieur ein Ticket tiefgehend für einen Standort. Heute lautet der erste Schritt: „Passiert das Muster auch woanders?“ Eine einzige Abfrage für die gesamte Flotte erkennt Probleme, bevor fünf ähnliche Tickets eingehen.

Auch die Ergonomie hat sich verbessert: Statt Roh-Logs zu durchforsten, lassen sich Hypothesen überprüfen – etwa ob eine hohe Fehlerrate tatsächlich neu ist.

Oder, wie ein Kollege nach einer langen Schicht sagte:
„It’s abso-f%&|ng-lutely awesome! Das nutze ich jetzt jedes Mal in Mission Control.“*

Wir mussten grinsen – und haben einfach weitergebaut.

Was als nächstes kommt

Wir wollen Signale weiter vereinheitlichen und Korrelationen schärfen – damit vom ersten Hinweis bis zur Bestätigung der Ursache weniger Zeit vergeht. Das bedeutet: schnellere MTTD, reduzierte MTTR und damit schnellere Rückkehr zur Normalität.

Auch proaktive Benachrichtigungen rücken in den Fokus: globale Phänomene mit breiter Wirkung (z. B. DNS-Probleme über Regionen hinweg) erfordern andere Alerts als lokale Effekte (z. B. ein Temperaturanstieg durch defekte Klimaanlage).

Und: weniger Fehlalarme. Mit mehr Historie und klareren Semantiken können wir Muster von echten Anomalien unterscheiden.

Ein Beispiel, das den Punkt verdeutlicht

An einem Nachmittag schlug ein Firewall-Diagramm aus. Ein Spike bei abgelehnten Paketen deutete auf Probleme hin – aber ein Ausschlag in einer Grafik ist nur eine aggregierte Ansicht, keine Diagnose.

In der alten Welt folgte dann reines Rätselraten: Geräte-Logs durchforsten, nach Mustern suchen, nach IP, Service oder Port aufschlüsseln – und hoffen, dass die Vermutung stimmt. Logs sind wortreich, und selbst wenn verteilte Traces verfügbar waren, war der Kontext verstreut und nur schwer zusammenzusetzen.

In der neuen Welt öffnet ein Ingenieur die Flottenansicht, vergleicht heute mit gestern, filtert nach Region und sieht ein Muster – vielleicht ein einzelner DNS-Pfad, vielleicht eine kleine Gruppe von IPs. Er folgt dem Trace und findet den Schuldigen: eine externe Abhängigkeit, deren Verhalten sich verändert hat. Keine Schuldzuweisungen, keine verlorenen Stunden. Nur eine klare Antwort, eine sinnvolle Massnahme – und für alle wieder Zeit zurück.

The Road Ahead

Observability verwandelt Rätselraten in Entdeckung – schneller, klarer, kundenorientierter.

Fertig sind wir nie – und das mit Absicht. Observability bei Open Systems lebt und wächst. Wir schärfen Metriken, vertiefen Identitätskorrelationen über ZTNA, SWG, VPN und Firewall – und verwandeln immer mehr Insights in schutzrelevante Datenprodukte.

Unser Weg begann klein – mit semantischen Konventionen und vorsichtigen Migrationen. Das Entscheidende war nicht die Reihenfolge, sondern die Möglichkeit, mit OpenTelemetry Stück für Stück zu wachsen. Schon kleine Schritte können die Grundlage für echte Observability-Reife schaffen.

Für die Nutzer bleibt dieser Wandel unsichtbar.
Und genau so soll es auch sein.

Lust auf mehr Details? Schauen Sie sich meinen KubeCon Observability Day Talk an – dort erzähle ich von unseren Herausforderungen und den Lektionen auf dem Weg zu unserem Observability-Stack.