Die RED-Methode für anfragegetriebene Dienste, mit Exemplaren, die einen langsamen Bucket mit einem Trace verknüpfen

Ziel

Jedem anfragegetriebenen Dienst dieselben drei Signale geben, damit Dashboards, Alarme und Vorfallsfragen über die gesamte Architektur hinweg gleich aussehen: Rate (Anfragen pro Sekunde), Errors (fehlschlagende Anfragen) und Duration (wie lange Anfragen dauern), die RED-Methode, die der zitierte Grafana-Beitrag Tom Wilkie als mikroservice-orientiertes Gegenstück zur USE-Methode zuschreibt, welche für Hardware-Ressourcen gilt.

Voraussetzungen

Eine Metrikbibliothek mit Zählern und Histogrammen, Route-Templates mit niedriger Kardinalität und optional ein Tracing-Setup, dessen Trace-IDs an Metrikbeobachtungen angehängt werden können.

Schritte

1. Für jeden Dienst einen Zähler <svc>_requests_total{route, method, code} bereitstellen, der beim Abschluss einer Anfrage erhöht wird, sowie ein Histogramm <svc>_request_duration_seconds mit denselben Labels. Errors werden aus code abgeleitet (5xx, oder ein domänenspezifisches Fehler-Label), statt aus einem separaten Zähler, der vom Gesamtwert abdriften kann.
2. Eine Dashboard-Zeile pro Dienst bauen: Anfragerate, Fehlerquote (Errors geteilt durch Gesamtzahl im selben Fenster) und Duration-Perzentile aus dem Histogramm. Zeilen nach Datenfluss anordnen, sodass die obere Zeile die aufrufende Seite der unteren ist.
3. Auf die Fehlerquote und auf das Duration-Ziel alarmieren, nicht auf die Rate; Ratenänderungen sind Kontext.
4. Exemplare anhängen. OpenMetrics definiert ein Exemplar als Verweis auf Daten ausserhalb des Metrik-Sets, meist eine Trace-ID, bestehend aus einem Label-Set und einem Wert mit optionalem Zeitstempel, wobei die kombinierte Länge von Label-Namen und -Werten auf 128 Codepunkte begrenzt ist. Die Spezifikation des OpenTelemetry-Metrics-SDK beschreibt ein Exemplar als eine aufgezeichnete Messung, die den Wert, den Zeitpunkt des Aufrufs, durch Aggregation verworfene Attribute sowie, bei synchronen Instrumenten, Trace-ID und Span-ID der aktiven Span offenlegt; ihr Standard-Exemplarfilter sollte TraceBased sein, sodass nur innerhalb einer gesampelten Span gemachte Messungen als Exemplar infrage kommen. Andere Client-Bibliotheken benötigen unter Umständen die mit der Beobachtung übergebene Trace-ID; die Dokumentation der jeweiligen Bibliothek prüfen.
5. Die Exemplarspeicherung im Metrik-Backend aktivieren und die Histogramm-Panels des Dashboards so konfigurieren, dass Exemplarpunkte angezeigt werden, die beim Anklicken den Trace öffnen.
6. Die Verknüpfung prüfen: einen langsamen Bucket im Dashboard auswählen, das Exemplar öffnen und bestätigen, dass der Trace die Anfrage zeigt, die die Beobachtung erzeugt hat.

Erwartetes Ergebnis

Jede diensthabende Person kann die Gesundheit jedes Dienstes in denselben drei Panels ablesen und ohne Suche von "p99 stieg um 14:02" zu einem konkreten Trace einer langsamen Anfrage gelangen.

Grenzen und Prüfbasis

RED deckt anfragegetriebene Komponenten ab; Queues und Batch-Jobs brauchen Aktualitäts- und Letzter-Erfolg-Indikatoren, und Ressourcenerschöpfung braucht USE. Exemplare sind nur so gut wie das Trace-Sampling: Eine nicht gesampelte langsame Anfrage hinterlässt kein Exemplar. Die Bucket-Grenzen entscheiden, welche Perzentile ein klassisches Histogramm beantworten kann.