OpenTelemetry (OTel) is a vendor-neutral, open-source observability framework under the Cloud Native Computing Foundation (CNCF), formed by the merger of OpenTracing and OpenCensus.

It provides a single set of APIs, SDKs, tooling, and integrations to generate, collect, transform, and export telemetry data—specifically Traces, Metrics, and Logs (the “three pillars of observability”), from software applications.

Core Problem It Solves

Before OpenTelemetry, every observability vendor (Datadog, New Relic, Dynatrace, Honeycomb, Jaeger, Prometheus) supplied its own proprietary SDKs and agents. This led to high vendor lock-in; switching or routing telemetry data to a new backend required rewriting application instrumentation code or swapping underlying agents across your entire infrastructure.

OpenTelemetry decouples instrumentation from the backend storage/analysis tool. You instrument your applications once using OTel standards, and you can route that data to any compatible backend (or multiple backends simultaneously) simply by changing a configuration file.

Architecture Components

An OpenTelemetry implementation consists of three primary layers:

1. API and SDKs

API: Defines the data types and instrumentation interfaces. Code written against the API has no operational dependencies and acts as a placeholder if no SDK is configured.

SDK: The implementation of the API for specific programming languages (Go, Java, Python, TypeScript, Rust, etc.). It manages batching, sampling, resource attribution, and exporting data.

2. Instrumentation Modules

Automatic Instrumentation: Injected via language agents or monkey-patching (e.g., Java byte-code manipulation, Node.js auto-instrumentation). Automatically captures HTTP requests, gRPC calls, database queries, and framework events without manual code changes.

Manual Instrumentation: Developer-written code using the API to record custom business metrics, track specific span attributes, or log domain-specific context.

3. OpenTelemetry Collector

A proxy component that receives, processes, and exports telemetry data. It consists of three pipelines:

[ Application / Agent ]
          │ (OTLP)
          ▼
┌─────────────────────────────────────────┐
│        OpenTelemetry Collector          │
│  ┌──────────┐  ┌───────────┐  ┌───────┐ │
│  │ Receivers│─►│ Processors│─►│Exporters│
│  └──────────┘  └───────────┘  └───────┘ │
└─────────────────────────────────────────┘
          │
  ────────┴────────────────────────────────────────
  │ (OTLP / Native)  │ (Prometheus)   │ (Vendor API)
  ▼                  ▼                ▼
[ Jaeger ]        [ Prometheus ]   [ Datadog / Honeycomb ]

Receivers: Ingest telemetry data in various formats (OTLP, Prometheus, Jaeger, Zipkin, Syslog).

Processors: Filter, transform, batch, scrub sensitive data (PII), or sample telemetry before forwarding.

Exporters: Translate processed telemetry into target formats and send it to storage backends (e.g., OTLP endpoints, S3, vendor-specific APIs).

Protocol Standard: OTLP

OpenTelemetry introduces OTLP (OpenTelemetry Protocol), an open specification defining how telemetry data is formatted and transmitted over gRPC or HTTP/Protobuf/JSON. OTLP optimizes payload size, connection reuse, and serialization speeds for telemetry transport.

Open Telemetry Pain point.

While OpenTelemetry (OTel) has won the industry standard war for observability, it is widely criticized for the friction, overhead, and complexity it introduces to engineering teams. The hatred generally stems from several key pain points.

1. Aggressive Over-Engineering and Complexity

To remain vendor-neutral and support virtually every programming language, architecture, and backend, OTel has to abstract almost everything.

  • You have to understand the API spec, the language-specific SDK implementation, automatic vs. manual instrumentation, exporters, processors, receivers, and the OpenTelemetry Collector architecture.

  • Every major cloud provider and vendor (AWS, Google, Datadog, Honeycomb) contributes to the spec, the design reflects enterprise edge cases rather than developer ergonomics. Simple tasks often require verbose boilerplate code.

2. Painful Developer Experience & Documentation

  • Finding clear examples is notoriously difficult. Documentation is split across the global OTel spec, language-specific GitHub repositories, collector component docs, and third-party vendor guides.

  • File a bug or look for feature support, and you frequently get passed around between the language SDK repo, the OTel Collector repo, and the core spec repo.

  • While Tracing is mature, Metrics and Logs lagged behind for years across different language ecosystems. A feature available in the Java SDK might be experimental or completely missing in Python or Go.

3. Performance Overhead and Resource Cost

  • overhead: Auto-instrumentation works via runtime monkey-patching or heavy reflection, adding CPU overhead to every request.
  • Languages using multi-process architectures (like Python/Gunicorn or Ruby/Unicorn) frequently struggle with thread context propagation, stats clobbering, and memory bloat.
  • Running an OTel Collector sidecar or gateway requires tuning batch sizes, queue limits, and memory limiters. Misconfiguring a collector can lead to memory leaks, dropped data, or out-of-memory crashes under spike loads.

4. The Data Explosion & Cost Trap

  • OTel makes it trivial to generate massive volumes of context-rich telemetry data. However, generating data is cheap, while storing and querying it is extremely expensive.

5. Alternative Technologies Offer More Better Sweeter Spots

  • For many use cases, lightweight alternatives feel much cleaner, eg., eBPF or Vendor-native SDKs.

Back to Certified Cloud Native Platform Engineering Associate Preparation