The line that explains the span.
Searching a log aggregator for the right timestamp is a bad way to spend an afternoon. Logs that arrive with a trace id are attached to the request that emitted them, so the relevant lines are already on the screen where you noticed the problem.
The lines are already next to the request.
3 stops, each one a real screen from the console.
What the service said, newest first
The feed sits under the charts on App Monitor, because that is where you already are when you want it. A warning is kept whether or not its request was sampled; the routine lines each carry the trace they came from.
Or start from the line and work backwards
Attached is the fast path, not the only one. Expand the feed and search the message, a service name, or a trace id pasted out of a ticket — every match keeps its link into the request that emitted it.
Open the request; the lines come with it
Open a match and the request comes with its own lines attached at their offset into it — the slow-call warning sitting exactly where the slow call ran. And the session that made the request is one button further on.
Everything under log management
OTLP logs, correlated by trace id, so the log lines attached to a slow or failing request are already next to it.
OTLP ingest
Standard OpenTelemetry logs to the same endpoint as traces. Set OTEL_LOGS_EXPORTER=otlp and the exporter you already run ships them.
console.log counts
Logging libraries are picked up automatically; for bare console.log in Node, @logclip/otel-console reads the active span so the line carries its trace id too.
Correlation-first retention
A line is kept when it is WARN or above, or when it carries a trace id. Trace-less INFO and DEBUG is dropped — you keep what explains a request and what signals a problem.
Recent logs feed
Newest first across the service, with an All / Warn+ switch. Each line shows time, level, service and message.
Search when you need to
Expand the feed and search the message, a service, or a trace id from a ticket. One box over all three, because that is what you arrive holding.
Click a line, open its trace
Any line with a trace id jumps to the waterfall of the request that emitted it — and from there to the session, if the request came from one.
On the trace
Open any trace and its lines are listed under the waterfall at their offset from the start of the request — +1 ms, +1.69 s — so you read what the service said while each span ran.
Seven days
Logs are a debugging aid attached to a request, not an archive: kept for seven days by default, truncated at 8 KB per message.
Per-service opt-in
Capture is a checkbox on the unit you instrument from Infrastructure, not an account-wide switch — and it needs an agent new enough to ship them.
One key, one endpoint
Traces and logs share the ingest key and the endpoint: POST /v1/logs with the same key your spans already use.
Why it matters.
Attached first, searchable second
A line carrying a trace id is already on that trace — nothing to query. When you are starting from the line instead, one box searches messages, services and trace ids.
Warnings are never dropped
A line is kept if it carries a trace id or if it is WARN or above. A warning with no trace still reaches the feed, so a failing deploy announces itself even when nothing was sampled.
Off until you turn it on
Log capture is per service, not per account: you tick it when you instrument a unit from Infrastructure, and re-instrumenting turns it off again.
Minutes, not quarters.
Send OTLP logs
The same exporter you already run for traces, pointed at the same endpoint.
Carry the trace id
Any line emitted inside a traced request is joined to it automatically; warnings and errors are kept regardless.
Read them in context
From the feed or from the trace — the lines are already next to the request.