What is OpenTelemetry?

OpenTelemetry (OTel) is an open source observability framework and toolkit for generating, collecting and exporting telemetry such as traces, metrics and logs. According to the project, it is vendor- and tool-agnostic, so the same data can go to a broad variety of backends. It is not a backend itself.

It is a Cloud Native Computing Foundation project, accepted on 7 May 2019 and graduated on 11 May 2026.

For what to do with the data once you have it, see LLM observability and agent observability.

What OpenTelemetry includes

The official overview lists these parts:

Part	What it does
APIs	Define how to generate telemetry data
SDKs	Language implementations that process and export the data
Instrumentation	Automatic components that generate telemetry without code changes
Collector	A proxy that receives, processes and exports telemetry
OTLP	A standard protocol for the shape of telemetry data
Semantic conventions	A standard naming scheme for common telemetry

The Collector docs describe it as a vendor-agnostic way to receive, process and export telemetry. Its components are receivers, processors, exporters, connectors and extensions, and it can handle retries, batching, encryption and sensitive data filtering.

OTLP runs over gRPC and HTTP. The default port is 4317 for gRPC and 4318 for HTTP, and the spec marks it stable for traces, metrics and logs.

Signals

A signal is a type of telemetry. The docs define them like this:

Signal	Definition from the docs
Traces	“The path of a request through your application”
Metrics	“A measurement captured at runtime”
Logs	“A recording of an event”
Baggage	“Contextual information that is passed between signals”
Profiles	“A recording of resource usage at the code level”, still in development

The observability primer defines a span as “a single unit of work or operation” with a name, timing data and attributes. A trace records the path of a single request, and its first span, the root, covers the whole request.

How you instrument an app

The instrumentation docs describe two routes, and you can use both together:

• Zero-code: no changes to the application. It supplies telemetry from libraries and the runtime, which suits getting started or code you cannot modify.
• Code-based: you add instrumentation with the OpenTelemetry APIs and SDKs, which gives deeper insight from the application itself.

Language support

The language pages list C++, C#/.NET, Erlang/Elixir, Go, Java, JavaScript, Kotlin, PHP, Python, Ruby, Rust and Swift. Each has a status per signal: Stable, Release candidate, Beta or Development. As of November 2026, Python had stable traces and metrics with logs in Development, and Java had all three stable. Check the table for your language before you rely on a signal.

Semantic conventions

Semantic conventions set common names for kinds of operations and data, so telemetry looks the same across codebases, libraries and platforms. They exist for traces, metrics, logs, profiles and resources. The GenAI conventions are covered in OpenTelemetry for LLM apps.

OpenTelemetry for LLMs and agents

The GenAI conventions now live in their own repository. Its overview marks them as Development status and lists these areas:

• Client inference and embeddings (spans, events and metrics)
• Agent spans
• Exceptions and token metrics
• Technology pages for Anthropic, Azure AI Inference, AWS Bedrock and OpenAI
• Model Context Protocol and A2A

The agent spans page is also in Development. It defines spans for creating an agent, invoking an agent, invoking a workflow, planning and executing a tool.

A model-call span is named {gen_ai.operation.name} {gen_ai.request.model}. Attributes such as gen_ai.usage.input_tokens are recommended, while the message content attributes gen_ai.input.messages and gen_ai.output.messages are opt-in (client inference spec).

Because the status is Development, attribute names can still change between versions. Pin your instrumentation version and read the changelog when you upgrade.

Sending OpenTelemetry traces to HoneyHive

HoneyHive accepts OTLP traces. The Collector integration forwards traces from any app that exports OTLP, and a processor in the Collector config copies the trace ID into the session ID so each trace becomes one session. The attribute mapping docs cover how OTel GenAI attributes map to HoneyHive keys.

FAQ

Is OpenTelemetry a monitoring tool?

No. The project says it is not an observability backend. It generates, collects and exports telemetry, and leaves storage and visualization to other tools.

What is OTLP?

The OpenTelemetry Protocol, the standard wire format for telemetry. The spec defines it over gRPC and HTTP, with default ports 4317 and 4318, and marks it stable for traces, metrics and logs.

Does OpenTelemetry support LLMs and agents?

Yes, through its GenAI semantic conventions, which cover model calls, agent operations, tool execution and MCP. They have Development status, so names can still change.