APM agents automatically report error data for supported frameworks. To optimize error reporting and alerting, you can further manage errors in order to:
- Catch errors that we don't instrument by default.
- Ignore errors that you don't want reported at all.
- Filter out noise from expected errors so you can focus on the errors that are affecting performance. (Java, Ruby, Node, Python, and .NET agents only)
ヒント
Check out our three-part error tracking tutorial. The tutorial uses an example scenario for an app outage in order to walk you through responding and solving critical errors.
Collect errors not instrumented by default
APM agents include API calls to report (or "notice") errors. These are useful when APM doesn't instrument your framework automatically or when there are particular errors that aren't caught for your supported framework.
To learn how to get an APM agent to report an error, see the agent-specific API documentation:
- Go:
NoticeError() - Java:
NoticeError() - .NET:
NoticeError() - Node.js:
noticeError() - PHP:
newrelic_notice_error() - Python:
notice_error() - Ruby:
notice_error()
Ignore errors
Sometimes the APM agent instruments an error that you don't want reported, such as errors that contain sensitive information like user login errors. If you don't want an error to report to our collector, you can ignore the error, and the APM agent discards the error entirely.
ヒント
For Java, .NET, Ruby, Node.js, Go, and Python: If you want to report errors to APM but don't want those errors to affect your Apdex or error rate, mark them as expected instead.
There are two ways to ignore errors: through the agent configuration or through server-side configuration in the UI:
Expected errors (Java, Node.js, Python, Ruby, Go, and .NET only)
For the below APM agents, you can mark errors as expected. These errors will be reported to APM and available for viewing, but they won't affect the Apdex or error rate (or alert conditions based on error rate).
To configure errors as expected, see the agent-specific documentation:
If expected errors are enabled, APM's Error analytics page will, by default, have a filter applied with the error.expected attribute set to false, meaning expected errors will not be displayed. To view expected errors, turn off the error.expected filter.
To view expected errors, query your data:
- To view charts of expected errors, create a query for the
error.expectedattribute. - To create alert conditions for NRQL queries, use the
error.expectedattribute.
Error fingerprinting with errors inbox
Errors inbox intelligently groups error occurrences to reduce noise and highlight important errors.
Error events get grouped into an error group when they share the same fingerprint. While our managed rules are able to provide automatic error grouping based on a predefined set of patterns, it is impossible to recognize every possible combination. For this reason, customers can also set their own fingerprint via a callback function if they find that our managed rules are not grouping occurrences accurately.
To configure custom fingerprint logic, see the agent-specific documentation:
View errors in the UI
Among other places, error data appears in these parts of the UI:
- Error analytics page: shows in-depth charts and visual analysis of errors.
- APM Overview page: shows a high-level view of your application, which includes errors.
- Alert conditions: can be based on error rate.
- The
transactionErrorevent: contains underlying error data, which can be used in NRQL queries.