Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat(Final text): APM lic and Logs UI
For DOC-7769
- Loading branch information
1 parent
9f40130
commit 5bdcb9e
Showing
3 changed files
with
191 additions
and
26 deletions.
There are no files selected for viewing
167 changes: 167 additions & 0 deletions
167
src/content/docs/apm/new-relic-apm/getting-started/get-started-logs-context.mdx
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,167 @@ | ||
| --- | ||
| title: APM logs in context | ||
| metaDescription: Get relevant logs, traces, errors, and other linking metadata within the context of your app or host, without additional configuration or context switching in New Relic. | ||
| --- | ||
|
|
||
| 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 APM agents can automatically add that identifier to application log data, which 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 functionality will change the way you troubleshoot by giving you visibility of logs from your applications, distributed traces, and errors directly in APM. | ||
|
|
||
| Learn more about the power of automatic logs in context with our [example](#response-time-example) of how an engineering team used it to troubleshoot their app's poor response time and rising error rates. | ||
|
|
||
| ## Get started [#get-started] | ||
|
|
||
| To set up APM logs in context: | ||
|
|
||
| 1. If you don't have one already, [create a New Relic account](https://newrelic.com/signup). It's free, forever. | ||
| 2. Update to the [supported agent version](#agents) for your apps and hosts. | ||
| 3. [Enable](#agents) logs for your agent, and make a few small updates to the configuration file. | ||
|
|
||
| That's it! Start troubleshooting your applications with APM logs in context in New Relic: | ||
|
|
||
| * Explorer UI at [one.newrelic.com](https://one.newrelic.com) | ||
| * Explorer UI for EU region: [one.eu.newrelic.com](https://one.eu.newrelic.com) | ||
|
|
||
| ## APM agent log configuration [#agents] | ||
|
|
||
| Our latest APM agents support automatically adding context and forwarding logs without the need to install or maintain third-party software! Your logs will automatically include attributes such as `span.id`, `trace.id`, `hostname`, `entity.guid`, `entity.name`, and more. This metadata links your logs to traces, spans, infrastructure data, and other telemetry, making it easier to troubleshoot. | ||
|
|
||
| Not every language or logging framework is supported yet. The following are our currently supported environments, with links to language-specific documentation: | ||
|
|
||
| * [Java logs in context procedures](/docs/logs/logs-context/java-configure-logs-context-all) for agent [v7.6.0 or higher](/docs/release-notes/agent-release-notes/java-release-notes) | ||
| * [.NET logs in context procedures](/docs/logs/logs-context/net-configure-logs-context-all) for agent [v9.7.0.0 or higher](/docs/release-notes/agent-release-notes/net-release-notes) | ||
| * [Ruby logs in context procedures](/docs/logs/logs-context/configure-logs-context-ruby) for agent [v8.6.0 or higher](/docs/release-notes/agent-release-notes/ruby-release-notes) | ||
|
|
||
| If your APM agent doesn't support our automatic logs in context solution yet, you can continue to use our [manual logs in context solutions](/docs/logs/logs-context/logs-in-context), and forward your logs via our infrastructure agent or supported third-party forwarder. | ||
|
|
||
| ## Ensure data privacy [#data-privacy] | ||
|
|
||
| <Callout variant="caution"> | ||
| 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 PII, PHI, or any other sensitive data. | ||
| </Callout> | ||
|
|
||
| Our log ingest pipeline automatically masks credit cards, Social Security numbers, national IDs, etc. For more information, see our [security documentation](/docs/logs/get-started/new-relics-log-management-security-privacy) 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](/docs/logs/ui-data/obfuscation-ui/) to find out more. | ||
|
|
||
| ## Prevent duplicate logs [#duplicate-logs] | ||
|
|
||
| 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. | ||
|
|
||
| <Callout variant="caution"> | ||
| 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. | ||
| </Callout> | ||
|
|
||
| For more information, follow the procedures to disable your [specific log forwarder](/docs/logs/forward-logs/enable-log-management-new-relic#log-forwarding). | ||
|
|
||
| ## Manage your ingest limits [#ingest] | ||
|
|
||
| **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. | ||
|
|
||
| To avoid any surprises, we recommend that you use [NRQL queries](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts/#data-queries) to create [alert conditions](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts/#alerts) to keep track of your ingest limits. For example: | ||
|
|
||
| <CollapserGroup> | ||
|
|
||
| <Collapser | ||
| id="limits-ui" | ||
| title="View data limits and usage in UI" | ||
| > | ||
| To [review your data limits in the UI](/docs/data-apis/manage-data/view-system-limits): From the [account dropdown](/docs/glossary/glossary/#account-dropdown) in the New Relic UI, click **Manage your data > Limits**. Or, to view your usage and estimated cost to date, click **View your usage**. | ||
|
|
||
| </Collapser> | ||
|
|
||
| <Collapser | ||
| id="query-estimate" | ||
| title="NRQL query: Estimated cost example" | ||
| > | ||
| To query your [month-to-date estimated cost of your ingested data](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts/#month-cost), run this NRQL query: | ||
|
|
||
| ``` | ||
| FROM NrMTDConsumption SELECT latest(estimatedCost) WHERE productLine = 'DataPlatform' SINCE this month | ||
| ``` | ||
|
|
||
| </Collapser> | ||
|
|
||
| <Collapser | ||
| id="nrql-alert" | ||
| title="NRQL alert: Usage threshold example" | ||
| > | ||
| To create an alert when your usage exceeds a fixed monthly threshold for gigabytes of data, add this [NRQL query](/docs/alerts-applied-intelligence/new-relic-alerts/alert-conditions/create-nrql-alert-conditions/) to your alert condition: | ||
|
|
||
| ``` | ||
| FROM NrMTDConsumption SELECT latest(GigabytesIngested) WHERE productLine = 'DataPlatform' | ||
| ``` | ||
|
|
||
| </Collapser> | ||
|
|
||
| </CollapserGroup> | ||
|
|
||
| ## The power of logs in context [#response-time-example] | ||
|
|
||
| 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 "Order Composer" 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. | ||
|
|
||
| <CollapserGroup> | ||
| <Collapser | ||
| id="when" | ||
| title="When and where did the errors begin?" | ||
| > | ||
| When the engineer looks at the app's **APM Summary** page, they see many more error logs leading up to the increase in response time. They want to see if the logs can expose the root cause of the problem. | ||
|
|
||
| **How can they quickly decide what's related to the problem?** | ||
|
|
||
| They have not set up log collection. But the Ruby agent for their app has been recently updated to include APM logs in context, so the app now automatically receives logs and linking metadata. The metrics facet the count by log severity set by Ruby's built-in Logger. | ||
|
|
||
| **What entities are related?** | ||
|
|
||
| On the same UI page, they click the **Logs** chart, so they can review the **Log Summary** view for entities in the New Relic Explorer. This view shows them when instrumented logs have been collected and when those logs had an `Error` severity level or worse. It also shows them a list of log patterns and what percentage of all logs fit each pattern. | ||
|
|
||
| </Collapser> | ||
|
|
||
| <Collapser | ||
| id="patterns" | ||
| title="What patterns emerge in the logs?" | ||
| > | ||
| In the **Log patterns** UI, rare error messages have begun to occur frequently, and they now appear in the list. This helps the engineer to focus on problematic logs instead of all the noisy status updates. | ||
|
|
||
| **What patterns should they focus on?** | ||
|
|
||
| The engineer notices an interesting log pattern and wants to view only the logs that fit this pattern. They click on it to add the pattern's value as a filter to the logs being displayed. This narrows the focus. | ||
|
|
||
| </Collapser> | ||
|
|
||
| <Collapser | ||
| id="log-details" | ||
| title="What can more log details reveal?" | ||
| > | ||
| The engineer wants to see all the values contained in the log record, so they click the **Log detail** view. This helps them validate that the log itself is meaningful. It also lets them drill down further into either the Kubernetes environment where the app runs, or directly to any distributed traces or APM errors related to the log record. | ||
|
|
||
| The engineer decides to look at the APM error where they can see a full stack trace. They can also see logs from their **Errors in-box** UI. | ||
|
|
||
| </Collapser> | ||
|
|
||
| <Collapser | ||
| id="log-sampling" | ||
| title="What additional test data will help troubleshoot?" | ||
| > | ||
| The troubleshooting team has been running tests to isolate the cause, but not all logs have been collected for the test transactions. The default log collection in their Ruby agent's config file (approximately 10,000 logs per minute in `application_logging.forwarding.max_samples_stored`) has been useful to validate that the services have an issue. But now they need to turn up the sampling to a higher number for more detailed troubleshooting. | ||
|
|
||
| </Collapser> | ||
|
|
||
| <Collapser | ||
| id="next-steps" | ||
| title="Problem solved. Now what?" | ||
| > | ||
|
|
||
| The troubleshooting team determines the problem stems from a recently introduced change, so they roll back that code. To save resources and ingest expenses, they turn down log collection for `application_logging.forwarding.max_samples_stored` in their config file, but they keep log sampling running in case the issue repeats itself. | ||
|
|
||
| The troubleshooting team also updates their runbooks to point to the **Log patterns** page filtered to this app, and they [add the runbook to their alert condition](/docs/alerts-applied-intelligence/new-relic-alerts/advanced-alerts/understand-technical-concepts/provide-runbook-instructions-alert-activity/). Next time they get an alert similar to this situation, they can use these lessons learned for faster troubleshooting. | ||
|
|
||
| </Collapser> | ||
|
|
||
| </CollapserGroup> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters