Apollo Mobile Exception Monitoring SDK: Overview, Workflow, Configuration Guidelines, and Performance Validation

Overview Typical abnormal data reporting only supports simple status‑code checks, making it difficult to pinpoint crashes caused by missing core fields. Apollo designed a mobile exception monitoring SDK that enables front‑end and back‑end teams to quickly locate and capture issues without additional development, merely through basic configuration.

Provided Capabilities a) Automatic capture and reporting of interface exceptions to the backend with minimal developer effort. b) Comprehensive capture of request parameters, user device environment, and response data to aid reproduction and resolution. c) Targeted monitoring for specific device models, users, or time windows.

SDK Workflow and Configuration Specification

01 Workflow The process relies on three configuration layers on the configuration platform:

Interface switch specification – enables or disables exception reporting per interface.

Targeted monitoring specification – defines criteria for selective full‑data collection.

Interface rule specification – describes key validation nodes and data types for each interface.

After developers configure these rules, the SDK receives request and response data, validates them against the specifications, captures the current user environment (device model, OS version, etc.), and reports any detected anomalies to the backend for analysis.

02 Flowchart [Flowchart image omitted in text]

03 Configuration Specification

1. Switch Configuration

Global switch – one‑click disable for all interfaces.

Interface‑level switch – enable or disable reporting per individual interface.

2. Exception Validation Configuration

Overall configuration is a JSON object for easy parsing.

Use the type keyword to validate data types.

Use the value keyword for strict value validation.

Use the subItems keyword to represent hierarchical data structures.

Example rule definition:

{
  "osVersion": "14.4/Android11", // system version
  "pin": "xxxxxx",               // user identifier
  "functionId": "ccart",        // interface name
  "startTime": "2022-03-01 17:51:54", // start time
  "endTime": "2022-03-01 18:51:54"   // end time
  // ... other fields
}

3. Targeted Monitoring Extension When a request matches the targeted monitoring configuration, the SDK skips validation and reports the full data set; otherwise, normal exception validation and reporting are performed.

Performance Verification Tested with 312 KB of interface data containing over 100 cart items. Validation covered condition checks, value checks, multi‑value checks, type checks, and null checks, demonstrating negligible impact on user perception and device performance.

Business Solution Case Sharing

Case 1 – Proactive Issue Discovery During a major sales event, logs revealed occasional empty‑cart situations after a delete‑item call. The team contacted product and backend owners, identified the root cause, and prevented future customer complaints.

Case 2 – Rapid Problem Localization In the same event, certain Android devices failed to navigate to the checkout page from the order‑detail screen. With backend logs disabled, the front‑end used the exception logs to quickly pinpoint the issue.