Transaction Gold Link Apollo Mobile Terminal Abnormal Monitoring System

Overview

01Business Background and Purpose

General abnormal data reporting only supports simple basic reporting such as whether the interface status code is abnormal. For some core fields, the missing values ​​​​of the sent values ​​​​cause the crash anomaly to be unable to be more precisely located. For this reason, Apollo Mobile has designed this business anomaly monitoring SDK to enable the front-end and back-end to quickly cooperate to locate the problem and monitor and capture anomalies in a timely manner. By formulating a complete set of processes, intelligent processing and reporting of interface anomalies can be achieved:

• Interface exceptions can be easily captured and reported to the backend, without any development required, only some basic configuration required
• At the same time, the information parameters of the abnormal interface (request parameters, user mobile phone environment, return parameters, etc.) are completely captured and can be viewed in the background, helping developers to reproduce and solve problems.
• Directed data monitoring for certain models, users, and time periods

02Available Capabilities

SDK workflow and configuration specifications

01Workflow

The exception capture function is realized through the configuration combination on the configuration platform: the first configuration is the interface switch specification. The switch specification makes this process more flexible. You can turn on the exception reporting function according to the interface; the second configuration is the directional monitoring specification. By configuring the parameters you want to monitor, you can obtain the full amount of data that meets the conditions; the third configuration is the interface rule configuration specification. Because the data of each interface is completely different, according to this set of interface configuration specifications, R&D personnel can configure the key nodes and data types that need to be verified according to the interface. After the developer completes the configuration according to the specification, the interface data related information (input and output parameters) is passed to the interface provided by this system. This system will perform double verification through standardized parsing and interface data. If an exception is found after verification, the exception will be reported. When reporting, the current user environment, such as machine model, system model, etc., will be captured and reported together. Finally, the developer can see the exception information in the reporting background, and troubleshoot and solve the problem based on the comprehensive information parameters.

02Flowchart

The main process of checking abnormalities is as follows:

03Configuration Specifications

1. Switch configuration specifications:

• Master switch configuration: shut down all interfaces with one click.
• Interface switch configuration: Each interface is individually configured to be turned on or off.

2. Abnormal check configuration specifications:

• The overall configuration is in a json format for easy parsing and transmission.
• To verify the data type, use the type keyword.
• If you need to verify the value of the data, use the value keyword. If there is a value, the value will be strongly verified.
• If there is a hierarchical verification relationship, use the subItems keyword to display the hierarchical relationship of the data structure.

The keywords in the rules are described as follows:

When the interface switch and interface rule configuration have been completed in the configuration background, the developer needs to call the API provided by this solution in the code that calls the interface, and pass in the interface input parameters and interface output parameters.

3. Based on the above functions, the judgment capability of <directional monitoring> can be added as needed

Configuring directional filtering specifications in mobile configuration

 {
 "osVersion":"14.4/Android11", //System version
 "pin":"xxxxxx", //User ID
 "functionId":"ccart", //Interface name
 "startTime":"2022-03-01 17:51:54", //Start time
 "endTime":"2022-03-01 18:51:54"//End time…………
 } 

Directed monitoring logic:

• If the above configuration is met, no abnormal verification will be performed and all data will be reported.
• If the above configuration is not matched, the above exception reporting logic will be performed normally.

04Abnormal Monitoring System—Verification Capability Example

05Abnormal Monitoring System—Logical Capability Example

Performance Verification

Test data: The interface data volume is 312kb, including the verification configuration of more than 100 products (single products, sets) in the shopping cart interface, including basic full coverage verification such as conditional verification, value verification, multi-value verification, type verification, and empty verification.

Conclusion: In normal use, business anomaly monitoring has little impact on users and has little impact on device performance.

Access business solution example sharing

Time: During the 2021 11.11 promotion

Case 1: Actively discover problems:

During the promotion period, business exception logs are also used as an effective monitoring method. Through monitoring logs, it is found that the interface for deleting products in the shopping cart will have an empty cart situation 4-5 times a day. This is an individual abnormal reason. We actively contact the product and service side to promote the investigation of the cause of the problem and effectively avoid customer complaints in the future.

Case 2: Quickly locate the problem:

During the promotion period, it was found that on some Android models, clicking on the order details to pay could not jump to the checkout page, and the user's clicks appeared to be unresponsive. Because the online server log was closed during the promotion period, the front-end checked the business exception log and quickly located the cause of the problem.