All Products
Search
Document Center

Serverless App Engine:Application overview

Last Updated:May 30, 2025

After enabling Application Monitoring for Serverless App Engine (SAE) Professional, Application Real-Time Monitoring Service (ARMS) starts monitoring the applications. On the Application Monitoring page, you can view metrics such as the number of requests, errors and instances, as well as average duration.

Dashboard overview

After Application Monitoring is enabled, a dashboard is generated on the Application Monitoring page, displaying real-time data of four metrics, Requests, Number of Errors, Average Duration, and Number of Instances.

Dhm1tLlluV

Section

Visualization style

Description

Requests

Ticker board

Displays the total number of requests of the application in the specified time period.

Day On Day: the percentage of increase or decrease in the number of requests in the specified time period of the current day with the number of requests in the same time period of the previous day.

Number of errors

Ticker board

Displays the total number of errors during the specified time period.

Day On Day: the percentage of increase or decrease in the number of errors in the specified time period of the current day with the number of errors in the same time period of the previous day.

Average Duration

Ticker board

Displays the average time consumed for the application in the specified time period.

Day On Day: the percentage of increase or decrease in the average time consumed for the application in the specified time period of the current day with the average time consumed in the same time period of the previous day.

Number of instances

Ticker board

Displays the total number of instances in the specified time period.

Day On Day: the percentage of increase or decrease in the number of instances in the specified time period of the current day with the number of instances in the same time period of the previous day.

Requests

Column chart

Shows the trends in the number of requests in the specified time period. The columns with different call types are stacked on top of each other.

Errors

Column chart with a trend line

Errors: uses a column chart to show the trends in the number of errors in the specified time period. The left y-axis represents the number of errors.

Error Rate: adds a trend line to the column chart to show the trends in the error rates in the specified time period. The right y-axis represents the error rates.

Duration

Trend chart

Shows the trends in the time consumed for the application in the specified time period. Supported values: average time consumed, 99th percentile of the time consumed, 90th percentile of the time consumed, and 75th percentile of the time consumed.

Peak CPU usage

Honeycomb

Shows the peak CPU utilization of the hosts in the specified time period.

Colors:

  • Green: the CPU utilization is normal.

  • Yellow: the CPU utilization exceed 60%.

  • Red: the CPU utilization exceeds 70%.

Provided Service Ranking of Requests

Top 5

Displays five services provided by the application with the most interface requests in the specified time period.

Call types:

  • HTTP

  • Dubbo

  • HSF

  • DSF

  • user_method

  • MQ

  • Kafka

  • Server

  • Producer

  • gRPC

  • Thrift

  • Sofa

  • Schedulerx

  • Spring_Scheduled

  • JDK_Timer

  • XXL_Job

  • Quartz

Provided Service Ranking of Errors

Top 5

Displays five services provided by the application with the most interface errors in the specified time period.

Call types:

  • HTTP

  • Dubbo

  • HSF

  • DSF

  • user_method

  • MQ

  • Kafka

  • Server

  • Producer

  • gRPC

  • Thrift

  • Sofa

  • Schedulerx

  • Spring_Scheduled

  • JDK_Timer

  • XXL_Job

  • Quartz

Provided Service Ranking of Average Duration

Top 5

Displays five services provided by the application with the most time consumed in the specified time period.

Call types:

  • HTTP

  • Dubbo

  • HSF

  • DSF

  • user_method

  • MQ

  • Kafka

  • Server

  • Producer

  • gRPC

  • Thrift

  • Sofa

  • Schedulerx

  • Spring_Scheduled

  • JDK_Timer

  • XXL_Job

  • Quartz

Peak CPU Usage Instance Ranking

Top 5

Displays five hosts with the highest CPU utilization in the specified time period.

Panels

Actions

Click image above the trend chart to compare data by group and time.

image

  • Comparison by group: The options for Groups are Basic fields and Instance tag.

    image

    • Basic fields: The tags shared by all metrics, which specify the server IP address for group comparison.

    • Instance tag: In addition to the default instance tags, you can also customize instance tags to enhance the comparison capabilities based on groups. For more information, see Add and use tags.

  • Comparison by time: Specify the time range for comparison.

Query statements

Click image above a section to view its Prometheus Query Language (PromQL) statements. In Managed Service for Prometheus or Managed Service for Grafana, customize the settings using the obtained PromQL statements.

image

  • In Managed Service for Prometheus, run the PromQL statements to view the metrics on the Metrics Explorer page.

  • Managed Service for Grafana lets you configure dashboards using PromQL statements. To do this, first integrate data sources.

FAQs

Why is the 99th percentile data not displayed?

By default, the percentile metrics are disabled. To view percentile data, enable the percentile statistics feature on the Custom Configurations page. For more information, see Customize settings for a Java application.

Why is the total number of requests on the Overview page in the old console inconsistent with the actual data from the last 5 minutes?

The data displayed on the Overview page in the old ARMS console includes data from one minute prior to the selected time range. If you select a time range of 5 minutes, data of the last 6 minutes is displayed. If you select a time range of 30 minutes, data of the last 31 minutes is displayed.

Why is the number of slow SQL statements on the Overview page in the old console inconsistent with the number queried using the POP API?

When the POP API is used to query slow SQL statements, it retrieves slow requests related to the databases supported by ARMS, the NoSQL database, and caches. However, the ARMS console queries only slow requests related to the databases supported by ARMS, resulting in the discrepancy.

To ensure that the data queried by the POP API is consistent with the data displayed on the Overview page in the old ARMS console, you can add filter conditions for rpcType to the queries.

Sample code:

QueryMetricByPageRequest.Filters filters2 = QueryMetricByPageRequest
.Filters
.builder() 
.key("rpcType") 
.value("60|62|63|65|66|67|68|69|58|59") 
.build();

Why is the number of queried instances greater than the number of running instances?

If the query takes a long time, the destroyed instances are also included in the total count of instances.

Why is the total number of requests on the Overview page in the new console inconsistent with that in the old console?

The Overview page in the new console includes data of scheduled tasks. By contrast, the Overview page in the old console does not include such data.