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.
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:
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:
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
To view expected errors, query your data:
- To view charts of expected errors, create a query for the
- To create alert conditions for NRQL queries, use the
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:
Among other places, error data appears in these parts of the UI: