Skip to content

SDK Pipelines: Processors, Readers and Exporters: OTCA practice questions

Inside an OpenTelemetry SDK, each signal has its own pipeline that starts at a provider and ends at an exporter. For traces, the TracerProvider owns the configuration: span processors, the ID generator, span limits and the sampler.

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What SDK Pipelines: Processors, Readers and Exporters covers in OTCA

Inside an OpenTelemetry SDK, each signal has its own pipeline that starts at a provider and ends at an exporter. For traces, the TracerProvider owns the configuration: span processors, the ID generator, span limits and the sampler. When a span is created, the SDK first settles the trace ID, then asks the sampler's ShouldSample for a decision, and only then hands recording spans to the registered span processors. A span processor is a hook that runs when a span starts and ends, and each processor registered on the provider begins its own pipeline that may end in its own exporter. Processors run in the order they were registered, which is how one application can send the same spans to two destinations.

The sampler decision controls how far a span travels. DROP means the span is not recorded at all. RECORD_ONLY means processors see the span but exporters should not, because the Sampled flag is not set. RECORD_AND_SAMPLE means the span is recorded, sampled and exported. The default sampler is ParentBased with AlwaysOn as the root sampler.

The SDK must ship two built-in span processors. The simple processor passes each finished span to the exporter right away. The batching processor queues finished spans and exports them in batches; its defaults are a queue of 2048 spans, a 5000 ms delay between exports, a 30000 ms export timeout and a maximum batch of 512 spans, mirrored by the OTEL_BSP_* environment variables. Exporters encode and transmit data, and retry logic belongs to the exporter, not to the processor.

Metrics use a different shape. A MetricReader collects from the MeterProvider and decides output temporality and default aggregation, normally taken from its exporter. If nothing is configured, cumulative temporality is used, and the default cardinality limit is 2000 metric points per collection cycle. The periodic exporting MetricReader collects every 60000 ms by default and passes data to a push exporter such as OTLP. A Prometheus exporter is a pull exporter: it only answers scrapes, so ForceFlush makes no sense for it. Views sit in front of this pipeline and let users rename streams, filter attributes, change aggregation or drop instruments entirely.

Logs mirror traces. LogRecordProcessors are registered on the LoggerProvider in order, and the SDK provides simple and batching processors. The batching log processor uses the same queue, batch and timeout defaults as the span processor, but its scheduled delay is 1000 ms instead of 5000 ms.

Across all signals, ForceFlush asks components to export pending data now. It is meant for cases such as function-as-a-service platforms that may freeze the process after an invocation. Shutdown is called once per component and includes the effect of ForceFlush.

Key points

  • Each span processor registered on the TracerProvider starts its own pipeline that can end in its own exporter.
  • BatchSpanProcessor defaults are 2048 queue size, 5000 ms delay, 30000 ms export timeout and 512 batch size.
  • RECORD_ONLY spans reach span processors but should not reach exporters because they are not sampled.
  • A MetricReader falls back to cumulative temporality and a cardinality limit of 2000 when nothing else is configured.
  • The periodic exporting MetricReader pushes every 60000 ms by default, while a Prometheus exporter is pull based.
  • The batching LogRecord processor differs from the span processor only in its 1000 ms scheduled delay.

Three sample questions

23 OTCA questions on SDK Pipelines: Processors, Readers and Exporters, 23 with explanations. How practice works

Question 1

Which method must be implemented by the MeterProvider to allow for resource cleanup?
  1. A.ForceFlush
  2. B.UpdateConfig
  3. C.GetResource
  4. D.Shutdown

Correct answer: D

The Metrics SDK spec says MeterProvider Shutdown "provides a way for provider to do any cleanup required", must be called only once, and after it further attempts to get a Meter are not allowed. Why the other options are wrong. "ForceFlush": ForceFlush asks for pending metrics to be exported now; it does not clean up the provider. "UpdateConfig": the MeterProvider interface has no UpdateConfig method; configuration is owned by the provider when it is created. "GetResource": there is no GetResource cleanup method; the resource is part of the provider's configuration.

Sources: OpenTelemetry spec: Metrics SDK, OpenTelemetry spec: Overview

Question 2

Your monitoring system requires aggregated statistics for specific attributes of your metrics, and you want to customize how these aggregations are performed. Which OpenTelemetry feature should you use to achieve this?
  1. A.Use the default aggregation provided by the OpenTelemetry API
  2. B.Override the default aggregation using Views
  3. C.Disable metric collection for unnecessary instruments
  4. D.Switch from metrics to tracing

Correct answer: B

The Metrics concepts page says a view lets SDK users "customize aggregation and what attributes you want to report on metrics". The Metrics SDK spec describes views as the way to override an instrument's default aggregation. Why the other options are wrong. "Use the default aggregation provided by the OpenTe…": the default aggregation is what you want to change; aggregation is also an SDK concern, not part of the API. "Disable metric collection for unnecessary instrume…": disabling instruments removes data instead of changing how it is aggregated. "Switch from metrics to tracing": traces do not produce aggregated statistics for metric attributes.

Sources: OpenTelemetry docs: Metrics, OpenTelemetry spec: Metrics SDK

Question 3

Which component of the OpenTelemetry Logs SDK is responsible for sending log records to external systems such as the OpenTelemetry Collector?
  1. A.Log Record
  2. B.Logger Provider
  3. C.Logger
  4. D.Log Record Exporter

Correct answer: D

The logs concepts page says "Log Record Exporters send log records to a consumer", which can be standard output during development, the OpenTelemetry Collector or a backend. The Logs SDK spec defines the LogRecordExporter as the interface that protocol-specific exporters implement, and each LogRecordProcessor registered on the LoggerProvider forms a pipeline that ends in an optional exporter. Why the other options are wrong. "Log Record": it is the data being exported, a recording of an event with top-level fields plus resource and attributes, not the sender. "Logger Provider": it is the factory that creates Loggers and holds the processor configuration; it does not send data itself. "Logger": it creates log records and passes them to the processors; transmission is the exporter's job.

Sources: OpenTelemetry spec: Logs SDK, OpenTelemetry docs: Logs

Practice this topic

Focus mode keeps every question on SDK Pipelines: Processors, Readers and Exporters until you leave it. 10 free guest answers, then a free account; no credit card.

Or open OTCA practice across all topics.

Sources

The explanation above was checked against these official documents.

Frequently asked questions

Where should retries for failed exports happen in the SDK?

In the exporter. The tracing SDK specification says retry logic is the exporter's responsibility because it depends on the protocol and backend, and the default span processors should not implement it.

When should I call ForceFlush?

Only when really needed, for example on FaaS platforms that may suspend the process before batched telemetry is exported. Shutdown already includes the effect of ForceFlush.