Glossary
Glossary

What Is OpenTelemetry (OTel)?

By Sazabi Team

Last verified on Nov 8, 2026.

OpenTelemetry (OTel) is an open source, vendor-neutral framework for generating, collecting, and exporting telemetry: traces, metrics, and logs. It is a Cloud Native Computing Foundation project, formed by merging the earlier OpenTracing and OpenCensus projects. The key point: it is not an observability backend. It produces the data, and you choose where it goes.

What OpenTelemetry Includes

The project's own list of major components:

  • A specification for all components
  • A standard protocol, OTLP, that defines the shape of telemetry data
  • Semantic conventions, a standard naming scheme for common telemetry data
  • APIs that define how to generate telemetry
  • Language SDKs that implement the specification and handle export
  • A library ecosystem of instrumentation for common libraries and frameworks
  • Automatic instrumentation that generates telemetry without code changes
  • The Collector, a proxy that receives, processes, and exports telemetry
  • Tools such as a Kubernetes Operator and Helm charts

Because of the API and SDK split, library authors can instrument against a stable API while the application owner decides which SDK and exporter to use.

Signals

OpenTelemetry calls its categories of telemetry signals. It currently supports traces, metrics, logs, and baggage. Events and profiles are in development or at the proposal stage.

SignalWhat it records
TracesThe path of a request through your application, as spans
MetricsA measurement captured at runtime
LogsA recording of an event
BaggageContextual information passed between signals

See telemetry for the broader term.

How Data Flows

  1. Instrument. Add the SDK and instrumentation libraries, or use automatic instrumentation.
  2. Export. The SDK sends data over OTLP. Its exporter reads standard environment variables such as OTEL_EXPORTER_OTLP_ENDPOINT.
  3. Collect. An optional Collector receives, processes, and forwards the data. The project recommends one next to your service because it handles retries, batching, encryption, and filtering of sensitive data, and the default exporters assume a local collector endpoint.
  4. Store and query. A backend of your choice. OpenTelemetry deliberately leaves storage and visualization to other tools.

Context travels with the request as headers in the W3C Trace Context format, which is how a trace ID crosses service boundaries.

What OpenTelemetry Is Not

  • Not a backend. It does not store or display your data.
  • Not a replacement for Prometheus or Jaeger. The project says it works with open source tools like these as well as commercial products. The Collector can receive Jaeger, Prometheus, and Fluent Bit formats.
  • Not a logging library. It adds log correlation and an export path. See the OpenTelemetry logs guide.

Getting Started by Language

Language guides cover SDK setup in detail: Node.js and Python. Start with automatic instrumentation, check that spans and logs appear in a backend, and add manual spans only where the automatic ones leave gaps.

OpenTelemetry in Sazabi

Sazabi, an AI-native observability and security platform, accepts OpenTelemetry logs and traces over OTLP/HTTP with no custom exporter, and metrics through a separate OpenTelemetry metrics source. Sazabi ingests OpenTelemetry metrics (Prometheus metrics through an OpenTelemetry Collector) and OTLP traces through the same intake as your logs. It stores each metric data point and each span as a log record that its agent queries alongside your logs, so there is no separate metrics store to run. See the OpenTelemetry integration, the Collector setup, and traces.

Frequently Asked Questions

What is OpenTelemetry in simple terms?

A free, open standard and toolkit for producing traces, metrics, and logs from your software in one common format, so you can send them to whichever backend you choose.

Is OpenTelemetry a monitoring tool?

No. It is not an observability backend. It generates, collects, and exports telemetry. Storage, querying, and visualization are left to other tools.

What is the difference between OpenTelemetry and OTLP?

OpenTelemetry is the whole project: APIs, SDKs, the Collector, and conventions. OTLP is one part, the protocol that carries telemetry from your app or Collector to a backend.

Do I need the OpenTelemetry Collector?

Not to get started, since SDKs can send straight to a backend. The project recommends running one next to your service for retries, batching, encryption, and filtering sensitive data.

What does OTel stand for?

OTel is the official short form of OpenTelemetry.

Sources

  1. OpenTelemetry is an open source, vendor- and tool-agnostic observability framework for generating, exporting, and collecting traces, metrics, and logs; it is not an observability backend; its components; it is a CNCF project formed by merging OpenTracing and OpenCensus (accessed Nov 8, 2026)
  2. OpenTelemetry is a collection of APIs, SDKs, and tools; spelling is one unhyphenated word; OTel is the short form; OTLP is the OpenTelemetry Protocol (accessed Nov 8, 2026)
  3. Supported signals are traces, metrics, logs, and baggage; events and profiles are under development or proposed (accessed Nov 8, 2026)
  4. The Collector receives, processes, and exports telemetry; a collector is recommended next to your service for retries, batching, encryption, and sensitive data filtering; default OTLP exporters assume a local collector endpoint (accessed Nov 8, 2026)
  5. OTLP is stable for traces, metrics, and logs, with gRPC on 4317 and HTTP on 4318 (accessed Nov 8, 2026)
  6. OTEL_EXPORTER_OTLP_ENDPOINT configures an OTLP exporter for traces, metrics, and logs (accessed Nov 8, 2026)
  7. Sazabi accepts logs and traces from any OpenTelemetry SDK over OTLP/HTTP with no custom exporter; metrics use a separate source (accessed Nov 8, 2026)
  8. Sazabi ingests traces over OTLP and stores spans as searchable records (accessed Nov 8, 2026)
Send OpenTelemetry data to Sazabi