Why can't I see my correlated logs in the Trace ID panel?
Clicking on a trace opens a contextual panel that contains information about the trace, about the host and the correlated logs. However the log panel can be empty in some specific cases. This page reviews how this can be fixed.
What logs are displayed in the trace panel?
When looking at a trace, there are two types of logs that can be seen:
host: Display logs from the trace’s host within the trace timeframe
trace_id: Display logs that have the corresponding trace id
If the log section is empty when the
host option is set, go into the log explorer and check if:
- Logs are being sent from the host that emitted trace.
- There are logs for that host within the trace timeframe.
- The timestamp of the logs is properly set. Checkout this specific guide for more explanation about the log timestamp.
Make sure you have a
trace_id standard attribute in your logs. You should see a trace icon next to the SERVICE name (black if trace is not sampled, grey if trace is sampled).
If your logs do not contain the
trace_id, follow the guide on correlating traces and logs.
The idea is then on the log side to:
- Extract the trace id in a log attribute
- Remap this attribute to the reserved
For JSON logs, step 1 and 2 are done automatically. The tracer inject the trace and span id automatically in the logs and it is remapped automatically thanks to the reserved attribute remappers.
If this isn’t working as expected, ensure the name of the logs attribute that contains the trace id is
dd.trace_id and verify it is properly set in reserved attributes.
For raw logs, using a log integration (setting the
source attribute to:
ruby, …) should do all the work automatically as well.
Here is an example with the Java integration pipeline:
Now it is possible that the log format is not covered by the integration pipeline. In this case, clone the pipeline and follow our parsing troubleshooting guide to make sure it fits your format.
For raw logs without any integration:
- Make sure that the custom parsing rule is extracting the trace and span IDs as a string as on the following example:
- Then define a Trace remapper on the extracted attribute to remap them to the official trace id of the logs.
Once the IDs are properly injected and remapped into your logs, you can make a direct trace to log correlation:
Additional helpful documentation, links, and articles: