Your Collector has the parts. Are they connected?

The receiver is defined. So is the exporter. The configuration looks convincing, yet you still cannot find the trace your service sent. A Collector needs more than a list of available parts: it needs a route connecting the parts that should handle this data.

Follow that route in the synthetic Dispatch lab. Starting with the course service and collector from the earlier lesson, where the receiver and debug output already work, add batching, break one reference and repair it. Save a copy of collector.yaml first. No production telemetry or public listener is needed.

Defining batch is not the same as using it

The receiver accepts data sent with OTLP, OpenTelemetry’s transfer protocol. The debug exporter writes it locally for inspection. Between those two, a batch processor can briefly gather items and pass them onward as a group.

Add batch under processors, then name it in the traces pipeline as well:

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
processors:
  batch:
    timeout: 1s
exporters:
  debug:
    verbosity: detailed
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]

The upper sections define what is available. The service.pipelines.traces section names what actually handles traces. A processor that appears only in its definition has been offered a job, not assigned one.

Restart the lab collector with the same Docker command as before. Send a known export request, keep its identifiers and look for the matching spans in debug output after the batch interval. A little delay in delivery is expected while items gather. Keep the application’s event timestamps separate from the later time its records appear in output.

Starting successfully shows that the Collector accepted its configuration. Finding recognizable work in the output shows that work traveled the configured route. It is worth doing both rather than asking the startup message to prove the whole journey.

Ask the pipeline for a processor that does not exist

Change only the pipeline entry from batch to batch_missing; leave the definition alone. Restart and read the startup output. The route now names an undefined processor, so expect a configuration error rather than normal delivery.

Restore the saved configuration, restart and submit another known request. Find its records after the repair. The service may have kept finishing exports while the Collector was unavailable. Match job and trace identifiers across service logs and collector output so that a broken telemetry route does not become an unsupported claim that the application stopped working.

Five minutes of room, under very specific conditions

The debug exporter writes locally. This exercise cannot establish what a remote telemetry backend outage would do. For an exporter sending remotely, inspect the retry policy, queue capacity, memory limits and any persistent storage extension.

For a separate planning example, imagine 1,000 equally sized batches arriving each minute. The destination accepts none, and an empty queue can hold 5,000. At those steady rates, it has a nominal five minutes of room. Double arrivals and the same room lasts two and a half minutes.

First check what the actual setting counts. Requests, items and bytes are not interchangeable, and processing consumes memory too. A neat division with the wrong units is still the wrong capacity estimate.

When delivery resumes, the exporter must drain faster than new work arrives for the backlog to shrink. Reconnection gets records moving again; it does not, on its own, say that the waiting ones are catching up.

Leave a recognizable request with the configuration

Save the restored configuration and observations from successful delivery, failed startup and repaired delivery. Identify the receiver, processor, exporter and service, along with where their failures appear. The next person should know which request to send and where its records should emerge.

Include an independent request to the application in that operating note. It helps distinguish a failing export service from a failing description of the service. This lab establishes configuration understanding, not production capacity, secure multi-tenant ingestion or lossless recovery from every outage.

You began looking for a trace among plausible settings. Now there is a connected route to follow, a specific reference that can break it and a recognizable request that shows it working again. The configuration explains how the pieces cooperate, not just that the pieces exist.

Sources

Collector configuration, resiliency and internal telemetry document the components and operating signals.