From 3de6809b750e8a7f73735b96af7bc712346380c1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20Tailland?= Date: Wed, 26 Aug 2026 08:12:07 +0200 Subject: [PATCH] Propagate trace context across gateway hops Every hop was starting its own trace: a single end-to-end transaction through LibreChat, Kong and the backends appeared in Tempo as a dozen unrelated traces, one per service. Verified on twelve consecutive traces, each containing exactly one service. Kong receives a W3C traceparent -- it is visible in the http-log records -- but without a propagation block it neither continues the caller's trace nor passes one downstream, so it minted a fresh trace id per request and the backends did the same. extract lists w3c first with b3 and jaeger as fallbacks, since the callers here are a mix of OTel SDKs; inject is w3c only, which is what the Python and Java agents downstream expect. Co-Authored-By: Claude Opus 5 --- .../global-policies-plugins.yaml | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/dataplane-globalpolicy-template/global-policies-plugins.yaml b/dataplane-globalpolicy-template/global-policies-plugins.yaml index f6f516e..649f1e8 100644 --- a/dataplane-globalpolicy-template/global-policies-plugins.yaml +++ b/dataplane-globalpolicy-template/global-policies-plugins.yaml @@ -103,3 +103,17 @@ config: service.name: ${NAME} sampling_rate: 1 http_response_header_for_traceid: X-Trace-Id + # Without this block every hop starts its own trace: a single end-to-end + # transaction shows up in Tempo as a dozen unrelated traces, one per service. + # `extract` is what makes the gateway continue the caller's trace instead of + # opening a new one, and `inject` is what carries it to the upstream so the + # backend can continue it in turn. + propagation: + extract: + - w3c + - b3 + - jaeger + inject: + - w3c + default_format: w3c + clear: []