Die RED-Methode ist ein Monitoring-Muster für anfragebasierte Services, das für jeden Service drei Signale erfasst: Rate (Anfragen pro Sekunde), Errors (fehlgeschlagene Anfragen absolut oder als Anteil) und Duration (die Verteilung der Antwortzeiten). So erhält jeder Microservice dieselben kompakten, nutzerorientierten Dashboards und Alarme.
Was ist die RED-Methode?
Die RED-Methode ist eine einfache Regel für das Monitoring von Services: Messen Sie für jeden Service die Rate der Anfragen, die Anzahl der Errors (Fehler) und die Duration (Dauer) dieser Anfragen. Bekannt gemacht hat sie Tom Wilkie, damals bei Weaveworks, als serviceorientiertes Gegenstück zur USE-Methode von Brendan Gregg, die Ressourcen statt Anfragen betrachtet.
Die Idee ist bewusst eng gefasst. Statt für jeden Microservice ein eigenes Dashboard zu entwerfen, wenden Teams überall dieselben drei Signale an. Wer in der Rufbereitschaft einen beliebigen Service öffnet, sieht dasselbe Layout und kann dieselben Fragen beantworten: Wie viel Traffic kommt an, wie viel davon schlägt fehl und wie lange dauert er? Genau diese Einheitlichkeit macht RED in Architekturen mit Dutzenden oder Hunderten Services so wertvoll.
Die drei Signale der RED-Methode
| Signal | Was es misst | Typische Einheit |
|---|---|---|
| Rate | Anfragen, die der Service verarbeitet | Anfragen pro Sekunde |
| Errors | Fehlgeschlagene Anfragen | Fehler pro Sekunde oder % der Anfragen |
| Duration | Zeit bis zur Antwort | Latenzverteilung, z. B. p50, p95, p99 |
Rate ist eng mit dem Durchsatz verwandt und zeigt Last, Verschiebungen im Traffic und Ausfälle, die sich als plötzlicher Abfall auf null bemerkbar machen. Errors sollte zählen, was Nutzer als Fehler erleben: HTTP-5xx-Antworten, gRPC-Fehlercodes, Timeouts und gegebenenfalls Antworten, die technisch erfolgreich, inhaltlich aber falsch sind. Als Fehlerrate ausgedrückt werden Services mit unterschiedlichem Traffic vergleichbar. Duration muss als Verteilung und nicht als Mittelwert gemessen werden, denn Durchschnittswerte verdecken genau die langsamen Ausreißer, die Nutzer bemerken. Erfassen Sie Perzentile wie p95 und p99, idealerweise aus Histogrammen, damit sie sich über Instanzen hinweg aggregieren lassen.
RED-Methode vs. USE-Methode und Golden Signals
RED, USE und die vier Golden Signals von Google überschneiden sich, setzen aber unterschiedliche Schwerpunkte. Die Golden Signals sind Latenz, Traffic, Fehler und Sättigung. RED entspricht im Kern den ersten drei, konsequent pro Service angewendet. USE (Utilization, Saturation, Errors) bezieht sich auf Ressourcen wie CPUs, Datenträger, Warteschlangen und Connection Pools. In der Praxis kombinieren Teams beides: RED zeigt, dass ein Service aus Sicht seiner Aufrufer krankt, USE zeigt, welche Ressource darunter knapp wird. RED allein kennt kein Sättigungssignal, daher kann ein Service bis zu dem Moment unauffällig wirken, in dem eine Ressource erschöpft ist.
Beispiel: RED mit PromQL
Angenommen, ein Service stellt ein Histogramm http_server_request_duration_seconds bereit (der Name aus den OpenTelemetry Semantic Conventions, nach Prometheus exportiert). Dann lassen sich die drei Signale so abfragen:
# Rate: Anfragen pro Sekunde je Service
sum by (service) (rate(http_server_request_duration_seconds_count[5m]))
# Errors: Anteil der 5xx-Antworten
sum by (service) (rate(http_server_request_duration_seconds_count{http_response_status_code=~"5.."}[5m]))
/ sum by (service) (rate(http_server_request_duration_seconds_count[5m]))
# Duration: p99-Latenz
histogram_quantile(0.99, sum by (service, le) (rate(http_server_request_duration_seconds_bucket[5m])))Ein einziges Histogramm genügt für alle drei Signale: Sein Zähler liefert die Rate, ein gefilterter Zähler die Fehler und die Buckets die Verteilung der Dauer. Die genauen Metrik- und Label-Namen hängen von Ihrer Instrumentierung und Ihrem Exporter ab.
Im Dashboard sollten die drei Panels je Service nebeneinander stehen und denselben Zeitraum zeigen. Gemeinsam gelesen sagen sie mehr als jedes Signal für sich: Sinkt die Rate bei steigenden Fehlern, scheitern Aufrufer oft schnell oder geben auf; steigt die Dauer bei gleichbleibender Rate, deutet das auf eine langsame Abhängigkeit oder Ressourcenkonkurrenz hin. Ein plötzlicher Anstieg der Rate bei stabilen Fehlern und stabiler Dauer zeigt dagegen nur, dass der Service mehr Last trägt. Diese erste Einordnung dauert Sekunden und zeigt, wo Sie weitersuchen sollten: in Traces, Logs oder Ressourcenmetriken.
Best Practices
- An der Servicegrenze messen. Instrumentieren Sie eingehende Anfragen serverseitig und bei Bedarf ausgehende Aufrufe clientseitig, um eigene Fehler von denen der Abhängigkeiten zu unterscheiden.
- Überall dieselben Namen und Labels verwenden. Wer den OpenTelemetry Semantic Conventions folgt, kann eine Dashboard-Vorlage für alle Services nutzen.
- Fehler und Dauer trennen. Schnelle Fehlschläge lassen die Latenz besser aussehen; messen Sie die Dauer erfolgreicher Anfragen bei Bedarf separat.
- Auf Symptome alarmieren, nicht auf Ursachen. RED-Signale eignen sich gut als SLIs für SLO-basierte Alarme, Ressourcenmetriken eher für die Diagnose.
- Kardinalität im Griff behalten. Gruppieren Sie Routen nach Vorlage (
/orders/{id}) statt nach Roh-URLs.
Häufige Fehler
- Durchschnittliche Latenz statt Perzentilen aus Histogrammen auszuweisen.
- 4xx-Clientfehler als Servicefehler zu zählen, wodurch echte Störungen im Rauschen untergehen.
- RED unverändert auf Batch-Jobs oder Queue-Consumer anzuwenden; dort sind Durchsatz, Rückstand und fehlgeschlagene Jobs aussagekräftiger.
- Bei RED stehen zu bleiben und Sättigung zu ignorieren, sodass Kapazitätsprobleme erst sichtbar werden, wenn Nutzer sie bereits spüren.
Wie Obseria hilft
Obseria leitet Rate, Fehler und Dauer für jeden instrumentierten Service aus OpenTelemetry-Traces und -Metriken ab, und Obseria TopoGraph ordnet sie in die automatisch erkannte Service-Topologie ein. RED-Metriken lassen sich mit PromQL, OQL oder SQL abfragen, als SLIs für SLOs mit Burn-Rate-Alarmen nutzen und über Distributed Tracing direkt mit den zugrunde liegenden Traces verknüpfen, sobald ein Signal auffällig wird.
