Was this helpful?

Deprecated

Mobile Analytics is now App Monitoring and content about Mobile Analytics is deprecated. For documentation related to these features, please see App Monitoring content, such as Monitoring app errors and crashes.

For information on migrating to App Monitoring, see Migrating from Mobile Analytics to App Monitoring.

Mobile Analytics allows you to track errors in the app log as well as in the crash log. The app log contains errors recorded by your app. The crash log contains crash data captured by the operating system if your app crashes. Being able to track data in both types of logs is probably the best way to isolate and fix bugs in your application. For an example, see Investigate issues in your mobile app.

Crash log data:  The data captured by Mobile Analytics from the crash log is presented in a summary that provides information related to each crash, such as the operating platform and device model of the device that ran the app. You also get a pointer to the crash log.

Clearly, if your application crashes, it has a very negative impact on users. You need to isolate and fix what's causing the crash as soon as possible. The crash log includes a stack trace, indicating where the error occurred. That's an important source of information in helping you isolate and debug the source of the crash.

App log data: The data captured by Mobile Analytics from the app log enables you to see how many errors were logged by your app for a specific period of time. You can also examine related data such as the error severity level. You can compare the errors recorded during a current period (such as today) versus a previous period (such as yesterday). You can also view the number of errors for different versions of your app, or compare errors by device platform or device type.

You can visually track error trends in graphs and drill down to see detailed data about each error.

App log errors don't necessarily cause a crash, but they can also lead to a negative user experience. So they need to be identified and fixed. In order to do that, you need to ensure that your app is instrumented properly, for example, you need to ensure that your app clearly identifies the severity of the error and generates an error message that clearly identifies the error situation.

Controlling log error capture

By default, Mobile Analytics tracks debug-level errors in the app log and all lower-level errors. The levels are:

  • Assert
  • Error
  • Warn
  • Info
  • Debug
  • Verbose

This means that by default, Mobile Analytics tracks debug, info, warning, error, and assert level errors for your app.

However, you can control what errors levels will be tracked by Mobile Analytics. You can even stop Mobile Analytics from monitoring the app log. You do both in the Monitor Configs section of the Configuration page.

To stop Mobile Analytics from monitoring the app log, uncheck the Enable Log Capture checkbox. The checkbox is checked by default.

To control what errors levels will be tracked by Mobile Analytics, select a level in the Log Capture Levels drop-down menu. This sets the highest error level that Mobile Analytics will monitor. Debug is the default.

See the “Configuring monitoring” section in Configure your app for further information about controlling Mobile Analytics monitoring.

Displaying error data

To display error data for your app, select Analytics in the main menu of the Mobile Analytics portal. Then select App Logs Analysis in the left navigation menu. This expands the App Logs Analysis menu item and opens Errors. Make sure that the application shown in the Application drop-down menu on the Errors page is your app. If not, select it in the drop-down menu.

Here are the various ways you can view error-related data. For each view, you get:

  • A graph that plots the number of logged errors for given points in time during a specified time period.
  • A table that summarizes logged error data for your app over the time period.
  • A table that summarizes logged data related to any application crashes recorded over the time period.
  • A table that lists raw data for each error logged over the time period.
Error data view What it displays
Errors Number of error-level and assert-level errors.
Errors by App Versions Number of error-level and assert-level errors for each version of your app.
Errors by Config Overrides Number of error-level and assert-level errors for each configuration specified for your app. This can include default configurations, beta test configurations, and A/B test configurations.
Errors by Device Platforms Number of error-level and assert-level errors for each device operating system (such as iOS or Android).
Errors by Device Models Number of error-level and assert-level errors for each device model (such as Apple iPhone 4g or HTC Thunderbolt).

Selecting a time period to display

Select the time period for the display by selecting one of the following buttons:

  • 1h. The previous hour. This is the default.
  • 3h. The previous three hours.
  • 6h. The previous six hours.
  • 12h. The previous twelve hours.
  • 1d. The previous day (24 hours).
  • 1w. The previous week (7 days).

For example, here is the Errors view for an app over the previous hour.

Notice the legend “Error & Above”. The error-related graphs plot the counts of error-level and assert-level errors. This is true even if you selected a higher-level error as the log capture level in the monitoring configuration. However, the data for those higher levels will appear in the application error summary table.

Here is a view of Errors by Device Models for the previous hour.

Displaying a time comparison

You can also display a view that compares error-related data for the currently selected time period with the same period yesterday or last week. You do this by checking a “Compare with” checkbox above the graph. For example, if the current view is for an hour, you can compare the error counts with the error counts captured for the same hour yesterday, or the same hour last week. Here is a display that compares error counts for the previous hour with the same hour yesterday:

By comparing error counts with a previous period, you can determine if a change you made in your code over that time period is causing problems. If the change is the root cause of a bug, the error counts for the current period should be higher than for the previous period.

Examining the application error summary

The application error summary is a table that summarizes the data captured for the current time period from the app log:

  • Total Errors. The number of logged error-level and assert-level errors.
  • Total Warnings. The number of logged warnings.
  • Total Events. The number of logged errors at all levels. This means that if the log capture level is set to Debug, all logged errors at the debug level and below, that is, debug, info, warning, error, and assert-level errors, will be counted.

If you select a “Compare with” checkbox, the summary displays two tables, one for the current period and one for the previous period.

Examining the application crashes summary

The application crashes summary is a table that contains the following information logged for each application crash recorded during the current time period:

  • Time Stamp. The time stamp of the crash.
  • Crash Logs. A pointer to the crash log.
  • Platform. The platform for the device (such as iOS or Android).
  • OS. The platform version for the device (such as iOS 6 or Android 3.2)
  • Device Model. The device model (such as Apple iPhone 4g).
  • App Version. The version of the app.
  • Device ID. The Apigee device id for the device. The device id is a unique ID that is randomly generated in the Mobile Analytics SDK when your app is first started in the device.

Each of the table columns is configurable. By clicking the down arrow next to a table column heading, you can sort the data in a column by ascending or descending order, group the data in the column, or remove or re-add a column from or to the display. Seldom used columns are hidden by default. The App Version column is the only column in the application crashes summary that is initially hidden. You can make it visible by clicking on the down arrow, then selecting Columns, and checking the App Version checkbox.

The pointer to the crash log is particularly valuable. That’s because it contains the stack trace of the crash recorded by the operating system. You can download the crash log and examine it. Note, though, that in iOS, you need to symbolicate the memory addresses in the crash log, which are shown as hexadecimal values. Symbolication replaces each hex address with function name, filename, and line number information. See Symbolicating iOS Crash Logs for further details.

Examining the application log raw data

Below the application crashes summary, you’ll see an application log raw data table that lists the data captured in the app log for each logged error. The columns of the table list the following information:

  • Time Stamp. The time stamp of the data capture.
  • Severity. The severity of the error (for example, ERROR or WARN).
  • TAG. The log grouping.
  • Log Message. The message that was logged.
  • Platform. The platform for the device (such as iOS or Android).
  • OS. The platform version for the device (such as iOS 6 or Android 3.2).
  • Device Model. The device model (such as Apple iPhone 4g).
  • App Version. The version of the app.
  • Conf Type. The app configuration (such as Default or Beta test).
  • Device ID. The Apigee device id for the device. The device id is a unique ID that is randomly generated in the Mobile Analytics SDK when your app is first started in the device.

As is the case for the application crashes summary, each of the table columns in the application log raw data table is configurable. Also, infrequently used columns are initially hidden, but can easily be displayed. The App Version, Conf Type, and Device ID columns are initially hidden.

Searching for logged errors

There are search fields in each column of the application log raw data table (other than the timestamp column). These allow you to search for errors in the table by severity level, tag, message content, platform, operating system, and device model. For example, if you've created specific messages for a new function in your app, you can search for those messages by entering an appropriate search string in the Log Message column.

Add new comment

Provide your email address if you wish to be contacted offline about your comment.
We will not display your email address as part of your comment.

We'd love your feedback and perspective! Please be as specific as possible.
Type the characters you see in this picture. (verify using audio)

Type the characters you see in the picture above; if you can't read them, submit the form and a new image will be generated. Not case sensitive.