czegi90 opened a new issue, #14051: URL: https://github.com/apache/apisix/issues/14051
### Description **Description** When the `opentelemetry` plugin is enabled, the `opa` plugin's HTTP request to OPA does not carry W3C trace context. The request headers are hard-coded to `Content-Type: application/json` in [`apisix/plugins/opa.lua`](https://github.com/apache/apisix/blob/master/apisix/plugins/opa.lua#L76-L98) (`_M.access`). OPA supports continuing an incoming trace from the `traceparent` HTTP header, but it never receives one. As a result, OPA's spans start a separate trace instead of appearing as children of the APISIX request span. The incoming `traceparent` is currently only visible to OPA inside the JSON body (`input.request.headers`). OPA does not use that for tracing. See open-policy-agent/opa#6905. **Proposed change** Forward the trace context header on the request to OPA, either always or behind a schema option (e.g. `propagate_trace_context: true`): ```lua headers = { ["Content-Type"] = "application/json", ["traceparent"] = core.request.header(ctx, "traceparent"), }, ``` I tested this by overriding the built-in plugin via `extra_lua_path` on 3.17.0 with OPA 1.11.0 and distributed tracing enabled. The OPA decision log `trace_id` matches the incoming trace, and in Tempo the OPA span appears as a child of the APISIX span in the same trace, alongside the upstream service span. **Environment** - APISIX 3.17.0 - OPA 1.11.0 (distributed tracing via OTLP gRPC) - OpenTelemetry Collector, Grafana Tempo -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
