Opens in a new tab
Observability · Lesson 12 of 12

Leave an investigation someone else can repeat

In brief

The slow trace is useful. The command, restart and comparison that explain it are useful too. Keep them together as you follow a local export from acceptance to completion.

4 min read

IntermediateLessonAbout reading levels
Is this the right starting point?
Before you read
Completion of the local Dispatch instrumentation and context-propagation labs.
What you will take away
Produce a reproducible investigation that separates worker delay from missing telemetry and verifies a propagation repair.
Sources
A blue cord winds across a layered pale terrain model beside blue lakes, passing stone cairns and reaching a circular wooden platform.
On this page6 sections

Your colleague opens the investigation the next morning and finds a slow trace. They can see the wait, but not the command that produced it. Did the service restart? Was that the run with a two-second delay? The conclusion may be sound; the route to it has gone home with you.

Keep that route in this capstone. In the disposable local Dispatch lab, compare two synthetic runs, try another explanation for a missing span and repair a broken connection between trace records. The goal is a comparison another engineer can repeat, not a screenshot they must take on trust.

Write the command before the first request

Start the Collector and run python3 dispatch-lab.py --worker-delay 0.2. Submit three exports, one at a time, recording each ID, status, logs and spans. Stop the process and repeat with --worker-delay 2.

Name the runs baseline and delayed. Save each launch command before submitting work. A restart resets counters, so these are separate runs; do not combine their cumulative counts into one rate. Generated identifiers will differ, but the saved settings tell the next reader where each observation belongs.

One request at a time keeps the question small: does the longer configured sleep appear in the worker interval and the wait for job success? This is not a test of capacity or concurrent work. That narrower comparison makes the result easier to explain.

The quick acceptance is only the beginning

Compare the acceptance span with the worker span. The HTTP 202 response can remain quick while the worker takes approximately the configured delay. The customer’s job completes after that work, so timing acceptance alone misses the wait you introduced.

Keep the job ID, trace ID, run settings and time window beside each observation. They connect the quick response to the slower work that follows. The supported explanation is a controlled delay in this worker stage. Dispatch does no real export storage in this lab, so the trace cannot establish that a production storage service is slow.

An empty space in a trace can have several causes

A missing worker span could mean broken context, failed delivery or a client looking up the wrong job. Try at least one alternative from the earlier fault modes. With --break-context, the job still completes but the worker appears under another trace. With the wrong OTLP port, status and logs can show progress while the Collector receives no spans.

Write the prediction before checking. A longer delay should lengthen the worker interval while acceptance can stay fast. Broken context can leave an on-time completion under another trace. Failed delivery can leave the Collector empty even though status and logs show the job. Now the next observation has something to distinguish; it need not merely agree with the first explanation that sounded plausible.

Put the worker back in the same trace

For the required repair, capture a disconnected run with --break-context, remove that flag and repeat with the same worker delay. Context propagation is the handoff that carries the trace relationship into the worker. Check that the acceptance and worker trace IDs now match and both spans appear under one trace.

Save the before-and-after pair: different IDs in the broken run, matching IDs in the repaired one. Changing only the relevant flag makes the restored relationship easier to attribute. Several simultaneous changes would leave more explanations open.

The result concerns this tested handoff. It does not establish complete queue timing, production sampling coverage or correct document generation. Those are other questions, requiring observations this comparison did not provide.

Let the next engineer get there without your memory

Save the question, setup, exact commands, identifiers, observations, alternative explanation, decisive test, repair and limitations. Place raw records or repeatable capture instructions beside screenshots so the useful detail survives outside the image.

The next engineer need not reproduce your exact IDs or durations. They should be able to reproduce the qualitative behavior: find the controlled stage that caused the wait and rerun the comparison that separated another explanation. When they open the slow trace tomorrow, the command will be there too. They can begin with the investigation instead of beginning by asking where you left it.

Sources

OpenTelemetry tracing and context propagation explain the mechanisms. Every run described uses the supplied synthetic service.

Sources & context

Sources linked in this article. Read alongside the author’s analysis; a citation does not independently verify a publisher’s claims.

Report an error or outdated detail

Keep reading

Where to go next