\n\n\n\n
Einleitung<\/h2>\n\n\n\n
Moderne Softwaresysteme basieren zunehmend auf verteilten Microservice-Architekturen, die zwar hohe Skalierbarkeit erm\u00f6glichen, jedoch den Betrieb und die Fehlersuche deutlich erschweren. Klassisches Monitoring st\u00f6\u00dft 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\u00f6sen und tiefere Einblicke in das Systemverhalten zu erm\u00f6glichen [1].<\/p>\n\n\n\n
Ein anschauliches Beispiel f\u00fcr die Relevanz dieser Thematik ist der AWS-Ausfall vom 7. Dezember 2021 in der Region US-East-1. Eine interne St\u00f6rung f\u00fchrte dort zu Kaskadeneffekten, die weltweit zahlreiche Dienste wie Netflix, Reddit oder Disney+ f\u00fcr mehrere Stunden beeintr\u00e4chtigten [2]. Besonders kritisch war dabei, dass Monitoring- und Statussysteme zeitweise keine zuverl\u00e4ssigen Informationen lieferten [3]. Der Vorfall verdeutlicht, wie schnell kleine technische Probleme gro\u00dffl\u00e4chige Auswirkungen haben k\u00f6nnen, insbesondere wenn Observability nicht zuverl\u00e4ssig funktioniert.<\/p>\n\n\n\n
Zielsetzung & Abgrenzung<\/h2>\n\n\n\n
Im Rahmen dieses Projekts wurde ein Uber-\u00e4hnliches 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\u00f6sungen f\u00fcr die \u00dcberwachung und Fehleranalyse zu entwerfen.<\/p>\n\n\n\n
Dabei soll untersucht werden, wie sich Requests \u00fcber mehrere Services hinweg nachvollziehen lassen, wie Metriken und Logs zentral gesammelt werden k\u00f6nnen und wie Fehler fr\u00fchzeitig erkannt werden.<\/p>\n\n\n\n
Diese Arbeit konzentriert sich hierbei ausschlie\u00dflich auf die Themen Monitoring, Distributed Tracing und Observability innerhalb der konzipierten Systemarchitektur. Die vollst\u00e4ndige Implementierung eines produktiven Ride-Sharing-Systems ist nicht Bestandteil der Arbeit. Funktionale Anforderungen werden lediglich soweit betrachtet, wie sie f\u00fcr das Verst\u00e4ndnis der Datenfl\u00fcsse und der Observability relevant sind.<\/p>\n\n\n\n
Ebenso liegt der Fokus nicht auf der detaillierten Implementierung einzelner Tools, sondern auf deren architektonischer Einordnung und dem Zusammenspiel innerhalb eines verteilten Systems.<\/p>\n\n\n\n
\n\n\n\n
I. Monitoring<\/h2>\n\n\n\n
Monitoring bezeichnet die kontinuierliche Beobachtung eines Systems anhand vorab definierter Metriken und Schwellwerte und beantwortet damit die Frage, ob ein System wie erwartet l\u00e4uft. Der grundlegende Ablauf ist dabei reaktiv: Eine Metrik wird gemessen, bei \u00dcberschreiten eines Schwellwerts oder Erkennen einer Anomalie wird ein Alert ausgel\u00f6st, auf den eine Reaktion folgt. Monitoring zeigt somit, dass ein Problem vorliegt, w\u00e4hrend 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].<\/p>\n\n\n\n
I.I Metriken, SLIs und SLOs<\/h3>\n\n\n\n
Metriktypen als Grundlage<\/strong><\/p>\n\n\n\n Metriken sind aggregierte numerische Zeitreihen wie Request-Rate, Latenz, Fehlerrate oder CPU-Auslastung. F\u00fcr das Verst\u00e4ndnis der weiteren Konzepte ist eine Unterscheidung der drei grundlegenden Metriktypen hilfreich [5]:<\/p>\n\n\n\n Die Instrumentierung dieser Metriken erfolgt \u00fcber OpenTelemetry, wodurch der Code nur einmal instrumentiert werden muss und das Backend \u2013 etwa M3, Prometheus oder Datadog \u2013 austauschbar bleibt.<\/p>\n\n\n\n Service Level Indicator (SLI)<\/strong><\/p>\n\n\n\n Ein Service Level Indicator ist eine messbare Qualit\u00e4tskennzahl aus Nutzerperspektive und wird formal als Verh\u00e4ltnis von erfolgreichen zu allen validen Ereignissen innerhalb eines Zeitfensters ausgedr\u00fcckt [7]. Typische SLIs sind Request-Latenz, Fehlerrate, Verf\u00fcgbarkeit und Durchsatz. F\u00fcr Latenz-SLIs werden dabei bewusst Perzentile statt des Durchschnitts verwendet, da der Mittelwert Ausrei\u00dfer verdeckt: Erhalten etwa ein Prozent der Nutzer zehnfach langsamere Antworten, bleibt der Durchschnitt unauff\u00e4llig, w\u00e4hrend p95 und p99 die Erfahrung der langsamsten Nutzer sichtbar machen \u2013 aus Sicht des Site Reliability Engineering (SRE) h\u00e4ufig die relevanteste Gruppe [7].<\/p>\n\n\n\n Bei Uber entstehen aus diesem Ansatz besondere Herausforderungen: Die verwendeten SLIs sind hochdimensional, das hei\u00dft, 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\u00dfen bei dieser Kardinalit\u00e4t an ihre Grenzen, was Ubers Eigenentwicklung M3 motiviert (siehe Abschnitt I.III).<\/p>\n\n\n\n SLO, Error Budget und Burn Rate<\/strong><\/p>\n\n\n\n Ein Service Level Objective (SLO) definiert einen Zielwert f\u00fcr einen SLI \u00fcber ein festgelegtes Zeitfenster. Es beschreibt bewusst ein \u201egut genug\u201c und keine hundertprozentige Zuverl\u00e4ssigkeit, da jede weitere \u201eNeun\u201c exponentiell teurer wird und die Weiterentwicklung von Funktionen verdr\u00e4ngt [7]. Ein typisches SLO w\u00e4re beispielsweise, dass die p95-Latenz \u00fcber 30 Tage zu 99,5 % unter 300 ms bleibt.<\/p>\n\n\n\n Aus dem SLO ergibt sich das Error Budget als erlaubte Fehlerquote, definiert als 1 \u2212 SLO. Ein SLO von 99,9 % entspricht somit einem Budget von 0,1 %, was etwa 43 Minuten Ausfallzeit pro Monat erlaubt [9]. Dieses Budget \u00fcberf\u00fchrt den Zielkonflikt zwischen Zuverl\u00e4ssigkeit 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\u00fcr modernes SLO-basiertes Alerting (vgl. Abschnitt I.II). In der Praxis wird dabei meist ein rollierendes 30-Tage-Fenster einem Kalendermonat vorgezogen [10].<\/p>\n\n\n\n Von diesen Konzepten ist das Service Level Agreement (SLA) abzugrenzen: W\u00e4hrend das SLA einen extern vereinbarten, vertraglichen Zielwert gegen\u00fcber Kunden darstellt und dessen Verletzung Konsequenzen wie Vertragsstrafen nach sich zieht, ist das SLO ein internes Ziel, das bewusst strenger als das SLA gew\u00e4hlt wird, um einen Puffer zu schaffen. Der SLI ist die zugrunde liegende Messgr\u00f6\u00dfe, auf der beide aufbauen [7].<\/p>\n\n\n\n Abbildung 1: SLO-Schwelle und Alert-Ausl\u00f6sung am Beispiel einer Fehlerrate.<\/em><\/p>\n\n\n\n Grundprinzipien<\/strong><\/p>\n\n\n\n Eine zentrale Herausforderung des Alertings ist das Verh\u00e4ltnis von Signal zu Rauschen. Zu viele Alerts f\u00fchren zu einer sogenannten Alert Fatigue: Engineers stumpfen ab und \u00fcbersehen echte Incidents. Wie real dieses Problem bei gro\u00dfen Systemen ist, zeigt ein Beispiel von Uber, bei dem im Rahmen der \u00dcberwachung von Buchungszahlen \u00fcber 2.000 St\u00e4dte innerhalb von zehn Tagen 232 Anomalien gemeldet wurden, von denen sich lediglich elf als echt erwiesen \u2013 ein Rauschanteil von 95 % [11]. Alerts sollten daher stets actionable<\/em> sein, also eine klare Handlungsanweisung und einen definierten Verantwortlichen besitzen. Ein weiteres SRE-Prinzip besteht darin, auf nutzersichtbare Symptome zu alarmieren (\u201eNutzer erhalten Fehler\u201c) statt auf m\u00f6gliche Ursachen (\u201eDisk-IO ist hoch\u201c), da Letztere h\u00e4ufig Rauschen erzeugen und nicht zwingend nutzerrelevant sind [4]. Nach Dringlichkeit wird zudem gestaffelt: Alerts hoher Priorit\u00e4t l\u00f6sen einen Page an den On-Call-Engineer aus, Alerts niedriger Priorit\u00e4t werden lediglich \u00fcber Slack oder E-Mail zugestellt.<\/p>\n\n\n\n Alerting-Typen im Vergleich<\/strong><\/p>\n\n\n\n In der Praxis lassen sich drei Alerting-Typen unterscheiden. Statische Schwellwerte folgen der einfachen Regel \u201eMetrik > X \u2192 Alert\u201c. Sie sind transparent und eignen sich gut f\u00fcr 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\u00fccksichtigt dadurch zyklische Effekte wie Nachfragespitzen zu bestimmten Uhrzeiten oder an einzelnen Flugh\u00e4fen; sie ist daf\u00fcr schwerer nachvollziehbar und zu debuggen. SLO-basiertes Alerting schlie\u00dflich l\u00f6st aus, wenn das Error Budget zu schnell verbraucht wird, und besitzt damit einen direkten Bezug zur Nutzerauswirkung, erfordert aber solide SLI-Definitionen [12].<\/p>\n\n\n\n F\u00fcr 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\u00e4chliche 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\u00fcr zyklische Business-Metriken n\u00f6tigen dynamischen Schwellwerte \u00fcber die Anomaly-Detection-Plattform Argos beziehungsweise den Forecasting-Layer F3 erzeugt [13]. Das damit verbundene Nachvollziehbarkeitsproblem adressiert Uber \u00fcber ein Alert-Backtesting, bei dem eine Alert-Konfiguration im Trockenlauf gegen historische Produktionsdaten gepr\u00fcft wird, bevor sie aktiv wird [14].<\/p>\n\n\n\n Ubers Monitoring-Stack veranschaulicht, warum klassische Werkzeuge bei Ultra-Large-Scale-Systemen an ihre Grenzen sto\u00dfen und eine Eigenentwicklung notwendig wird. Urspr\u00fcnglich setzte Uber auf Nagios, das Graphite-Schwellwertpr\u00fcfungen gegen Carbon-Metriken ausf\u00fchrte. Mit dem Wachstum des Unternehmens erwies sich dieser Ansatz aufgrund von Skalierungsproblemen des Carbon-Clusters als nicht mehr tragf\u00e4hig, woraufhin eine eigene Plattform entwickelt wurde [13].<\/p>\n\n\n\n Das Metriken-Backend M3 wurde ab 2014\/2015 entwickelt und als Open-Source-Projekt ver\u00f6ffentlicht. Es ist nativ f\u00fcr extreme Kardinalit\u00e4t und horizontale Skalierung ausgelegt und besteht im Kern aus drei Komponenten: der verteilten Zeitreihendatenbank M3DB mit invertiertem Index, dem Prometheus-kompatiblen M3 Coordinator f\u00fcr das Query- und Write-Routing sowie dem M3 Aggregator f\u00fcr Aggregation und Downsampling vor dem Schreiben. Zur Einordnung der Gr\u00f6\u00dfenordnung: M3 aggregiert rund 500 Millionen Metriken pro Sekunde, persistiert etwa 20 Millionen davon pro Sekunde und verwaltete bereits 2018 \u00fcber 6,6 Milliarden Zeitreihen. Der wesentliche Grund f\u00fcr die Eigenentwicklung war, dass kommerzielle und quelloffene Werkzeuge dieses Datenvolumen nicht zu vertretbaren Kosten verarbeiten konnten [15].<\/p>\n\n\n\n Auf M3 setzt das hauseigene Alerting-System uMonitor auf, das Nagios abl\u00f6ste. Es verwaltet rund 125.000 Alert-Konfigurationen und pr\u00fcft dabei etwa 700 Millionen Datenpunkte \u00fcber 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\u00fcfungen etwa im Minutentakt anst\u00f6\u00dft, und Workern, welche die Pr\u00fcfungen ausf\u00fchren. uMonitor unterst\u00fctzt sowohl statische als auch anomaliebasierte Schwellwerte [16].<\/p>\n\n\n\n Erg\u00e4nzt wird uMonitor durch Neris, ein Host-Level-Alerting f\u00fcr hochaufl\u00f6sende Host-Metriken, die nicht in M3 gespeichert werden. Da pro Rechenzentrum etwa 1,5 Millionen Host-Metriken pro Minute \u00fcber 40.000 Hosts anfallen, pr\u00fcft Neris direkt auf dem jeweiligen Host statt gegen eine zentrale Datenbank und vermeidet so unn\u00f6tigen Ingest- und Speicheraufwand [16]. Beide Systeme m\u00fcnden in eine gemeinsame Benachrichtigungs-Pipeline, in der die Deduplizierungs-Komponente Origami Alerts etwa nach Stadt, Produkt oder App-Version b\u00fcndelt und dadurch ein Alert-Flooding bei Kaskaden-Failures verhindert. Zus\u00e4tzlich testet die Komponente Blackbox die API-Infrastruktur von au\u00dferhalb Ubers und erkennt so Probleme, die interne Metriken nicht sichtbar machen [13].<\/p>\n\n\n\n F\u00fcr 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\u00dfteil der Incidents durch Deployments verursacht wird, erkennt uMonitor den Zeitpunkt einer \u00c4nderung und kann automatisch den verantwortlichen Change-Owner kontaktieren. Die ausgel\u00f6sten Benachrichtigungen lassen sich zudem mit Trace-Links aus Jaeger anreichern, wodurch der \u00dcbergang von der Erkennung zur Ursachenanalyse mittels Distributed Tracing (Kapitel III) vorbereitet wird [13].<\/p>\n\n\n\n Abbildung 2: Ubers Alerting-Pipeline (nach [13]).<\/em><\/p>\n\n\n\n F\u00fcr den Uber-Klon wird als Metriken-Backend ein M3-basierter Stack gew\u00e4hlt, da dieser f\u00fcr hohe Kardinalit\u00e4t und horizontale Skalierung ausgelegt ist \u2013 genau die Anforderung, die aus den hochdimensionalen SLIs eines solchen Systems entsteht. Prometheus allein skaliert bei dieser Kardinalit\u00e4t nicht ausreichend, da es an die Grenzen einzelner Knoten und des verf\u00fcgbaren Arbeitsspeichers st\u00f6\u00dft, w\u00e4hrend SaaS-L\u00f6sungen wie Datadog oder New Relic bei diesem Datenvolumen prohibitiv teuer sind und ein Vendor Lock-in bedeuten [15].<\/p>\n\n\n\n F\u00fcr das Alerting wird ein Konzept eingesetzt, das SLIs kontinuierlich gegen ihre SLOs pr\u00fcft und bei einer Verletzung der Burn Rate eskaliert \u2013 realisierbar etwa \u00fcber den Prometheus Alertmanager oder ein zu uMonitor analoges System. Nagios scheidet aus, da es f\u00fcr tausende Microservices nicht skaliert. Als Alerting-Strategie werden statische Schwellwerte f\u00fcr stabile Infrastruktur-Metriken, SLO- beziehungsweise Burn-Rate-basiertes Alerting f\u00fcr nutzerrelevante Symptome und Anomaly Detection f\u00fcr zyklische Business-Metriken kombiniert. Die Instrumentierung erfolgt einheitlich \u00fcber 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\u00fcnstiger ausfallen als mit dem Volumen skalierende Cloud-Kosten.<\/p>\n\n\n\n Distributed Tracing ist ein zentrales Konzept zur Beobachtung und Analyse von Requests in modernen, verteilten Microservice-Architekturen. Ziel ist es, den vollst\u00e4ndigen Lebenszyklus eines einzelnen Requests \u00fcber mehrere unabh\u00e4ngige Services hinweg nachvollziehbar zu machen [17]. Dadurch wird es m\u00f6glich trotz zahlreicher Services, Systeminteraktionen transparent darzustellen und Fehlerursachen zu identifizieren. Besonders in stark entkoppelten Architekturen, wie sie beispielsweise in einem Uber-\u00e4hnlichen System auftreten [1], ist Distributed Tracing eine wichtige Methode, um Abh\u00e4ngigkeiten und Systemverhalten zu verstehen.<\/p>\n\n\n\n Das Grundkonzept von Distributed Tracing basiert auf der Erfassung und Verkn\u00fcpfung von Informationen \u00fcber die Verarbeitung eines Requests innerhalb eines verteilten Systems. Hierbei sind zentrale Bestandteile der sogenannte Trace und der Span [18]:<\/p>\n\n\n\n Zur eindeutigen Zuordnung werden zwei zentrale Identifikatoren verwendet [19]:<\/p>\n\n\n\n Durch diese Struktur l\u00e4sst sich der Ablauf eines Requests, die Abh\u00e4ngigkeiten zwischen Services sowie Latenzen einzelner Verarbeitungsschritte analysieren. Dadurch wird Transparenz in ansonsten schwer nachvollziehbaren Microservice-Systemen geschaffen.<\/p>\n\n\n\n Typische Tracing-Systeme bestehen aus vier Hauptkomponenten:<\/p>\n\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/07\/image.png\")
<\/a><\/figure>\n\n\n\nI.II Alerting-Strategie<\/h3>\n\n\n\n
I.III Ubers Monitoring-Stack: M3, uMonitor und Neris<\/h3>\n\n\n\n
<\/a><\/figure>\n\n\n\nI.IV Umsetzung im Uber-Klon<\/h3>\n\n\n\n
\n\n\n\nII. Distributed Tracing<\/h2>\n\n\n\n
II.I Grundkonzept<\/h3>\n\n\n\n
\n
\n
II.II Tools und Technologien<\/h3>\n\n\n\n