Distributed tracing for gateway endpoints#20864
Conversation
Enhance the tracing utilities to create distributed spans for gateway calls when a traceparent header is present. This includes new functions to check for traceparent headers, retrieve token usage from spans, and create distributed spans linked to the gateway trace. Update the `maybe_traced_gateway_call` function to accept request headers and integrate tracing into the gateway API invocations. Additionally, add tests to validate the new tracing functionality and ensure proper behavior with and without traceparent headers. Signed-off-by: Tomu Hirata <tomu.hirata@gmail.com>
🛠 DevTools 🛠
Install mlflow from this PRFor Databricks, use the following command: |
…distributed-tracing Signed-off-by: Tomu Hirata <tomu.hirata@gmail.com>
There was a problem hiding this comment.
Pull request overview
Adds distributed tracing support for MLflow Gateway endpoints so incoming requests carrying W3C traceparent context can be linked back to an upstream “agent” trace while preserving a separate gateway trace.
Changes:
- Extend
maybe_traced_gateway_callto optionally create a distributed span using incoming request headers. - Plumb HTTP request headers through gateway API handlers into the tracing wrapper.
- Add a new span attribute key for linking the distributed span to the gateway trace, plus new unit/integration tests.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
mlflow/gateway/tracing_utils.py |
Adds distributed tracing helpers and creates a distributed span when traceparent is present. |
mlflow/server/gateway_api.py |
Captures request headers and passes them into maybe_traced_gateway_call across gateway endpoints. |
mlflow/tracing/constant.py |
Introduces SpanAttributeKey.LINKED_GATEWAY_TRACE_ID for cross-trace linkage. |
tests/gateway/test_tracing_utils.py |
Adds tests for traceparent detection and distributed tracing behavior (streaming + non-streaming). |
Comments suppressed due to low confidence (1)
mlflow/gateway/tracing_utils.py:25
- _has_traceparent only checks for exact keys "traceparent" and "Traceparent". HTTP header keys are case-insensitive and some frameworks may produce other casings (e.g., "TRACEPARENT"), which would silently disable distributed tracing. Consider normalizing keys (e.g., casefold/lower) before checking.
if not span:
return
|
Documentation preview for f7002d6 is available at: Changed Pages (2)
More info
|
Signed-off-by: Tomu Hirata <tomu.hirata@gmail.com>
…eval - Introduced a new dataclass `_ProviderSpanInfo` to encapsulate span name and attributes. - Updated `_get_provider_span_attributes` to `_get_provider_span_info`, returning a list of `_ProviderSpanInfo` instead of a dictionary. - Modified the `maybe_create_distributed_span` function to create individual spans for each provider span, improving traceability in distributed tracing scenarios. - Updated tests to reflect changes in the span information retrieval and ensure correct functionality. Signed-off-by: Tomu Hirata <tomu.hirata@gmail.com>
- Extract only W3C trace context headers (traceparent, tracestate) before passing to distributed tracing, avoiding propagation of sensitive headers - Make gateway_experiment_id test fixture resilient to duplicate experiment names by reusing existing experiments Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: Tomu Hirata <tomu.hirata@gmail.com>
|
|
||
| try: | ||
| with set_tracing_context_from_http_request_headers(request_headers): | ||
| with mlflow.start_span( |
There was a problem hiding this comment.
I'm actually not sure if there's any clearer way to copy spans with some modification to a distributed span.
Signed-off-by: Tomu Hirata <tomu.hirata@gmail.com>
| return { | ||
| "endpoint_id": endpoint_config.endpoint_id, | ||
| "endpoint_name": endpoint_config.endpoint_name, | ||
| } |
There was a problem hiding this comment.
Can we log the server URL as well?
There was a problem hiding this comment.
The actual server hostname?
B-Step62
left a comment
There was a problem hiding this comment.
Looks good once #20864 (comment) is addressed
There was a problem hiding this comment.
[Follow-up] I think it is useful to have a guide page about how to use Gateway with different llm/agent libraries, like OpenAI client, LangChain/Graph, LiteLLM, etc, including the distributed tracing setup.
- Add ASCII diagram documenting distributed trace shape - Log server URL (from Host header) in gateway span attributes - Rename provider → model in span naming to align with endpoint IA - Propagate span status to distributed model spans - Add timing assertions in tests 🤖 Generated with Claude Code Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: Tomu Hirata <tomu.hirata@gmail.com>
…distributed-tracing Signed-off-by: Tomu Hirata <tomu.hirata@gmail.com>
Signed-off-by: Tomu Hirata <tomu.hirata@gmail.com> Co-authored-by: Claude <noreply@anthropic.com>
Signed-off-by: Tomu Hirata <tomu.hirata@gmail.com> Co-authored-by: Claude <noreply@anthropic.com>
Related Issues/PRs
n/a
What changes are proposed in this pull request?
When the gateway endpoint is called by a traced agent, we want to show gateway execution in the trace as well. To achieve both gateway endpoint observability and the distributed tracing between client and gateway, we will duplicate the gateway spans but without input/output payloads to minimize the additional storage utilization.
How is this PR tested?
Does this PR require documentation update?
Does this PR require updating the MLflow Skills repository?
Release Notes
Is this a user-facing change?
What component(s), interfaces, languages, and integrations does this PR affect?
Components
area/tracking: Tracking Service, tracking client APIs, autologgingarea/models: MLmodel format, model serialization/deserialization, flavorsarea/model-registry: Model Registry service, APIs, and the fluent client calls for Model Registryarea/scoring: MLflow Model server, model deployment tools, Spark UDFsarea/evaluation: MLflow model evaluation features, evaluation metrics, and evaluation workflowsarea/gateway: MLflow AI Gateway client APIs, server, and third-party integrationsarea/prompts: MLflow prompt engineering features, prompt templates, and prompt managementarea/tracing: MLflow Tracing features, tracing APIs, and LLM tracing functionalityarea/projects: MLproject format, project running backendsarea/uiux: Front-end, user experience, plotting, JavaScript, JavaScript dev serverarea/build: Build and test infrastructure for MLflowarea/docs: MLflow documentation pagesHow should the PR be classified in the release notes? Choose one:
rn/none- No description will be included. The PR will be mentioned only by the PR number in the "Small Bugfixes and Documentation Updates" sectionrn/breaking-change- The PR will be mentioned in the "Breaking Changes" sectionrn/feature- A new user-facing feature worth mentioning in the release notesrn/bug-fix- A user-facing bug fix worth mentioning in the release notesrn/documentation- A user-facing documentation change worth mentioning in the release notesShould this PR be included in the next patch release?
Yesshould be selected for bug fixes, documentation updates, and other small changes.Noshould be selected for new features and larger changes. If you're unsure about the release classification of this PR, leave this unchecked to let the maintainers decide.What is a minor/patch release?
Bug fixes, doc updates and new features usually go into minor releases.
Bug fixes and doc updates usually go into patch releases.