# OpenTelemetry

> Source: https://aiwiki.ai/wiki/opentelemetry
> Updated: 2026-09-27
> Fact-checked: 2026-09-27
> Categories: AI Infrastructure, Developer Tools, MLOps
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) - attribute to "AI Wiki (aiwiki.ai)"
> Cite as: AI Wiki. "OpenTelemetry." aiwiki.ai, 27 Sept 2026. https://aiwiki.ai/wiki/opentelemetry
> From AI Wiki (https://aiwiki.ai), the free encyclopedia of artificial intelligence. Reuse freely with attribution.

OpenTelemetry (OTel) is an open-source framework for generating, collecting, processing, and exporting telemetry from software systems. It supplies instrumentation APIs, language SDKs, a telemetry protocol, conventions for naming data, and the OpenTelemetry Collector. It leaves long-term storage, dashboards, and analysis to separate observability backends.[1]

In [MLOps](https://aiwiki.ai/wiki/mlops), OpenTelemetry can connect the operation of a model-serving application to the databases, network requests, and other services it uses. For applications built around [large language models](https://aiwiki.ai/wiki/large_language_model), its generative AI conventions describe model calls and related operations. Those conventions have their own maturity and versioning considerations; support for OpenTelemetry does not mean that every integration emits the same AI-specific fields.[2][3]

## Origins and scope

OpenTelemetry was formed by merging OpenTracing and OpenCensus in May 2019. The Cloud Native Computing Foundation announced its promotion to an incubating project in August 2021. The merger brought work on instrumentation APIs and telemetry collection into one project.[4]

Distributed tracing predates OpenTelemetry. Google's 2010 Dapper technical report describes an earlier production tracing system, including its use of sampling and instrumentation in common libraries to limit overhead. Dapper is useful background for understanding the engineering problems that tracing addresses, but its measurements are not OpenTelemetry benchmarks.[5]

OpenTelemetry's scope is the telemetry pipeline. A Collector is not a replacement for a searchable trace database, and installing an SDK does not create an operational dashboard. The framework can supply data to different backends, but queries, retention settings, and product-specific analysis features remain responsibilities of those backends.[1]

## Traces, metrics, and logs

These signals answer different questions about a system:

| Signal | What it represents | Illustrative question |
| --- | --- | --- |
| Trace | Related spans describing work performed during an operation | Which downstream call contributed to a slow request? |
| Metric | Numeric measurements aggregated into time series | How has request duration changed across a deployment? |
| Log | A record of an event, with a body and optional contextual fields | What error did a component report during a particular request? |

The examples describe uses of the data, not guarantees that a particular instrumentation package records it.[6][7][8]

A span represents an operation with a start and an end. It has a trace identifier, its own span identifier, attributes, and other fields. Parent-child relationships describe nested operations. Span events record timestamped occurrences within an operation, while span links can express relationships that do not fit a simple parent-child hierarchy, including work associated with another trace.[6]

Metrics summarize measurements rather than retaining a full request history. A counter records increments; an up-down counter also supports decreases; a gauge records a current value; and a histogram records a distribution of measurements. SDK views can change aggregation or select which measurement attributes to retain.[7]

OpenTelemetry log records can carry timestamps, severity, a body, attributes, and trace and span identifiers. This makes it possible to correlate a log with traced work when the integration supplies the relevant context. Existing logging libraries can be connected to the OpenTelemetry logging pipeline through bridges or appenders.[8]

Maturity must be checked separately for each signal, SDK, and Collector component. The status of the specification is not necessarily the status of its implementation in a particular programming language. The project also develops profiling support, with availability differing by component.[2]

## Context, resources, and instrumentation scope

Context propagation connects work across service boundaries. An outgoing request can carry the current trace context; the receiving service extracts it and creates a span associated with that request. OpenTelemetry's default propagation uses W3C Trace Context headers. Without working propagation, instrumentation in two services may produce separate traces for what was logically one request.[9]

Three kinds of metadata have different purposes:

| Metadata | Purpose | Example |
| --- | --- | --- |
| Resource | Identifies the entity producing telemetry | A logical service name or Kubernetes namespace |
| Instrumentation scope | Identifies the software unit producing the instrumentation | An instrumentation library's name and version |
| Span or log attributes | Describe the recorded operation or event | An operation name or error classification |

The resource field `service.name` is especially useful for distinguishing services. Instrumentation scope makes it possible to distinguish records emitted by different libraries even when they run in the same service.[10][11]

Baggage is another mechanism: key-value data propagated with context. Baggage values do not automatically become attributes on every span, metric, or log. Instrumentation must explicitly copy them or use a component that does so. Baggage also lacks built-in integrity checks and may travel to downstream services, so it should not be treated as a trusted identity or authorization mechanism.[12]

## Instrumentation and SDKs

The API exposes operations such as creating spans or recording measurements. An SDK implements data processing and export. This separation lets a library expose instrumentation without choosing the application's telemetry destination. The application configures the SDK and exporters.[13]

OpenTelemetry supports both code-based and zero-code instrumentation. Code-based instrumentation adds application-specific spans or measurements where developers understand the operation. Zero-code instrumentation can obtain telemetry from supported frameworks, libraries, or runtime behavior without changing application source. They can be used together.[14]

For example, automatic HTTP instrumentation can describe a request to a model endpoint. An application-defined span can describe the broader task that required that request. These are different observations: the transport call does not by itself identify every retrieval step, tool decision, or business outcome. The useful boundary for manual instrumentation depends on the application's questions.[14]

Compatibility is more specific than a language name. A deployment needs compatible API and SDK packages, instrumentation for the libraries actually in use, and an exporter understood by its destination. The project publishes a component status table and links to a specification compliance matrix. An implementation should be checked there rather than assuming that all languages support every signal equally.[2]

## Collector pipelines and deployment

The Collector accepts telemetry and forwards it through configured pipelines. Its components have distinct roles:[15]

| Component | Role |
| --- | --- |
| Receiver | Obtains telemetry through an incoming protocol or a collection mechanism |
| Processor | Transforms or filters telemetry within a pipeline |
| Exporter | Sends telemetry to another Collector or a backend |
| Connector | Connects pipelines, acting as an exporter for one and a receiver for another |
| Extension | Supplies capabilities such as health checks or authentication outside the signal-processing pipelines |

Declaring a component in a configuration file does not enable it. Pipeline components must also appear in the appropriate `service.pipelines` configuration, and extensions must be enabled in the service configuration. Component availability depends on the Collector distribution.[15]

An agent-pattern Collector runs beside an application or on its host. In [Kubernetes](https://aiwiki.ai/wiki/kubernetes), this can be a sidecar or a DaemonSet. A gateway-pattern deployment instead gives applications or other Collectors a shared endpoint backed by one or more Collector instances.[16][17]

Gateways centralize policies and credentials, but introduce another service to operate. Some processing is stateful. Tail sampling, for example, needs related spans to reach the same processing instance; distributing individual spans randomly can undermine the sampling decision. The documented gateway pattern includes trace-aware routing for this reason.[17]

The OpenTelemetry Protocol (OTLP) carries telemetry between compatible senders and receivers. OTLP/gRPC uses port 4317 by default. OTLP/HTTP uses port 4318 by default and defines paths including `/v1/traces`, `/v1/metrics`, and `/v1/logs`. The HTTP transport supports Protobuf data encoded in binary or JSON form. Endpoints and transports still need to agree: an open TCP port alone does not demonstrate a working telemetry pipeline.[18]

## Generative AI telemetry

The GenAI conventions cover model operations, agent operations, metrics, events, and other AI-related activity. In the documentation reviewed on September 27, 2026, the main semantic-conventions site identifies version 1.44.0 and directs GenAI readers to the separate `semantic-conventions-genai` repository. Its overview, model-span, agent-span, and metric documents are marked Development. The move should not be mistaken for the removal of GenAI telemetry support.[3][19]

Selected fields and operations illustrate what the conventions describe:

| Convention | Meaning |
| --- | --- |
| `gen_ai.operation.name` | The operation being performed |
| `gen_ai.request.model` | The model requested by the caller |
| `gen_ai.response.model` | The model identified in the response |
| `gen_ai.client.operation.duration` | A histogram of client-observed operation duration, in seconds |
| Agent invocation spans | The execution of an agent operation, distinct from an individual model call |

These are a selected reference, not a complete schema or a claim that every integration emits them. Field requirement levels and availability must be checked against the convention and instrumentation versions in use.[20][21][22]

Client-observed GenAI spans describe logical operations. The model-span convention recommends covering the operation until the response has been received or the operation terminates, including automatic retries. Consequently, client duration is not interchangeable with time spent computing inside a model server.[20]

The metric conventions distinguish client streaming measurements, such as time to the first chunk, from model-server token measurements. A streamed chunk is not necessarily one token. Dashboards should preserve the documented units and measurement boundaries rather than relabeling one measurement as another.[21]

For [AI agents](https://aiwiki.ai/wiki/ai_agents) and [retrieval-augmented generation](https://aiwiki.ai/wiki/retrieval_augmented_generation), an operational trace can help separate model calls from surrounding work. It does not itself establish factual correctness or task success. The GenAI conventions include an evaluation-result event for recording results supplied by an evaluator; defining a format for such results does not supply the evaluation method.[22][23]

## Sampling, cardinality, and delivery limits

Recording every trace can be expensive. Head sampling decides early, before the full outcome is known. Tail sampling decides after considering all or most spans and can select traces with particular errors or latency. It requires buffering and stateful processing. A tail sampler cannot recover spans already discarded by an earlier head-sampling decision.[24]

Sampling changes the interpretation of the retained dataset. A policy that deliberately keeps error traces should not be mistaken for an unweighted random sample when estimating overall error frequency. Its purpose is often investigation of selected cases. The sampling policy belongs alongside the dashboard definition and should be considered when comparing deployments.[24]

Metric cardinality is the number of distinct attribute combinations associated with a metric. A request identifier, arbitrary user input, or other unbounded value can multiply the number of series. SDK views can restrict measurement attributes. Cardinality controls and aggregation mean that a metric series is not a substitute for storing every individual request.[7]

Export is not an absolute delivery guarantee. Collector sending queues and retries can handle temporary destination failures, but queues can fill and retry limits can expire. Persistent queues can survive process restarts when configured with suitable storage; they still depend on disk capacity and reliability. Collector health should therefore include export failures and queue occupancy, not only whether the process is running.[25]

OTLP also permits an important trade-off during interrupted delivery: if a sender cannot determine whether data was acknowledged, retrying can create duplicate records. Consumers should not assume exactly-once delivery simply because both ends use OTLP.[18]

## Privacy and security

Telemetry can contain credentials, personal information, and confidential application data. OpenTelemetry cannot decide which fields are sensitive in a particular deployment. Its security guidance recommends collecting only necessary data and reviewing the output of instrumentation libraries. Collector processors can remove or transform fields, but preventing unnecessary collection avoids moving that data through the pipeline in the first place.[26]

The GenAI model-span guidance treats instructions, user messages, and model outputs as potentially sensitive and large. It recommends not capturing this content by default, with an explicit opt-in for collection. The same guidance describes keeping content in external storage and recording references when separate access controls or storage requirements are needed.[20]

Baggage deserves separate review because propagation can send it to services beyond the original application. Outgoing context should be controlled at trust boundaries, and externally supplied context should not be accepted as authoritative merely because its headers are well formed.[9][12]

Collector security includes authenticated, encrypted connections, restricted listening addresses, least-privilege execution, and protection of configuration secrets. Binding a receiver to every network interface exposes it more widely than binding to a specific interface. A deployment should enable only the Collector components it needs and review their individual security requirements.[27]

## Adoption and verification

A useful initial deployment follows one application operation through its dependencies, with an explicit service identity and a backend that can display the resulting trace. Manual application spans can then fill gaps left by automatic instrumentation. Resources and instrumentation scopes help separate deployment identity from the library that emitted a record.[9][10][11][14]

Verification should cover the full route from application to backend. A receiver can accept data while a later processor drops it or an exporter fails. The Collector's own metrics, queues, and failure reporting help distinguish application failures from telemetry-pipeline failures.[25]

For AI-specific instrumentation, pinning package versions is only part of this work. The emitted semantic-convention revision, content-capture policy, and backend interpretation also need to be understood. Development-stage conventions can change. A dashboard depending on a renamed attribute may become incomplete even when the application still sends valid OTLP.[3][19]

## References

1. OpenTelemetry. [What is OpenTelemetry?](https://opentelemetry.io/docs/what-is-opentelemetry/).
2. OpenTelemetry. [Status](https://opentelemetry.io/status/). Component maturity table, consulted September 27, 2026.
3. OpenTelemetry. [Semantic conventions for generative AI systems](https://github.com/open-telemetry/semantic-conventions-genai/blob/e57c543b4889619eb2a05702471937db5119165d/docs/gen-ai/README.md). Revision e57c543, September 24, 2026.
4. Cloud Native Computing Foundation. [OpenTelemetry becomes a CNCF incubating project](https://www.cncf.io/blog/2021/08/26/opentelemetry-becomes-a-cncf-incubating-project/). August 26, 2021.
5. Sigelman, Benjamin H., et al. [Dapper, a Large-Scale Distributed Systems Tracing Infrastructure](https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/). Google technical report, 2010.
6. OpenTelemetry. [Traces](https://opentelemetry.io/docs/concepts/signals/traces/).
7. OpenTelemetry. [Metrics](https://opentelemetry.io/docs/concepts/signals/metrics/).
8. OpenTelemetry. [Logs](https://opentelemetry.io/docs/concepts/signals/logs/).
9. OpenTelemetry. [Context propagation](https://opentelemetry.io/docs/concepts/context-propagation/).
10. OpenTelemetry. [Resources](https://opentelemetry.io/docs/concepts/resources/).
11. OpenTelemetry. [Instrumentation scope](https://opentelemetry.io/docs/concepts/instrumentation-scope/).
12. OpenTelemetry. [Baggage](https://opentelemetry.io/docs/concepts/signals/baggage/).
13. OpenTelemetry. [Components](https://opentelemetry.io/docs/concepts/components/).
14. OpenTelemetry. [Instrumentation](https://opentelemetry.io/docs/concepts/instrumentation/).
15. OpenTelemetry. [Collector configuration](https://opentelemetry.io/docs/collector/configuration/).
16. OpenTelemetry. [Agent deployment pattern](https://opentelemetry.io/docs/collector/deploy/agent/).
17. OpenTelemetry. [Gateway deployment pattern](https://opentelemetry.io/docs/collector/deploy/gateway/).
18. OpenTelemetry. [OTLP specification 1.11.0](https://opentelemetry.io/docs/specs/otlp/).
19. OpenTelemetry. [OpenTelemetry semantic conventions 1.44.0](https://opentelemetry.io/docs/specs/semconv/).
20. OpenTelemetry. [Semantic conventions for generative client AI spans](https://github.com/open-telemetry/semantic-conventions-genai/blob/e57c543b4889619eb2a05702471937db5119165d/docs/gen-ai/gen-ai-spans.md). Revision e57c543, September 24, 2026.
21. OpenTelemetry. [Semantic conventions for generative AI metrics](https://github.com/open-telemetry/semantic-conventions-genai/blob/e57c543b4889619eb2a05702471937db5119165d/docs/gen-ai/gen-ai-metrics.md). Revision e57c543, September 24, 2026.
22. OpenTelemetry. [Semantic conventions for GenAI agent and framework spans](https://github.com/open-telemetry/semantic-conventions-genai/blob/e57c543b4889619eb2a05702471937db5119165d/docs/gen-ai/gen-ai-agent-spans.md). Revision e57c543, September 24, 2026.
23. OpenTelemetry. [Semantic conventions for Generative AI events](https://github.com/open-telemetry/semantic-conventions-genai/blob/e57c543b4889619eb2a05702471937db5119165d/docs/gen-ai/gen-ai-events.md). Revision e57c543, September 24, 2026.
24. OpenTelemetry. [Sampling](https://opentelemetry.io/docs/concepts/sampling/).
25. OpenTelemetry. [Collector resiliency](https://opentelemetry.io/docs/collector/resiliency/).
26. OpenTelemetry. [Handling sensitive data](https://opentelemetry.io/docs/security/handling-sensitive-data/).
27. OpenTelemetry. [Collector configuration best practices](https://opentelemetry.io/docs/security/config-best-practices/).