What is OpenTelemetry?

OpenTelemetry explained

OpenTelemetry, usually shortened to OTel, is the open standard for producing observability data. It is a Cloud Native Computing Foundation (CNCF) project formed in 2019 by merging two earlier projects, OpenTracing and OpenCensus, and it has since become one of the most active projects in the cloud-native ecosystem, with contributions from end users and virtually every major observability vendor.

The problem it solves is simple to state. Before OTel, each monitoring vendor shipped its own agents, libraries and data formats. Instrumenting an application meant committing to one vendor; switching meant re-instrumenting everything. OpenTelemetry separates producing telemetry from analyzing it. You instrument once against a vendor-neutral API, and the data can go to any backend that speaks the OpenTelemetry Protocol (OTLP).

Just as important is what OpenTelemetry is not. It does not store data, draw dashboards or send alerts. Those jobs belong to an observability backend. OTel is the plumbing and the common language that sits in front of it.

Signals: traces, metrics, logs and profiles

OpenTelemetry calls each type of telemetry a signal. Each has its own data model, API and maturity level:

Signal	What it captures	Status
Traces	The path of a request through a distributed system as a tree of spans with timing, status and attributes	Stable
Metrics	Measurements such as counters, gauges, up-down counters and histograms (including exponential histograms), with exemplars linking to traces	Stable
Logs	Timestamped records; OTel bridges existing logging libraries and enriches records with trace context	Stable
Profiles	Continuous stack samples showing where code spends CPU and memory, linkable to traces	Public alpha (2026)

Two supporting concepts tie the signals together. Context propagation carries trace and span IDs across process boundaries, by default using the W3C Trace Context traceparent header. Baggage carries user-defined key-value pairs, such as a tenant ID, along the same path. Resources describe the entity producing telemetry (service name, version, host, Kubernetes pod, cloud region) and are attached to every signal, which is what makes cross-signal correlation possible.

The components of OpenTelemetry

API and SDKs

The API defines how code creates spans, records metrics and emits logs. It is deliberately thin, so libraries can depend on it without forcing any implementation on their users; without an SDK, API calls are no-ops. The SDK is the implementation that applications configure: samplers, processors, exporters and resource detection. OpenTelemetry maintains SDKs for many languages, including Java, .NET, Python, Go, JavaScript/Node.js, C++, Rust, PHP, Ruby, Swift and Erlang/Elixir, with maturity varying by language and signal.

Instrumentation

Telemetry comes from three sources. Zero-code (automatic) instrumentation, such as the Java agent or the Python and .NET auto-instrumentation, hooks into popular frameworks and libraries at runtime. Instrumentation libraries add OTel support to specific frameworks, HTTP clients, database drivers and messaging systems. Manual instrumentation uses the API directly to add business-relevant spans and attributes, such as order value or customer tier. On Kubernetes, the OpenTelemetry Operator can inject auto-instrumentation into workloads via annotations, and eBPF-based approaches can capture some telemetry without touching application code at all.

Semantic conventions

Semantic conventions are the shared vocabulary of OTel: standardized names and meanings for attributes, spans and metrics. Examples include service.name, http.request.method, http.response.status_code, db.system and k8s.pod.name. Because every library and vendor uses the same names, a dashboard or query for HTTP latency works regardless of which language or framework produced the data. Conventions exist for HTTP, databases, messaging, RPC, cloud providers, Kubernetes, exceptions and, more recently, generative AI.

OTLP

The OpenTelemetry Protocol (OTLP) defines how telemetry is encoded and transported between SDKs, collectors and backends. It uses Protocol Buffers over gRPC (default port 4317) or HTTP (default port 4318, with protobuf or JSON payloads). OTLP has become the de facto interchange format for observability data, and most commercial and open-source backends accept it natively.

The Collector

The OpenTelemetry Collector is a vendor-agnostic service that receives, processes and exports telemetry. A Collector configuration defines pipelines built from:

• Receivers that ingest data, for example OTLP, Prometheus scraping, host metrics, Kafka or file logs.
• Processors that batch, filter, sample, redact or enrich data, for example adding Kubernetes metadata or performing tail-based sampling.
• Exporters that send data to one or more backends.
• Connectors that link pipelines, for example deriving RED metrics from spans.
• Extensions for health checks, authentication and other operational concerns.

Collectors are typically deployed as an agent (a sidecar or DaemonSet next to workloads) and/or a gateway (a central, scalable tier). The project ships a core distribution and a contrib distribution with hundreds of community components, and you can build custom distributions with only the components you need.

How OpenTelemetry works end to end

1. An instrumented service receives a request. The SDK creates a root span, or continues an existing trace if an incoming traceparent header is present.
2. Instrumentation libraries add child spans for outgoing HTTP calls, database queries and messages, injecting the trace context into each outbound request.
3. Metrics are recorded through instruments, and log records emitted through bridged logging libraries automatically carry the active trace and span IDs.
4. The SDK batches telemetry and exports it via OTLP, usually to a local Collector.
5. The Collector enriches, filters, samples and masks the data, then exports it to one or more observability backends, where it is stored, correlated and analyzed.

Here is a minimal Collector pipeline that receives OTLP, adds Kubernetes metadata, batches and forwards everything over OTLP:

receivers:
  otlp:
    protocols:
      grpc:
      http:
processors:
  k8sattributes:
  batch:
exporters:
  otlphttp:
    endpoint: https://otlp.example.com
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [k8sattributes, batch]
      exporters: [otlphttp]

Why teams adopt OpenTelemetry

• No vendor lock-in. Instrumentation is decoupled from the backend, so you can change, combine or evaluate vendors by editing exporter configuration.
• Consistent data. Semantic conventions give every team and language the same attribute names, which makes cross-service queries and shared dashboards possible.
• Built-in correlation. Shared context and resources link traces, metrics, logs and profiles without custom glue code.
• Ecosystem support. Frameworks, cloud services and infrastructure projects increasingly emit OTel data natively.
• Control over data. The Collector lets you filter, sample and redact telemetry before it leaves your environment, which helps with both cost and data protection.

Adopting OpenTelemetry step by step

Few organizations start from scratch; most already run proprietary agents, Prometheus exporters and log shippers. A pragmatic migration path looks like this:

1. Deploy Collectors first. Put a Collector tier in front of your current backend. It can receive OTLP, scrape Prometheus endpoints and tail log files, so existing data keeps flowing while you gain a central control point.
2. Instrument one critical journey. Add zero-code instrumentation to the services behind, for example, login or checkout, and verify that traces are complete end to end.
3. Agree on conventions. Publish a short internal guide on resource attributes, naming and which custom attributes teams should add.
4. Expand and retire. Roll instrumentation out service by service and remove proprietary agents once OTel coverage is equivalent.

Because the Collector can export to several destinations in parallel, you can run old and new backends side by side during evaluation and compare results on identical data.

Best practices and common pitfalls

• Set resource attributes deliberately. Always define service.name, service.version and deployment.environment.name. Missing or inconsistent service names are the most common cause of confusing data.
• Start with zero-code, then add manual spans. Auto-instrumentation gives broad coverage quickly; manual spans and attributes add the business context that makes traces useful.
• Use a Collector, even for small setups. It centralizes retries, batching, sampling and redaction, and lets you change backends without touching services.
• Prefer tail-based sampling for debugging value. Keep all errors and slow traces; sample the healthy majority. Tail sampling requires that all spans of a trace reach the same Collector instance, for example via load balancing by trace ID.
• Watch attribute cardinality on metrics. Putting user IDs or full URLs into metric attributes can explode the number of time series. Keep such fields on spans and logs.
• Do not break context propagation. Check that trace context survives message queues, async workers, proxies and third-party gateways.
• Track semantic convention versions. Some conventions, notably HTTP, were renamed when they stabilized. Pin versions and plan migrations so dashboards do not silently break.
• Mask sensitive data early. Use Collector processors to remove or hash personal data in URLs, headers and log bodies before export.

How Obseria helps

Obseria is OpenTelemetry-native: it ingests OTLP traces, metrics, logs and profiles directly from your existing SDKs and Collectors, and teams typically see a first trace within 15 minutes. Semantic conventions are understood out of the box, so service maps in Obseria TopoGraph, RED metrics and cross-signal correlation work without custom mapping. Obseria Pipeline adds filtering, enrichment, PII masking and routing at ingest, and tail-based sampling keeps the traces that matter. For hosts where you prefer not to deploy SDKs everywhere, the Obseria Agent complements OTel data. And because you can export via OTLP at any time, your instrumentation remains yours.