OpenTelemetry FAQ: What It Is, What It Is Not, and How to Adopt It

OpenTelemetry comes up in almost every observability conversation, and it is frequently misunderstood. Teams think they are choosing between OpenTelemetry and Datadog, or wonder whether they need OpenTelemetry if they already have Grafana. This FAQ addresses the questions that come up most often when teams are evaluating or adopting the standard.

What Is OpenTelemetry?

OpenTelemetry is an open-source observability framework and collection of APIs, SDKs, and tools for generating, collecting, and exporting telemetry data — specifically metrics, logs, and traces. It is maintained by the Cloud Native Computing Foundation (CNCF) and has broad vendor and platform support.

The simplest accurate description: OpenTelemetry is how you instrument your code. It is not where you store, visualize, or alert on the data that comes out of that instrumentation.

Is OpenTelemetry a Competitor to Datadog or Grafana?

No. OpenTelemetry and platforms like Datadog, Grafana, Honeycomb, or New Relic operate at different layers.

OpenTelemetry handles the instrumentation layer — the code inside your services that generates telemetry. Datadog and Grafana are backends — they store the telemetry, provide query interfaces, build dashboards, and send alerts.

You can use OpenTelemetry to generate traces and export them to Datadog, to Grafana Tempo, to Jaeger, or to any other OTLP-compatible backend. Swapping backends does not require changing your application code. That is the primary value proposition.

Using OpenTelemetry does not mean you are abandoning any particular vendor. It means you are not permanently coupled to a vendor's proprietary instrumentation library.

What Does OTLP Stand For?

OTLP is the OpenTelemetry Protocol — the wire format used to transmit telemetry data between components. When vendors say they support OTLP, they mean they can receive data in this format. When you configure an OpenTelemetry exporter with an endpoint URL, you are typically sending data over OTLP (either HTTP or gRPC).

OTLP has become the default protocol for telemetry in most modern observability tooling. Grafana's entire LGTM stack accepts OTLP natively. Datadog accepts OTLP through the Datadog Agent. Most hosted observability platforms have OTLP endpoints.

What Languages Does OpenTelemetry Support?

OpenTelemetry has mature, generally-available SDKs for:

• Go
• Java
• JavaScript / TypeScript (Node.js and browser)
• Python
• .NET (C#)
• Ruby
• PHP
• Rust
• C++

Erlang/Elixir and Swift SDKs exist in varying states of maturity. The specification is language-agnostic, so the APIs are consistent across languages even though implementation details differ.

What Is Auto-Instrumentation?

Auto-instrumentation refers to instrumentation that happens automatically for popular libraries and frameworks, without requiring the developer to add code at each integration point.

For example, OpenTelemetry's Node.js auto-instrumentation automatically generates spans for HTTP calls made with the native http module, Express route handling, PostgreSQL queries via pg, Redis calls via ioredis, and many other common libraries.

Auto-instrumentation covers the infrastructure layer. It does not cover your business logic. For anything specific to your application — an order processing function, a pricing calculation, a background job — you write custom spans using the OpenTelemetry API directly.

Do I Need the OpenTelemetry Collector?

Not always. The Collector is a standalone service that receives telemetry, processes it (filtering, sampling, attribute enrichment), and exports it to one or more backends. It sits between your services and your observability backend.

You need the Collector when:

• You want to fan out telemetry to multiple backends simultaneously (e.g., send traces to both Tempo and a third-party tool)
• You want to apply tail-based sampling at the infrastructure level, without modifying application code
• You need to filter or redact sensitive attributes before data leaves your environment
• You are operating at scale and want to manage exporter configuration centrally rather than per-service

For simpler setups, you can export directly from your services to your backend using the OTLP exporter. Start without the Collector and add it when you need its capabilities.

How Does OpenTelemetry Handle Trace Context Propagation?

Trace context propagation is the mechanism that links spans across service boundaries. When service A calls service B, service A injects the current trace context into the outbound request headers. Service B extracts it and creates child spans under the same trace.

OpenTelemetry uses the W3C Trace Context standard by default — specifically the traceparent and tracestate headers. This is the widely adopted standard and most instrumentation libraries handle injection and extraction automatically for HTTP.

For non-HTTP protocols — gRPC, message queues, event streams — propagation requires explicit handling. You inject context into message metadata when publishing and extract it when consuming. Auto-instrumentation handles this for some messaging systems (Kafka via specific instrumentation packages, for example) but not all.

How Long Does It Take to Instrument an Existing Service?

It depends on the language, the framework, and what you want to cover.

For a standard HTTP service in a supported language with auto-instrumentation: basic trace coverage can be added in a few hours. You install the SDK and instrumentation packages, write the initialization code, and deploy.

For full coverage including custom spans across business logic, proper attribute strategy, and context propagation across async boundaries: plan for one to several days of focused engineering time per service, plus additional time for testing and validation.

For a microservices system with many services, the work is additive. Prioritize the services closest to users and the most latency-sensitive paths first.

Will Adding OpenTelemetry Affect My Service's Performance?

OpenTelemetry adds overhead. How much depends on your sampling rate, the number of spans generated per request, and whether you export synchronously or asynchronously.

In practice, for most production services with reasonable sampling and asynchronous export, the overhead is small — typically under 1-2% CPU and negligible latency impact on request handling. The SDK is designed for production use.

Potential performance problems arise when:

• 100% of requests are sampled at high throughput
• Spans generate very large attribute payloads
• The exporter uses synchronous mode (which blocks request handling during export)

Configure sampling appropriately, keep attribute values small, and use the default asynchronous batch exporter. Review performance impact after initial deployment.

What Is the Best Way to Start?

1. Choose one service — preferably a high-traffic, user-facing one.
2. Add the OpenTelemetry SDK with auto-instrumentation and point it at a simple backend (Jaeger running locally, or Grafana Cloud's free tier).
3. Deploy and look at the traces that come out.
4. Add custom spans for the most important business operations in that service.
5. Wire up trace context propagation to the next service downstream.
6. Repeat.

The value of tracing is proportional to coverage. One instrumented service in a chain of five gives you partial visibility. All five gives you the complete picture. Work outward from the entry point.

If you are setting up OpenTelemetry across a multi-service system and want the instrumentation done correctly from the start, Clixo can design and implement the observability foundation — from instrumentation strategy to backend selection to alert configuration.