Use Telemetry with OpenTelemetry
Telemetry and OpenTelemetry solve related but different parts of an observability system. OpenTelemetry provides vendor-neutral APIs, SDKs, semantic conventions, and a Collector for traces, metrics, and logs. Telemetry provides a managed path for purpose-built JSON application outcomes, typed tables, DataFusion SQL, dashboards, and alerts.
Telemetry does not currently provide an OTLP ingestion endpoint and should not be described as an OpenTelemetry Collector backend. Use the OpenTelemetry Collector with an OTLP-compatible observability backend for traces, metrics, and logs. Emit a separate Telemetry event when the application reaches a business or operational outcome that benefits from SQL.
Give each signal one job
| Signal | Best starting question |
|---|---|
| Metric | Is aggregate service or infrastructure health changing? |
| Trace | Where did time go across this distributed request? |
| Diagnostic log | What local detail explains this code path? |
| Telemetry event | What completed outcome affected a user, account, workflow, or cost center? |
A checkout trace can show database and provider spans. A checkout_completed event can hold the terminal status, safe account ID, plan, amount category, retry count, release, and latency required for revenue-impact SQL. Neither needs to duplicate the other.
Correlate with approved identifiers
Read the active OpenTelemetry span context at the application outcome boundary:
import { trace } from "@opentelemetry/api";
const spanContext = trace.getActiveSpan()?.spanContext();
await telemetry.log("checkout_completed", {
checkout_id: checkoutId,
status: "success",
latency_ms: 684,
trace_id: spanContext?.traceId,
span_id: spanContext?.spanId,
checkout_version: "v2",
release: process.env.APP_RELEASE,
});
Treat trace and span IDs as lookup fields, not chart dimensions. Confirm that the tracing system and Telemetry have compatible access and retention boundaries before making cross-system correlation part of an incident workflow.
Do not copy span events, resource attributes, baggage, prompts, request bodies, or stack traces wholesale. Use an allowlist. OpenTelemetry baggage in particular can propagate across service boundaries and should not be assumed safe for analytics.
Operate the pipelines independently
The OpenTelemetry Collector can batch, retry, filter, and export its supported signals. The Telemetry SDK or Log API has its own delivery behavior. Monitor both pipelines and avoid coupling their failure modes:
- a failed outcome-event delivery should not end an otherwise successful request
- a failed trace export should not trigger recursive event logging
- critical audit or billing outcomes should use an explicitly durable application path
- sampling decisions should be signal-specific
- deployment verification should confirm both correlation and independent availability
The OpenTelemetry logging specification explains correlation across trace and log context. Use the OpenTelemetry integration guide, Logs, Metrics, Traces, and Events, and Canonical Wide Events to choose the smallest reliable signal set.