OpenTelemetry SDK

The OpenTelemetry SDK implements the runtime behavior that turns collected telemetry into exported data, including trace sampling, span processing, resource attribution, and exporters. In a Java backend, it sits between application instrumentation and telemetry backends such as tracing collectors.

The OpenTelemetry SDK provides the implementation behind an application's telemetry pipeline. Instrumentation creates spans and other telemetry records, while the SDK determines how those records are processed, enriched, sampled, and ultimately exported.

For traces, a `TracerProvider` owns configuration such as samplers, span processors, and resource information. A sampler decides whether a trace or span should be recorded or sampled, while a span processor receives completed spans and prepares them for export. The processor may export synchronously or buffer data for asynchronous export depending on its implementation.

A `Resource` describes the entity producing telemetry, such as a service name, deployment environment, or host information. Resource attributes are associated with telemetry so a backend can identify which service produced a span. Resource configuration is separate from individual span attributes, which describe a particular operation.

Exporters translate SDK telemetry into a backend- or protocol-specific representation. In Java deployments, exporters can send telemetry through mechanisms such as OTLP. Production configurations commonly use batching to reduce export overhead and avoid making application threads wait on every individual span.

The SDK therefore provides the control plane for telemetry after instrumentation has produced it: sampling controls volume, processors control lifecycle handling, resources provide identity, and exporters deliver the resulting data.

Key points

• `TracerProvider` coordinates tracing configuration and creates tracers.
• Samplers determine which traces or spans are recorded or sampled.
• Span processors handle spans during their lifecycle, commonly before export.
• Resources identify the service or environment producing telemetry.
• Exporters deliver telemetry to an observability backend, commonly through OTLP.

Interview questions

What is the role of the OpenTelemetry SDK in a Java application?

The SDK implements the runtime behavior behind OpenTelemetry instrumentation. It configures sampling, span processing, resource information, and exporters. Instrumentation creates spans, and the SDK manages what happens to those spans before they reach an observability backend. This separates application instrumentation from telemetry delivery concerns.

How does sampling work in OpenTelemetry?

Sampling determines whether telemetry should be recorded or retained according to the configured sampling policy. This is useful for controlling telemetry volume and cost when an application produces many traces. Sampling can be configured using policies such as always sampling, never sampling, or probability-based approaches, depending on the SDK configuration. In distributed systems, consistent sampling decisions across a trace are important so that traces are not arbitrarily fragmented.

What is a SpanProcessor and why would you use batching?

A `SpanProcessor` receives spans as they progress through completion and passes them toward the configured exporter. A batch processor can accumulate completed spans and export them in groups rather than performing an export operation for every span. This can reduce network and per-export overhead and limit the amount of application work tied to individual exports. The tradeoff is additional buffering, configuration complexity, and the need to handle shutdown and flushing correctly.

What is an OpenTelemetry Resource, and how is it different from span attributes?

A `Resource` describes the entity that produces telemetry, such as a service, deployment, host, or runtime. Span attributes instead describe properties of an individual operation represented by that span. Resource information is therefore useful for identifying and grouping telemetry by service or deployment. Keeping these concepts separate makes service-level metadata consistent across the telemetry produced by a process.

How would you design an OpenTelemetry export pipeline for a high-throughput Java service?

I would generally use asynchronous or batch-oriented span processing so application request paths are not coupled to individual network exports. I would choose a sampling strategy appropriate to the required observability and telemetry budget, while ensuring errors or other important traces are retained according to the design. I would configure resource attributes consistently so exported data can be grouped by service and deployment. I would also consider exporting to an OpenTelemetry Collector so applications remain less coupled to individual backend vendors and operational concerns such as retries or routing can be centralized.