Global Settings/Application Settings
In order to make it convenient for developers to set application functions, the Tingyun App 3.0 platform provides two setting methods: "Global Settings" and "Application Settings".
- Global configuration: The general settings for all applications can be configured directly in "Global Settings". After configuration, turn on the [Use Global Configuration] switch in the application to take effect.
- App Settings: Settings for adapting to a single app can be configured in App Settings.
Basic settings
To enable the platform to automatically distinguish between its own services and third-party services, you can configure your own services, support entering the IP address or domain name of the service, or use the global configuration, which will overwrite the current application configuration. Self-service refers to the service provided by the customer's own application. Third-party services are domain names other than their own services.
-
App name can be customized, but the generated App Key is fixed and cannot be modified.
-
Both host and URL Scheme are provided to facilitate the deployment of the SDK.
-
App platform supports iOS and Android.
-
Click Save the settings the button when you are finished for the configuration to take effect.
-
You can turn on the View Deployment SDK Documentation switch in the report to view the deployment instructions.
Security settings
Module control switch
The module control switch is the main switch of each sub-module, which controls whether the SDK collects the data of the corresponding module. It is off by default. When enabled, you can separately control whether the SDK collects data from the request analysis module, WebView module, cross-application tracking, crash module, stutter module, user experience module, user statistics module and network detection.
-
Request analysis module: After the switch is turned off, the SDK will no longer embed code into the network class library, which will affect all data display in the "network analysis" function.
-
WebView module: After the switch is turned off, the SDK will no longer inject JS probes into the H5 page inside the application, which will affect the data display of the App H5 page in the "Web" product line.
-
Cross-application tracking: After cross-application tracking is enabled, SDK will add the request header of the Tingyun to the request header. When a request is called across applications, it can be tracked according to this identifier.
-
Crash module: After the switch is turned off, the SDK no longer collects crash data, which affects the display of "crash" data in exception analysis.
-
Stall module: After the switch is turned off, the SDK will no longer collect the stutter data, which affects the display of the "stutter" data in the anomaly analysis.
-
User experience module: After the switch is turned off, the SDK will no longer collect the data of application startup, operation and page, which will affect all data display in the user experience function.
-
User statistics module: After the switch is turned off, the SDK no longer collects the usage duration data, which affects the data collection of "user duration" in user statistics and the custom error data collection in exception analysis.
-
Network detection module (off by default): After this switch is turned off, the SDK will no longer receive network detection tasks, and the network detection function cannot be used. The "network delay" and "packet loss rate" indicators in network analysis cannot be collected.
-
Log retrieving module (off by default): After this switch is turned off, the SDK will no longer receive log retrieving tasks.
-
Cache size: Log files are stored on a daily basis. The default cache size for storing a single log file per day is 10 MB (up to 7 days of logs). You can adjust the storage size for a single log file as needed.
-
Log level: All levels of logs are obtained by default. You can manually adjust the level of log storage as needed.
-
When the main switch changes from off to on, the settings you previously made for the single module switch remain unchanged.
Click Save the settings the button when you are finished for the configuration to take effect.
In the application setting, the module switch can be controlled according to the specified version.
Enhanced security (apply settings)
The secondary verification method used to prevent man-in-the-middle attacks can prevent applications from being counterfeited by criminals.
-
Fill in the contents
- For iOS, please complete the Bundle Identifier.
- For Android, please fill in "SHA1 fingerprint".
-
Click Save the settings the button when you are finished for the configuration to take effect.
Threshold settings
Threshold settings You can customize the slow threshold of each indicator, and the platform will store single sample data according to the corresponding threshold.
- Configuration description
- Maximum number of crash trace collections: refers to the number of steps back from the page where the crash occurred. Select from the drop-down list, including 20, 50, 80, 100, No restrictions and Disable Crash Trace Collection. The default is 20.
- Stuck threshold: the threshold for judging the application stuttering, unit: millisecond; default threshold: 5000ms, the minimum threshold shall not be less than 1000ms.
- Startup experience threshold: slow startup threshold, unit: millisecond; default threshold: 3000ms, the minimum threshold shall not be less than 1000ms.
- Operation experience threshold: slow operation and blocking operation threshold, unit: millisecond; default threshold: 3000ms, the minimum threshold shall not be less than 1000ms.
- Page Experience Threshold: Two thresholds can be set.
- Slow interactive threshold, unit: millisecond; default threshold: 1000ms, the minimum threshold shall not be less than 100ms. When the interaction process exceeds the set threshold, the system will record the complete tracking process of the interaction for analysis and optimization.
- Slow first screen threshold, unit: millisecond; default threshold: 3000ms, the minimum threshold shall not be less than 1000ms.
- Slow request threshold: two constraint ranges of the number of bytes downloaded and the download rate can be configured.
- By default, when the number of bytes downloaded is greater than 50 KB and the download rate is less than or equal to 50 KB/s, it is judged as a slow request.
- By default, when the number of bytes downloaded is less than or equal to 50 KB and the request time is greater than or equal to 2000 ms, it is judged as a slow request.
- Click Save the settings the button when you are finished for the configuration to take effect.
Call chain trace settings
For the user who uses the third-party APM server to monitor, after configuring the request header and jump address of the third-party APM, the SDK will add the set request header to each request and generate a UUID, so as to realize the tracking and analysis of the call chain from the Tingyun platform to the third-party APM.
Configure call chain tracking for the current application. The steps are the same as those for general configuration. For details, see [Distributed Tracing General Configuration]. After the switch is turned on Use Platform Common Configuration, the platform general configuration will override the call chain tracking configuration of the current application.
The added request header data will be displayed in the following interface.
-
Network Analysis > Slow Request List > Detail List > TraceID
-
User Tracking > Slow Requests > TraceID
-
User Experience > Startup Experience/Page Experience/Operation Experience > Exception Statistics and Tracking > Breakdown Diagram > Network Request > TraceID
Scoring settings
The score setting is used to measure the user experience of the application in the form of score quantification.
Performance Rating Weight
The default performance score weight is: startup time 10%, interactive time 5%, first screen time 5%, operation time 5%; request response time 10%, request error 15%, crash rate 30% and stutter rate 20%. You can increase or decrease the score weight of an indicator as required. After setting the weight, continue to set the low threshold, baseline threshold, and high threshold for each indicator.
Performance Baselines and Threshold
Explain: When calculating the score, each threshold is automatically obtained by the system and updated every calendar month.
-
The score for each of the above indicators is calculated as follows:
- Indicator score = 100 \ * (indicator mean-industry 90th percentile)/ (industry 10th percentile-industry 90th percentile)
- The final score of the application is the sum of the scores of each indicator multiplied by the corresponding weights.
-
Click Save the settings the button when you are finished for the configuration to take effect.
Request settings
In the Request settings page, the user can make the following settings:
-
Adds a key request, adding an alias to the specified URL.
-
The requests are grouped to build a hierarchy.
-
Add custom aggregation rules for app requests.
-
Acquisition request parameters.
-
Set the black and white list for the request.
-
Set the request error filter condition.
Click Save all settings the button when you are finished for the configuration to take effect.
Key request settings
The key request setting switch is off by default.
Click the Add a key request button, enter the full URL and request alias, and click Confirm to add a key request. Alias can be input up to 128 characters, Chinese and English characters are supported, and special characters are not supported.
In the drop-down menu in front of the search box, you can toggle between searching by URL and searching by Alias key requests.
Click the button in the upper right corner Add in bulk to batch enter URLs and aliases through the CSV template. When uploading files, the size of a single file cannot exceed 500KB and the format must be CSV.
Key request list data can be exported locally by clicking the button in the upper right corner Export the list.
Critical requests can be deleted in bulk by checking the box in front of multiple critical requests and then clicking the button in the upper right corner Mass delete.
Request grouping settings
The request grouping setting switch is off by default.
Click Add a key grouping the button to enter the group name. The maximum number of characters that can be entered is 128. Chinese and English characters are supported, and special characters are not supported.
When selecting Specify the URL, expand the host selection request in the list on the left, or directly check the check box in front of the host to select all requests under the host, and click the right triangle icon in the middle to add to the list on the right. The request list only displays the interface, not the aggregated URI, such as:/*.jpg, and displays the URL of the throughput Top 2000 in the last seven days by default.
If the request you want to add to the group cannot be found in the specified URL, it can be added by "wildcard matching". The configuration method is as follows:
-
Select Wildcard matches.
-
Fill in the rule in the Wildcard Rule input box. For an introduction to wildcards, see the description of the product interface.
-
Enter the URL to be matched based on the wildcard in Text to be matched.
-
In the "Matching Result", it will automatically verify whether the "Text to be matched" can be matched normally according to the "Wildcard Rule".
-
Click Confirm to save the grouping.
Request aggregation settings
Custom request aggregation rules (such as interfaces carrying specific URL parameters) Request aggregation settings can be added, and corresponding URL parameters can be added for interfaces. The system uses a general aggregation rule by default when aggregating for page URL, path, and request URL. In addition to regular aggregations, you can use custom aggregation rules. The request aggregation setting switch is off by default.
A custom aggregation rule works as follows:
-
The default aggregated URLs can be split according to business requirements.
-
The default split URLs can be combined according to business requirements.
-
The parameters of the request header/request body that can be given to the URL are split according to the business requirements.
How to use:
-
Click Add a request rule the button, enter the URL or path of the aggregation rule to be adjusted in the URL input box, and click Identification.
-
The system will automatically split the URL or path into hostname, path, and parameters, and will generate several aggregatable methods for selection. At the same time, you can modify the rules for the second time in the text box. After modification, you can view the final aggregation results below.
- Hostname: The protocol header is ignored by default and can be modified.
- Path: If there is a random number in the path, the platform will automatically replace the random number with "*", which can be modified.
- Click Confirm to save.
Select a domain name in "Network Request -- > Request Analysis" to view the request list, and the platform will splice the configured URL parameters behind the URI, as shown in the following figure:
Black and white list settings
Blacklist settings You can control to collect only the URL request data that meets the conditions. There are three types of filtering, which are No filtration, Whitelist filtering, and Blacklist filtering. The default is no filtering.
-
Set up instructions
- No filtering: The SDK collects all URL request data.
- Whitelist filtering: The SDK only collects URL request data in the whitelist.
- Blacklist filtering: The SDK will collect all URL requests except those in the blacklist.
-
Configure the rules
- You can enter a normal URL or a regular expression. The regular expression should A forward slash start with and end with. For example, to filter the domain names of QQ. Com, configure/. \ *qq.com*/.
Request error filtering
After the Request error filtering switch is turned on, the qualified error data will not be recorded, including the number of errors, error tracking information, etc., and the default is off.
Click Add IP settings the button to configure the URL and error response code to filter. You can enter a normal URL or a regular expression that begins and ends with A forward slash. For example, to filter the domain name of the QQ. Com, configure /.*qq.com*/
the.
Click Save the settings the button when you are finished for the configuration to take effect.
Exception analysis settings
Exception status setting
Exceptions (including crashes, stutters, and custom errors) can be "Ignored", "Fixed", or "Ignored or Fixed". You can select whether the exception is included in the exception statistics and exception list according to your own needs.
Exception indicator settings
Users can change the algorithm and unit of "crash rate", "OOM rate" and "stutter rate" of the platform according to business needs. By default, the function switch is turned off. The default algorithm of crash rate and OOM rate is "number of occurrences/number of activations", and the unit is percentage. The default algorithm of stutter rate is "number of stutters/number of activations", and the unit is percentage. Users can make changes according to their statistical needs.
Abnormal device filtering
When abnormal device filtering is enabled, the platform no longer displays abnormal data uploaded by "Jailbreak/ROOT" devices, including crashes, stutters, and OOM. The function switch is off by default. Users can also close the abnormal data collection on the jailbroken device by calling the interface. For details, please refer to the Filtering abnormal data collection of jailbreak device interface in the SDK interface description document.
Custom dimensions
First, upload the custom dimension through the SDK API configuration custom information, and then set the dimension whitelist to filter the custom dimension in the App exception analysis custom error and indicator query.
Notice Using the generic configuration will override the current application configuration.
Link Tracking
Link Tracking Vendor Configuration
The Tingyun SDK provides you with a comprehensive set of link tracking tools for App, Web and MP, aiming to help developers and operation and maintenance teams deeply understand and optimize application performance. The following are the main features of our SDK:
-
Automatic Trace ID generation: After integrating our SDK, your application will automatically generate Trace IDs compatible with different vendors, simplifying the complexity of link tracking.
-
Flexible control switches: We support the tracking IDs of three vendors, TingYun, Opentelemetry and SkyWalking. You can easily turn on or off the tracking function of a specific vendor through a simple configuration switch.
-
End-to-end jump support: For Opentelemetry and SkyWalking, we provide backend link address configuration options to ensure seamless end-to-end tracking jumps.
Customized link tracking configuration
The TingYun SDK provides flexible link tracking ID configuration options, adapting to App, Web and MP to meet the needs of different business scenarios:
-
Customized tracking ID: You can automatically generate the corresponding TraceID according to the configured URL to achieve a close integration of business logic and tracking data.
-
Display and viewing:
-
- In the TraceID section of slow requests, you can view the tracking ID of a specific request to help quickly locate and analyze performance issues.
-
In the Distributed Traces of the session details, you can view the distributed tracking information of the entire session to understand the flow of requests between different services.
-
Easy to integrate: The SDK configuration is simple and intuitive, and personalized link tracking can be achieved without complex code modifications.
Resource Monitoring
Energy Consumption Settings
You can define the exception type by configuring the number of "Get Location Duration, AlarmManager Settings, WakeLock Wake-up Duration". When the threshold is exceeded, it is considered as a power consumption exception.
CPU Settings
When the application's CPU usage rate exceeds the threshold, the SDK will record it as a CPU exception; when a CPU exception occurs, the SDK will collect the thread stack that exceeds the thread CPU usage threshold.
- CPU usage rate threshold: If the CPU usage rate of the application process in the foreground exceeds the threshold, it will be identified as abnormal; default threshold: 3, minimum value is 1, maximum value is 16
- Thread CPU usage rate threshold: If the CPU usage rate of the thread exceeds the threshold, it will be identified as abnormal; default threshold: 0.05, minimum value is 0.01, maximum value is 1