Die Fehlerrate (Error Rate) ist der Anteil der Requests oder Operationen, die in einem bestimmten Zeitfenster fehlschlagen, meist als Prozentsatz aller Requests angegeben. Sie ist eines der vier Golden Signals und das E der RED-Methode. Was als Fehler gilt, etwa HTTP-5xx-Antworten oder Exceptions, muss pro Service ausdrücklich festgelegt werden.
Was die Fehlerrate bedeutet
Die Fehlerrate misst, wie oft ein Service nicht leistet, was von ihm verlangt wurde. Meist ist sie ein Verhältnis:
Fehlerrate = fehlgeschlagene Requests / alle Requests (in einem Zeitfenster)Hat ein Service in den letzten fünf Minuten 120.000 Requests verarbeitet und sind 360 davon fehlgeschlagen, liegt die Fehlerrate bei 0,3 %. Manchmal wird der Begriff auch für Fehler pro Sekunde verwendet, also einen absoluten Wert. Beides ist nützlich, beantwortet aber unterschiedliche Fragen: Die Quote zeigt, wie schlecht die Erfahrung für einen durchschnittlichen Request ist, der absolute Wert, wie viele Nutzer betroffen sind. 50 % auf einem Testendpunkt mit zwei Aufrufen wiegen weniger als 0,5 % im Checkout zur Hauptlastzeit.
Die Fehlerrate gehört mit Latenz, Traffic und Sättigung zu den vier Golden Signals und ist Grundlage der meisten Verfügbarkeits-SLOs.
Was als Fehler zählt
Die Formel ist einfach, umstritten ist die Definition von „fehlgeschlagen“. Gängige Regeln:
| Protokoll / Signal | Meist ein Fehler | Meist kein Fehler |
|---|---|---|
| HTTP-Server | 5xx-Antworten, Timeouts, abgebrochene Verbindungen | 4xx-Antworten, die der Client verursacht (404, 401, 422) |
| HTTP-Client | 4xx- und 5xx-Antworten, Verbindungsfehler | Erwartete 404-Prüfungen, sofern behandelt |
| gRPC | INTERNAL, UNAVAILABLE, DEADLINE_EXCEEDED, UNKNOWN, DATA_LOSS | NOT_FOUND, INVALID_ARGUMENT bei serverseitigen Metriken |
| Jobs und Nachrichten | Fehlgeschlagene Läufe, Nachrichten in der Dead-Letter-Queue | Wiederholte und später erfolgreiche Versuche, sofern separat erfasst |
Die OpenTelemetry Semantic Conventions folgen derselben Logik. Bei HTTP-Server-Spans setzt ein 5xx-Status den Span-Status auf Error, 4xx-Antworten lassen ihn ungesetzt, weil der Server korrekt gehandelt hat. Bei Client-Spans sind aus Sicht des Aufrufers sowohl 4xx als auch 5xx Fehler. Das Attribut error.type hält Statuscode oder Exception-Klasse fest, sodass Metriken wie http.server.request.duration nach Fehlerart aufgeschlüsselt werden können.
Zwei Sonderfälle verdienen Aufmerksamkeit. Erstens ist ein 429 oder 503 aus Ihrem eigenen Rate Limiting oder Überlastschutz aus Nutzersicht ein echter Fehler. Zweitens bleibt ein Request, der 200 mit einer Fehlermeldung im Body liefert, für statuscodebasierte Fehlerraten unsichtbar. Business-Checks oder synthetische Tests decken solche Fälle auf.
So wird sie gemessen
Die Fehlerrate lässt sich aus drei Quellen ableiten, die sich ergänzen:
- Metriken. Request-Zähler oder Histogramme mit Status-Label. Günstig, vollständig und ideal für Alerting und SLOs.
- Traces. Spans mit Fehlerstatus zeigen, wo in der Aufrufkette der Fehler entstand und welche Attribute die fehlerhaften Requests gemeinsam haben.
- Logs und Fehlerereignisse. Stacktraces und Meldungen erklären, was im Code schiefging.
Eine beispielhafte PromQL-Abfrage für die Server-Fehlerquote eines Checkout-Service über fünf Minuten, basierend auf nach Prometheus exportierten OpenTelemetry-HTTP-Metriken:
sum(rate(http_server_request_duration_seconds_count{service_name="checkout",http_response_status_code=~"5.."}[5m]))
/
sum(rate(http_server_request_duration_seconds_count{service_name="checkout"}[5m]))Alerting auf die Fehlerrate
Eine statische Regel wie „Page, wenn die Fehler eine Minute lang über 1 % liegen“ ist schnell geschrieben und meist verrauscht. Kurze Spitzen lösen sie aus, ein langsamer Anstieg von 0,1 % auf 0,8 % über einen Tag bleibt dagegen unbemerkt. Zuverlässiger sind Alerts auf die Burn Rate des Error Budgets mit mehreren Fenstern: Sie setzen die aktuelle Fehlerrate ins Verhältnis zum SLO und reagieren auf schwere Probleme schneller als auf leichte.
Bei Services mit wenig Traffic droht ein kleiner Nenner: Ein fehlgeschlagener von drei Requests ergibt 33 % Fehlerrate. Verlangen Sie eine Mindestanzahl an Requests im Fenster, aggregieren Sie über einen längeren Zeitraum oder ergänzen Sie synthetischen Traffic.
Retries machen das Bild unschärfer. Wiederholt ein Client einen fehlgeschlagenen Aufruf und gelingt der zweite Versuch, sieht der Nutzer einen Erfolg, während der Server einen Fehler verbucht. Messen Sie die Fehlerrate deshalb sowohl pro Versuch am Server als auch pro logischer Operation am Rand des Systems, etwa am API-Gateway. Wächst der Abstand zwischen beiden Werten, ist das ein frühes Warnsignal: Retries verdecken ein Problem und erzeugen zusätzlich Last.
Best Practices
- Die Fehlerdefinition schriftlich festhalten, pro Service, und in Dashboards, Alerts und SLOs einheitlich verwenden.
- Quoten aus Summen berechnen, nicht als Mittelwert der Fehlerraten einzelner Instanzen, damit stark ausgelastete Instanzen ihr tatsächliches Gewicht behalten.
- Nach Route, Version und Abhängigkeit aufschlüsseln. Globale 0,2 % können einen Endpunkt mit 30 % Fehlern verbergen.
- Mit Deployments korrelieren. Viele Fehlerspitzen beginnen mit einem Release oder einer Konfigurationsänderung.
- Gleichzeitig auf den Durchsatz achten. Eine sinkende Fehlerrate bei einbrechendem Traffic kann schlicht bedeuten, dass Clients aufgegeben haben.
Wie Obseria unterstützt
Obseria leitet Fehlerraten aus OpenTelemetry-Metriken und -Spans gemäß den Semantic Conventions ab, sodass 4xx und 5xx über alle Sprachen hinweg einheitlich klassifiziert werden. Das Fehler-Tracking gruppiert Exceptions zu Issues mit erstem und letztem Auftreten sowie betroffenen Releases, und Distributed Tracing zeigt, welcher nachgelagerte Aufruf einen fehlerhaften Request verursacht hat.
