Eine Anfrage-ID wird am Netzwerkrand – vom Load Balancer, Gateway oder dem ersten Dienst – generiert und in einem Antwortheader wie X-Request-Id zurückgegeben. Jede während der Bearbeitung dieser Anfrage geschriebene Protokollzeile enthält diese ID. Wenn die Anfrage an andere Dienste weitergeleitet wird, bleibt die ID erhalten, sodass der gesamte Pfad später rekonstruiert werden kann.
Kunden sollten die ID jedes gemeldeten Fehlers protokollieren und in Fehlerberichte aufnehmen; der Support kann so die entsprechenden serverseitigen Protokolle innerhalb von Sekunden finden. Standards für verteiltes Tracing wie der W3C Trace Context (der Traceparent-Header) formalisieren dasselbe Prinzip und fügen über- und untergeordnete Spans für die Zeitmessung hinzu.
Ein Zeitstempel und ein Endpunkt reichen nicht aus, um eine Anfrage in den Protokollen zu finden. Auf einem stark ausgelasteten System erfolgen Tausende identischer Aufrufe pro Sekunde. Ohne die ID ist "it failed around 10:42" eine Suche, keine Treffersuche.
Das Live-Backend setzt bei jeder Antwort einen X-Request-Id-Header und fügt die gleiche requestId in die JSON-Bodies ein – auch in die 500-Fehler, wo sie das einzige Detail ist, das sie preisgibt.
Diese Seite auf Englisch lesen
Alle Glossarbegriffe · Testtechniken · Alle 39 Mock-REST-APIs
Zuletzt aktualisiert