Nach dem Link Istio/Distributed tracing kann ich die Ablaufverfolgung mit Zipkin arbeiten.Ist es möglich, x-request-id zurück zu senden, wenn istio mit zipkin für verteilte Tracing verwendet wird?
Momentan, damit der Client/Anrufer über die x-request-id informiert wird (falls keine ID gesendet wird, erstellt zipkin eine), muss er sie als Teil der Anfrage senden ( ).
Dies gibt ihm die Möglichkeit, die Anfrage zu verfolgen. Alles funktioniert gut.
Ich denke jedoch, es ist vielleicht keine gute Idee für den Client, die X-Request-ID zu senden, um Probleme mit Zwängen/Duplikation zu vermeiden.
Es wäre gut, wenn es möglich ist, dass man auf der istio-Ebene in der Lage sein sollte, die Antwortheader zu modifizieren und die x-request-id zurück zu senden.
Ich finde solche Fähigkeiten für istio derzeit nicht. Wenn es einen Weg gibt, dies zu erreichen, lass es mich wissen.
Ich schaue mehr aus einer Perspektive einer Person, die den von istio offengelegten Dienst aufruft. Es wäre schön, wenn der Client oder der Aufrufer Ablaufverfolgungsfunktionen verwenden könnte, um den Anfragefluss zu überprüfen. –
oh ich sehe, also Sie bedeuten, die Traceid als Folge der Ingress-Anfrage extern ausgesetzt. Ich denke, das könnte eine Option sein (wahrscheinlich nicht die Standardeinstellung, da für die meisten Leute diese Information intern bleiben sollte). Ich habe nicht versucht, aber vielleicht könnten Sie die Header zuerst in diesem externen Dienst generieren und es würde nur nachgelagert verwendet werden? (Erreichen Sie Ihr Ziel, indem Sie es im Voraus festlegen, anstatt es an Ihr externes System zurückzugeben) –