You are part of a team who have recently developed a new mobile application for your organization. Your unit and integration tests have highlighted a lot of defects that have since been fixed; however you're still not sure if these have fixed all of the problems with the app, since every phone and iOS version out there can't physically be tested in your QA and Dev environments.
Your app is complex, and you need to get more visibility in navigating its complex dependencies, understanding how your back end changes affect the front end, as well as understanding how your app performs on different devices, OS, and app versions.
How to use Splunk software for this use case
- Open Splunk Real User Monitoring where the overview page appears so you can see some key performance indicators for how your system is performing. You can see app crashes and errors, the number of sessions, application lifecycle events and metrics generated from these. You can also choose the time range, environment, app and source in this area.
- Under the Endpoint Errors section, you can see that there is an error occurring. Click see all to find out more, or drill down on a specific endpoint to continue troubleshooting.
- This takes you to the Tag Spotlight screen where you can continue troubleshooting. This page shows the endpoint errors across many different dimensions or tags. For example, you can choose to filter further via a HTTP status code, as you can see in the highlighted box below.
At this point, if you need to filter the data by OS, device, environment or app version, for example, you can do so using the dimensions listed in this area.
The table below shows a list of example sessions matching the criteria selected in the filter. Each example session also provides a lot of data about a session span, for example, the associated operation (
GET), and what the
Start Timeis associated with. You can click on any of the example SessionIDs to find out more.
- Clicking an example SessionID takes you to the matching span in the Session details page when you can continue triaging the issue. The example below shows the span associated to the 500 HTTP error. Lower down the screen in this area you can see collected tags, for example, app and app version, device model name and more. This helps you understand the exact environment where the error occurred.
- After you have instrumented your back-end APIs or your back-end code with Splunk APM, here you'll also see an APM link. Hover over this to access some meta data and see the Trace ID. Click on the Trace ID.
- Within Splunk APM the Waterfall view opens. Clicking the 500 error shows you other tags that the backend code is collecting which correspond to this error.
- To get a different view of errors in the system, go back to the Overview page in Splunk Real User Monitoring and change some attributes - for example, selecting a time range of one hour and adding a Mobile source filter. In this view you can see crashes that correspond with the Pixel 3 device.
- Click Tag Spotlight to see more. Here you can see a number of operation errors, and by clicking on one of these you can access more information about the error.
- Under Example Sessions, as before, click the session ID.
- Within the Session Details you can see the exact area within your code where the error occurred, allowing you to make a fix quickly and easily.
The content in this guide comes from a .conf21 session, one of the thousands of Splunk resources available to help users succeed. In addition, these Splunk resources might help you understand and implement this use case: