Articles

OpenTelemetry Collector Interview Questions: Pipelines, Processors, and Dropped Telemetry

Prepare for OpenTelemetry Collector interviews with pipeline configuration, processor order, queue sizing, retry behavior, and evidence of dropped telemetry.

Your application is healthy, the OpenTelemetry Collector process is running, and traces are disappearing. Restarting the Collector might briefly improve the dashboard while destroying the buffered evidence you needed to explain the incident. A better interview answer follows one signal through its actual pipeline and identifies the last boundary that demonstrably accepted it.

This guide uses official OpenTelemetry documentation and component references checked in September 2026. The incident, configuration exercise, and queue calculations are original practice material. No candidate reports are used, and no claim is made that a named employer asks these exact questions. Configuration fields and component availability must match the Collector distribution and version you deploy.

The distributed tracing interview guide covers propagation and sampling foundations; this article focuses on pipeline activation, processor state, and evidence of telemetry loss.

Does defining a receiver make the Collector use it?

Official fact: Components must be referenced in the appropriate service.pipelines configuration to participate in data flow. A receiver declared at the top level but omitted from the pipeline is not enabled there. Processor order follows the pipeline's processor list. Collector configuration.

Draw the enabled path before reading every tuning field. Identify the signal type, receiver protocol, listening address, processor sequence, exporter, and backend endpoint. A working traces pipeline does not establish that a metrics pipeline exists.

Here is a minimal local trace-debugging example. It is documentation-reviewed, not a configuration executed for this article. It deliberately exports to the local debug output rather than claiming delivery to a remote backend.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 127.0.0.1:4317
processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 256
    spike_limit_mib: 64
  batch:
    timeout: 1s
    send_batch_size: 512
    send_batch_max_size: 1024
exporters:
  debug:
    verbosity: basic
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [debug]

The numeric settings are illustrative. Validate the file with the actual Collector binary, then send a known trace using the matching protocol. A loopback receiver is reachable from its own network namespace; an application in another container needs an intentionally configured network path. Do not diagnose an unreachable listener by raising the batch size.

Why does processor order change the result?

Official fact: The batch processor documentation recommends placing it after the memory limiter and sampling processors. send_batch_size triggers a send; send_batch_max_size imposes a maximum. Confusing those settings can leave a supposed size limit unenforced. Batch processor reference.

In the example, memory admission happens before batching. If a sampling or filtering stage were added, explain whether it should remove data before downstream buffering and export work occur. For an attribute-based policy, also ask whether a transformation must run first to create the attribute the policy reads.

This is an ordering argument, not a universal recipe. A transform that renames a service attribute before a filter can change which spans survive. Moving it after the filter changes the policy's inputs even if every individual component configuration remains valid.

Official fact: Reusing one processor identifier in several pipelines creates separate processor instances for those pipelines. Reusing a receiver can instead create a shared receiver that fans data into multiple paths. The architecture documentation warns that synchronous propagation can couple those paths when a processor blocks. Collector architecture.

My design inference is to treat pipeline names as routing descriptions, not proof of failure isolation. If an interview requires one destination's outage to have no effect on another, identify the queue and process boundaries that provide that isolation, then test them under a deliberately stalled destination.

Is memory-limiter refusal the same as permanent loss?

Official fact: The memory limiter begins refusing data above its soft limit by returning a non-permanent error to the preceding component. Above the hard limit it also forces garbage collection. Recovery depends on the upstream component's handling of that refusal; the processor does not manufacture durable storage. Memory limiter reference.

A strong answer distinguishes “the Collector refused this attempt” from “the application has permanently lost these spans.” The second conclusion requires knowing whether the sender retries, what it buffers, and when it abandons the data.

In our hypothetical incident, the SDK has a bounded export queue. If the Collector refuses exports long enough, pressure can move back to that SDK and eventually exhaust its buffer. Increasing only the Collector's limit could postpone the symptom while making process termination more likely under the same memory constraint.

Ask for the memory limit of the running process or container, observed memory over time, refusal counters, and upstream retry behavior. Compare the timeline with the deployment change. A memory spike after adding a stateful processor is a different lead from gradual growth during a backend outage.

The proposed fix should include a failure experiment: slow the destination, observe where admission starts failing, and verify that the application remains healthy. Passing a normal-load smoke test does not establish behavior under pressure.

Which metrics prove where the data stopped?

Official fact: Collector internal telemetry exposes receiver acceptance and refusal, exporter sending failures, successful sends, queue size, and enqueue failures. Exporter send failures alone do not imply data loss because retries may succeed. Internal telemetry guidance.

Use the following matrix as an original incident worksheet. Metric names below are examples from that guidance; verify the exported names and labels for the running version and telemetry configuration.

Observation	Plausible interpretation	Evidence needed next
No receiver acceptance increase	No matching input reached the enabled path	Sender endpoint, protocol, network reachability, active pipeline
`otelcol_receiver_refused_spans` rises	The receiver returned errors upstream	Error cause and sender retry or drop behavior
`otelcol_exporter_send_failed_spans` rises	Export attempts are failing	Retry logs, queue trend, later successful sends
`otelcol_exporter_enqueue_failed_spans` rises	Data could not enter the sending queue	Queue settings, occupancy, admission behavior
Backend lacks a trace despite successful sends	Delivery counters do not explain query visibility	Tenant, index delay, retention, sampling, and trace ID

Do not subtract two arbitrary counters and label the difference “lost spans.” They may cover different windows, replicas, signal paths, or intentional sampling decisions. Counter resets after a restart are another source of misleading arithmetic.

For a controlled test, choose a known trace ID and an interval with stable configuration. Follow it from the SDK through the selected receiver and exporter to the destination. Use a debug exporter only where its output is appropriate for the environment; verbose telemetry can expose attributes and create additional load. Collect the smallest evidence that identifies the broken boundary.

How long can an exporter queue absorb an outage?

Official fact: Exporter-helper settings distinguish retry behavior from sending-queue behavior. Queue capacity is measured in the configured sizing unit, which may be requests, items, or bytes. Overflow behavior also depends on configuration, including whether admission blocks. Read the implementation used by your exporter rather than assuming one queue unit equals one span. Exporter helper reference.

For an original arithmetic model, assume a queue with 1,000 request slots, 250 already occupied, and incoming traffic of 50 export requests per second. The backend is completely unavailable, no requests drain, and no earlier retry timeout or memory limit intervenes.

Free request slots = 1,000 - 250 = 750
Time to full queue = 750 / 50 = 15 seconds

The answer is fifteen seconds under those assumptions, not fifteen seconds of guaranteed durability. Requests may contain different numbers of spans. A capacity expressed in bytes needs a byte-rate model instead, and a real retry lifecycle can invalidate the simplified estimate.

Now suppose the backend recovers with an effective drain rate of 80 requests per second while input remains 50. The net drain is 30. If the backlog is 750 requests at recovery, clearing it takes approximately 25 seconds, assuming stable rates and no additional bottleneck.

That recovery phase matters in an interview. “The backend is available again” does not mean the queue is empty or latency has returned to baseline. State the backlog, the spare export capacity, and the deadline within which old telemetry remains useful.

Do retries or disk queues guarantee delivery?

Official fact: The resiliency guidance distinguishes in-memory buffering from persistent queues and external message queues. Data can still be lost through queue exhaustion, retry expiration, process failure without persistence, or failures of the storage layer. Collector resiliency.

A disk-backed queue can improve restart survival, but only if the configured storage persists across the restart you are considering. Replacing a pod and deleting its ephemeral storage is not the same failure as restarting a process with its storage intact.

My proposed review asks four concrete questions: when does the sender receive acknowledgment, where is the acknowledged data stored, which failures preserve that storage, and what happens if the destination rejects the payload permanently? These answers are more useful than describing the pipeline as “reliable.”

Retries also need an end condition. A temporary connection failure may recover; a rejected payload may require fixing data or configuration. Treating all errors as retryable can occupy capacity with work that will never succeed.

The original failure drill would include a short outage, an outage longer than the intended buffer window, a Collector restart, and a permanent destination rejection. Record counts and representative identifiers before and after recovery. Specify the expected result for each case rather than promising lossless or exactly-once behavior from the presence of a queue.

When can adding Collector replicas make things worse?

Official fact: Collector scaling guidance treats stateless and stateful components differently. Increasing replicas is not sufficient if the load-balancing strategy fails to distribute work or splits data needed for a stateful decision. Scaling the Collector.

Tail sampling is a concrete example. Its processor makes decisions from spans belonging to a trace and therefore needs those spans routed to the appropriate shared decision point. Its reference discusses trace completeness, decision timing, and limits on retained traces. Tail sampling processor.

In our exercise, randomly spreading spans from one trace across two independent samplers could leave each with an incomplete picture. Adding capacity without preserving trace affinity can change the sampling result while making each instance look less busy.

A better proposed experiment checks both utilization and correctness: send identifiable multi-service traces, change the replica count, and verify which sampler receives each trace's spans. Also inspect late arrivals. A decision made before a slow span arrives is a timing problem, not necessarily an exporter problem.

The interview answer should finish at the limiting stage. If the backend accepts data too slowly, more upstream Collectors may only create a larger fleet of growing queues. If parsing or processing is the bottleneck, additional suitable replicas may help. Demonstrate which case you have before choosing the scaling action.