Observability
Trace propagation: multiple-choice review
Crux Multiple-choice synthesis across the trace-propagation unit — the W3C header, consistent sampling, tail-sampling collector limits, async boundaries, and silent production failures.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a call you make in a real incident — not a definition to recite, but a propagation decision to weigh while a dashboard lies to you about how much you can see.
Goal
Confirm you can connect the W3C header format, consistent sampling, tail-sampling collector economics, async-boundary failures, and propagation observability — the synthesis the individual lessons built toward.
Quiz
Completed
A service receives 'traceparent: 99-aaaaaaaa-bbbbbbbb-01'. Per the W3C spec, what must it do, and why does this rule matter for the whole fleet?
Heads-up traceparent is a hint, not access control. The spec mandates ignoring an invalid header and starting a fresh trace; rejecting the request would break the user flow over a telemetry detail.
Heads-up Using a malformed trace-id silently merges or corrupts traces in the backend, which keys all spans by trace-id. A wrong id is worse than a fresh valid one.
Heads-up The spec defines no repair behaviour; an all-zero trace-id or parent-id is itself invalid. The only correct action is to discard and regenerate.
Quiz
Completed
A team runs probabilistic head sampling at 1% across 12 services with no central coordinator. How do all 12 independently agree to keep or drop the same trace?
Heads-up Head sampling decides before spans leave the service; there is no after-the-fact reconciliation. Consistency comes from deterministic trace-id hashing at each service, not from the collector.
Heads-up Independent per-service dice would keep service A's span and drop service B's for the same trace — exactly the partial trace consistent sampling exists to prevent.
Heads-up Downstreams honour the sampled flag in trace-flags — but the deeper guarantee is that even re-hashing the same trace-id yields the same answer, so the system is consistent by construction.
Quiz
Completed
A tail-sampling collector OOMs every few hours. Trace count is flat but spans-per-trace is climbing. What is the cause, and which 'fix' makes it worse?
Heads-up Duplicates would raise span count across many traces, not concentrate it on a few. The signature here is a few traces each carrying thousands of spans — a long-running-trace problem.
Heads-up Replicas behind the load-balancing exporter split active traces across instances, but one fat trace still lands wholly on one replica. The real fix is breaking the work into span-linked sub-traces.
Heads-up Round-robin scatters one trace's spans across replicas so no instance sees the whole trace — that breaks tail sampling outright. trace-id hashing is mandatory; it is not the cause.
Quiz
Completed
A Node service uses OTel HTTP auto-instrumentation. Work deferred via setTimeout, and messages it publishes to Kafka, both show up as orphan traces. What is the correct two-part fix?
Heads-up context.bind only revives in-process context. Kafka crosses a process boundary with no shared memory, so the trace-id must be written into the message headers via inject and read back via extract.
Heads-up inject/extract is for serialised carriers like message headers. A setTimeout callback runs in the same process on a new async stack; it needs context.bind, not header injection.
Heads-up Auto-instrumentation handles HTTP fine; the gaps are specifically unwrapped async callbacks and queue boundaries. The fix is targeted binding and inject/extract, not abandoning auto-instrumentation.
Quiz
Completed
An internal service's orphan-span rate sits at 5% for a quarter while dashboards show full-looking traces. The team adds tail sampling hoping to clean it up. What is the core misunderstanding?
Heads-up Entry-point services legitimately root traces, but a healthy internal service should sit near 0%. A sustained 5% on an internal service is a propagation regression, not a baseline.
Heads-up This is exactly the silent-failure trap from the unit: dashboards keep rendering traces while half are disconnected. The orphan-rate metric is the truth; the rendered traces are the illusion.
Heads-up Sampling rate governs whether spans are exported, not whether they carry a correct parent-id. Exporting more orphans does not connect them.
Quiz
Completed
A consumer pulls 1,000 Kafka messages and processes them in one batch. Modelling this as one parent span with 1,000 children OOMs the collector. What is the idiomatic fix and what does it preserve?
Heads-up num_traces caps active trace count, not spans-per-trace. A 1,000-child trace still floods one buffer; raising the cap defers the OOM instead of removing the fan-in.
Heads-up Dropping all batch traces also drops the error and slow ones the team needs. span-links keep the batch observable while bounding its size.
Heads-up Fully independent traces lose the fan-in causality — you can no longer see that one batch operation processed those specific messages. span-links exist precisely to keep that link.
Recap
The unit’s through-line is one chain: the 55-byte W3C traceparent stitches services together, an invalid header means start fresh, and a uniformly random trace-id lets every service hash the same keep/drop verdict for consistent sampling. The tail-sampling collector trades RAM (active-traces × spans × bytes × window) for outcome-aware selection, so long-running traces and fan-in must be broken up with span-links. Async boundaries (setTimeout needs context.bind, queues need inject/extract) are the leading source of orphans — and because propagation fails silently, the orphan-span rate is the only metric that tells you the dashboard is lying.