tencent cloud

Elastic MapReduce

Release Notes and Announcements
Release Notes
Announcements
Security Announcements
Product Introduction
Overview
Strengths
Architecture
Features
Use Cases
Constraints and Limits
Technical Support Scope
Product release
Purchase Guide
EMR on CVM Billing Instructions
EMR on TKE Billing Instructions
EMR Serverless HBase Billing Instructions
Getting Started
EMR on CVM Quick Start
EMR on TKE Quick Start
EMR on CVM Operation Guide
Planning Cluster
Administrative rights
Configuring Cluster
Managing Cluster
Managing Service
Monitoring and Alarms
TCInsight
EMR on TKE Operation Guide
Introduction to EMR on TKE
Configuring Cluster
Cluster Management
Service Management
Monitoring and Ops
Application Analysis
EMR Serverless HBase Operation Guide
EMR Serverless HBase Product Introduction
Quotas and Limits
Planning an Instance
Managing an Instance
Monitoring and Alarms
Development Guide
EMR Development Guide
Hadoop Development Guide
Spark Development Guide
Hbase Development Guide
Phoenix on Hbase Development Guide
Hive Development Guide
Presto Development Guide
Sqoop Development Guide
Hue Development Guide
Oozie Development Guide
Flume Development Guide
Kerberos Development Guide
Knox Development Guide
Alluxio Development Guide
Kylin Development Guide
Livy Development Guide
Kyuubi Development Guide
Zeppelin Development Guide
Hudi Development Guide
Superset Development Guide
Impala Development Guide
Druid Development Guide
TensorFlow Development Guide
Kudu Development Guide
Ranger Development Guide
Kafka Development Guide
Iceberg Development Guide
StarRocks Development Guide
Flink Development Guide
JupyterLab Development Guide
MLflow Development Guide
Practical Tutorial
Practice of EMR on CVM Ops
Data Migration
Practical Tutorial on Custom Scaling
API Documentation
History
Introduction
API Category
Cluster Resource Management APIs
Cluster Services APIs
User Management APIs
Data Inquiry APIs
Scaling APIs
Configuration APIs
Other APIs
Serverless HBase APIs
YARN Resource Scheduling APIs
Making API Requests
Data Types
Error Codes
FAQs
EMR on CVM
Service Level Agreement
Contact Us

Viewing Scaling Records

PDF
Mode fokus
Ukuran font
Terakhir diperbarui: 2026-03-20 17:34:03
The records of auto scaling actions can be viewed in Scaling history. Grading of auto scaling events is supported, and event alarm policies are set based on the event level. For more information about event levels, see Cluster Events. For more information about event alarm configuration, see Alarm Configurations.

Custom Scaling Records

Supports filtering the scaling records by execution time range and searching by policy name.
By default, untriggered rules are not displayed. To view all scaling records, you can disable Show Only Triggered Rules.
Sorts by Execution time, and displays Execution time, Policy name, Scaling type, and Execution status. You can click Details in the Operation column to view details.
There are four auto scaling execution statuses
Not triggered: The condition for auto scaling (scale-out/scale-in) is not met; the rule is not triggered.
Retrying: If auto scaling cannot execute at the specified time due to various reasons, the system will retry within the set time range.
In progress: The auto scaling activity is being executed.
Successful: According to the scaling rule, all target numbers of nodes are successfully added to or removed from the cluster.
Partially successful: According to the scaling rule, some nodes are successfully added to or removed from the cluster, while others fail due to disk quota management or CVM inventory.
Failed: According to the scaling rule, no nodes were added to or removed from the cluster.

Scaling Group Scaling Records

You can filter scaling records by execution time period and search for them by policy name.
By default, untriggered rules are not displayed. To view all scaling records, you can disable Show Only Triggered Rules.
The list displays the execution time, scaling group name, policy name, scaling type, and execution status. You can sort by execution time and filter by scaling type and execution status. You can click Details under the operation type to view detailed information, or click Analyze to view policy execution details, primarily used for troubleshooting failure reasons.
The execution status of auto scaling includes the following 6 types:
Not triggered: The condition for auto scaling (scale-out/scale-in) is not met; the rule is not triggered.
Retrying: If auto scaling cannot execute at the specified time due to various reasons, the system will retry within the set time range.
In progress: The auto scaling activity is being executed.
Successful: According to the scaling rule, all target numbers of nodes are successfully added to or removed from the cluster.
Partially successful: According to the scaling rule, some nodes are successfully added to or removed from the cluster, while others fail due to disk quota management or CVM inventory.
Failed: According to the scaling rule, no nodes were added to or removed from the cluster.

Managed scaling records

Supports filtering the scaling records by Execution Time or Scaling Type.
The list displays the execution time, scaling type, model specifications, quantity, execution status, and reason. You can sort by execution time and filter by scaling type and execution status.
The execution status of managed scaling includes the following 2 types:
Successful: The target node is added to or removed from the cluster based on the cluster load.
Failed: The target node failed to be added to the cluster based on the cluster load due to resource insufficiency. We recommend you modify the preset resource specification.
Model Specification: The target model specification and type after the rule is triggered for a scale-out or scale-in.
Quantity: The number of added or removed nodes in various specifications after the operation.

Bantuan dan Dukungan

Apakah halaman ini membantu?

masukan