You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Enhancement] Add OpenTelemetry instrumentation for request tracing and latency metrics #719
Add optional OpenTelemetry instrumentation to the Python SDK that automatically creates spans and records metrics for all Deepgram API calls — STT (REST + WebSocket), TTS (REST + WebSocket), Voice Agent sessions, and Audio Intelligence requests.
Problem it solves
Enterprise teams deploying Deepgram in production need distributed tracing and metrics to monitor performance, debug latency issues, and track usage across their application stack. Currently, developers must manually wrap every SDK call with OpenTelemetry instrumentation, which is error-prone, inconsistent, and misses internal SDK timing (WebSocket connection setup, audio chunking, response parsing). A built-in instrumentation layer provides consistent, zero-effort observability.
Proposed API
# Opt-in via instrumentor (standard OTEL pattern)fromdeepgram.instrumentation.opentelemetryimportDeepgramInstrumentorDeepgramInstrumentor().instrument()
# All subsequent SDK calls automatically create spans and record metricsclient=DeepgramClient(api_key="...")
response=client.listen.rest.v("1").transcribe_file(payload, options)
# → Span: "deepgram.stt.rest" with attributes: model, language, duration_ms, audio_duration_s# → Metrics: deepgram.stt.latency (histogram), deepgram.stt.requests (counter)# WebSocket streaming sessions create parent span + child spans per resultasyncwithclient.listen.websocket.v("1").transcribe_stream(options) asws:
# → Span: "deepgram.stt.websocket" (parent)# → Metric: deepgram.stt.ttfb_ms (time to first result)
...
OpenTelemetry is a reasonable future SDK capability, but it should not be implemented here as a Python-only manual patch. It requires a coordinated Fern/API-spec design across generated HTTP and WebSocket paths, with shared span names, attributes, metric definitions, opt-in behavior, and strict privacy/redaction rules.
This is complementary to the separate Sentry proposal in #756: Sentry should capture actionable SDK exceptions, while OpenTelemetry provides request/session traces and metrics. A future design must avoid duplicate wrappers around the same transport paths while allowing an error to be represented in both systems as appropriate.
No implementation is planned in this SDK until upstream cross-SDK support and concrete customer demand exist.
Activity
GregHolmes commentedon Sep 3, 2026
OpenTelemetry is a reasonable future SDK capability, but it should not be implemented here as a Python-only manual patch. It requires a coordinated Fern/API-spec design across generated HTTP and WebSocket paths, with shared span names, attributes, metric definitions, opt-in behavior, and strict privacy/redaction rules.
This is complementary to the separate Sentry proposal in #756: Sentry should capture actionable SDK exceptions, while OpenTelemetry provides request/session traces and metrics. A future design must avoid duplicate wrappers around the same transport paths while allowing an error to be represented in both systems as appropriate.
No implementation is planned in this SDK until upstream cross-SDK support and concrete customer demand exist.