OpenTelemetry

Visit Website

Introduction

OpenTelemetry (OTel) is a CNCF project that defines how applications describe traces, metrics, and logs, and ships the libraries and agents that emit them. The specification is open-telemetry/opentelemetry-specification (Apache-2.0). Language APIs and SDKs, semantic conventions, and the OpenTelemetry Collector live in sibling repositories. The point of the project is to instrument once and choose a backend later: Jaeger, Prometheus, Grafana, Honeycomb, Datadog, and others can receive OTLP.

OpenTelemetry is not a dashboard and not a test runner. A test can emit spans, and CI can export them, but something else must store and query the data. There is no OpenTelemetry company plan. Vendors charge for the backend.

Features

1. Traces, metrics, and logs: One project covers all three signals, with a shared context model so a log line can carry a trace id.
2. APIs and SDKs: Stable APIs exist for the major languages (Java, Python, JavaScript, Go, .NET, and others). The API is what libraries depend on. The SDK is what you configure at process start.
3. OTLP: The OpenTelemetry Protocol is the wire format between an SDK, a collector, and a backend. gRPC and HTTP are both specified.
4. Collector: opentelemetry-collector is a binary you run to receive, process, and export telemetry. Processors handle batching, filtering, and attribute changes so each service does not hard-code a vendor.
5. Auto-instrumentation: Java, JavaScript, Python, and .NET agents can wrap common frameworks without manual spans. Coverage and quality vary by framework.
6. Semantic conventions: Attribute names for HTTP, databases, messaging, and, increasingly, CI and tests. Following them is what makes a Grafana board and a vendor board agree.
7. Context propagation: W3C Trace Context is the default way a trace crosses HTTP services. Baggage carries extra attributes. Both have to be enabled on the way in and the way out.
8. Test and CI conventions: Semantic conventions for CI and test spans exist so a JUnit or Playwright run can be exported as telemetry. The runner still executes the test.

Pros

1. Vendor-neutral instrumentation: You can change exporters without rewriting every span in application code, if you actually routed through the collector.
2. Wide language coverage: Polyglot systems can share trace context instead of one vendor SDK per service.
3. The collector is a policy point: Sampling, redaction of attributes, and fan-out to two backends belong there, not in every repo.
4. CNCF and Apache-2.0: The spec and the main implementations are free to run. No OpenTelemetry license server.
5. Libraries can instrument safely: A database client depends on the API, not on your vendor, so your app decides whether tracing is on.

Cons

1. No UI: After you export, you still need Prometheus, Jaeger, Tempo, or a commercial backend. “We adopted OpenTelemetry” is not an observability product.
2. Version skew: Spec, semantic conventions, and SDKs do not release as one number. An attribute renamed in a convention update breaks a dashboard.
3. Auto-instrumentation is partial: The agent covers common frameworks and misses your business logic. Manual spans are still required for the operations you care about.
4. Collector config is a product: Receivers, processors, and exporters are a YAML surface area with its own failure modes (queue full, exporter auth, memory limit).
5. Sampling drops the error you wanted: Head sampling decided before the request failed will throw away the trace you need. Tail sampling belongs in the collector and costs memory.

Usage and Links (Example)

A minimal Node setup using the SDK and an OTLP HTTP exporter:

npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node @opentelemetry/exporter-trace-otlp-http

const { NodeSDK } = require("@opentelemetry/sdk-node");
const { getNodeAutoInstrumentations } = require("@opentelemetry/auto-instrumentations-node");
const { OTLPTraceExporter } = require("@opentelemetry/exporter-trace-otlp-http");

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: process.env.OTEL_EXPORTER_OTLP_ENDPOINT,
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});
sdk.start();

Point OTEL_EXPORTER_OTLP_ENDPOINT at a collector you run (otelcol listening on 4318) or at a vendor’s OTLP intake. Start the SDK before the rest of the app imports HTTP frameworks, or auto-instrumentation will miss them. The collector config is a separate file; the OpenTelemetry docs’ collector getting-started page is the one to follow for the current image tag.

Resources:

• OpenTelemetry website
• Documentation
• Collector
• GitHub: open-telemetry/opentelemetry-specification

Pricing

1. Free: The specification, SDKs, instrumentation, and collector are open source, Apache-2.0 for the spec and the collector. There is no OpenTelemetry bill.
2. Backends are not free: Grafana Cloud, Datadog, Honeycomb, and similar products charge for the OTLP data you send them. Self-hosted Jaeger or Prometheus costs machines instead.
3. Commercial distributions: Vendors ship their own collector builds and support. You are paying the vendor, not the CNCF project.

Recommended for?

1. Services that may change observability vendors, or that already send data to more than one place.
2. Polyglot systems that need one propagation standard across Java, Go, and JavaScript.
3. Platform teams who can run a collector and own its config.
4. Test pipelines that should emit CI and test spans into the same backend as production. Pick a backend that understands those conventions.

Conclusion

OpenTelemetry is the instrumentation standard to adopt so application code stops importing a vendor SDK directly. It becomes useful when a collector and a backend are actually running. Budget that backend, pin SDK and convention versions, and treat sampling as a design choice. The project will not display a dashboard and it will not run your tests.