tencent cloud

Tencent Cloud Observability Platform

Quick Integration

Download
Focus Mode
Font Size
Last updated: 2026-05-25 18:01:55
This article helps you quickly integrate the Terminal Performance Monitoring Pro (RUM Pro) SDK and use and verify the data reporting feature.

Creating an Application

1. Log in to the RUM Pro console and go to the Application List page.
2. On the Application List page, click Create Application and select the business system as required. If you do not have a business system, click Create a new business system, enter the information, and create one on the Business System List page.

3. After the application is created successfully, you can see the AppID and AppKey assigned by the platform, which serve as the product credentials on the platform.


Purchasing a Resource Package

After you create an application in RUM Pro, you need to purchase and bind a resource package to use the application to report data. For more information about resource packages, see Billing Overview. If the application does not have a bound and active resource package, or if the bound resource package has been used up, the application cannot report data.
1. Go to the Resource Management page, choose Resource Package, and click Purchase Resource Package. For more information about resource packages, see Billing Overview.

2. After the purchase is complete, click Bind in the Operation column to bind the application.


Integrating the SDK

After the application is created successfully, you can refer to the Android SDK Integration Guide, iOS SDK Integration Guide, HarmonyOS SDK Integration Guide, Windows SDK Integration Guide, Flutter SDK Integration Guide, and Electron SDK Integration Guide to integrate the RUM Pro SDK into your application.

Checking the Reporting Feature

After the RUM Pro SDK is integrated into the application according to the guide, you can simulate or trigger relevant events to check the reporting process. RUM Pro supports features such as crash monitoring, ANR monitoring, OOM monitoring, error monitoring, and performance monitoring (startup monitoring, lag monitoring, and memory monitoring).
Different monitoring features are different in their data reporting logic. For abnormal termination monitoring, reporting is enabled globally by default. After the SDK captures an exception, it is reported immediately or upon the next application startup. For performance monitoring, sampling is enabled by default. You can create configuration tasks and select appropriate sampling rates based on your needs.

Crash Monitoring

Crash monitoring is enabled globally by default and does not support sampling. You can simulate a crash, restart the application after the crash occurs, and check whether the Crash/Issue List contains the reported data.
Android sample code:
public void testNPECrash() {
String value = null;
System.out.println("Length of str is: " + value.length());
}
iOS sample code:
- (void)testNPECrash {
NSString *str = nil;
NSInteger length = [str length];
NSLog(@"Length of str is: %ld", length);
}

ANR Monitoring

Android ANR monitoring is enabled globally by default and does not support sampling. iOS ANR monitoring is enabled globally by default and supports sampling.
The following sample code simulates an ANR by executing a long-running task (such as sleeping for 20 seconds) on the UI thread. After the application is killed by the system due to unresponsiveness, restart the application and check whether the ANR/Issue List contains the reported data.
Android sample code:
public void testANR() {
try {
Thread.sleep(20000); // Simulates a time-consuming operation.
} catch (InterruptedException e) {
e.printStackTrace();
}
}
iOS sample code:
- (void)startLongRunningTask {
dispatch_async(dispatch_get_main_queue(), ^{
// Simulates a long-running task.
[NSThread sleepForTimeInterval:20.0];
});
}

OOM Monitoring

Android OOM monitoring is enabled globally by default and does not support sampling. iOS OOM monitoring is enabled globally by default and supports sampling.
The following sample code simulates an OOM scenario by continuously allocating memory without releasing it, ultimately causing the application to be killed by the system due to OOM. Restart the application and check whether the OOM/Issue List contains the reported data.
Android sample code:
public void simulateOOM() {
List<byte[]> list = new ArrayList<>();
while (true) {
byte[] bytes = new byte[1024 * 1024]; // Allocates 1 MB of memory.
list.add(bytes);
}
}
iOS sample code:
- (void)simulateFOOM {
NSMutableArray *array = [NSMutableArray array];
while (true) {
@autoreleasepool {
NSString *string = [NSString stringWithFormat:@"%d", arc4random_uniform(1000000)];
[array addObject:string];
}
}
}

Error Monitoring

Error monitoring is enabled globally by default and does not support sampling. The RUM Pro SDK provides a series of APIs that allow you to report custom exceptions and caught exceptions. These exceptions are referred to as errors.
After the application calls the error reporting API to report data, you can directly check whether the Error/Issue List contains the reported data without restarting the application.

Performance Monitoring

RUM Pro supports lag monitoring, startup monitoring, and memory monitoring. All these performance monitoring features support sampling, and sampling is disabled by default. You need to create configuration tasks in Settings/SDK Configuration to specify the sampling rate for each performance monitoring item.
1. For easier testing during the testing phase, it is recommended to create a dedicated allowlist testing task with all monitoring features set to 100% sampling, which means to set "sample_ratio" and "event_sample_ratio" to 1.
2. Configuration changes generally take 10 minutes to take effect. To ensure the configurations are applied, it is recommended to start the application 10 minutes after the configurations are modified, and then restart the application after a few minutes.
3. After application startup monitoring is enabled, the startup monitoring feature is automatically activated when the application starts. Startup data is reported after SDK initialization.
4. Lag and memory metrics are collected during runtime after monitoring is enabled, and the data is reported upon the next startup.
5. For lag and memory issue monitoring, after monitoring is enabled, when abnormal cases are detected, data is reported immediately if the device is connected to Wi-Fi. Otherwise, data is cached locally and reported upon the next application startup.


Viewing the Data

After the data is successfully reported, you can view the data in the RUM Pro console, as shown below:
1. The left sidebar contains the entry points for various monitoring features.
2. Each monitoring feature includes an overview, metric analysis, issue list, and issue details.


Exception Overview

The exception overview includes metric analysis data for quality monitoring such as crash, error, ANR, and OOM monitoring. It supports real-time data analysis, trend analysis, and exception distribution.


Metric Analysis

Metric analysis includes lag, memory, and startup analysis data. It supports trend analysis, comparative analysis, and multidimensional analysis for metrics.


Issue List

Both quality monitoring (such as crash, error, ANR, and OOM monitoring) and performance monitoring (such as lag, memory, and startup monitoring) have issue lists. After an exception is identified, the SDK collects on-device information and reports it to the server. After the server receives the data, the processing pipeline extracts the characteristics of each reported case, and aggregates cases with identical characteristics into issues. The issue list displays these issues and provides rich search capabilities to facilitate user analysis and queries.
Common steps for using the issue list:
1. Edit the search conditions based on analysis needs. You can also choose to display only frequently used search conditions and hide less frequent ones.
2. After you edit the search conditions, click Query to submit the search task.
3. After the search is complete, the page automatically refreshes to update the search results.
4. Click to view the details of an issue.


Issue Details

Issue details display the details of a specific issue. Typically, you use issue details to identify the root cause of the exception.
1. First, analyze the error stack. In the case details, select a specific case and analyze its error stack.
2. If the error stack is insufficient to define the issue, you may need to use logs, FD information, process infomation, or even information in attachment.

3. If you are still uncertain about why the issue occurs, you can use the drill-down analysis feature to analyze its reporting trends and distribution.




Help and Support

Was this page helpful?

Help us improve! Rate your documentation experience in 5 mins.

Feedback