Die vier Golden Signals sind Latenz, Traffic, Fehler und Sättigung (Saturation): die vier Metriken, die das SRE-Buch von Google für jedes nutzernahe System empfiehlt. Sie beschreiben, wie schnell ein Service antwortet, wie viel Last er bedient, wie oft er scheitert und wie nah er an seinen Kapazitätsgrenzen arbeitet.
Das Wichtigste in Kürze
- Golden Signals: Latenz (wie lange), Traffic (wie viel), Fehler (wie oft etwas scheitert) und Sättigung (wie voll).
- Die RED-Methode (Rate, Errors, Duration) überträgt die Idee auf jeden request-basierten Service, die USE-Methode (Utilization, Saturation, Errors) auf jede Ressource.
- Messen Sie Latenz als Perzentile aus Histogrammen und trennen Sie die Latenz fehlgeschlagener Requests von erfolgreichen.
- Alarmieren Sie auf Symptome in den Golden Signals, idealerweise über SLOs, und nutzen Sie Sättigung und USE-Metriken für die Ursachenanalyse.
Was sind die vier Golden Signals?
Die vier Golden Signals sind ein minimaler Satz von Metriken, um jedes nutzernahe System zu überwachen: Latenz, Traffic, Fehler und Sättigung. Sie stammen aus dem Kapitel „Monitoring Distributed Systems“ des Site-Reliability-Engineering-Buchs von Google. Die Kernaussage: Wenn Sie für ein nutzernahes System nur vier Metriken erfassen können, dann diese vier. Ein Service mit gesunden Golden Signals bedient seine Nutzer in aller Regel gut. Verändert sich eines davon, sind Nutzer betroffen oder werden es bald sein.
Der Wert der Golden Signals liegt in ihrer Allgemeingültigkeit. Sie funktionieren für eine REST-API, einen gRPC-Microservice, eine Datenbank, einen Message Broker oder ein Web-Frontend. Sie geben jedem Team dasselbe Grundvokabular und machen Dashboards über Hunderte Services hinweg vergleichbar.
Die vier Signale im Detail
1. Latenz
Latenz ist die Zeit, die ein Request zur Bearbeitung braucht. Zwei Details sind entscheidend. Erstens: Messen Sie Verteilungen statt Durchschnittswerte. p50 beschreibt den typischen Request, p95 und p99 den Long Tail, den ein relevanter Teil der Nutzer bei jedem Seitenaufruf mit vielen Backend-Calls erlebt. Zweitens: Trennen Sie erfolgreiche und fehlgeschlagene Requests. Eine Datenbank, die Anfragen in 2 ms ablehnt, lässt die durchschnittliche Latenz hervorragend aussehen, während Nutzer Fehler sehen. Ein langsamer Fehler ist noch schlimmer als ein schneller, deshalb sollten Sie beides erfassen.
2. Traffic
Traffic misst die Last auf dem System in einer passenden Einheit: HTTP-Requests pro Sekunde für einen Webservice, Nachrichten pro Sekunde für einen Queue-Consumer, Transaktionen oder Lesezugriffe pro Sekunde für eine Datenbank, gleichzeitige Sessions oder Bytes pro Sekunde für einen Streaming-Dienst. Traffic liefert den Kontext für alle anderen Signale: Ein Fehleranstieg während einer Lastspitze erzählt eine andere Geschichte als einer um drei Uhr nachts.
3. Fehler
Fehler bezeichnen die Rate fehlgeschlagener Requests. Das SRE-Buch unterscheidet drei Arten: explizite Fehler (HTTP 500), implizite Fehler (HTTP 200 mit falschem oder leerem Inhalt) und Policy-Fehler (etwa jede Antwort über einer Sekunde, weil Sie diese Grenze zugesagt haben). Implizite Fehler sind nur über End-to-End-Prüfungen, synthetische Tests oder fachliche Validierung sichtbar.
4. Sättigung
Sättigung (Saturation) beschreibt, wie „voll“ ein Service ist, mit Fokus auf die knappste Ressource: CPU bei rechenintensiven Services, Arbeitsspeicher, I/O, Connection Pools, Thread Pools oder Queue-Tiefe. Viele Systeme verschlechtern sich lange vor 100 % Auslastung, daher braucht Sättigung einen Zielwert, der abbildet, ab wann die Performance leidet. Sättigung hat auch eine Vorhersagekomponente: „Die Festplatte ist in vier Stunden voll“ ist ein Sättigungssignal. Steigende Latenz ist oft der früheste Hinweis auf Sättigung.
RED und USE: zwei verwandte Methoden
Zwei weitere bekannte Frameworks wenden dasselbe Denken auf andere Bereiche an.
Die RED-Methode, beschrieben von Tom Wilkie, konzentriert sich auf request-basierte Services. Für jeden Service messen Sie Rate (Requests pro Sekunde), Errors (fehlgeschlagene Requests pro Sekunde) und Duration (Verteilung der Latenz). RED entspricht im Kern den Golden Signals ohne Sättigung und passt gut zu Microservices, weil sich alle drei Metriken aus einem einzigen Latenz-Histogramm mit Fehler-Label ableiten lassen.
Die USE-Methode, entwickelt von Brendan Gregg für die Performance-Analyse, konzentriert sich auf Ressourcen. Für jede Ressource (CPU, Speicher, Festplatten, Netzwerkschnittstellen, aber auch Locks, Thread Pools und Connection Pools) prüfen Sie Utilization (Anteil der Zeit, in der die Ressource beschäftigt ist), Saturation (wartende Arbeit) und Errors (Fehlerereignisse). USE ist als Checkliste gedacht, um Engpässe schnell zu finden.
| Methode | Signale | Geltungsbereich | Ideal für |
|---|---|---|---|
| Vier Golden Signals | Latenz, Traffic, Fehler, Sättigung | Nutzernahe Systeme | Service-Gesundheit, Alerting, SLOs |
| RED | Rate, Errors, Duration | Jeder request-basierte Service | Microservice-Dashboards, einheitliche Service-Sicht |
| USE | Utilization, Saturation, Errors | Jede Hardware- oder Software-Ressource | Engpassanalyse, Kapazitätsplanung |
Die Methoden ergänzen sich, statt zu konkurrieren. Eine praktische Regel: Mit RED oder den Golden Signals erkennen Sie, dass und wo Nutzer betroffen sind, mit USE auf Hosts, Containern und Pools finden Sie heraus, warum.
Golden Signals für unterschiedliche Systemtypen
Die vier Signale sind universell, doch was Sie konkret messen, hängt vom Systemtyp ab. Die Tabelle zeigt typische Entscheidungen:
| System | Latenz | Traffic | Fehler | Sättigung |
|---|---|---|---|---|
| HTTP- oder gRPC-API | Request-Dauer p50/p99 | Requests pro Sekunde | 5xx- und gRPC-Fehlercodes | CPU, Thread- und Connection Pools |
| Queue-Consumer | Alter der Nachricht Ende zu Ende | Verarbeitete Nachrichten pro Sekunde | Fehlgeschlagene Nachrichten, Dead Letters | Consumer Lag, Queue-Tiefe |
| Datenbank | Query-Dauer | Queries oder Transaktionen pro Sekunde | Fehlgeschlagene Queries, Deadlocks | Belegte Verbindungen, Disk und IOPS |
| Batch-Job | Laufzeit im Verhältnis zur Deadline | Verarbeitete Datensätze pro Lauf | Fehlgeschlagene Läufe, abgewiesene Datensätze | Worker-Auslastung, Rückstau |
| Web-Frontend | Core Web Vitals wie LCP und INP | Seitenaufrufe, Sessions | JavaScript-Fehler, fehlgeschlagene API-Calls | Blockierter Main Thread, Long Tasks |
Bei asynchronen Systemen sollte die Latenz abbilden, wie lange die Arbeit aus Nutzersicht gedauert hat, also etwa die Zeit von der Erzeugung einer Nachricht bis zu ihrer Verarbeitung, nicht nur die Bearbeitungszeit im Consumer. Ein Consumer, der jede Nachricht in 5 ms verarbeitet, lässt Nutzer trotzdem im Stich, wenn die Queue einen Rückstau von zwei Stunden hat. Genau solche Fälle bleiben unsichtbar, wenn Sie Golden Signals nur mechanisch auf HTTP-Endpunkte anwenden. Definieren Sie daher für jeden Systemtyp bewusst, was Latenz, Traffic, Fehler und Sättigung aus Nutzersicht bedeuten.
Golden Signals mit OpenTelemetry messen
Die Semantic Conventions von OpenTelemetry machen es einfach, Golden Signals herstellerneutral abzuleiten. Die stabile HTTP-Metrik http.server.request.duration ist ein Histogramm mit Attributen wie http.request.method, http.route, http.response.status_code und error.type. Aus diesem einen Instrument erhalten Sie:
- Traffic / Rate: die Anzahl der Histogramm-Einträge pro Sekunde.
- Fehler: die Anzahl mit gesetztem
error.typeoder 5xx-Status, geteilt durch die Gesamtzahl. - Latenz / Duration: Perzentile, berechnet aus den Histogramm-Buckets.
Sättigung stammt aus Ressourcenmetriken: CPU-Throttling und Memory Working Set von Containern, Runtime-Metriken wie Garbage-Collection-Zeit, Auslastung des Datenbank-Connection-Pools und Consumer Lag von Message Queues. Distributed Traces ergänzen, was Metriken nicht leisten: welcher nachgelagerte Aufruf einen langsamen Request langsam gemacht hat.
In PromQL sehen die klassischen RED-Queries über das exportierte Histogramm so aus:
# Rate
sum by (http_route) (rate(http_server_request_duration_seconds_count[5m]))
# Fehlerquote
sum(rate(http_server_request_duration_seconds_count{http_response_status_code=~"5.."}[5m]))
/ sum(rate(http_server_request_duration_seconds_count[5m]))
# p99-Latenz
histogram_quantile(0.99,
sum by (le) (rate(http_server_request_duration_seconds_bucket[5m])))Von Golden Signals zu Alerts und SLOs
Golden Signals sind der richtige Ort für Alerts, weil sie Symptome beschreiben, die Nutzer spüren. Alerts auf Ursachen wie „CPU über 80 %“ erzeugen Pages, die oft irrelevant sind, und übersehen Ausfälle mit unerwarteten Ursachen. Ein ausgereiftes Setup sieht so aus:
- Latenz und Fehler als SLIs nutzen und SLOs für kritische User Journeys definieren.
- Auf die SLO-Burn-Rate pagen statt auf starre Schwellwerte einzelner Signale.
- Traffic-Anomalien (plötzliche Einbrüche sind so wichtig wie Spitzen) als zweite Alert-Ebene nutzen, denn ein stiller Ausfall zeigt sich oft nur als fehlender Traffic.
- Sättigung für Kapazitätswarnungen und Tickets nutzen, nicht für Pages, außer eine Ressource läuft unmittelbar voll.
- USE-Metriken für die Diagnose auf Dashboards bereithalten, verlinkt aus jeder Service-Ansicht.
Typische Fallstricke
- Latenz mitteln. Ein Mittelwert von 120 ms kann ein p99 von vier Sekunden verbergen. Nutzen Sie Histogramme und Perzentile und mitteln Sie niemals Perzentile über Instanzen hinweg.
- Traffic-Einbrüche ignorieren. Die Fehlerrate bleibt bei null, wenn gar keine Requests ankommen. Achten Sie darauf, ob der Traffic unter sein erwartetes Muster fällt.
- Clientfehler als Serverfehler zählen. Eine Welle von 404-Antworten wegen eines kaputten Links ist wissenswert, sollte aber nicht Ihr Verfügbarkeits-SLO belasten.
- Nur am Service messen. Load Balancer, CDN und Browser sehen Fehler, die Ihr Service nie loggt. Ergänzen Sie Edge-Metriken, synthetische Checks und Real User Monitoring.
- Kardinalitätsexplosion. Labels mit Nutzer-IDs oder vollständigen URLs machen Metriken teuer und langsam. Verwenden Sie Routen-Templates und legen Sie hochkardinale Details in Traces und Logs ab.
- Sättigung nur als CPU verstehen. Die eigentliche Grenze ist oft ein Connection Pool, ein Thread Pool, eine rate-limitierte Downstream-API oder eine Queue.
Wie Obseria unterstützt
Obseria leitet Golden Signals und RED-Metriken automatisch für jeden erkannten Service ab, aus OpenTelemetry-Spans und -Metriken oder über den Obseria Agent, und zeigt sie ohne manuellen Dashboard-Aufwand in einer einheitlichen Service-Ansicht. Obseria TopoGraph ordnet jeden Service in seinen Abhängigkeitsgraphen ein. So lässt sich ein Latenzanstieg bis zum gesättigten Datenbank-Pool oder Container darunter verfolgen, wo Ressourcenmetriken im Sinne von USE einen Klick entfernt sind. Dieselben Daten fragen Sie per OQL, PromQL oder SQL ab, machen jedes Golden Signal zum SLO und lassen Anomalieerkennung und Obseria Intelligence ungewöhnliche Veränderungen bei Traffic, Fehlern oder Latenz melden, bevor sie Ihr Error Budget aufbrauchen.