OpenTelemetry Visual Handbook · lab
The trace id in the message is not a link
The incident review asks for every log of one slow request. Half of
them have trace_id=4bf9… in the text, and the
“show logs for this trace” button finds none of them. The
other half came from a worker thread and carry no id at all.
A LogRecord has fields for the trace and span ids. The log bridge fills them by reading the context that is active on the thread that called the logger, at that moment. Watch it in the showcase, then be the handler in the simulation.
Break it
- Turn the log bridge off, start a span and log. The body gets the id pasted in, the fields stay empty, and the last column says the backend has nothing to link.
- Start a second span inside the first and log. The record names the inner span. End it and log again: now it names the outer one.
- Turn off “hand the context to new threads”, spawn the worker and log from it. The worker has no active context, and neither does its record. Nothing errored.
- End every span and log. No context, no fields — and that one is correct.
Predict before you look
Answer first, then try it in the simulation.
A request handler, with the OpenTelemetry log bridge installed, hands work to a thread pool without passing the context, and the task logs 'receipt queued'. What does that LogRecord carry?
Commit to an answer first. You cannot change it afterwards.
What people get wrong
Each row is a belief the simulation is built to take apart. The right column is the specification, with the link.
| What people believe | What the spec says |
|---|---|
| Just put the trace_id in the log message. | A LogRecord has TraceId and SpanId as fields, and backends join logs to traces on those fields. An id inside the body is text: searchable by hand, invisible to the link from a log to its trace. source |
| Once a request has a trace, every log it causes has the trace. | The log bridge reads the context that is active on the calling thread at the moment of the call. A log after the span ended, or on a thread nobody handed the context to, has none. source |
| The log is attached to the request's root span. | It is attached to whichever span is active when the logger is called — the innermost open one. That is what makes 'show logs for this span' precise. source |
Where this connects
Hard context and baggage is how the context crosses a process boundary; this lab is how it crosses — or fails to cross — a thread inside one. Reading an OTLP payload shows the same 16-byte trace id that the LogRecord field carries, and Three pillars is the incident this link is for.
Check your understanding
The assessment for this lab has not been authored yet.