Add opt-in telemetry auto-configuration#553
Merged
Merged
Conversation
jsurloppe
reviewed
May 25, 2026
aa7ab84 to
bf80c79
Compare
ab1403d to
a55a112
Compare
a55a112 to
d7be63b
Compare
Nelson-PROIA
approved these changes
May 26, 2026
jsurloppe
approved these changes
May 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds opt-in OpenTelemetry telemetry auto-configuration for the Python SDK.
The SDK already emits spans via the OTel API. This PR adds a
mistralai[telemetry]optional extra with the OTel SDK/exporter dependencies, plus helper/env-based configuration so users do not need to manually wire an OTLP exporter, endpoint, auth headers, span processor, and tracer provider just to get Mistral SDK traces working.Telemetry remains off by default.
Usage
Explicit opt-in with an SDK-owned telemetry provider:
Use the global OpenTelemetry provider:
Attach an already constructed provider:
Or configure by environment:
For SDK-owned dedicated telemetry, the exporter endpoint can be overridden with:
Longer term, the target generated API is:
That constructor parameter is not included here because the constructor is Speakeasy-generated; this PR keeps the implementation in hand-owned code and leaves the path open for codegen support later.
Behavior
mistralai[telemetry]with:opentelemetry-sdkopentelemetry-exporter-otlp-proto-httpMISTRAL_SDK_TELEMETRY=dedicatedorconfigure_telemetry(client).MISTRAL_SDK_TELEMETRY=globalorconfigure_telemetry(client, provider="global").configure_telemetry(client, provider=<TracerProvider>).set_tracer_provider(client, provider)as a compatibility wrapper overconfigure_telemetry(client, provider=provider).MISTRAL_SDK_TELEMETRY=falseas an env opt-out.telemetry=Falsehandling for future SDK config/env resolution, but does not expose that on the public helper API.dedicatedauto-config skips if the application already has a real global OTel provider and logs a debug message.configure_telemetry(client)can still attach an SDK-owned per-client provider even when a global provider exists.dedicatedtelemetry sends toMISTRAL_OTLP_TRACES_ENDPOINTwhen set, otherwise to the default Mistral telemetry endpoint.OTEL_EXPORTER_OTLP_ENDPOINTandOTEL_EXPORTER_OTLP_TRACES_ENDPOINTremain scoped to application/global OTel configuration; they do not opt into or steer the SDK-owned dedicated provider.mistralai[telemetry]if optional telemetry dependencies are missing.