Lexicon
SDK
What an SDK is in observability: how OpenTelemetry SDKs turn instrumentation into telemetry, the API and SDK split, and where language support gets uneven.
On this page
Definition
An SDK, or software development kit, is a set of libraries and tools for building against a platform or standard. In observability the term almost always means the OpenTelemetry SDK: the language specific implementation that turns instrumentation calls in your code into telemetry that can actually be exported.
What it means in observability
OpenTelemetry splits its libraries into an API and an SDK, and the split is the point. Application and library code writes against the API, a stable and lightweight set of interfaces. The SDK is the engine behind those interfaces, wired up once at process startup. This lets shared libraries add instrumentation without forcing an implementation on their users, and it lets you change how telemetry is processed and exported without touching any of the code that produces it.
How it works in practice
At startup the SDK configures three kinds of machinery. Providers create the tracers, meters, and loggers the rest of the process uses. Resources attach identity: the attributes describing which service, version, host, and environment the telemetry comes from. Processors and exporters handle the outbound path, batching spans, reading metrics on an interval, and sending everything onward over OTLP. Most of this can be configured through environment variables rather than code, and auto instrumentation packages layer on top, creating spans and metrics for popular frameworks with no hand written hooks.
Where it gets hard
Maturity is uneven across languages and signals. Traces are stable everywhere, while logs support and some metrics paths are newer in certain SDKs, so identical setups can behave differently across a polyglot estate. Version drift between API and SDK packages causes confusing no-op behavior, where instrumentation runs but silently produces nothing. And configuration sprawl across environment variables, code, and auto instrumentation layers makes it easy to lose track of what a process is actually exporting.
Where Tsuga fits
Tsuga works with stock OpenTelemetry SDKs in every supported language. There are no forked SDKs, wrapper packages, or proprietary agents to install. Configure the standard OTLP exporter with a Tsuga ingestion key and endpoint, and the telemetry arrives with its shape intact.
Related terms
- APIAn API, or application programming interface, is the defined contract through which one piece of software talks to another.
- InstrumentationInstrumentation is the code, runtime configuration, or platform setup that makes software emit telemetry.
- OpenTelemetryOpenTelemetry is an open source framework for generating, collecting, and exporting telemetry: the logs, metrics, and traces that describe how software behaves in production.
- OTLPOTLP is the OpenTelemetry Protocol, the standard wire format for sending logs, metrics, and traces between the components of an OpenTelemetry pipeline.
- Semantic conventionsSemantic conventions are OpenTelemetry's standard vocabulary: the agreed names, types, and values for the attributes that describe telemetry.