What is OpenTelemetry?

OpenTelemetry is an open-source observability framework for generating, collecting, processing, and exporting telemetry. It provides common APIs, SDKs, semantic conventions, protocols, instrumentation, and a Collector that work across languages and backends.

OpenTelemetry is not an observability database or dashboard. It standardizes the path from software to a telemetry backend while leaving storage, querying, visualization, alerting, and incident response to other systems.

Understand the main signals

The official OpenTelemetry overview covers several signals:

• Traces connect operations across a request or task path.
• Metrics aggregate measured values over time.
• Logs record timestamped events and detailed context.
• Baggage propagates selected contextual values across boundaries.
• Profiles describe where applications spend resources.

These signals answer different questions. Metrics can show that latency increased. Traces identify which path and dependency contributed. Logs preserve a detailed failure. Profiles help explain CPU cost inside a process.

ML systems add durable run context and evaluation. OpenTelemetry can transport technical evidence, but it does not know which dataset, model, prompt, artifact, or acceptance criterion defines a successful outcome.

Separate API, SDK, and instrumentation

The API is the interface application and library authors use to create telemetry. The SDK implements collection, sampling, processing, and export behavior. Instrumentation libraries add telemetry for supported frameworks and dependencies.

Libraries should normally depend on the API and avoid choosing a backend for the application. Applications or platform configuration select the SDK, exporters, and operational policy.

Automatic or zero-code instrumentation establishes broad coverage quickly. Manual instrumentation adds domain meaning around work such as queue admission, artifact loading, evaluation, retrieval, or tool execution. Use both while avoiding duplicate spans around the same call.

Use semantic conventions for consistency

Semantic conventions define common names and meanings for attributes, resources, operations, and metrics. They make telemetry from different libraries and languages queryable through one vocabulary.

Consistency is not automatic. Pin compatible instrumentation versions, review convention changes, and standardize service, environment, cluster, namespace, and version identity.

Keep high-cardinality or sensitive fields controlled. Raw URLs, SQL, file paths, prompts, user identifiers, and arbitrary Kubernetes labels can increase cost or expose private content. Use normalized routes and bounded dimensions for metrics, with precise identifiers in traces, logs, or Polyaxon metadata.

Propagate context across boundaries

Distributed traces depend on context propagation through HTTP, RPC, messaging, workflow, and queue boundaries. Standard propagators carry trace context between compatible services.

Asynchronous ML work needs deliberate propagation. A submission can move from an API to a queue, controller, Kubernetes Job, storage service, and evaluation step over minutes or hours. Preserve the relationship without treating the entire lifecycle as one indefinitely open span.

Use span links for related asynchronous or batched work and connect traces to a durable run identifier. Avoid putting business payloads or secrets into baggage because baggage can travel through every downstream service.

Use OTLP and the Collector as boundaries

OTLP is OpenTelemetry's protocol for telemetry transport. Applications can send OTLP to an OpenTelemetry Collector, which receives, processes, and exports signals to one or more backends.

The Collector creates a useful policy boundary for batching, memory protection, filtering, redaction, enrichment, sampling, routing, retries, and backend credentials. It can run near workloads, as a shared gateway, or in both patterns.

The OpenTelemetry Collector for ML platforms guide covers these deployment and reliability decisions in detail.

Plan sampling and reliability

Telemetry volume can grow quickly. Sampling traces controls cost, but it changes which analysis remains valid. Head sampling decides early; tail sampling can retain errors, slow traces, or selected workload classes after more context is available.

Metrics require label and aggregation design rather than arbitrary sampling. Logs need severity, retention, and filtering policy. Every signal requires backpressure and failure handling.

Monitor the telemetry path itself: accepted and dropped records, queue size, export errors, target health, configuration changes, and backend latency. Missing telemetry must not look like a healthy zero.

Fit OpenTelemetry into ML observability

Use OpenTelemetry for technical execution context across APIs, services, models, retrieval, tools, and infrastructure. Use Polyaxon to preserve the ML lifecycle: projects, operations, inputs, parameters, logs, metrics, lineage, and artifacts.

Polyaxon platform observability covers the services managing workloads. Our distributed tracing guide explains trace design, while AI observability adds evaluation, safety, quality, and feedback for generative systems.

OpenTelemetry gives teams a common language and transport for observability signals. Its value comes from the questions, data governance, reliability, and ML context designed around that standard.