When you're troubleshooting an issue in your app or host, you need all the New Relic tools at your fingertips. But you don't want to do a lot of context switching across the UI or be overwhelmed by the wealth of information available.
Our logs in context feature lets you to see your log data in the context of other New Relic data, making it easier to find correlations and resolve issue. And our APM agents can automatically add relevant attributes to your application log data. This makes using logs in context extremely easy. Applications can also use the agent to forward log data directly to New Relic.
Logs are more valuable in the context of the application, transaction, or error they belong to. Using our logs in context feature changes the way you troubleshoot by giving you visibility of logs from your applications, distributed traces, and errors directly in APM.
To see how logs in context can help you find the root cause of an issue in your apps and hosts, watch this short video (approx. 3:40 minutes):
With APM logs-in-context, you can:
- Cut through the noise of thousands of logs when troubleshooting time-critical issues, so you automatically see only the most relevant logs.
- Navigate within multiple types of telemetry data, and have the data correlate back to the original issue.
- Easily drill down into more detailed information from the same place in the UI.
- Find the log lines that you need to identify and resolve a problem.
To learn more about the power of logs in context, see an example use case. The example describes how an engineering team used it to troubleshoot their app's poor response time and rising error rates.
To set up APM logs in context:
- If you don't have one already, create a New Relic account. It's free, forever.
- Update to the latest APM agent version.
- The newest versions of our APM agents have logs in context (addition of metadata and forwarding) enabled by default. You may sometimes have to make some updates to the agent config file to get logs working correctly. For details on this, see Enable logs for your agent.
That's it! Start troubleshooting your applications with APM logs in context by going to the APM UI and looking for associated log data.
Drill down into your logs, traces, and errors, all from the APM Summary page in New Relic.
Our latest APM agents automatically add context and forward logs without the need to install or maintain third-party software. Your logs will automatically include attributes such as
entity.name, and more. This metadata links your logs to traces, spans, infrastructure data, and other telemetry in New Relic, making it easier to troubleshoot issues.
Here's information about the APM agents that support logs in context and log forwarding, with links to their docs:
- Go logs in context procedures for agent v3.17.0 or higher
- Java logs in context procedures for agent v7.6.0 or higher
- .NET logs in context procedures for agent v9.8.0 or higher
- Node.js logs in context procedures for agent v8.11.0 or higher
- PHP logs in context procedures for agent v10.1.0 or higher
- Python logs in context procedures for agent v18.104.22.168
- Ruby logs in context procedures for agent v8.6.0 or higher
If your APM agent doesn't support our automatic logs-in-context solutions yet, you can continue to use our manual logs in context solutions, and forward your logs via our infrastructure agent or supported third-party forwarder.
APM logs in context automatically forwards APM agent log data and is enabled by default. This can have a negative impact on your security, compliance, billing, or system performance. For more information, or if you need to adjust the default setting, follow the procedures to disable automatic logging.
Here are some additional known limitations:
- Startup logs are not available until after the agent is loaded.
- If you are using Kubernetes, be aware that we decorate the logs via instrumentation, not from the Kubernetes API. This is separate and apart from the writing logs out to the filesystem. The logs never touch the host or exist in a place where the API can be called.
- When an exception is thrown from your application, currently you will not see stack traces in the associated logs in context for Java or .NET agents. As a workaround, you can change your drop filter rules.
- Fluentd can add the
processIDfrom the entity that generated the log, but APM logs can't see that. Also, in Kubernetes, the API is called to add metadata, but this data cannot be seen from within the application. If you need the entity metadata, we recommend that you use automatic logs in context, but do not ship the logs from the application. Instead, continue to use Fluentd, Fluent Bit, or another solution to forward the log files.
You control what log data is sent to New Relic, so be sure to follow your organization's security guidelines to mask, obfuscate, or prevent sending personal identifiable information (PII), protected health information (PHI), or any other sensitive data.
Our log ingest pipeline automatically masks credit cards, Social Security numbers, national IDs, etc. For more information, see our security documentation for log management.
You can also create custom rules to mask or hash sensitive data in your logs with our obfuscation feature. This is critical when it is impractical or impossible to restrict access to sensitive data, or when some data should never be stored by New Relic. Read our obfuscation documentation to find out more.
Using logs in context functionality will increase your data ingest. Depending on your account's pricing model, this may have an impact on your ingest limits and billing.
If you want to use the APM agent to send logs directly from your applications, you must disable or modify log forwarding solutions that are currently collecting logs from those applications. Otherwise you will be sending duplicate logs, which will result in double billing.
Check our upgrade guide to learn more about how you can avoid sending duplicate logs.
For more information, follow the procedures to disable your specific log forwarder.
Example: Your engineering team is troubleshooting a problem with your app, so you temporarily increase the volume of logs collected by the APM agent to provide more granular logging. However, if you leave higher limits running for several days, this could lead to sending unnecessary data that will increase your bill.
Here is a detailed use case of using APM logs in context to get to the root cause of a problem.
Example scenario: The on-call engineer receives a New Relic alert notification about poor response time and rising error rates for their app. They need to discover the root cause behind the increase in errors and latency, so they can decide whether to rotate a problematic host out of load balancing or to roll back the most recent release.
To start troubleshooting, they go to the New Relic UI.