-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #18743 from newrelic/daily-release/Sep-23--2024-9_18
Daily release/sep 23 2024 9 18
- Loading branch information
Showing
54 changed files
with
1,802 additions
and
2,951 deletions.
There are no files selected for viewing
87 changes: 47 additions & 40 deletions
87
...s/apm/agents/net-agent/getting-started/net-agent-compatibility-requirements.mdx
Large diffs are not rendered by default.
Oops, something went wrong.
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,222 @@ | ||
--- | ||
title: 'Group request errors: Analyze network failures' | ||
metaDescription: "Group, sort, and filter HTTP errors and network failures for your mobile app with the request errors UI page." | ||
redirects: | ||
- /docs/mobile-apps/errors-dashboard | ||
- /docs/mobile-monitoring-ui/errors-dashboard | ||
- /docs/mobile-monitoring/mobile-monitoring-ui/network-dashboards/errors-dashboard-mobile-apps | ||
- /docs/mobile-monitoring/mobile-monitoring-ui/network-dashboards/errors-mobile-apps | ||
- /docs/mobile-monitoring/mobile-monitoring-ui/network-pages/network-errors-ui-analyze-http-errors-network-failures | ||
- /docs/mobile-monitoring/mobile-monitoring-ui/network-pages/network-errors-ui-http-error-network-failure-analysis | ||
- /docs/mobile-monitoring/mobile-monitoring-ui/network-pages/network-errors-http-error-network-failure-analysis | ||
- /docs/network-errors-http-error-network-failure-analysis | ||
- /docs/mobile-monitoring/mobile-monitoring-ui/network-pages/errors-mobile-apps | ||
- /docs/mobile-monitoring/mobile-monitoring-ui/network-pages/http-errors-network-failure-analysis | ||
- /docs/mobile-monitoring/mobile-monitoring-ui/network-pages/http-errors-page | ||
freshnessValidatedDate: 2024-09-20 | ||
--- | ||
|
||
Network request errors that occur because of either server issues or network failures can slow down your mobile app and negatively impact the user experience. Use the request errors page to understand what's causing HTTP errors and share actionable data with your team to solve the underlying issues. | ||
|
||
## View the request errors page [#request-errors-page] | ||
|
||
To view the request errors page, go to **<DNT>[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Mobile > (select an app) > Request errors</DNT>**. | ||
|
||
<img | ||
title="Request errors overview" | ||
style={{align: "left" }} | ||
alt="Screenshot of the request errors overview" | ||
src="/images/errors-inbox_screenshot-crop_request-errors-overview.webp" | ||
/> | ||
|
||
## Recommended workflow [#suggested-workflow] | ||
|
||
We recommend the following approach to investigate HTTP request errors and network failures, allowing you to gain a complete understanding of the error, identify contributing factors, and implement effective debugging strategies: | ||
|
||
1. **Drill down into a single error**: To view details about a request error or network failure, click on the row from the error group table. Here you can view the request information, request attributes, and response body as well as get more information about that error. | ||
|
||
2. **Query and share error data**: To explore the data behind any of the charts or lists on the HTTP errors page: | ||
|
||
* On any chart, click the **…** menu, and then click **<DNT>View query</DNT>**. | ||
* From the query builder, you can add the error data to a dashboard and share it via a permalink. | ||
|
||
To dig deeper into the error data, query your data for the following events and attributes: | ||
|
||
* `MobileRequestError` events and attributes | ||
* `MobileRequest` events and attributes | ||
|
||
3. **Change how the page groups and sorts errors and network failures**: Make selections using both the attributes and filter bars at the top of the page. By default, the errors are grouped by request domain and request path. | ||
|
||
4. **Filter for specific errors and network failures**: Select an error or failure using multiple filters from the filter bar. | ||
|
||
5. **See which filters you applied or remove filters**: The filters you select display in the filter bar. To clear filters, select the **X** next to the filter you want to clear. | ||
|
||
6. **Change the time window**: Select a new time period from the time picker dropdown. | ||
|
||
7. **View information for one specific app version**: Select the version that you want to see charts and lists for in the versions dropdown. By default, all available versions are shown. | ||
|
||
|
||
The sections below describe what you can do on the request errors page. | ||
|
||
## Triage tab [#triage-errors] | ||
|
||
The triage tab shows an overview of unresolved errors and how they correlate with the error rate. The error group table lists groups of errors by occurrence and allows you to asssign them to users who can investigate and fix them. | ||
|
||
|
||
## Group request errors tab [#group-errors] | ||
|
||
On the group errors tab you can: | ||
|
||
* **Assess overall HTTP and network request error trends**: See an overview of request errors and error rates across multiple request domains and mobile app types and versions. Use this data to quickly identify and fix your API requests. | ||
|
||
* **Filter for deeper analysis**: Use groups and filters to focus on specific request attributes, such as the request type, request path, error type, or any custom attributes you've defined. | ||
|
||
* **Identify patterns**: Examine the request error table for trends related to request domains, request paths, and frequency of occurrence. | ||
|
||
* **Investigate individual request errors**: Select a request error report to view its distributed trace, event trail, response body, attributes, and other relevant details necessary for effective debugging. | ||
|
||
* **Update error status**: Mark the request error as **Resolved** or assign it to a specific team member who can own and examine the issue, and then deploy a fix. | ||
|
||
## Request error details [#error-details] | ||
|
||
On the request errors page, click into a specific error to see: | ||
* **User journeys**: Displays the different paths and actions a user performed that led to the error. | ||
* **All occurrences chart**: Displays the frequency of a request error over the selected period, starting from its initial detection. You can view either the aggregated data of all occurrences or a breakdown by app version. | ||
* **Error type breakdown**: Displays the distribution of this request errors across different operating system versions or affected devices. | ||
|
||
Resolved errors include a banner containing details on the user who resolved the request error and the resolution timestamp. Note that [mobile monitoring data retention policies](/docs/data-apis/manage-data/manage-data-retention/) apply, allowing you to filter by resolved errors for historical analysis when needed. | ||
|
||
<img | ||
title="Request errors details page" | ||
alt="Screenshot of the request errors details page" | ||
src="/images/errors-inbox_screenshot-crop_request-errors-details-page.webp" | ||
/> | ||
|
||
|
||
<figcaption> | ||
**<DNT>[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Mobile > Request errors</DNT>**: Select a request error to open the request errors details page. | ||
</figcaption> | ||
|
||
### Profiles [#error-profiles] | ||
|
||
When you look at a specific error,, the profiles section provides visual details about significant differences in the frequency of different values for HTTP error events. For each attribute, the error profile includes: | ||
* A heatmap showing how the error's attribute is distributed for values that deviate the most | ||
* A label comparing the error attribute's distribution to that of other errors | ||
|
||
<img | ||
title="Request errors profiles" | ||
style={{align: "left" }} | ||
width="50%" | ||
alt="Screenshot of the request errors profiles section" | ||
src="/images/errors-inbox_screenshot-crop_request-errors-profiles.webp" | ||
/> | ||
|
||
|
||
<figcaption> | ||
**<DNT>[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Mobile > Request errors</DNT> > (Select a specific error)**: Select a request error to open the request errors details page and view the error profiles. | ||
</figcaption> | ||
|
||
### Triage [#triage-errors] | ||
|
||
When you look at a specific error, the triage section associates the specific error occurrence you are viewing with its [system-created error group](/docs/errors-inbox/errors-inbox/#groups). These system-created error groups are identified by a unique fingerprint. It is this unique fingerprint that allows you to triage error groups by status updates or assignments. | ||
|
||
For more info on how error groups are created, see [How error groups work](/docs/errors-inbox/errors-inbox/#how-groups-work), and to learn more about status and assignments, see [Error tracking](/docs/errors-inbox/errors-inbox/#assign). | ||
|
||
<img | ||
title="Request errors triage page" | ||
alt="Screenshot of the request errors triage page" | ||
src="/images/errors-inbox_screenshot-crop_request-errors-triage-page.webp" | ||
/> | ||
|
||
|
||
<figcaption> | ||
**<DNT>[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Mobile > Request errors</DNT> > (Select a request error)**: From the request errors details page you can triage specific error occurrences by adding status updates or assignments. | ||
</figcaption> | ||
|
||
### Distributed trace [#distributed-trace] | ||
|
||
When you look at a specific error, the distributed trace section tracks and observes your requests as they flow through your application, traversing various services to reach completion. By visualizing the entire request path across different services, you can rapidly identify failures or performance bottlenecks. | ||
|
||
To learn more about how distributed tracing works, see [Track requests across your microservices](/docs/distributed-tracing/concepts/introduction-distributed-tracing/). | ||
|
||
<img | ||
title="Request errors distribute trace section" | ||
alt="Screenshot of the request errors distribute trace section" | ||
src="/images/errors-inbox_screenshot-crop_request-errors-distributed-trace.webp" | ||
/> | ||
|
||
|
||
<figcaption> | ||
**<DNT>[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Mobile > Request errors</DNT> > (Select a request error)**: From the request errors details page you view the distributed trace associated with that request. | ||
</figcaption> | ||
|
||
### Response [#response] | ||
|
||
A typical response to a request comprises a response header and response body, which together convey information about the success or failure of the request. The response header contains metadata about the server, while the response body holds information about the output, including a success or failure code and corresponding message. | ||
|
||
We capture the response body for requests whenever available, displaying it on the request errors details page to expedite debugging. | ||
|
||
<img | ||
title="Request errors response section" | ||
alt="Screenshot of the request errors response" | ||
src="/images/errors-inbox_screenshot-crop_request-errors-response.webp" | ||
/> | ||
|
||
|
||
<figcaption> | ||
**<DNT>[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Mobile > Request errors</DNT> > (Select a request error)**: From the request errors details page you view the response body associated with that request. | ||
</figcaption> | ||
|
||
### Event trail [#event-trail] | ||
|
||
When you look at a specific error, the event trail provides a chronological log of all events leading up to the request error, which helps with root cause analysis. These can be events New Relic monitors by default, or custom events. The event trail is sorted chronologically, beginning with the oldest event, which is typically the app launch, but you can modify the following: | ||
|
||
* Sort: Toggle between ascending and descending order | ||
* Event filtering: Filter by event type, like `app launch`, `request`, `request error`, or `user actions`. | ||
* Event details: Expand individual events to inspect their attributes, like `errorType`, `responseTime`, or `requestUrl` for request events. | ||
|
||
After you've sorted and filtered your events, you can dig a little deeper into the events that lead up to the error by examining: | ||
|
||
* **Custom breadcrumbs**: Utilize the [Record breadcrumb SDK](/docs/mobile-monitoring/new-relic-mobile/mobile-sdk/record-breadcrumb/) to create custom `MobileBreadcrumb` events. This allows you to log specific application interactions that may be relevant to investigating your error. | ||
* **Handled exceptions**: Use the [Record Handled Exception SDK](/docs/mobile-monitoring/new-relic-mobile/mobile-sdk/record-handled-exceptions/) methods for iOS and Android to annotate where exceptions are handled in your application. These annotations will automatically populate the crash event trail. | ||
|
||
For guidance on enhancing crash event trails with custom data, see [Record breadcrumbs](/docs/mobile-monitoring/new-relic-mobile/mobile-sdk/record-breadcrumb/). | ||
|
||
To fully leverage our crash analysis tools, make sure to: | ||
1. Use the mobile SDK to create custom `MobileBreadcrumb` or `MobileHandledException` events. | ||
2. Enable `MobileRequest` events for capturing network request data. | ||
|
||
<img | ||
title="Request errors event trail" | ||
alt="Screenshot of the request errors event trail section" | ||
src="/images/errors-inbox_screenshot-crop_request-errors-event-trail.webp" | ||
/> | ||
|
||
|
||
<figcaption> | ||
**<DNT>[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Mobile > Request errors</DNT> > (Select a request error)**: From the request errors details page you can dig deeper into the events that led up to a specific error using our event trail. | ||
</figcaption> | ||
|
||
### Attributes [#attributes] | ||
|
||
When you look at a specific error, each request error sample includes a comprehensive set of attributes that provide detailed information about the request, response, and the specific parameters that triggered the error. These attributes offer valuable insights into the error's context and help in understanding the root cause. | ||
|
||
<img | ||
title="Request errors attributes" | ||
style={{align: "left" }} | ||
alt="Screenshot of the request errors attributes section" | ||
src="/images/errors-inbox_screenshot-crop_request-errors-attributes.webp" | ||
/> | ||
|
||
|
||
<figcaption> | ||
**<DNT>[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Mobile > Request errors</DNT> > (Select a request error)**: In the attributes section, you can dig deeper into the attributes collected for that request. | ||
</figcaption> | ||
|
||
## Troubleshooting [#troubleshooting] | ||
|
||
* Keep in mind that profiles are disabled when there are no profiles available that match the applied filters. | ||
* Distributed trace for requests will most likely contain only one occurrence as it's a single HTTP event that's recorded in our system. | ||
* Network failures do not have response body. | ||
* The mobile agents maintain a list of exception types. In some cases, custom exceptions thrown by applications fall outside of this list. When this happens, `Unknown` may appear in the mobile errors inbox page. | ||
If you find `Unknown` in your list of errors and need assistance in researching which exception types are being missed, get support at [support.newrelic.com](https://support.newrelic.com). |
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
Oops, something went wrong.