New Relic Logs in Context is the secret sauce that makes your APM traces and logs talk to each other, so you don’t have to manually correlate timestamps.
Let’s see it in action. Imagine you’re in your New Relic APM dashboard, looking at a slow transaction. You see a specific span in the trace, maybe a database query that’s taking too long. Normally, you’d then have to go to your logging tool, filter by the timestamp of that span, and hope you find the right log. With Logs in Context, you can click on that span and instantly see the relevant logs right there, pre-filtered for you.
Here’s a simplified example of what that looks like.
APM Trace Span:
GET /users/:id
- DB Query: SELECT * FROM users WHERE id = 123 (150ms)
- Log: [INFO] User ID 123 fetched from database. Query took 148ms.
- Log: [DEBUG] Executing SQL: SELECT * FROM users WHERE id = 123
The magic happens because your application, when it emits logs, also includes specific attributes that New Relic can use to link them back to your APM data. The most crucial of these are:
trace.id: This is the unique identifier for the entire distributed trace.span.id: This identifies the specific operation within the trace (like the database query).entity.guid: This tells New Relic which application or service generated the APM data.
When your application sends logs to New Relic, and it has these attributes attached, New Relic automatically associates them with the corresponding trace and span. You don’t need to do anything special in the New Relic UI; it just appears.
To get this working, you need to instrument your application for APM and configure your logging agent or library to send logs with these contextual attributes.
For Java applications using the OpenTelemetry Java agent:
If you’re using the OpenTelemetry Java agent, it often automatically injects trace.id and span.id into your logs if you’re using a compatible logging framework (like Logback or Log4j2) and have enabled the appropriate exporters. You’ll want to ensure your opentelemetry-exporter-otlp is configured correctly.
For Node.js applications using the New Relic Node.js agent:
The New Relic Node.js agent automatically instruments many common logging libraries (like Winston, Pino, Bunyan). Ensure you’re using a supported version and that the agent is enabled. You might need to explicitly enable log correlation in your newrelic.js configuration file:
exports.config = {
// ... other config
logging: {
level: 'info',
enabled: true, // Ensure logging is enabled
forwarding: {
enabled: true, // Ensure log forwarding is enabled
// The agent will automatically inject trace and span IDs for supported loggers.
// No explicit configuration needed here for basic trace/span correlation.
}
},
distributed_tracing: {
enabled: true
}
};
For Python applications using the New Relic Python agent:
Similar to Node.js, the Python agent automatically adds context to logs from supported libraries. Ensure your newrelic.ini has the necessary settings:
[logging]
enabled = true
emission_enabled = true
[distributed_tracing]
enabled = true
The key is that your logs must contain the trace.id and span.id that match the active trace and span when the log is generated. If your application is generating logs outside of an active trace context (e.g., in a background process not initiated by a traced request), these IDs won’t be present, and the logs won’t be linkable.
When you’re debugging, this feature lets you jump from a slow database query in your APM trace directly to the log message that says "User ID 123 fetched from database. Query took 148ms." This dramatically reduces the time spent hunting for information across different tools. It’s not just about seeing logs near a trace; it’s about seeing the exact logs generated during that trace’s execution.
The most surprising thing is how seamlessly this integration works once configured; you don’t see separate "logs" or "traces" tabs for correlation, but rather logs appearing as inline annotations directly within the trace view.
Once you have Logs in Context working, the next logical step is to explore how to use log patterns to identify recurring issues and set up alerting based on those patterns.