Leveraging MobileRequest/MobileRequest Error Data
In the relatively recent past we added the ability for our mobile SDKs to collect mobile HTTP request, HTTP error, & network failure event data to analyze in Insights (available to Mobile Enterprise customers on iOS/Android SDK v5.14+).
This post will walk through a few interesting use cases for leveraging this data:
- Filtering out unhelpful/noisy errors. For example, filter out errors from…
- Creating a targeted alert for a team responsible for a dependent service endpoint
- Calculating the error rate for a given endpoint/set of endpoints
- Calculating the scope or impact of various performance-related issues on your user base
To accomplish the above, we’re going to use the following events in Insights:
MobileRequest MobileRequestError MobileSession
IMPORTANT: To use the MobileRequest and MobileRequestError event types you’ll need to ensure an up to date agent version (5.14.0+) is in use and you’ve enabled the network requests feature flag via the iOS or Android SDKs (you should definitely do this!). You will need to use both event types to calculate, for example, error rate.
Alright, enough preamble already, let’s get into this Make sure to follow along in Insights to try the various queries out:
Filtering out unhelpful/noisy errors from a domain, url, or HTTP error code
Sometimes there are a few usual suspects that are causing error-related reporting issues and obscure the errors you truly care about. In those cases, you may wish to ignore them all together, or at a minimum, have a useful way filter them out as you are doing some troubleshooting.
I find it helpful to start each query by simply listing out the unique occurrences of errors per the attribute I’m interested in filtering against, I’ll therefore show you in the examples a 1-2 punch approach of faceting by the attribute, followed by filtering it out:
While writing NRQL queries in practice is easier on a single line (as seen in video), I’ve written them here in a more traditional sql format for legibility’s sake.
Filter by domain:
NRQL > SELECT count(*) FROM MobileRequestError WHERE requestDomain != '[ domain you want to filter out ]'
Filter by URL:
NRQL > SELECT count(*) FROM MobileRequestError WHERE requestUrl != '[ url you want to filter out ]'
- Use wildcards (
%) and the
not likeoperator for set of URLs:
requestUrl not like 'https://xyz.com/%/directory/%'
Filter by error status code:
NRQL > SELECT count(*) FROM MobileRequestError WHERE statusCode != '[ code you want to filter out ]'
Here are other example
MobileRequestError queries to try.
Creating an alert for a dependent service endpointIn larger organizations, you'll often find there's a number of teams responsible for the various endpoints a mobile app team depends upon. In this case, it's helpful to setup alerts for those services such that critical notifications are getting out to the right folks quickly, without interrupting other teams unnecessarily.
One way you can accomplish this is to leverage NRQL alerts. Let’s take a peek at the workflow. Please note that the ‘
%’ is a wildcard you can use in your NRQL queries:
Total Errors from endpoint:
NRQL > SELECT count(*) FROM MobileRequestError WHERE requestUrl like 'https://replaceme.com/%/all-urls-with-this-path/%' SINCE 30 minutes ago
Calculating the error rate for a given endpoint/set of endpoints
In the example video above, we looked at the volume of errors, but what if we want to know the rate of errors?
NRQL > SELECT percentage( count(*), WHERE errorType = 'HTTPError' or errorType = 'NetworkFailure' ) as 'Endpoint Error Rate %' FROM MobileRequestError, MobileRequest WHERE requestUrl like 'https://replaceme.com/%/all-urls-with-this-path/%' SINCE 3 days ago
Calculating the scope or impact of various performance-related issues on your user base.
Additionally, our latest SDKs allow you to enable the collection of event-level data for successful HTTP requests (aka MobileRequest events) and unsuccessful HTTP requests (aka MobileRequestError events) which means you can do full network analysis in Insights. Let’s say for example you want to understand what the distribution of response times look like for all successful requests across different country codes:
NRQL > SELECT histogram(responseTime,20,20) FROM MobileRequest FACET countryCode SINCE 3 days ago
The SDK tracks response time, bytes sent and bytes received, and more.
You can then take that same
responseTime attribute to assess the impact of particularly slow response times on your actual users. This is a helpful example of how you can use both the
MobileRequestError events to determine the scope of issues and what may need to be prioritized for resolution. Let’s jump into a quick video to walk through this in greater detail:
% of users with greater than 3 seconds response time:
NRQL > SELECT percentage( uniqueCount(uuid), WHERE responseTime >3 ) FROM MobileRequest, MobileSession WHERE appName = '[ app name you are interested in ]' and appVersion > '[ minimum version you want to include ]' SINCE 1 day ago COMPARE WITH 2 days ago
% of users impacted by 500 errors:
NRQL > SELECT percentage( uniqueCount(uuid), WHERE statusCode = 500 ) FROM // Note we changed our event type from MobileRequest to: MobileRequestError, MobileSession WHERE appName = '[ app name you are interested in ]' and appVersion > '[ minimum version you want to include ]' SINCE 1 day ago COMPARE WITH 2 days ago
Here are other example MobileRequest queries to try.
In addition, here is another Level-Up post on MobileRequestError events, and here is a blog post on the same topic.
PS - Mobile network request and request error events also show up in the recently-released Crash Event Trail, which is the tab next to each crash stack trace. This gives you much more information about what happened before a crash. And, you can also use our new recordBreadcrumb API (iOS: Obj-c, Swift / Android) to add additional events to the trail.
Check out the latest and let us know your thoughts