Von Metriken zu Unknown Unknowns: Observability im Uber-Klon

Abstract

Verteilte Microservice-Architekturen ermöglichen hohe Skalierbarkeit, erschweren jedoch Betrieb und Fehlersuche, da klassisches Monitoring den Zusammenhang zwischen den vielen Services in Ultra-Large-Scale-Systemen nur unzureichend abbildet. Diese Arbeit konzipiert ein integriertes Monitoring-, Tracing- und Observability-Framework am Beispiel eines Uber-ähnlichen, verteilten Ride-Sharing-Systems. Dabei werden SLO-basiertes Alerting, Distributed-Tracing-Konzepte mit angepasster Sampling-Strategie sowie eine auf OpenTelemetry gestützte, herstellerunabhängige Gesamtarchitektur zur Trennung von Metriken, Traces und angereicherten Events entworfen. Die Konzeption orientiert sich an realen Architekturentscheidungen etablierter ULS-Anbieter und wägt bewusst Kompromisse zwischen Kosten, Datenkardinalität, Konsistenz und Betriebsaufwand ab. Die Ergebnisse zeigen, dass Observability in diesem Kontext nicht als einzelnes Werkzeug, sondern als übergreifende, technisch wie kulturell verankerte Systemeigenschaft verstanden werden muss. Die Arbeit schließt mit einer kritischen Würdigung der organisatorischen Voraussetzungen sowie einem Ausblick auf eBPF-basierte Instrumentierung und KI-gestützte Observability-Werkzeuge ab.

Index Terms — Observability, Monitoring, Distributed Tracing, Ultra-Large-Scale-Systeme, Microservices, SLO, SLI, Error Budget, OpenTelemetry, M3, Jaeger, ClickHouse, Sampling, SRE.

Einleitung

Moderne Softwaresysteme basieren zunehmend auf verteilten Microservice-Architekturen, die zwar hohe Skalierbarkeit ermöglichen, jedoch den Betrieb und die Fehlersuche deutlich erschweren. Klassisches Monitoring stößt dabei schnell an seine Grenzen, da es den Zusammenhang zwischen den Services in hochverteilten Systemen nur unzureichend abbilden kann. Mittels einer Full-Stack Observability versucht man dieses Problem mittels Metriken, Logs und Distributed Tracing zu lösen und tiefere Einblicke in das Systemverhalten zu ermöglichen [1].

Ein anschauliches Beispiel für die Relevanz dieser Thematik ist der AWS-Ausfall vom 7. Dezember 2021 in der Region US-East-1. Eine interne Störung führte dort zu Kaskadeneffekten, die weltweit zahlreiche Dienste wie Netflix, Reddit oder Disney+ für mehrere Stunden beeinträchtigten [2]. Besonders kritisch war dabei, dass Monitoring- und Statussysteme zeitweise keine zuverlässigen Informationen lieferten [3]. Der Vorfall verdeutlicht, wie schnell kleine technische Probleme großflächige Auswirkungen haben können, insbesondere wenn Observability nicht zuverlässig funktioniert.

Zielsetzung & Abgrenzung

Im Rahmen dieses Projekts wurde ein Uber-ähnliches System konzipiert, das auf einer verteilten Microservice-Architektur basiert. Ziel dieser Arbeit ist es, die Konzepte Monitoring, Tracing und Observability innerhalb einer solchen Architektur zu analysieren und geeignete Lösungen für die Überwachung und Fehleranalyse zu entwerfen.

Dabei soll untersucht werden, wie sich Requests über mehrere Services hinweg nachvollziehen lassen, wie Metriken und Logs zentral gesammelt werden können und wie Fehler frühzeitig erkannt werden.

Diese Arbeit konzentriert sich hierbei ausschließlich auf die Themen Monitoring, Distributed Tracing und Observability innerhalb der konzipierten Systemarchitektur. Die vollständige Implementierung eines produktiven Ride-Sharing-Systems ist nicht Bestandteil der Arbeit. Funktionale Anforderungen werden lediglich soweit betrachtet, wie sie für das Verständnis der Datenflüsse und der Observability relevant sind.

Ebenso liegt der Fokus nicht auf der detaillierten Implementierung einzelner Tools, sondern auf deren architektonischer Einordnung und dem Zusammenspiel innerhalb eines verteilten Systems.

I. Monitoring

Monitoring bezeichnet die kontinuierliche Beobachtung eines Systems anhand vorab definierter Metriken und Schwellwerte und beantwortet damit die Frage, ob ein System wie erwartet läuft. Der grundlegende Ablauf ist dabei reaktiv: Eine Metrik wird gemessen, bei Überschreiten eines Schwellwerts oder Erkennen einer Anomalie wird ein Alert ausgelöst, auf den eine Reaktion folgt. Monitoring zeigt somit, dass ein Problem vorliegt, während die Fragen nach dem Wo (Kapitel II) und dem Warum (Kapitel III) durch Distributed Tracing und Observability beantwortet werden. Es bildet dabei das Fundament der gesamten Observability, da ohne eine stabile Metrik- und Alerting-Pipeline auch nachgelagerte Analysewerkzeuge keinen Mehrwert liefern. In einer Microservice-Architektur mit tausenden Services, wie sie dem betrachteten Uber-Klon zugrunde liegt, erfordert dies eine dedizierte und horizontal skalierbare Infrastruktur [4].

I.I Metriken, SLIs und SLOs

Metriktypen als Grundlage

Metriken sind aggregierte numerische Zeitreihen wie Request-Rate, Latenz, Fehlerrate oder CPU-Auslastung. Für das Verständnis der weiteren Konzepte ist eine Unterscheidung der drei grundlegenden Metriktypen hilfreich [5]:

• Counter: Ein monoton steigender Wert, der nur bei einem Neustart auf null zurückgesetzt wird. Er eignet sich etwa für die Gesamtzahl bearbeiteter Requests oder aufgetretener Fehler, nicht jedoch für Werte, die auch sinken können.
• Gauge: Ein aktueller Wert, der beliebig steigen und fallen kann, beispielsweise die CPU-Auslastung, die Länge einer Queue oder die Anzahl gleichzeitiger Requests.
• Histogram: Zählt Beobachtungen in konfigurierbaren Buckets und speichert zusätzlich deren Summe und Gesamtzahl. Auf dieser Basis lassen sich serverseitig Perzentile wie p95 oder p99 berechnen, was insbesondere für Latenz-Metriken zentral ist [6].

Die Instrumentierung dieser Metriken erfolgt über OpenTelemetry, wodurch der Code nur einmal instrumentiert werden muss und das Backend – etwa M3, Prometheus oder Datadog – austauschbar bleibt.

Service Level Indicator (SLI)

Ein Service Level Indicator ist eine messbare Qualitätskennzahl aus Nutzerperspektive und wird formal als Verhältnis von erfolgreichen zu allen validen Ereignissen innerhalb eines Zeitfensters ausgedrückt [7]. Typische SLIs sind Request-Latenz, Fehlerrate, Verfügbarkeit und Durchsatz. Für Latenz-SLIs werden dabei bewusst Perzentile statt des Durchschnitts verwendet, da der Mittelwert Ausreißer verdeckt: Erhalten etwa ein Prozent der Nutzer zehnfach langsamere Antworten, bleibt der Durchschnitt unauffällig, während p95 und p99 die Erfahrung der langsamsten Nutzer sichtbar machen – aus Sicht des Site Reliability Engineering (SRE) häufig die relevanteste Gruppe [7].

Bei Uber entstehen aus diesem Ansatz besondere Herausforderungen: Die verwendeten SLIs sind hochdimensional, das heißt, Metriken werden nach Attributen wie Route, Region, Stadt, Status-Code und Betriebssystem getaggt. Eine einzige Metrik-Emission kann dadurch bis zu 100 Millionen einzigartige Zeitreihen erzeugen [8]. Klassische Werkzeuge wie Graphite oder Prometheus stoßen bei dieser Kardinalität an ihre Grenzen, was Ubers Eigenentwicklung M3 motiviert (siehe Abschnitt I.III).

SLO, Error Budget und Burn Rate

Ein Service Level Objective (SLO) definiert einen Zielwert für einen SLI über ein festgelegtes Zeitfenster. Es beschreibt bewusst ein „gut genug“ und keine hundertprozentige Zuverlässigkeit, da jede weitere „Neun“ exponentiell teurer wird und die Weiterentwicklung von Funktionen verdrängt [7]. Ein typisches SLO wäre beispielsweise, dass die p95-Latenz über 30 Tage zu 99,5 % unter 300 ms bleibt.

Aus dem SLO ergibt sich das Error Budget als erlaubte Fehlerquote, definiert als 1 − SLO. Ein SLO von 99,9 % entspricht somit einem Budget von 0,1 %, was etwa 43 Minuten Ausfallzeit pro Monat erlaubt [9]. Dieses Budget überführt den Zielkonflikt zwischen Zuverlässigkeit und Release-Geschwindigkeit in eine datenbasierte Entscheidung: Ist das Budget aufgebraucht, wird der Fokus auf Stabilisierung gelegt; ist noch Budget vorhanden, sind neue Deployments vertretbar. Die Burn Rate beschreibt, wie schnell das Budget verbraucht wird, und bildet die Grundlage für modernes SLO-basiertes Alerting (vgl. Abschnitt I.II). In der Praxis wird dabei meist ein rollierendes 30-Tage-Fenster einem Kalendermonat vorgezogen [10].

Von diesen Konzepten ist das Service Level Agreement (SLA) abzugrenzen: Während das SLA einen extern vereinbarten, vertraglichen Zielwert gegenüber Kunden darstellt und dessen Verletzung Konsequenzen wie Vertragsstrafen nach sich zieht, ist das SLO ein internes Ziel, das bewusst strenger als das SLA gewählt wird, um einen Puffer zu schaffen. Der SLI ist die zugrunde liegende Messgröße, auf der beide aufbauen [7].

Abbildung 1: SLO-Schwelle und Alert-Auslösung am Beispiel einer Fehlerrate.

I.II Alerting-Strategie

Grundprinzipien

Eine zentrale Herausforderung des Alertings ist das Verhältnis von Signal zu Rauschen. Zu viele Alerts führen zu einer sogenannten Alert Fatigue: Engineers stumpfen ab und übersehen echte Incidents. Wie real dieses Problem bei großen Systemen ist, zeigt ein Beispiel von Uber, bei dem im Rahmen der Überwachung von Buchungszahlen über 2.000 Städte innerhalb von zehn Tagen 232 Anomalien gemeldet wurden, von denen sich lediglich elf als echt erwiesen – ein Rauschanteil von 95 % [11]. Alerts sollten daher stets actionable sein, also eine klare Handlungsanweisung und einen definierten Verantwortlichen besitzen. Ein weiteres SRE-Prinzip besteht darin, auf nutzersichtbare Symptome zu alarmieren („Nutzer erhalten Fehler“) statt auf mögliche Ursachen („Disk-IO ist hoch“), da Letztere häufig Rauschen erzeugen und nicht zwingend nutzerrelevant sind [4]. Nach Dringlichkeit wird zudem gestaffelt: Alerts hoher Priorität lösen einen Page an den On-Call-Engineer aus, Alerts niedriger Priorität werden lediglich über Slack oder E-Mail zugestellt.

Alerting-Typen im Vergleich

In der Praxis lassen sich drei Alerting-Typen unterscheiden. Statische Schwellwerte folgen der einfachen Regel „Metrik > X → Alert“. Sie sind transparent und eignen sich gut für stabile Infrastruktur-Metriken wie CPU- oder Disk-Auslastung, ignorieren jedoch Tageszeit, Wochentag und saisonale Muster. Anomaly Detection nutzt hingegen dynamische, aus historischen Daten gelernte Schwellwerte und berücksichtigt dadurch zyklische Effekte wie Nachfragespitzen zu bestimmten Uhrzeiten oder an einzelnen Flughäfen; sie ist dafür schwerer nachvollziehbar und zu debuggen. SLO-basiertes Alerting schließlich löst aus, wenn das Error Budget zu schnell verbraucht wird, und besitzt damit einen direkten Bezug zur Nutzerauswirkung, erfordert aber solide SLI-Definitionen [12].

Für das SLO-basierte Alerting empfiehlt das SRE-Workbook ein Multi-Window-Multi-Burn-Rate-Verfahren, das zwei Zeitfenster (etwa eine Stunde und sechs Stunden) kombiniert, um schnelle, tatsächliche Incidents von kurzen Spitzen zu unterscheiden und so sowohl eine hohe Precision als auch einen hohen Recall bei kurzer Detection Time zu erreichen [12]. Bei Uber werden die für zyklische Business-Metriken nötigen dynamischen Schwellwerte über die Anomaly-Detection-Plattform Argos beziehungsweise den Forecasting-Layer F3 erzeugt [13]. Das damit verbundene Nachvollziehbarkeitsproblem adressiert Uber über ein Alert-Backtesting, bei dem eine Alert-Konfiguration im Trockenlauf gegen historische Produktionsdaten geprüft wird, bevor sie aktiv wird [14].

I.III Ubers Monitoring-Stack: M3, uMonitor und Neris

Ubers Monitoring-Stack veranschaulicht, warum klassische Werkzeuge bei Ultra-Large-Scale-Systemen an ihre Grenzen stoßen und eine Eigenentwicklung notwendig wird. Ursprünglich setzte Uber auf Nagios, das Graphite-Schwellwertprüfungen gegen Carbon-Metriken ausführte. Mit dem Wachstum des Unternehmens erwies sich dieser Ansatz aufgrund von Skalierungsproblemen des Carbon-Clusters als nicht mehr tragfähig, woraufhin eine eigene Plattform entwickelt wurde [13].

Das Metriken-Backend M3 wurde ab 2014/2015 entwickelt und als Open-Source-Projekt veröffentlicht. Es ist nativ für extreme Kardinalität und horizontale Skalierung ausgelegt und besteht im Kern aus drei Komponenten: der verteilten Zeitreihendatenbank M3DB mit invertiertem Index, dem Prometheus-kompatiblen M3 Coordinator für das Query- und Write-Routing sowie dem M3 Aggregator für Aggregation und Downsampling vor dem Schreiben. Zur Einordnung der Größenordnung: M3 aggregiert rund 500 Millionen Metriken pro Sekunde, persistiert etwa 20 Millionen davon pro Sekunde und verwaltete bereits 2018 über 6,6 Milliarden Zeitreihen. Der wesentliche Grund für die Eigenentwicklung war, dass kommerzielle und quelloffene Werkzeuge dieses Datenvolumen nicht zu vertretbaren Kosten verarbeiten konnten [15].

Auf M3 setzt das hauseigene Alerting-System uMonitor auf, das Nagios ablöste. Es verwaltet rund 125.000 Alert-Konfigurationen und prüft dabei etwa 700 Millionen Datenpunkte über 1,4 Millionen Zeitreihen pro Sekunde. Architektonisch besteht uMonitor aus drei Komponenten: einem Storage-Service, der Alert-Definitionen und deren State-Machine in Cassandra ablegt, einem Scheduler, der die Prüfungen etwa im Minutentakt anstößt, und Workern, welche die Prüfungen ausführen. uMonitor unterstützt sowohl statische als auch anomaliebasierte Schwellwerte [16].

Ergänzt wird uMonitor durch Neris, ein Host-Level-Alerting für hochauflösende Host-Metriken, die nicht in M3 gespeichert werden. Da pro Rechenzentrum etwa 1,5 Millionen Host-Metriken pro Minute über 40.000 Hosts anfallen, prüft Neris direkt auf dem jeweiligen Host statt gegen eine zentrale Datenbank und vermeidet so unnötigen Ingest- und Speicheraufwand [16]. Beide Systeme münden in eine gemeinsame Benachrichtigungs-Pipeline, in der die Deduplizierungs-Komponente Origami Alerts etwa nach Stadt, Produkt oder App-Version bündelt und dadurch ein Alert-Flooding bei Kaskaden-Failures verhindert. Zusätzlich testet die Komponente Blackbox die API-Infrastruktur von außerhalb Ubers und erkennt so Probleme, die interne Metriken nicht sichtbar machen [13].

Für die Erkennung von Incidents ist die Minimierung der Mean Time to Detect (MTTD) entscheidend, da eine proaktive Erkennung stets einer Meldung durch Nutzer vorzuziehen ist. Da ein Großteil der Incidents durch Deployments verursacht wird, erkennt uMonitor den Zeitpunkt einer Änderung und kann automatisch den verantwortlichen Change-Owner kontaktieren. Die ausgelösten Benachrichtigungen lassen sich zudem mit Trace-Links aus Jaeger anreichern, wodurch der Übergang von der Erkennung zur Ursachenanalyse mittels Distributed Tracing (Kapitel III) vorbereitet wird [13].

Abbildung 2: Ubers Alerting-Pipeline (nach [13]).

I.IV Umsetzung im Uber-Klon

Für den Uber-Klon wird als Metriken-Backend ein M3-basierter Stack gewählt, da dieser für hohe Kardinalität und horizontale Skalierung ausgelegt ist – genau die Anforderung, die aus den hochdimensionalen SLIs eines solchen Systems entsteht. Prometheus allein skaliert bei dieser Kardinalität nicht ausreichend, da es an die Grenzen einzelner Knoten und des verfügbaren Arbeitsspeichers stößt, während SaaS-Lösungen wie Datadog oder New Relic bei diesem Datenvolumen prohibitiv teuer sind und ein Vendor Lock-in bedeuten [15].

Für das Alerting wird ein Konzept eingesetzt, das SLIs kontinuierlich gegen ihre SLOs prüft und bei einer Verletzung der Burn Rate eskaliert – realisierbar etwa über den Prometheus Alertmanager oder ein zu uMonitor analoges System. Nagios scheidet aus, da es für tausende Microservices nicht skaliert. Als Alerting-Strategie werden statische Schwellwerte für stabile Infrastruktur-Metriken, SLO- beziehungsweise Burn-Rate-basiertes Alerting für nutzerrelevante Symptome und Anomaly Detection für zyklische Business-Metriken kombiniert. Die Instrumentierung erfolgt einheitlich über OpenTelemetry (vgl. Abschnitt I.I), sodass das Backend austauschbar bleibt. Der bewusste Verzicht auf teure SaaS-Suiten zugunsten quelloffener, selbst betriebener Komponenten ist bei den hier betrachteten Datenmengen wirtschaftlich sinnvoll, da fixe Betriebs- und Personalkosten günstiger ausfallen als mit dem Volumen skalierende Cloud-Kosten.

II. Distributed Tracing

Distributed Tracing ist ein zentrales Konzept zur Beobachtung und Analyse von Requests in modernen, verteilten Microservice-Architekturen. Ziel ist es, den vollständigen Lebenszyklus eines einzelnen Requests über mehrere unabhängige Services hinweg nachvollziehbar zu machen [17]. Dadurch wird es möglich trotz zahlreicher Services, Systeminteraktionen transparent darzustellen und Fehlerursachen zu identifizieren. Besonders in stark entkoppelten Architekturen, wie sie beispielsweise in einem Uber-ähnlichen System auftreten [1], ist Distributed Tracing eine wichtige Methode, um Abhängigkeiten und Systemverhalten zu verstehen.

II.I Grundkonzept

Das Grundkonzept von Distributed Tracing basiert auf der Erfassung und Verknüpfung von Informationen über die Verarbeitung eines Requests innerhalb eines verteilten Systems. Hierbei sind zentrale Bestandteile der sogenannte Trace und der Span [18]:

• Trace: Ein Trace repräsentiert den vollständigen End-to-End-Verlauf eines Requests und bildet somit den gesamten Verlauf eines Requests durch das System ab. Er kann als gerichteter azyklischer Graph (DAG) von einzelnen Verarbeitungsschritten verstanden werden.
• Span: Diese Verarbeitungsschritte werden als Spans bezeichnet. Ein Span beschreibt eine einzelne Arbeitseinheit innerhalb eines Services, beispielsweise einen HTTP-Request, einen Datenbankzugriff oder einen RPC-Aufruf. Jeder Span enthält dabei Informationen wie Startzeit, Endzeit, Dauer, Status sowie zusätzliche Metadaten. Durch die Verknüpfung mehrerer Spans entsteht die vollständige Struktur eines Traces.

Zur eindeutigen Zuordnung werden zwei zentrale Identifikatoren verwendet [19]:

• Trace-ID: Die Trace-ID wird beim Eintritt eines Requests in das System erzeugt und über alle beteiligten Services hinweg weitergegeben. Sie dient dazu, alle zugehörigen Spans eines Requests zu gruppieren.
• Span-ID: Die Span-ID identifiziert hingegen eine einzelne Operation innerhalb eines Services. Zusätzlich enthält jeder Span typischerweise eine Parent-Span-ID, wodurch die hierarchische Struktur eines Requests rekonstruiert werden kann.

Durch diese Struktur lässt sich der Ablauf eines Requests, die Abhängigkeiten zwischen Services sowie Latenzen einzelner Verarbeitungsschritte analysieren. Dadurch wird Transparenz in ansonsten schwer nachvollziehbaren Microservice-Systemen geschaffen.

II.II Tools und Technologien

Typische Tracing-Systeme bestehen aus vier Hauptkomponenten:

1. Instrumentierung: Erzeugung der Spans in den Services,
2. Transport: Übertragung der Trace-Daten
3. Backend: Speicherung und Verarbeitung der Trace-Daten
4. Frontend: Visualisierung der Daten in einer UI

Im Kontext moderner Cloud-native Architekturen haben sich unter anderem folgende Lösungen etabliert: Jaeger, Zipkin und Grafana Tempo.

Jaeger

Jaeger ist ein verteiltes Tracing-System, das ursprünglich bei Uber entwickelt wurde und von Googles Dapper-Architektur inspiriert ist [20]. Es wird heute häufig in komplexen Microservice-Umgebungen eingesetzt und ist Teil des CNCF-Ökosystems [21].

Jaeger ist modular und verteilt aufgebaut und besteht aus Instrumentierung, Collector-, Query- und Storage-Komponenten. Wie in Abbildung 3 gezeigt wird, senden die instrumentierten Microservices ihre Trace-Daten direkt an die Collector-Komponente. Diese nimmt die Daten entgegen und schreibt sie anschließend in das Storage-Backend.

Abbildung 3: Direct-To-Storage Architektur von Jaeger

Die Storage-Schicht muss dabei sowohl durchschnittliche Last als auch hohe zuverlässig verarbeiten können. Zur kurzfristigen Entkopplung kann der Collector eine in-memory Queue verwenden, um Traffic-Spitzen abzufangen. Bei länger anhaltenden Lastspitzen kann es jedoch zu Datenverlust kommen, wenn das Storage-System nicht ausreichend skaliert ist oder die Ingest-Rate nicht mithält [21].

Zipkin

Zipkin ist eines der älteren Distributed-Tracing-Systeme und wurde entwickelt, um einfache Microservice-Architekturen schnell beobachtbar zu machen [22].

Im Vergleich zu neueren Systemen ist Zipkin stärker zentralisiert aufgebaut. Das System ist dadurch einfacher zu betreiben, stößt jedoch bei hoher Last oder sehr großen Systemen schneller an Skalierungsgrenzen [23].

Grafana Tempo

Grafana Tempo ist ein modernes, hochskalierbares Tracing-Backend, das von Grafana Labs entwickelt wurde [24]. Es ist besonders auf einfache Skalierung und niedrige Betriebskosten ausgelegt. Es verfolgt einen anderen Ansatz als klassische Systeme [22]:

• Traces werden gesammelt und direkt in Object Storage abgelegt
• Es gibt keine klassische Indexierung

Durch den Verzicht auf Indexierung kann Tempo sehr große Datenmengen kosteneffizient speichern, allerdings ist die explorative Suche eingeschränkter als bei anderen Tools [25].

II.III Sampling-Strategien und -Methoden

In großen Distributed-Tracing-Systemen entstehen innerhalb kurzer Zeit sehr hohe Mengen an Trace-Daten, was zu erheblichen Speicher-, Netzwerk- und Verarbeitungsaufwand führen. Aus diesem Grund werden sogenannte Sampling-Strategien eingesetzt [26].

Sampling beschreibt die gezielte Auswahl eines repräsentativen Anteils aller Traces bei möglichst geringem Speicher- und Performance-Overhead. Ziel ist es, trotz reduzierter Datenmenge weiterhin aussagekräftige Schlüsse aus den Traces ziehen zu können [27].

Dabei entsteht ein Trade-off: Wird zu viel gesampelt und somit ein Großteil der Traces gespeichert, steigen Speicherbedarf sowie zusätzlicher Verarbeitungs- und Netzwerkaufwand. Erfolgt dagegen zu wenig Sampling, können relevante Fehler oder langsame Requests unentdeckt bleiben.

Grundsätzlich wird zwischen Head-based und Tail-based Sampling unterschieden [26]:

• Head-based Sampling: Es wird bereits zu Beginn, beim ersten Span, eines Requests entschieden, ob ein Trace gespeichert wird. Der Vorteil dieses Ansatzes liegt in der hohen Effizienz, da keine vollständigen Traces zwischengespeichert werden müssen. Allerdings können Fehler oder langsame Requests verworfen werden, bevor deren Verhalten bekannt ist.
• Tail-based Sampling: Es wird erst nach Abschluss des gesamten Traces entschieden, ob ein Trace gespeichert wird. Der Collector besitzt dadurch Informationen über alle Spans, Fehler und Latenzen. Dadurch lassen sich fehlerhafte oder langsame Requests zuverlässig erfassen. Allerdings ist dieser Ansatz ressourcenintensiver, da vollständige Traces zunächst zwischengespeichert werden müssen.

Zur Umsetzung von Sampling existieren verschiedene Verfahren, die je nach Systemanforderung kombiniert werden können [26]:

• Probabilistic Sampling: Zufällige Auswahl von Traces mit fester Wahrscheinlichkeit. Einfach zu konfigurieren und geeignet für gleichmäßigen Traffic, jedoch ohne Garantie, dass seltene Fehler oder kritische Requests erfasst werden.
• Adaptive Sampling: Dynamische Anpassung der Sampling-Rate an Systemlast und Traffic einzelner Endpunkte. Dadurch wird die Datenerfassung automatisch optimiert, allerdings steigt die Komplexität der Konfiguration.
• Rate-Limiting Sampling: Feste Anzahl von Traces pro Zeitintervall (z. B. 100 Traces/s). Schützt das Backend vor Lastspitzen und sorgt für eine vorhersehbare Datenmenge unabhängig vom Gesamttraffic.
• Rule-based Sampling: Auswahl anhand definierter Regeln oder Attribute wie Fehlerstatus, Latenz oder Endpoint. Ermöglicht gezielte Speicherung relevanter Traces, erfordert jedoch eine genaue Regeldefinition.

II.IV Umsetzung im Uber-Klon

Im Folgenden wird die Auswahl der eingesetzten Technologien sowie der konkreten Sampling-Strategien und -Methoden für den Uber-Klon beschrieben.

Auswahl des Distributed Tracing Tools

Für den Uber-Klon wurde Jaeger als Distributed Tracing Tool ausgewählt. Die Entscheidung basiert auf den Anforderungen einer sehr großen Microservice-Architektur mit tausenden verteilten Services, in der insbesondere horizontale Skalierbarkeit wichtig ist. Jaeger eignet sich in diesem Kontext besonders gut, da es eine stark modulare und skalierbare Architektur besitzt und somit für hohe Trace-Datenmengen ausgelegt ist. Zusätzlich ermöglicht es eine explorative Analyse von Traces über eine umfangreiche UI, was für Debugging und Root-Cause-Analysen in komplexen Systemlandschaften entscheidend ist.

Ein weiterer Vorteil ist die enge Integration in das CNCF- und OpenTelemetry-Ökosystem, wodurch eine langfristige Weiterentwicklung sowie eine standardisierte Instrumentierung sichergestellt sind.

Sampling-Strategie

Für den Uber-Klon wird grundsätzlich Head-based Sampling als Standardstrategie eingesetzt. Diese Entscheidung basiert auf der hohen Effizienz und dem geringen Ressourcenverbrauch, wodurch sich der Ansatz besonders für Systeme mit sehr hohem Traffic eignet.

Für kritische Systeme, insbesondere den Payment-Service, wird jedoch eine kombinierte Strategie eingesetzt. Hier kommt Tail-based Sampling in Kombination mit Rule-based Sampling zum Einsatz, um sicherzustellen, dass alle fehlerhaften oder auffälligen Requests vollständig erhalten bleiben und für Analysen verfügbar sind.

Sampling-Methoden

Ergänzend werden verschiedene Sampling-Methoden je nach Anwendungsfall eingesetzt.

• Probabilistic Sampling: Einsatz für die meisten Services mit gleichmäßigem Traffic. Traces werden zufällig mit einer festen Wahrscheinlichkeit gespeichert.
• Rate-Limiting Sampling: Einsatz bei erwarteten Traffic-Spitzen, z. B. bei Ride-Requests während Stoßzeiten, um das Backend vor Überlastung zu schützen.
• Adaptive Sampling: Einsatz in High-Volume-Services wie Location-Updates, bei denen sich die Last stark dynamisch verändert und die Sampling-Rate automatisch angepasst werden muss.

III. Observability

Der Übergang von klassischem Monitoring und Distributed Tracing hin zur Observability bedeutet einen wesentlichen Paradigmenwechsel in der Systemdiagnostik. Während Monitoring und Tracing primär darauf ausgelegt sind, bekannte Fehlermuster zu identifizieren und den Ort ihres Auftretens zu lokalisieren, liefert Observability den notwendigen Kontext für eine tiefgreifende Ursachenforschung bei unvorhersehbaren Systemausfällen. Es handelt sich hierbei nicht um ein einzelnes technisches Bauteil oder isoliertes Produkt, sondern um eine Verkettung von Vorgehensweisen, die es ermöglichen, explorative Fragen an ein System zu stellen [28].

III.I Grundkonzept

Um diese konzeptionelle Einordnung und die Abgrenzung der Disziplinen zu verdeutlichen, wird in der Praxis häufig das Konstrukt der „Unknown Unknowns“ herangezogen [29]. Dieses Framework, das ursprünglich durch ein Zitat des ehemaligen US-Verteidigungsministers Donald Rumsfeld im historischen Kontext des Irakkriegs Anfang der 2000er Jahre geprägt wurde, kategorisiert den Systemzustand in drei wesentliche Ebenen.

Zunächst werden die Known Knowns betrachtet. Das sind Systemzustände, von denen bekannt ist, dass sie verstanden werden. In der IT-Architektur wird diese Ebene durch das klassische Monitoring abgedeckt. Beispielsweise ist es technologisch bekannt, dass Server über CPUs verfügen und eine Auslastung von 100 % zu kritischen Systemproblemen führt. Diese Risiken können im Vorfeld präventiv getestet werden, sodass gezielt reaktive Dashboards aufgebaut und strikte Limitierungen in Form von Service Level Objectives definiert werden können. Die potenziellen Fragen an das System sind somit bereits vor Eintreten eines Ausfalls definiert.

Die zweite Kategorie umfasst die Known Unknowns, also jene Symptome, von denen bekannt ist, dass die exakte Ursache noch unbekannt ist. Dieser Bereich wird durch das Distributed Tracing adressiert. Ein typisches Beispiel hierfür ist eine systemübergreifende Fahrtanfrage, die sporadisch hohe Latenzen aufweist. Es ist für die Entwickler ersichtlich, dass ein Performance-Problem vorliegt, jedoch bleibt unklar, in welchem der Vielzahl an beteiligten Microservices das tatsächliche Problem verursacht wird. Da die Symptome grundlegend bekannt sind, wird das System im Vorfeld so instrumentiert, dass Request-Pfade durchgängig gemessen werden können, um den Fehlerort kausal einzugrenzen.

Die Observability hingegen widmet sich den Unknown Unknowns, den blinden Flecken einer Systemarchitektur. Hierbei handelt es sich um hochkomplexe Fehlerkombinationen, von denen im Vorfeld nicht einmal antizipiert werden konnte, dass sie gemessen werden müssen. Für derartig unendliche Merkmalskombinationen, welche durch eine hohe Kardinalität gekennzeichnet sind, kann präventiv kein dediziertes Monitoring-Dashboard erstellt werden.

Ein verteilbares System gilt nur dann als „observable“, wenn es ermöglicht wird, völlig neue, spontane Fragen ad hoc an die Systemdaten zu stellen. Dies muss zwingend erfolgen können, ohne dass im Vorfeld neuer Programmcode geschrieben, zusätzliche Log-Statements implementiert oder das System im Rahmen einer Störung neu deployt werden muss. Ist diese Flexibilität nicht gegeben, akkumulieren sich signifikante Geschäftsverluste durch ungelöste Ausfallzeiten. Folglich darf Observability nicht als fertiges Produkt verstanden werden, das über externe Dienstleister bezogen wird, sondern es ist als eine übergeordnete Systemeigenschaft zu betrachten. Diese tiefgreifende Systemeigenschaft wird final dadurch realisiert, dass die verlässlichen Metriken des Monitorings sowie die Request-Verläufe des Tracings herangezogen und intelligent miteinander verschmolzen werden [30].

III.II Observability Tools und Technologien

Um Observability in verteilten Systemen technisch realisieren zu können, bedarf es einer Datengrundlage, die eine hohe Detailtiefe aufweist. Klassische, unstrukturierte Text-Logs, die primär für die menschliche Lesbarkeit konzipiert wurden, sind für die automatisierte und multidimensionale Auswertung ungeeignet. Stattdessen wird in modernen Architekturen auf sogenannte Enriched Events zurückgegriffen. Hierbei handelt es sich um die Evolution des unstrukturierten Logs zu hochstrukturierten JSON-Dokumenten, die maschinell verarbeitet werden und jede Systemaktion mit einem maximalen Kontext anreichern, der oftmals aus über einhundert Key-Value-Paaren besteht.

Diese Detailtiefe führt unweigerlich zu der bereits angesprochenen, technologischen Herausforderung der hohen Kardinalität. Während klassische Metriken des Monitorings eine niedrige Kardinalität aufweisen, wie beispielsweise eine begrenzte Handvoll von HTTP-Statuscodes (z. B. 200 oder 404), zeichnen sich Observability-Daten durch eine hohe Anzahl einzigartiger Werte aus. Zu diesen hochdimensionalen Daten gehören unter anderem Millionen von User-IDs, exakte Geo-Hashes oder Millionen von individuellen Trace-IDs. Werden derartige Datenkombinationen in herkömmliche Time-Series-Datenbanken (TSDB) ingestiert, entsteht das Problem der sogenannten „Index Bloat“. Für jede einzigartige Tag-Kombination wird ein neuer interner Index generiert, was den Arbeitsspeicher der Server in kürzester Zeit auslastet und unweigerlich zu Systemabstürzen führt [31].

Um Milliarden von Datensätzen nach hunderten Dimensionen filtern und gruppieren zu können, müssen folglich spezifische Anforderungen an die Datenbankarchitektur gestellt werden. Da relationale Datenbankmanagementsysteme unter der Last solcher multidimensionalen Abfragen kollabieren würden, ist ein Architekturwechsel hin zu einer OLAP-Datenbank (Online Analytical Processing) zwingend erforderlich. Im Gegensatz zu herkömmlichen Systemen, welche Daten zeilenweise ablegen, nutzt OLAP eine spaltenbasierte Speicherung. Wird eine Abfrage zur Fehleranalyse lediglich auf spezifische Dimensionen eingegrenzt, müssen auf der physischen Speicherebene auch nur diese entsprechenden Spalten eingelesen werden. Dies führt zu einer massiven Einsparung von I/O-Ressourcen, ermöglicht eine extreme Lesegeschwindigkeit und erlaubt eine effiziente Kompression der hochstrukturierten Events [32].

Der Einsatz einer derartigen OLAP-Architektur geht jedoch mit systembedingten Kompromissen einher. Durch die Optimierung auf schnellen Lesezugriffe und Datenkompression sind nachträgliche Änderungen oder Löschungen von einzelnen Datensätzen kaum möglich, da die Daten primär über ein Append-only-Verfahren angehängt werden. Zudem wird zugunsten der Performance oftmals auf absolute Konsistenz verzichtet, wodurch das System lediglich eine Eventual Consistency aufweist. Für den Anwendungsfall der Observability, die historische und aggregierte Auswertung von Telemetriedaten, sind diese Einschränkungen jedoch technologisch weniger relevant und können zugunsten der Analysegeschwindigkeit über riesige Datensätze hinweg in Kauf genommen werden [33].

III.III Umsetzung im Uber-Klon und Gesamtarchitektur

Bei der Konzeption einer geeigneten Observability-Lösung muss die infrastrukturelle Skalierung des Unternehmens zwingend berücksichtigt werden. Während Start-ups aus Gründen der geringeren Komplexität oftmals auf verwaltete SaaS-Lösungen wie Datadog oder Honeycomb setzen, explodieren bei diesen Modellen im Ultra-Large-Scale-Bereich die Kosten durch die Abrechnung pro Ereignis oder Gigabyte massiv. Mittelständische Unternehmen greifen häufig auf Open-Source-Alternativen wie den ELK-Stack zurück [34] [35]. Die dort verwendete Elasticsearch-Technologie nutzt jedoch invertierte Indizes, welche zwar für klassische Volltextsuchen optimiert sind, bei der Metadaten-Filterung von hochkardinalen Datenmengen jedoch zu einem RAM- und CPU-Kollaps führen. Für ein ULS-System ist folglich ein „Make“-Ansatz mit der Eigenentwicklung einer auf OLAP-Datenbanken basierenden Pipeline erforderlich. Ab einem gewissen Datenvolumen amortisiert sich der personelle Aufwand für dedizierte Database Engineers, da die extreme Hardware-Effizienz und Datenkompression der spaltenbasierten Speicherung die laufenden Cloud- und Lizenzkosten signifikant unterbieten [36].

Im Bereich der ULS-Systeme hat sich der Einsatz von OLAP-Datenbanken als Branchenstandard etabliert. Ein Konkurrenzvergleich verdeutlicht jedoch unterschiedliche architekturspezifische Ausprägungen. Das Technologieunternehmen Grab setzt primär auf Apache Pinot, welches speziell auf Echtzeit-Ingestionen optimiert ist. Der architektonische Nachteil gegenüber ClickHouse äußert sich jedoch darin, dass das System starrer operiert und spontane, hochkomplexe JOIN-Operationen weniger performant verarbeitet werden können [37]. Der Fahrtvermittler Lyft vollzog hingegen kürzlich eine Migration von Apache Druid auf ClickHouse. Die Treiber für diesen Wechsel waren ein geringerer operativer Overhead, eine vereinfachte Bedienung sowie ein signifikant reduzierter Lernaufwand für die involvierten Entwicklerteams [38].

Basierend auf diesen Erkenntnissen fällt die architektonische Entscheidung für den konzipierten Uber-Klon auf ClickHouse. Die ausgeprägte Fähigkeit zur Datenkompression führt zu erheblichen Kosteneinsparungen im Vergleich zu dokumentenbasierten Systemen wie Elasticsearch. Durch die standardisierte Datenerfassung via OpenTelemetry wird zudem ein klassischer Vendor Lock-in vermieden, da die abstrahierte API eine nahtlose Austauschbarkeit des Speicher-Backends ermöglicht.

Um zu gewährleisten, dass Millionen von System-Events pro Sekunde stabil und ohne Informationsverlust verarbeitet werden, bedarf es einer robusten Gesamtarchitektur. Das Leitprinzip der konzipierten Daten-Pipeline basiert darauf, dass jeder Datentyp in einer spezifisch für seinen Einsatzzweck optimierten Datenbank abgelegt wird [33].

Abbildung 4: Gesamtarchitektur der Datenpipeline.

Die erste Stufe dieser Pipeline bildet die Erfassung der Daten. Die verteilten Microservices generieren standardisierte OpenTelemetry-Daten und pushen diese asynchron an einen lokalen Agenten. Der nachgeschaltete OpenTelemetry Collector fungiert in dieser Architektur als intelligenter Router. Er übernimmt das logische Routing und filtert sensible, personenbezogene Daten präventiv heraus, bevor diese in die zentrale Infrastruktur gelangen. Zudem reichert er die Datenpakete automatisch um essentielle Infrastruktur-Metadaten an, bevor sie an das Transportsystem übergeben werden.

Für den Transport der generierten Telemetriedaten wird eine Kafka-Queue eingesetzt, sie fungiert als Puffer für die hohen ULS-Datenströme. Die asynchrone Entkopplung stellt sicher, dass die nachgelagerten Datenbanken die einfließenden Informationen in ihrem eigenen Tempo wegschreiben können, wodurch Systemabstürze bei massiven Überlastungen, beispielsweise durch plötzliche Traffic-Spitzen, verhindert werden. Diese Stream-Architektur bietet zudem den strategischen Vorteil, dass zu einem späteren Zeitpunkt neue Konsumenten, wie etwa Machine-Learning-Algorithmen zur Echtzeit-Betrugserkennung, nahtlos an den Datenstrom angefügt werden können, ohne die Erfassungslogik der Microservices zu modifizieren.

Nach der Pufferung erfolgt der sogenannte Storage-Split, bei dem die Datenströme in drei spezialisierte Säulen aufgeteilt werden. Aggregierte Metriken werden an die Time-Series-Datenbank M3 weitergeleitet, welche für Zeitreihen-Aggregationen optimiert ist und als Basis für das reaktive Monitoring dient. Die Request-Pfade (Traces) werden in einer Cassandra-Datenbank persistiert. Diese NoSQL-Datenbank fängt die massive Schreiblast der verteilten Systeme ab, sodass die Traces im Anschluss performant durch Jaeger visualisiert werden können. Alle angereicherten Events fließen für die explorative Ad-hoc-Analyse in die Observability-Datenbank ClickHouse.

Die Orchestrierung und Korrelation dieser drei isolierten Datentöpfe für Observability erfolgt über das zentrale Tool Grafana. Als verbindendes Element durch das gesamte System fungiert dabei die eindeutige Trace-ID. Durch diese ID wird es ermöglicht, in der Benutzeroberfläche von einem identifizierten Metrik-Ausschlag (M3) direkt zu dem betroffenen Pfad (Jaeger) und von dort nahtlos in die tiefen Event-Details der Observability-Ebene (ClickHouse) zu springen.

III.IV Auswirkungen auf andere Teams und kritische Würdigung

Die Implementierung einer umfassenden Observability-Architektur entfaltet ihren Mehrwert nicht isoliert innerhalb des Betriebs- oder SRE-Teams, sondern fungiert als wichtige Datengrundlage für angrenzende Abteilungen im Software Development Life Cycle. Da es sich bei Observability-Daten anders gesagt um sehr hochauflösende Business-Daten handelt, ergeben sich weitreichende Synergieeffekte für das gesamte Ökosystem. Im Bereich des CI/CD (Continuous Integration / Continuous Deployment) dient die Observability-Datenbank als automatisiertes Quality Gate. Nach dem Rollout einer neuen Softwareversion an eine begrenzte Nutzerbasis kann die Deployment-Pipeline aktiv Abfragen an die Datenbank richten. Hierbei werden nicht lediglich rudimentäre Infrastrukturmetriken wie die CPU-Auslastung evaluiert, sondern spezifische Business-Events analysiert. Werden diese durch das Deployment signifikant negativ beeinflusst, greift ein automatischer Circuit Breaker, durch den die Version unverzüglich zurückgerollt wird, noch bevor ein manuelles Eingreifen erforderlich wird [39] [40].

Darüber hinaus profitieren Abteilungen wie der Customer Support und spezialisierte Fraud-Teams von diesem Ansatz, was in der Praxis häufig unter dem Begriff der Business Observability zusammengefasst wird. Durch die Gewährung von Lesezugriffen auf die leistungsstarke Observability-Datenbank können diese Teams in Echtzeit komplexe Analysen durchführen. Beispielsweise lassen sich sogenannte Velocity-Abuse-Muster identifizieren. Hierbei wird analytisch evaluiert, ob identische Zahlungsmittel in kürzester Zeit von unterschiedlichen Nutzern in verschiedenen geografischen Regionen verwendet wurden, um so automatisiert betrügerische Aktivitäten aufzudecken [41].

Trotz der weitreichenden technologischen Vorteile muss der Einsatz einer solchen Architektur im Ultra-Large-Scale-Kontext kritisch gewürdigt werden. Einen wesentlichen Kompromiss stellt der Storage Trade-off dar. Selbst bei der Anwendung von datenreduzierenden Maßnahmen wie dem Tail-based Sampling generiert das System immense Datenmengen, deren dauerhafte Speicherung auf hochperformanten Speichermedien ökonomisch nicht vertretbar ist. Zur Lösung dieses Problems wird zwingend ein striktes Data Tiering benötigt. Rohdaten, die den gesamten Event-Kontext beinhalten, werden lediglich für einen kurzen Zeitraum im sogenannten „Hot Storage“ vorgehalten, um eine unmittelbare Fehleranalyse zu gewährleisten. Nach Ablauf dieser Frist werden die Daten aggregiert, komprimiert und in einen kostengünstigeren, jedoch langsameren „Cold Storage“ verschoben [33].

Neben den infrastrukturellen Limitierungen existiert ein noch wichtigerer kultureller Trade-off. Observability darf nicht rein als Software-Tool verstanden werden, sondern muss als soziotechnisches System betrachtet werden. Die leistungsfähigste Architektur verliert ihren Wert, wenn sie mit unvollständigen oder fehlerhaften Daten gespeist wird. Es wird von den Entwicklern eine hohe Disziplin gefordert, sauberen und kontextreichen Code zu schreiben, in dem korrekte Tags und Telemetriedaten aktiv in die OpenTelemetry-Spans injiziert werden. Werden bei der Entwicklung neuer Services kritische Metadaten vergessen, ist eine spätere, granulare Ursachenforschung nahezu unmöglich. Um dieser Herausforderung zu begegnen, muss Observability als fundamentale Ingenieurskultur etabliert werden [42].

IV. Fazit

Die Implementierung von Monitoring, Tracing und Observability in hochkomplexen, verteilten Systemen verfolgt das primäre Ziel, Ausfallzeiten und die Mean Time To Recovery zu minimieren sowie präventiv größeren Systemausfällen entgegenzuwirken. Realisiert wird dies durch das synergetische Zusammenspiel dreier Datentypen: aggregierte Metriken, verknüpfte Request-Pfade (Traces) und tiefgreifende Kontext-Logs (Events). Während das Monitoring anhand vordefinierter Schwellwerte die essenzielle Frage beantwortet, ob ein System fehlerhaft agiert, lokalisiert das Distributed Tracing mittels Spans den Ort des Problems. Observability liefert darauf aufbauend durch das multidimensionale Filtern roher Events die finale Antwort auf die Frage nach der eigentlichen Ursache und ermöglicht die Identifikation zuvor unbekannter Systemzustände.

Für die technologische Umsetzung in einem Ultra-Large-Scale-Szenario wie dem konzipierten Uber-Klon wird eine strikte Entkopplung der Datenerfassung von der Datenspeicherung empfohlen. Durch den Einsatz von OpenTelemetry als standardisiertes Erfassungswerkzeug wird ein Vendor-Lock-in vermieden und technologische Unabhängigkeit gewährleistet. Auf Ebene der Persistenz wird eine nutzenzentrierte Trennung vorgenommen, bei der Metriken in der Time-Series-Datenbank M3, Traces in Cassandra zur anschließenden Visualisierung durch Jaeger und Observability-Events in ClickHouse für rasant auszuführende Ad-hoc-Analysen gespeichert werden. Dieser „Make“-Ansatz und die damit verbundene strategische Investition in interne Site Reliability Engineers werden durch ihren Business Case legitimiert. Bei den anfallenden Petabyte-Datenmengen würde die Nutzung kommerzieller SaaS-Lösungen die ökonomische Profitabilität des Gesamtsystems durch exponentiell steigende Kosten massiv untergraben.

Dennoch erfordert die konzipierte Gesamtarchitektur bewusste Kompromisse. Um die immensen Speicherkosten zu kontrollieren, wird auf die vollständige Nachverfolgbarkeit fehlerfreier Requests verzichtet und stattdessen ein selektives Sampling angewendet. Zudem wird zugunsten einer hohen Schreibgeschwindigkeit eine eventuelle Inkonsistenz in der Datenspeicherung in Kauf genommen, da sich kritische Fehlermuster bei der schieren Masse an Transaktionen dennoch zuverlässig abzeichnen. Der entscheidendste Trade-off ist jedoch kultureller Natur. Observability ist keine reine Software-Suite, die lediglich installiert werden muss, sondern stellt eine tiefgreifende Ingenieurskultur dar, die aktiv eingefordert werden muss. Selbst die leistungsfähigste technologische Infrastruktur bleibt unbrauchbar, wenn die Entwickler keinen Sinn in ihrer Anwendung sehen.

V. Ausblick

Ein Ausblick auf die technologische Evolution von Monitoring, Tracing und Observability in Ultra-Large-Scale-Systemen zeigt ein deutliches Potential in der Datenerfassung sowie der tiefgehenden Fehleranalyse. Mit der zunehmenden Adaption von eBPF (Extended Berkeley Packet Filter) wird es ermöglicht, Programme direkt auf der Betriebssystemebene im Linux-Kernel auszuführen, ohne dass dieser aufwendig modifiziert oder das System neu gestartet werden muss. Da jegliche Microservice-Kommunikation mit dem Netzwerk oder der Hardware unweigerlich den Kernel passiert, können Telemetriedaten künftig zentral abgegriffen werden, wodurch der manuelle Aufwand für Entwickler zur Implementierung von Meta-Tags drastisch reduziert wird [43] [44]. Diese Technologie ebnet zugleich den Weg für das „Continuous Profiling“, welches zunehmend als vierte Säule der Observability (neben Logs, Metriken und Traces) betrachtet wird. Während traditionelle Ansätze meist bei der Fehlerlokalisation auf Service-Ebene enden, kann durch kontinuierliches Profiling direkt in der Produktionsumgebung exakt identifiziert werden, welche spezifische Code-Zeile oder Funktion für Ressourcenengpässe wie CPU-Blockaden oder RAM-Überlastungen verantwortlich ist [45] [46].

Auf der analytischen Seite wird die Bewältigung der immensen Observability-Datenmengen künftig durch AIOps und Large Language Models transformiert. Anstatt für das Filtern und Suchen komplexe SQL- oder PromQL-Abfragen manuell formulieren zu müssen, wird die Interaktion mit den Telemetriedaten zunehmend über natürliche Sprache als Observability-Copilot erfolgen. Werden diese generativen KI-Modelle mit den zugrunde liegenden Datenbank-Schemata sowie dem historischen Wissen alter Post-Mortem-Berichte trainiert, können sie eigenständig Anomalien erkennen, Traces analysieren und fundierte Fehlerzusammenfassungen generieren. Darüber hinaus birgt dieser KI-gestützte Ansatz enormes Potenzial für die Optimierung von Speicherkosten. LLMs könnten künftig dynamisch und intelligent evaluieren, welche spezifischen Traces für eine spätere Fehleranalyse relevant sind und gespeichert werden müssen, während unwichtige Daten zur Ressourcenersparnis verworfen werden [47] [48] [49].

Literaturverzeichnis

[1] Uber, „Uber Blog,“ 2 February 2017. [Online]. Available: https://www.uber.com/de/en/blog/distributed-tracing/. [Zugriff am 13 May 2026].

[2] C. Wieschollek, „T3N,“ 8 December 2021. [Online]. Available: https://t3n.de/news/netflix-disney-mehr-aws-ausfall-1435394/. [Zugriff am 13 May 2026].

[3] R. Losio, „InfoQ,“ 18 December 2021. [Online]. Available: https://www.infoq.com/news/2021/12/aws-outage-postmortem/. [Zugriff am 13 May 2026].

[4] B. Beyer, C. Jones, J. Petoff und N. R. Murphy, „Monitoring Distributed Systems,“ in Site Reliability Engineering, O’Reilly / Google, 2016.

[5] Prometheus, „Metric types,“ [Online]. Available: https://prometheus.io/docs/concepts/metric_types/. [Zugriff am 13 Mai 2026].

[6] Prometheus, „Histograms and summaries,“ [Online]. Available: https://prometheus.io/docs/practices/histograms/. [Zugriff am 13 Mai 2026].

[7] B. Beyer, C. Jones, J. Petoff und N. R. Murphy, „Service Level Objectives,“ in Site Reliability Engineering, O’Reilly / Google, 2016.

[8] Uber, „Optimizing Observability with Jaeger, M3, and XYS at Uber,“ 26 November 2019. [Online]. Available: https://www.uber.com/en/blog/optimizing-observability/. [Zugriff am 13 Mai 2026].

[9] B. Beyer, N. R. Murphy, D. K. Rensin, K. Kawahara und S. Thorne, „Error Budget Policy,“ in The Site Reliability Workbook, O’Reilly / Google, 2018.

[10] B. Beyer, N. R. Murphy, D. K. Rensin, K. Kawahara und S. Thorne, „Implementing SLOs,“ in The Site Reliability Workbook, O’Reilly / Google, 2018.

[11] Uber, „uVitals – An Anomaly Detection & Alerting System,“ 28 Dezember 2023. [Online]. Available: https://www.uber.com/en/blog/uvitals-an-anomaly-detection-alerting-system/. [Zugriff am 13 Mai 2026].

[12] B. Beyer, N. R. Murphy, D. K. Rensin, K. Kawahara und S. Thorne, „Alerting on SLOs,“ in The Site Reliability Workbook, O’Reilly / Google, 2018.

[13] Uber, „Observability at Scale: Building Uber’s Alerting Ecosystem,“ 20 November 2018. [Online]. Available: https://www.uber.com/en/blog/observability-at-scale/. [Zugriff am 13 Mai 2026].

[14] Uber, „Engineering a Job-based Forecasting Workflow for Observability Anomaly Detection,“ 16 Mai 2018. [Online]. Available: https://www.uber.com/en/blog/observability-anomaly-detection/. [Zugriff am 13 Mai 2026].

[15] Uber, „M3: Uber’s Open Source, Large-scale Metrics Platform for Prometheus,“ 7 August 2018. [Online]. Available: https://www.uber.com/en/blog/m3/. [Zugriff am 13 Mai 2026].

[16] S. Srivatsan, „Scaling Observability at Uber: Building In-House Solutions, uMonitor and Neris,“ 20 Dezember 2018. [Online]. Available: https://www.infoq.com/news/2018/12/observability-uber/. [Zugriff am 13 Mai 2026].

[17] N. T. Jha, „Medium,“ 2024 February 2024. [Online]. Available: https://medium.com/%40nikhiltjha/understanding-distributed-tracing-in-microservices-architectures-437aab1c1786. [Zugriff am 13 May 2026].

[18] B. H. B. L. A. B. M. S. P. P. M. B. D. e. a. Sigelman, „Dapper, a Large-Scale Distributed Systems Tracing Infrastructure,“ Google, Inc., 2010.

[19] A. Villela, „Medium,“ 14 July 2021. [Online]. Available: https://medium.com/dzerolabs/observability-journey-understanding-logs-events-traces-and-spans-836524d63172. [Zugriff am 13 May 2026].

[20] „IBM,“ [Online]. Available: https://www.ibm.com/de-de/products/instana/supported-technologies/jaeger-apm-integration. [Zugriff am 13 May 2026].

[21] „Jaeger Tracing v2.17,“ 1 April 2026. [Online]. Available: https://www.jaegertracing.io/docs/2.17/architecture/. [Zugriff am 13 May 2026].

[22] K. Wakayama, „Codesociety,“ 25 January 2023. [Online]. Available: https://codersociety.com/blog/articles/jaeger-vs-zipkin-vs-tempo#3-grafana-tempo. [Zugriff am 13 May 2026].

[23] „dash0,“ 23 March 2026. [Online]. Available: https://www.dash0.com/comparisons/zipkin-vs-jaeger-what-is-the-difference#limitations. [Zugriff am 13 May 2026].

[24] K. Bhogayata, „Middleware,“ 10 April 2026. [Online]. Available: https://middleware.io/blog/what-is-grafana-tempo/. [Zugriff am 13 May 2026].

[25] A. Udasi, „Last9,“ 20 May 2025. [Online]. Available: http://last9.io/blog/grafana-tempo-vs-jaeger/. [Zugriff am 13 May 2026].

[26] D. Horovits, „logzIO,“ 9 January 2024. [Online]. Available: https://logz.io/learn/sampling-in-distributed-tracing-guide/#understanding-sampling. [Zugriff am 13 February 2026].

[27] „Google Cloud Docs,“ [Online]. Available: https://docs.cloud.google.com/trace/docs/trace-sampling?hl=de. [Zugriff am 13 May 2026].

[28] H. Weakly, „TheNewStack,“ 3 Oktober 2024. [Online]. Available: https://thenewstack.io/the-4-evolutions-of-your-observability-journey/. [Zugriff am 31 Juni 2026].

[29] A. Gibson, „Do you know your unknown-unknowns?,“ 27 Oktober 2021. [Online]. Available: https://tinycode2.medium.com/do-you-know-your-unknown-unknowns-5ae5e01daa87. [Zugriff am 31 Juni 2026].

[30] A. Wallrabenstein, „Computer Science Blog @ HDM,“ 9 Februar 2019. [Online]. Available: https://blog.mi.hdm-stuttgart.de/index.php/2019/02/09/observability-where-do-we-go-from-here/. [Zugriff am 31 Juni 2026].

[31] J. Holdsworth, „IBM,“ [Online]. Available: https://www.ibm.com/de-de/think/topics/full-stack-observability. [Zugriff am 31 Juni 2026].

[32] K. K. e. al., „Uber Engineering Blog,“ 1 Februar 2024. [Online]. Available: https://www.uber.com/in/en/blog/datacentral-ubers-observability-and-chargeback-platform/. [Zugriff am 31 Juni 2026].

[33] G. Orosz, „The Pragmatic Engineer,“ 12 März 2023. [Online]. Available: https://newsletter.pragmaticengineer.com/p/how-uber-built-its-observability-platform. [Zugriff am 31 Juni 2026].

[34] E. Schabell, „chronosphere,“ 21 Dezember 2023. [Online]. Available: https://chronosphere.io/learn/3-key-differences-of-open-source-observability-tools-vs-proprietary-observability-tools/. [Zugriff am 31 Juni 2026].

[35] Deutsche Startups, „Deutsche Startups,“ 12 Mai 2023. [Online]. Available: https://www.deutsche-startups.de/2023/05/12/full-stack-observability-startups/. [Zugriff am 30 Juni 2026].

[36] G. Pepe, „Uber Engineering Blog: From Monitoring to Observability: Our Ultra-Marathon to a Cloud-Native Platform,“ 6 Januar 2026. [Online]. Available: https://www.uber.com/us/en/blog/from-monitoring-to-observability-cloud-native/. [Zugriff am 30 Juni 2026].

[37] Y. N. Ong, „Grab Tech Blog: Ensuring data reliability and observability in risk systems,“ 23 April 2024. [Online]. Available: https://engineering.grab.com/data-observability. [Zugriff am 31 Juni 2026].

[38] R. Varyani, „Medium: Druid Deprecation and ClickHouse Adoption at Lyft,“ 29 November 2023. [Online]. Available: https://eng.lyft.com/druid-deprecation-and-clickhouse-adoption-at-lyft-120af37651fd. [Zugriff am 30 Juni 2026].

[39] A. Hilton, „Google Cloud Blog: Reliable releases and rollbacks—CRE life lessons,“ 24 März 2017. [Online]. Available: https://cloud.google.com/blog/products/gcp/reliable-releases-and-rollbacks-cre-life-lessons?hl=en. [Zugriff am 30 Juni 2026].

[40] Š. D. Alec Warner, „Canarying Releases,“ in Google SRE Workbook, Google, 2018.

[41] OneUptime, „OneUptime: How to Build a Real-Time Fraud Detection System with ClickHouse,“ 31 März 2026. [Online]. Available: https://oneuptime.com/blog/post/2026-03-31-clickhouse-real-time-fraud-detection/view. [Zugriff am 30 Juni 2026].

[42] OpenTelemetry, „OpenTelemetry: Docs,“ [Online]. Available: https://opentelemetry.io/docs/specs/semconv/cicd/cicd-metrics/. [Zugriff am 30 Juni 2026].

[43] S. Azulay, „Datacenter Insider: Wie eBPF dabei hilft, die Observability-Ausgaben zu begrenzen,“ 7 Dezember 2023. [Online]. Available: https://www.datacenter-insider.de/microservice-architekturen-observability-ebpf-ac337af53f10fac06f59655be70e6bd3a/. [Zugriff am 30 Juni 2026].

[44] C. R. China, „IBM: Was ist eBPF?,“ [Online]. Available: https://www.ibm.com/de-de/think/topics/ebpf. [Zugriff am 30 Juni 2026].

[45] M. Hirt, „Datadog Blog: Why continuous profiling is the fourth pillar of observability,“ 25 Juli 2025. [Online]. Available: http://datadoghq.com/blog/continuous-profiling-fourth-pillar/. [Zugriff am 30 Juni 2026].

[46] CNCF, „Continuous Profiling Your Production Kubernetes Deployments Running at Scale – Vijay Samuel & Nick Pordash, eBay,“ https://www.youtube.com/watch?v=6TqzXj1I8aw, 2023.

[47] Grafana Labs, „Grafana Cloud: Actually Useful AI™ for your entire stack,“ https://grafana.com/products/cloud/ai-observability/

[48] Elastic, „elastic: What is LLM observability?,“ [Online]. Available: https://www.elastic.co/what-is/llm-observability. [Zugriff am 30 Juni 2026].

[49] J. Noble, „IBM: Was ist LLM-Observability,“ [Online]. Available: https://www.ibm.com/de-de/think/topics/llm-observability. [Zugriff am 30 Juni 2026].

[50] R. Miller, „Tech Crunch,“ 17 Februar 2021. [Online]. Available: https://techcrunch.com/2021/02/17/grafana-labs-launches-observability-stack-aimed-at-enterprise-users/. [Zugriff am 30 Juni 2026].