# Log and Trace Correlation

groundcover enables seamless correlation between **logs** and **traces**, giving you deep observability across your applications and infrastructure. This powerful link lets you jump from a trace to the exact logs emitted during its execution—or from a log line back to the root trace context—so you can understand issues faster and troubleshoot more effectively.

### Why It Matters

Correlating logs and traces enables:

* **Faster root cause analysis:** Quickly identify where and why something went wrong.
* **Streamlined debugging:** No need to align timestamps or track request paths manually.
* **Actionable alerts:** Jump directly from an alert to relevant logs and traces in a single click.

### How It Works

groundcover does not automatically inject trace context into logs. It relies on your application to include the trace information—most commonly the trace\_id—as part of your log payload.

Once logs and traces are ingested, groundcover correlates them using the shared trace\_id field. This allows you to:\
• View logs emitted during a specific trace execution.\
• Navigate from a log line to its originating trace, assuming a shared trace context exists.

<figure><img src="https://2771001740-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FUHgqKYgCiRKdOpWQdi52%2Fuploads%2Fgit-blob-4546f3f1b34e20c20f01ef670722fd09411f6733%2Fimage.png?alt=media" alt=""><figcaption><p>Log - Trace Correlation in groundcover</p></figcaption></figure>

### Log - Trace Correlation in Practice

When viewing a log that contains a trace\_id (see screenshot), you can enable correlation by toggling "Correlation by Trace I&#x44;**"**

If a matching trace is found, the relevant spans will be displayed.

Keep in mind that trace sampling can impact correlation. If a particular trace wasn’t sampled and therefore not ingested into groundcover, it won’t be available for correlation—even if the log contains the correct trace\_id.

To dive deeper into a trace, click **“View in Traces”** to open the Waterfall view on the Traces page.

From the trace view, you can also jump back to the relevant logs by switching to the **“Logs”** tab.

<figure><img src="https://2771001740-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FUHgqKYgCiRKdOpWQdi52%2Fuploads%2Fgit-blob-579165f8ed1e894d918cc7d1ec2ce04a205881b5%2Fimage.png?alt=media" alt=""><figcaption><p>Waterfall view of a trace correlated from a log</p></figcaption></figure>

### Prerequisites

1. **Instrument your services** with OpenTelemetry or Datadog SDK to generate distributed traces.
2. Configure your logging framework to extract the current trace context and include it in each log line.
3. Prefer structured logging formats like JSON for clean parsing and visualization.
4. Standardize field names like trace\_id and span\_id across services to simplify correlation.\
   See below for the valid field names you can use to include the trace\_id in your logs.

### Valid trace\_id Fields in Logs

You can use the following suffixes for your trace\_id field names: `trace_id`, `trace-id`, `traceid`, `trace.id` .

This means any field name ending with one of these suffixes—such as `x_trace_id` or `my-traceid` will be recognized as a valid trace\_id field in your logs.

Field names are **case-insensitive**, so something like CaPsLock-Trace.iD is also considered valid.

###