Lexicon
OpenTelemetry
OpenTelemetry explained: how the SDKs, Collector, and OTLP fit together, where teams struggle in practice, and why OTel native beats OTel compatible platforms.
Definition
OpenTelemetry is an open source framework for generating, collecting, and exporting telemetry: the logs, metrics, and traces that describe how software behaves in production. It defines a shared data model and a set of tools so that instrumentation works the same way regardless of which backend eventually stores and analyzes the data.
What it means in observability
Before OpenTelemetry, instrumentation was a vendor decision. Every observability platform shipped its own agents, its own SDKs, and its own wire formats, which meant the code you wrote to understand your systems only worked with one company's product. Switching vendors meant re-instrumenting everything. OpenTelemetry broke that coupling. It is a project of the Cloud Native Computing Foundation, the second most active after Kubernetes, and it has become the default answer to the question of how to instrument modern software. You instrument once, in a vendor neutral format, and choose where the data goes separately. That single change reshaped the economics and politics of the entire observability market.
How it works in practice
OpenTelemetry has a few moving parts that come up constantly. APIs and SDKs are the language specific libraries your code calls to create spans, record metrics, and emit logs; auto instrumentation packages cover common frameworks so most telemetry appears without hand written hooks. The Collector is a standalone process that receives telemetry, transforms it, batches it, and exports it onward, and it is where teams handle enrichment, filtering, redaction, and routing. OTLP is the OpenTelemetry Protocol, the wire format that carries all three signals between SDKs, Collectors, and backends. Alongside these sit the semantic conventions, a shared vocabulary of attribute names so that a Kubernetes pod or an HTTP status code is described identically no matter who produced the data.
Where it gets hard
OpenTelemetry's maturity varies by language and signal. Tracing is solid almost everywhere, while logs and some metrics paths are newer in certain SDKs. Collector configuration is powerful but easy to get subtly wrong, and a misconfigured pipeline fails quietly rather than loudly. The bigger trap is the phrase "OpenTelemetry compatible." Many platforms accept OTLP at the front door, then immediately translate it into their own proprietary format. Attributes get renamed, resource context gets flattened, and the fidelity you instrumented for is lost in translation. Compatibility is not the same thing as being built on the standard.
Where Tsuga fits
Tsuga is OpenTelemetry native, not OpenTelemetry compatible. OTLP is the native ingestion format, the semantic conventions are the internal data model, and there are no proprietary agents to install or maintain. Your instrumentation stays portable, and your telemetry keeps the exact shape you gave it.
Related terms
- APIAn API, or application programming interface, is the defined contract through which one piece of software talks to another.
- Context propagationContext propagation is the OpenTelemetry mechanism that carries trace identifiers and baggage across process boundaries, so that spans created in different services join into a single trace.
- eBPFeBPF is a Linux kernel technology that runs small, verified programs inside the kernel itself, attached to events like system calls, network packets, and scheduler activity.
- GrafanaGrafana is the open source standard for dashboards, and Grafana Labs builds an observability stack around it: Loki for logs, Tempo for traces, Mimir for metrics, with Grafana Cloud as the managed offering.
- InstrumentationInstrumentation is the code, runtime configuration, or platform setup that makes software emit telemetry.
- ObservabilityObservability is the ability to understand what is happening inside a system from the data it emits: its logs, metrics, and traces.
- OpenTelemetry CollectorThe OpenTelemetry Collector is a standalone process that receives telemetry from applications and infrastructure, transforms it, and exports it to one or more destinations.
- OTLPOTLP is the OpenTelemetry Protocol, the standard wire format for sending logs, metrics, and traces between the components of an OpenTelemetry pipeline.
- SDKAn SDK, or software development kit, is a set of libraries and tools for building against a platform or standard.
- Semantic conventionsSemantic conventions are OpenTelemetry's standard vocabulary: the agreed names, types, and values for the attributes that describe telemetry.
- Vendor lock-inVendor lock-in is the accumulation of switching costs that makes leaving a platform impractical regardless of how the relationship is going: proprietary instrumentation, captive data, workflows that exist in only one tool, and contracts priced to reward staying.