Begriff
Observability
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Monitoring sagt dir: "Der Server ist rot." (Bekannter Fehler). Observability sagt dir: "Der Server ist langsam, weil Kunde Müller eine irre Query abgesetzt hat, die den Cache umgeht." (Unbekannter Fehler). Monitoring prüft auf Dinge, die du erwartest (CPU zu hoch). Observability erlaubt dir, Fragen zu stellen, an die du beim Programmieren nie gedacht hast. Es basiert auf drei Säulen (The Three Pillars):
- Logs: (Was ist passiert?).
- Metrics: (Wie viel passiert?).
- Traces: (Wo ist es passiert?).
Merksatz: Eine Eigenschaft eines Systems, die beschreibt, wie gut man seinen internen Zustand allein durch die Analyse seiner externen Ausgaben (Logs, Metriken, Traces) verstehen kann.
Tools wie Honeycomb, Datadog, Jaeger. Du klickst dich durch Daten. "Zeig mir alle Requests, die länger als 2s dauerten." "Gruppier sie nach User-ID." "Aha! Alle kommen von User 1234." "Zeig mir den Trace für einen Request von User 1234." "Aha! Er ruft den kaputten Microservice B auf."
1. High Cardinality
Der Schlüssel zu echter Observability. Alte Monitoring-Tools (Prometheus) hassen "User-IDs" als Label (zu viele verschiedene Werte = High Cardinality). Sie explodieren. Observability-Tools lieben High Cardinality. Nur so findest du den "Nadel im Heuhaufen" (den einen User, der den Bug auslöst).
2. Distributed Tracing
Ohne Tracing bist du bei Microservices blind. Ein Trace (eine ID) wandert durch alle Services mit. Du siehst einen Wasserfall-Graphen: Frontend (10ms) -> Backend (50ms) -> DB (2000ms!). Du siehst sofort, wer der Schuldige ist.
1. High Cardinality & Columnar Storage Engines
Warum kippen Prometheus oder InfluxDB (klassische Time-Series Databases - TSDBs) bei "User-ID" Tracing aus den Schuhen?
In Prometheus aggregiert eine Metrik aus Name und Label-Tags einen Index (z. B. http_requests_total{method="GET", user_id="UUID"}). Jede unike Variation ist im TSD Graph eine dedizierte Time Series. Läuft "UUID" auf 1 Million Varianten auf, explodiert der RAM Index State Space (Cardinality Explosion). Der OOM-Killer vernichtet die Infrastruktur Node.
Echte O11y-Backends (wie Honeycomb oder ClickHouse) verwerfen den pre-aggregierten TSDB-Ansatz komplett!
Sie betreiben O11y auf rohen, unstrukturierten breiten Events innerhalb extrem aggressiver Columnar Databases. Einzelne Spalten (user_id) werden mit gigantischer Dictionary- & Run-Length-Encoding (RLE) Kompression komprimiert. Eine ad-hoc Suche generiert den Graph Live zur Laufzeit per vektorisierter SIMD-CPU-Filterung über hunderte Gigabyte Log-Strings, anstatt sie schon beim Ingest teuer vorab in Index-Hierarchien zu backen. Das verschiebt die Kostenstruktur auf massiven C-Read-Parallelismus.
2. Distributed Context Propagation (B3 Headers / W3C Trace Context)
Wie verbindet Jaeger einen HTTP-Request am AWS API Gateway logisch mit einem RabbitMQ Async-Job tief im Kubernetes Cluster von Node 15?
Der magische Leim ist Trace-Propagation. Das System (OpenTelemetry Profiler Client) klinkt in Web-Framework Middleware (Express/Spring Boot) ein.
Es generiert bei Entry Point (/login) eine Trace-ID: 5b8aa... und eine Span-ID: e123.
Wenn der Container via fetch() oder HTTP/gRPC den Nachbar-Service pingt, injiziert der Framework-Interceptor hart das Header-Wissen ein. Standard war lange X-B3-TraceId (Zipkin), der moderne IETF-Standard ist der HTTP Header:
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01.
Dieser Token durchbricht alle Netzwerk-Layer. Nimmt der Worker-Prozess die Pipeline auf, liest er den HTTP-Header des Vorbesitzers, spannt einen Sub-Span (Parent-ID=vorbesitzer_id) auf und reportet via gRPC asynchron (Fire and Forget Base UDP out of band!) direkt ans Collector-Backend. Ohne diesen transparenten Header Passing-Hack entkernt sich Tracing nutzlos im LAN Routing.
3. Tail-based vs. Head-based Sampling
Wenn Amazon 100 Millionen Queries pro Sekunde absetzt, ist 100% Traces Storage ein Multi-Millionen-Dollar AWS-S3 Fiasko. Man sticht aus (Sampling). Head-based Sampling ist primitiv und dumm: Die Entrypoint API wirft beim Start zufällig einen Würfel. Zu 99% killt sie den Trace sofort, keine Headers werden jemals geschrieben. Zu 1% feuert es. Nachteil: Du hast am Ende fast nur noch 1% "erfolgreiche" billige Standard-Happy-Pathes gelogt, der extrem seltene Nadel-Request (Der Timeout Bug User) war zu 99% vom Würfel ignoriert worden. Observability Müll! Tail-based Sampling ist die Genialität: Das System sticht nicht vorne aus. Es trackt 100% aller 5 Millionen Requests der Node flüchtig ins RAM oder Redis! Nachdem ein Request komplett ist (Tail), untersucht der Collector den Graphen: War es ein Fehler (HTTP 500)? War er ultra langsam (> 5s)? Gab es Anomalien? Ist die Antwort JA -> Speichere als VIP permanent ab. War es ein normaler "All Okay" Call -> Lösche ihn sofort. Das Resultat verdichtet extrem smarte Error/Latenz Graphen massiv in Kosteneffizienten Storage.
Quick-Check
Ist es nur ein Buzzword für Monitoring?
Böse Zungen sagen Ja. Aber der Fokus ist anders: Exploration (Warum?) statt nur Alerting (Dass!).Kostet es Performance?
Ja. Tracing erzeugt riesige Datenmengen. Man nutzt oft "Sampling" (nur 10% der Requests speichern), um Geld zu sparen.Was ist OpenTelemetry?
Der Standard. Früher hatte jedes Tool eigene Agenten. Jetzt nutzen alle (Google, AWS, Microsoft) OpenTelemetry zum Sammeln der Daten.