What is OpenTelemetry?
OpenTelemetry (OTel) is an open, vendor-neutral CNCF standard — a set of APIs, SDKs, and the OTLP wire protocol — for generating and exporting telemetry (traces, metrics, and logs) from your software to any compatible backend.
Definition
OpenTelemetry is a project of the Cloud Native Computing Foundation (CNCF) that standardizes how software produces telemetry. Before OTel, every observability vendor shipped its own proprietary agent and SDK, so instrumenting your code tied you to that vendor. OpenTelemetry breaks that coupling: you instrument once against a common API, and you can export the data to any backend that speaks the standard — switching tools without re-instrumenting.
OpenTelemetry has several parts. The APIs and SDKs (available for most languages) let you create and manage traces, metrics, and logs in code, often with automatic instrumentation for common frameworks. OTLP (the OpenTelemetry Protocol) is the standardized wire format for transmitting that data. And the OpenTelemetry Collector is an optional standalone service that receives, processes, batches, and routes telemetry to one or more destinations.
The pieces of OpenTelemetry
OTel is a stack of standardized components that together carry telemetry from your code to a backend.
APIs & SDKs
Language-specific libraries for creating spans, metrics, and logs in your application, often with auto-instrumentation for popular frameworks and clients.
OTLP protocol
The OpenTelemetry Protocol — a standardized format (over gRPC or HTTP) for transmitting traces, metrics, and logs to any compatible backend.
The Collector
An optional standalone service that receives telemetry, then processes, batches, filters, and exports it to one or more backends — decoupling your apps from any specific vendor.
Instrumentation
The code that emits telemetry — auto-instrumentation hooks common libraries with no code changes, while manual instrumentation adds custom spans and attributes.
Vendor neutrality
Because the API, data model, and protocol are open standards, you avoid lock-in: change observability backends without rewriting your instrumentation.
Why OpenTelemetry matters
The biggest hidden cost of observability used to be vendor lock-in. Instrumenting an application is real engineering work, and when that work is tied to one vendor's proprietary SDK, switching tools means redoing all of it. OpenTelemetry turns instrumentation into a portable asset: you write it once against an open standard, and your traces, metrics, and logs can flow to whichever backend serves you best — today or after a migration.
OTel has also become the industry's common language. It is supported across cloud providers, frameworks, and observability platforms, which means broad auto-instrumentation, a shared data model, and an ecosystem that keeps growing. Standardizing on OpenTelemetry future-proofs your telemetry strategy and lets teams share tooling and knowledge instead of relearning a new SDK per vendor.
OpenTelemetry with AllStak
AllStak accepts OTLP traces over HTTP, so you can instrument your services with OpenTelemetry and send spans directly to AllStak without a proprietary agent. Your tracing instrumentation stays portable and standards-based, and the traces land alongside your errors and logs for end-to-end debugging.
Note that AllStak's OpenTelemetry support today targets OTLP traces over HTTP specifically — not OTLP metrics or logs ingestion. For metrics and logs, AllStak provides its own collection paths rather than an OTLP endpoint.
Frequently asked questions
What is OpenTelemetry?
It is a CNCF open standard — APIs, SDKs, the OTLP protocol, and a collector — for generating and exporting traces, metrics, and logs from your software to any compatible observability backend.
What is OTLP?
OTLP is the OpenTelemetry Protocol, the standardized wire format (over gRPC or HTTP) used to transmit telemetry from instrumented apps or the collector to a backend.
Does OpenTelemetry avoid vendor lock-in?
Yes. Because instrumentation is written against an open API and data model, you can switch observability backends without re-instrumenting your code, which is OTel's central value.
Does AllStak support OpenTelemetry?
AllStak accepts OTLP traces over HTTP, so you can send OpenTelemetry spans directly to it. OTLP metrics and logs ingestion are not part of that endpoint today; metrics and logs use AllStak's own collection paths.
Explore more
By framework
Send OpenTelemetry traces to AllStak
Instrument once with OpenTelemetry and ship OTLP traces over HTTP straight into AllStak — no proprietary agent.