@alicloud/ess20220222 1.10.1 → 1.10.3

package/dist/client.d.ts

@@ -255,7 +255,7 @@ export default class Client extends OpenApi {
      */
     attachLoadBalancers(request: $_model.AttachLoadBalancersRequest): Promise<$_model.AttachLoadBalancersResponse>;
     /**
-     * Attaches server groups to a scaling group. To seamlessly adjust the number of instances in response to changes in your business workload or to maintain the uninterrupted accessibility of your application, you can call the AttachServerGroups operation. By attaching Application Load Balancer (ALB) or Network Load Balancer (NLB) server groups to your scaling group, this operation enables Auto Scaling to automatically tailor your computing capacity to your business needs. Furthermore, it optimizes traffic routing by dynamically allocating incoming requests based on current workload patterns, which significantly improves the stability and performance of your application.
+     * Attaches server groups to a scaling group. To seamlessly adjust the number of instances in response to changes in your business workload or to maintain the uninterrupted accessibility of your application, you can call the AttachServerGroups operation. By attaching Application Load Balancer (ALB), Network Load Balancer (NLB), or Gateway Load Balancer (GWLB) server groups to your scaling group, this operation enables Auto Scaling to automatically tailor your computing capacity to your business needs. Furthermore, it optimizes traffic routing by dynamically allocating incoming requests based on current workload patterns, which significantly improves the stability and performance of your application.
      *
      * @param request - AttachServerGroupsRequest
      * @param runtime - runtime options for this request RuntimeOptions
@@ -263,7 +263,7 @@ export default class Client extends OpenApi {
      */
     attachServerGroupsWithOptions(request: $_model.AttachServerGroupsRequest, runtime: $dara.RuntimeOptions): Promise<$_model.AttachServerGroupsResponse>;
     /**
-     * Attaches server groups to a scaling group. To seamlessly adjust the number of instances in response to changes in your business workload or to maintain the uninterrupted accessibility of your application, you can call the AttachServerGroups operation. By attaching Application Load Balancer (ALB) or Network Load Balancer (NLB) server groups to your scaling group, this operation enables Auto Scaling to automatically tailor your computing capacity to your business needs. Furthermore, it optimizes traffic routing by dynamically allocating incoming requests based on current workload patterns, which significantly improves the stability and performance of your application.
+     * Attaches server groups to a scaling group. To seamlessly adjust the number of instances in response to changes in your business workload or to maintain the uninterrupted accessibility of your application, you can call the AttachServerGroups operation. By attaching Application Load Balancer (ALB), Network Load Balancer (NLB), or Gateway Load Balancer (GWLB) server groups to your scaling group, this operation enables Auto Scaling to automatically tailor your computing capacity to your business needs. Furthermore, it optimizes traffic routing by dynamically allocating incoming requests based on current workload patterns, which significantly improves the stability and performance of your application.
      *
      * @param request - AttachServerGroupsRequest
      * @returns AttachServerGroupsResponse
@@ -541,26 +541,26 @@ export default class Client extends OpenApi {
      * @remarks
      * A scaling group is a group of Elastic Compute Service (ECS) instances that can be used for similar purposes.
      * You can create only a limited number of scaling groups in a region. To check the quota of the scaling groups, go to Quota Center.
-     * A scaling group does not immediately take effect after you create the scaling group. You can call the [EnableScalingGroup](https://help.aliyun.com/document_detail/25939.html) operation to enable a scaling group. You can trigger scaling events and execute scaling rules only in scaling groups that are in the Enabled state.
+     * A scaling group does not immediately take effect after you create it. You can call the [EnableScalingGroup](https://help.aliyun.com/document_detail/25939.html) operation to enable a scaling group. You can trigger scaling events and execute scaling rules only in scaling groups that are in the Enabled state.
      * If you want to attach a Classic Load Balancer (CLB, formerly known as SLB) instance and an ApsaraDB RDS instance to the scaling group that you want to create, the scaling group, the CLB instance, and the ApsaraDB RDS instance must reside in the same region. For more information, see [Regions and zones](https://help.aliyun.com/document_detail/40654.html).
      * If you attach a CLB instance to the scaling group that you want to create, Auto Scaling automatically adds the ECS instances in the scaling group to the backend server groups of the CLB instance. You can specify the following types of server groups to add ECS instances:
      * *   Default server group: ECS instances in this group process frontend requests. If no listeners are configured for vServer groups or primary/secondary server groups, the frontend requests are forwarded to the ECS instances in the default server group.
      * *   vServer group: If you want to forward different requests to different backend servers, or you want to forward requests based on domain names or URLs, you can specify vServer groups.
-     * >  If you specify both the default server group and multiple server groups simultaneously, Auto Scaling adds the ECS instances in your scaling group to these server groups concurrently.
-     * The default weight of each ECS instance as a backend server is 50. If you want to attach a CLB instance to the scaling group that you want to create, make sure that the CLB instance meets the following requirements:
+     * >  If you specify both the default server group and multiple VServer groups, the ECS instances are added to these server groups.
+     * The default weight of each ECS instance as a backend server is 50. The CLB instance must meet the following requirements:
      * *   The CLB instance is in the Active state. You can call the [DescribeLoadBalancers](https://help.aliyun.com/document_detail/2401696.html) operation to query the status of CLB instances.
-     * *   Health check must be enabled on all listener ports configured for the CLB instance. Otherwise, the scaling group will fail to be created.
-     * If you attach Application Load Balancer (ALB) or Network Load Balancer (NLB) server groups to the scaling group that you want to create, Auto Scaling adds the ECS instances in your scaling group to the ALB or NLB server groups to process the access requests forwarded by the corresponding ALB or NLB instances. You can attach multiple ALB or NLB server groups to a scaling group. Make sure that the ALB or NLB server groups belong to the same virtual private cloud (VPC). For more information, see [AttachAlbServerGroups](https://help.aliyun.com/document_detail/266800.html) or [AttachServerGroups](https://help.aliyun.com/document_detail/600535.html).
-     * If you attach an ApsaraDB RDS instance to the scaling group that you want to create, Auto Scaling automatically adds the private IP addresses of the ECS instances in your scaling group to the IP address whitelist of the ApsaraDB RDS instance. Before you attach an ApsaraDB RDS instance to your scaling group, make sure that the ApsaraDB RDS instance meets the following requirements:
-     * *   The ApsaraDB RDS instance is in the Running state. You can call the [DescribeDBInstances](https://help.aliyun.com/document_detail/610396.html) state to query the status of ApsaraDB RDS instances.
-     * *   The number of IP addresses in the IP address whitelist of the ApsaraDB RDS instance does not reach its upper limit. For more information, see [Configure a whitelist](https://help.aliyun.com/document_detail/43185.html).
-     * If you set MultiAZPolicy for the scaling group that you want to create to COST_OPTIMIZED, the following rules apply:
-     * *   If you use OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, and SpotInstancePools to specify the instance allocation mode under the cost optimization policy, Auto Scaling prioritizes the implementation of the specified instance allocation mode during scale-out events.
+     * *   All listening ports configured for the CLB instance must be health check. Otherwise, the scaling group fails to be created.
+     * If you attach Application Load Balancer (ALB), Network Load Balancer (NLB), or Gateway Load Balancer (GWLB) server groups to the scaling group that you want to create, Auto Scaling adds the ECS instances in your scaling group to the ALB or NLB server groups to process the access requests forwarded by the corresponding ALB or NLB instances. You can specify multiple ALB, NLB, or GWLB server groups, but the server groups must belong to the same VPC as the scaling group. For more information, see [AttachAlbServerGroups](https://help.aliyun.com/document_detail/266800.html) or [AttachServerGroups](https://help.aliyun.com/document_detail/600535.html).
+     * If you associate an RDS instance with the scaling group, the scaling group will automatically add the internal IP addresses of ECS instances that join the scaling group to the access whitelist of the RDS instance. The RDS instance must meet the following requirements:
+     * *   The RDS instance must be in the Running state. You can call the [DescribeDBInstances](https://help.aliyun.com/document_detail/610396.html) operation to view the status of the specified RDS instance.
+     * *   The number of IPs in the RDS instance\\"s access whitelist cannot exceed the upper limit. For more information, see [Configure a whitelist](https://help.aliyun.com/document_detail/43185.html).
+     * If the MultiAZPolicy for the scaling group is set to COST_OPTIMIZED, the following rules apply:
+     * *   When you specify OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, and SpotInstancePools parameters (i.e., defining the instance allocation method under the cost optimization policy), Auto Scaling will prioritize this allocation method during scaling operations.
      * *   If you do not specify OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, or SpotInstancePools, Auto Scaling preferentially creates instances of the lowest-priced instance type based on the cost optimization policy.
      * If you set `Tags.Propagate` to true, the following rules will apply:
-     * *   Tags that you add to the scaling group cannot be propagated to existing instances in the scaling group. Tags that you add to the scaling group are propagated to only new instances.
-     * *   If you specify instance tags in the scaling configuration that is used to create instances and propagate the tags that you add to the scaling group to the instances, all tags exist at the same time.
-     * *   If the tag key that you specify in a scaling configuration and the tag key that you add to the scaling group of the scaling configuration are the same, the tag value that you specify in the scaling configuration is preferentially used.
+     * *   Tags added to the scaling group will only propagate to newly created instances and will not affect instances already running within the scaling group.
+     * *   If instance tags are specified in the scaling configuration and the scaling group’s tags are propagated to the instance, all tags will coexist.
+     * *   If the tag key specified in the scaling configuration matches a tag key in the scaling group, the tag value from the scaling configuration will take precedence.
      *
      * @param request - CreateScalingGroupRequest
      * @param runtime - runtime options for this request RuntimeOptions
@@ -573,26 +573,26 @@ export default class Client extends OpenApi {
      * @remarks
      * A scaling group is a group of Elastic Compute Service (ECS) instances that can be used for similar purposes.
      * You can create only a limited number of scaling groups in a region. To check the quota of the scaling groups, go to Quota Center.
-     * A scaling group does not immediately take effect after you create the scaling group. You can call the [EnableScalingGroup](https://help.aliyun.com/document_detail/25939.html) operation to enable a scaling group. You can trigger scaling events and execute scaling rules only in scaling groups that are in the Enabled state.
+     * A scaling group does not immediately take effect after you create it. You can call the [EnableScalingGroup](https://help.aliyun.com/document_detail/25939.html) operation to enable a scaling group. You can trigger scaling events and execute scaling rules only in scaling groups that are in the Enabled state.
      * If you want to attach a Classic Load Balancer (CLB, formerly known as SLB) instance and an ApsaraDB RDS instance to the scaling group that you want to create, the scaling group, the CLB instance, and the ApsaraDB RDS instance must reside in the same region. For more information, see [Regions and zones](https://help.aliyun.com/document_detail/40654.html).
      * If you attach a CLB instance to the scaling group that you want to create, Auto Scaling automatically adds the ECS instances in the scaling group to the backend server groups of the CLB instance. You can specify the following types of server groups to add ECS instances:
      * *   Default server group: ECS instances in this group process frontend requests. If no listeners are configured for vServer groups or primary/secondary server groups, the frontend requests are forwarded to the ECS instances in the default server group.
      * *   vServer group: If you want to forward different requests to different backend servers, or you want to forward requests based on domain names or URLs, you can specify vServer groups.
-     * >  If you specify both the default server group and multiple server groups simultaneously, Auto Scaling adds the ECS instances in your scaling group to these server groups concurrently.
-     * The default weight of each ECS instance as a backend server is 50. If you want to attach a CLB instance to the scaling group that you want to create, make sure that the CLB instance meets the following requirements:
+     * >  If you specify both the default server group and multiple VServer groups, the ECS instances are added to these server groups.
+     * The default weight of each ECS instance as a backend server is 50. The CLB instance must meet the following requirements:
      * *   The CLB instance is in the Active state. You can call the [DescribeLoadBalancers](https://help.aliyun.com/document_detail/2401696.html) operation to query the status of CLB instances.
-     * *   Health check must be enabled on all listener ports configured for the CLB instance. Otherwise, the scaling group will fail to be created.
-     * If you attach Application Load Balancer (ALB) or Network Load Balancer (NLB) server groups to the scaling group that you want to create, Auto Scaling adds the ECS instances in your scaling group to the ALB or NLB server groups to process the access requests forwarded by the corresponding ALB or NLB instances. You can attach multiple ALB or NLB server groups to a scaling group. Make sure that the ALB or NLB server groups belong to the same virtual private cloud (VPC). For more information, see [AttachAlbServerGroups](https://help.aliyun.com/document_detail/266800.html) or [AttachServerGroups](https://help.aliyun.com/document_detail/600535.html).
-     * If you attach an ApsaraDB RDS instance to the scaling group that you want to create, Auto Scaling automatically adds the private IP addresses of the ECS instances in your scaling group to the IP address whitelist of the ApsaraDB RDS instance. Before you attach an ApsaraDB RDS instance to your scaling group, make sure that the ApsaraDB RDS instance meets the following requirements:
-     * *   The ApsaraDB RDS instance is in the Running state. You can call the [DescribeDBInstances](https://help.aliyun.com/document_detail/610396.html) state to query the status of ApsaraDB RDS instances.
-     * *   The number of IP addresses in the IP address whitelist of the ApsaraDB RDS instance does not reach its upper limit. For more information, see [Configure a whitelist](https://help.aliyun.com/document_detail/43185.html).
-     * If you set MultiAZPolicy for the scaling group that you want to create to COST_OPTIMIZED, the following rules apply:
-     * *   If you use OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, and SpotInstancePools to specify the instance allocation mode under the cost optimization policy, Auto Scaling prioritizes the implementation of the specified instance allocation mode during scale-out events.
+     * *   All listening ports configured for the CLB instance must be health check. Otherwise, the scaling group fails to be created.
+     * If you attach Application Load Balancer (ALB), Network Load Balancer (NLB), or Gateway Load Balancer (GWLB) server groups to the scaling group that you want to create, Auto Scaling adds the ECS instances in your scaling group to the ALB or NLB server groups to process the access requests forwarded by the corresponding ALB or NLB instances. You can specify multiple ALB, NLB, or GWLB server groups, but the server groups must belong to the same VPC as the scaling group. For more information, see [AttachAlbServerGroups](https://help.aliyun.com/document_detail/266800.html) or [AttachServerGroups](https://help.aliyun.com/document_detail/600535.html).
+     * If you associate an RDS instance with the scaling group, the scaling group will automatically add the internal IP addresses of ECS instances that join the scaling group to the access whitelist of the RDS instance. The RDS instance must meet the following requirements:
+     * *   The RDS instance must be in the Running state. You can call the [DescribeDBInstances](https://help.aliyun.com/document_detail/610396.html) operation to view the status of the specified RDS instance.
+     * *   The number of IPs in the RDS instance\\"s access whitelist cannot exceed the upper limit. For more information, see [Configure a whitelist](https://help.aliyun.com/document_detail/43185.html).
+     * If the MultiAZPolicy for the scaling group is set to COST_OPTIMIZED, the following rules apply:
+     * *   When you specify OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, and SpotInstancePools parameters (i.e., defining the instance allocation method under the cost optimization policy), Auto Scaling will prioritize this allocation method during scaling operations.
      * *   If you do not specify OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, or SpotInstancePools, Auto Scaling preferentially creates instances of the lowest-priced instance type based on the cost optimization policy.
      * If you set `Tags.Propagate` to true, the following rules will apply:
-     * *   Tags that you add to the scaling group cannot be propagated to existing instances in the scaling group. Tags that you add to the scaling group are propagated to only new instances.
-     * *   If you specify instance tags in the scaling configuration that is used to create instances and propagate the tags that you add to the scaling group to the instances, all tags exist at the same time.
-     * *   If the tag key that you specify in a scaling configuration and the tag key that you add to the scaling group of the scaling configuration are the same, the tag value that you specify in the scaling configuration is preferentially used.
+     * *   Tags added to the scaling group will only propagate to newly created instances and will not affect instances already running within the scaling group.
+     * *   If instance tags are specified in the scaling configuration and the scaling group’s tags are propagated to the instance, all tags will coexist.
+     * *   If the tag key specified in the scaling configuration matches a tag key in the scaling group, the tag value from the scaling configuration will take precedence.
      *
      * @param request - CreateScalingGroupRequest
      * @returns CreateScalingGroupResponse
@@ -715,7 +715,7 @@ export default class Client extends OpenApi {
      */
     deleteAlarm(request: $_model.DeleteAlarmRequest): Promise<$_model.DeleteAlarmResponse>;
     /**
-     * DeleteDiagnoseReport
+     * Deletes a health diagnosis report for a scaling group.
      *
      * @param request - DeleteDiagnoseReportRequest
      * @param runtime - runtime options for this request RuntimeOptions
@@ -723,7 +723,7 @@ export default class Client extends OpenApi {
      */
     deleteDiagnoseReportWithOptions(request: $_model.DeleteDiagnoseReportRequest, runtime: $dara.RuntimeOptions): Promise<$_model.DeleteDiagnoseReportResponse>;
     /**
-     * DeleteDiagnoseReport
+     * Deletes a health diagnosis report for a scaling group.
      *
      * @param request - DeleteDiagnoseReportRequest
      * @returns DeleteDiagnoseReportResponse
@@ -979,12 +979,16 @@ export default class Client extends OpenApi {
      */
     describeElasticStrength(request: $_model.DescribeElasticStrengthRequest): Promise<$_model.DescribeElasticStrengthResponse>;
     /**
+     * Instance creation and deletion statistics.
+     *
      * @param request - DescribeInstanceCreateAndDeleteStatisticsRequest
      * @param runtime - runtime options for this request RuntimeOptions
      * @returns DescribeInstanceCreateAndDeleteStatisticsResponse
      */
     describeInstanceCreateAndDeleteStatisticsWithOptions(request: $_model.DescribeInstanceCreateAndDeleteStatisticsRequest, runtime: $dara.RuntimeOptions): Promise<$_model.DescribeInstanceCreateAndDeleteStatisticsResponse>;
     /**
+     * Instance creation and deletion statistics.
+     *
      * @param request - DescribeInstanceCreateAndDeleteStatisticsRequest
      * @returns DescribeInstanceCreateAndDeleteStatisticsResponse
      */
@@ -1176,12 +1180,16 @@ export default class Client extends OpenApi {
      */
     describeScalingActivityDetail(request: $_model.DescribeScalingActivityDetailRequest): Promise<$_model.DescribeScalingActivityDetailResponse>;
     /**
+     * The distribution of scaling activities in different states over a period of time.
+     *
      * @param request - DescribeScalingActivityStatisticsRequest
      * @param runtime - runtime options for this request RuntimeOptions
      * @returns DescribeScalingActivityStatisticsResponse
      */
     describeScalingActivityStatisticsWithOptions(request: $_model.DescribeScalingActivityStatisticsRequest, runtime: $dara.RuntimeOptions): Promise<$_model.DescribeScalingActivityStatisticsResponse>;
     /**
+     * The distribution of scaling activities in different states over a period of time.
+     *
      * @param request - DescribeScalingActivityStatisticsRequest
      * @returns DescribeScalingActivityStatisticsResponse
      */
@@ -1388,7 +1396,7 @@ export default class Client extends OpenApi {
      */
     detachLoadBalancers(request: $_model.DetachLoadBalancersRequest): Promise<$_model.DetachLoadBalancersResponse>;
     /**
-     * Detach server groups from a scaling group. To seamlessly adjust the number of instances in response to changes in your business workload or to maintain the uninterrupted accessibility of your application, you can call the DetachServerGroups operation. By detaching Application Load Balancer (ALB) or Network Load Balancer (NLB) server groups from your scaling group, this operation enables Auto Scaling to automatically tailor your computing capacity to your business needs. Furthermore, it optimizes traffic routing by dynamically allocating incoming requests based on current workload patterns, which significantly improves the stability and performance of your application.
+     * Remove one or more SLB server groups from a scaling group. Supported server group types include Application Load Balancer (ALB), Network Load Balancer (NLB), and Gateway Load Balancer (GWLB), which can dynamically adjust SLB policies and help improve high availability of the system.
      *
      * @param request - DetachServerGroupsRequest
      * @param runtime - runtime options for this request RuntimeOptions
@@ -1396,7 +1404,7 @@ export default class Client extends OpenApi {
      */
     detachServerGroupsWithOptions(request: $_model.DetachServerGroupsRequest, runtime: $dara.RuntimeOptions): Promise<$_model.DetachServerGroupsResponse>;
     /**
-     * Detach server groups from a scaling group. To seamlessly adjust the number of instances in response to changes in your business workload or to maintain the uninterrupted accessibility of your application, you can call the DetachServerGroups operation. By detaching Application Load Balancer (ALB) or Network Load Balancer (NLB) server groups from your scaling group, this operation enables Auto Scaling to automatically tailor your computing capacity to your business needs. Furthermore, it optimizes traffic routing by dynamically allocating incoming requests based on current workload patterns, which significantly improves the stability and performance of your application.
+     * Remove one or more SLB server groups from a scaling group. Supported server group types include Application Load Balancer (ALB), Network Load Balancer (NLB), and Gateway Load Balancer (GWLB), which can dynamically adjust SLB policies and help improve high availability of the system.
      *
      * @param request - DetachServerGroupsRequest
      * @returns DetachServerGroupsResponse
@@ -1908,45 +1916,61 @@ export default class Client extends OpenApi {
      */
     modifyScheduledTask(request: $_model.ModifyScheduledTaskRequest): Promise<$_model.ModifyScheduledTaskResponse>;
     /**
+     * Queries the historical monitoring data of a scaling group that uses predictive scaling rules.
+     *
      * @param request - QueryHistoricalMetricRequest
      * @param runtime - runtime options for this request RuntimeOptions
      * @returns QueryHistoricalMetricResponse
      */
     queryHistoricalMetricWithOptions(request: $_model.QueryHistoricalMetricRequest, runtime: $dara.RuntimeOptions): Promise<$_model.QueryHistoricalMetricResponse>;
     /**
+     * Queries the historical monitoring data of a scaling group that uses predictive scaling rules.
+     *
      * @param request - QueryHistoricalMetricRequest
      * @returns QueryHistoricalMetricResponse
      */
     queryHistoricalMetric(request: $_model.QueryHistoricalMetricRequest): Promise<$_model.QueryHistoricalMetricResponse>;
     /**
+     * Queries predicted monitoring data.
+     *
      * @param request - QueryPredictiveMetricRequest
      * @param runtime - runtime options for this request RuntimeOptions
      * @returns QueryPredictiveMetricResponse
      */
     queryPredictiveMetricWithOptions(request: $_model.QueryPredictiveMetricRequest, runtime: $dara.RuntimeOptions): Promise<$_model.QueryPredictiveMetricResponse>;
     /**
+     * Queries predicted monitoring data.
+     *
      * @param request - QueryPredictiveMetricRequest
      * @returns QueryPredictiveMetricResponse
      */
     queryPredictiveMetric(request: $_model.QueryPredictiveMetricRequest): Promise<$_model.QueryPredictiveMetricResponse>;
     /**
+     * Queries the information about a prediction task.
+     *
      * @param request - QueryPredictiveTaskInfoRequest
      * @param runtime - runtime options for this request RuntimeOptions
      * @returns QueryPredictiveTaskInfoResponse
      */
     queryPredictiveTaskInfoWithOptions(request: $_model.QueryPredictiveTaskInfoRequest, runtime: $dara.RuntimeOptions): Promise<$_model.QueryPredictiveTaskInfoResponse>;
     /**
+     * Queries the information about a prediction task.
+     *
      * @param request - QueryPredictiveTaskInfoRequest
      * @returns QueryPredictiveTaskInfoResponse
      */
     queryPredictiveTaskInfo(request: $_model.QueryPredictiveTaskInfoRequest): Promise<$_model.QueryPredictiveTaskInfoResponse>;
     /**
+     * Queries the predicted number of instances in a scaling group.
+     *
      * @param request - QueryPredictiveValueRequest
      * @param runtime - runtime options for this request RuntimeOptions
      * @returns QueryPredictiveValueResponse
      */
     queryPredictiveValueWithOptions(request: $_model.QueryPredictiveValueRequest, runtime: $dara.RuntimeOptions): Promise<$_model.QueryPredictiveValueResponse>;
     /**
+     * Queries the predicted number of instances in a scaling group.
+     *
      * @param request - QueryPredictiveValueRequest
      * @returns QueryPredictiveValueResponse
      */
@@ -2136,7 +2160,7 @@ export default class Client extends OpenApi {
      */
     setGroupDeletionProtection(request: $_model.SetGroupDeletionProtectionRequest): Promise<$_model.SetGroupDeletionProtectionResponse>;
     /**
-     * Sets instance health. At times, the automatic health check system might not sufficiently determine the precise health status of your Elastic Compute Service (ECS) instances or elastic container instances. To overcome this, you can call the SetInstanceHealth operation to swiftly pinpoint problematic instances and resolve issues. This operation is designed to more precisely align with real-world business requirements and tackle O\\&M hurdles efficiently.
+     * Sets instance health. At times, the automatic health check system might not sufficiently determine the precise health status of your Elastic Compute Service (ECS) instances or elastic container instances. To overcome this, you can call the SetInstanceHealth operation to swiftly pinpoint problematic instances and resolve issues. This operation is designed to more precisely align with real-world business requirements and tackle O\\\\\\&M hurdles efficiently.
      *
      * @remarks
      * Auto Scaling detects and removes unhealthy ECS instances or elastic container instances from their scaling groups. To prevent a specific instance from being removed, you can put it in either the Standby or Protected state. For more information, see [EnterStandby](https://help.aliyun.com/document_detail/459345.html) and [SetInstancesProtection](https://help.aliyun.com/document_detail/459342.html).
@@ -2147,7 +2171,7 @@ export default class Client extends OpenApi {
      */
     setInstanceHealthWithOptions(request: $_model.SetInstanceHealthRequest, runtime: $dara.RuntimeOptions): Promise<$_model.SetInstanceHealthResponse>;
     /**
-     * Sets instance health. At times, the automatic health check system might not sufficiently determine the precise health status of your Elastic Compute Service (ECS) instances or elastic container instances. To overcome this, you can call the SetInstanceHealth operation to swiftly pinpoint problematic instances and resolve issues. This operation is designed to more precisely align with real-world business requirements and tackle O\\&M hurdles efficiently.
+     * Sets instance health. At times, the automatic health check system might not sufficiently determine the precise health status of your Elastic Compute Service (ECS) instances or elastic container instances. To overcome this, you can call the SetInstanceHealth operation to swiftly pinpoint problematic instances and resolve issues. This operation is designed to more precisely align with real-world business requirements and tackle O\\\\\\&M hurdles efficiently.
      *
      * @remarks
      * Auto Scaling detects and removes unhealthy ECS instances or elastic container instances from their scaling groups. To prevent a specific instance from being removed, you can put it in either the Standby or Protected state. For more information, see [EnterStandby](https://help.aliyun.com/document_detail/459345.html) and [SetInstancesProtection](https://help.aliyun.com/document_detail/459342.html).

package/dist/client.js

@@ -612,7 +612,7 @@ class Client extends openapi_core_1.default {
         return await this.attachLoadBalancersWithOptions(request, runtime);
     }
     /**
-     * Attaches server groups to a scaling group. To seamlessly adjust the number of instances in response to changes in your business workload or to maintain the uninterrupted accessibility of your application, you can call the AttachServerGroups operation. By attaching Application Load Balancer (ALB) or Network Load Balancer (NLB) server groups to your scaling group, this operation enables Auto Scaling to automatically tailor your computing capacity to your business needs. Furthermore, it optimizes traffic routing by dynamically allocating incoming requests based on current workload patterns, which significantly improves the stability and performance of your application.
+     * Attaches server groups to a scaling group. To seamlessly adjust the number of instances in response to changes in your business workload or to maintain the uninterrupted accessibility of your application, you can call the AttachServerGroups operation. By attaching Application Load Balancer (ALB), Network Load Balancer (NLB), or Gateway Load Balancer (GWLB) server groups to your scaling group, this operation enables Auto Scaling to automatically tailor your computing capacity to your business needs. Furthermore, it optimizes traffic routing by dynamically allocating incoming requests based on current workload patterns, which significantly improves the stability and performance of your application.
      *
      * @param request - AttachServerGroupsRequest
      * @param runtime - runtime options for this request RuntimeOptions
@@ -659,7 +659,7 @@ class Client extends openapi_core_1.default {
         return $dara.cast(await this.callApi(params, req, runtime), new $_model.AttachServerGroupsResponse({}));
     }
     /**
-     * Attaches server groups to a scaling group. To seamlessly adjust the number of instances in response to changes in your business workload or to maintain the uninterrupted accessibility of your application, you can call the AttachServerGroups operation. By attaching Application Load Balancer (ALB) or Network Load Balancer (NLB) server groups to your scaling group, this operation enables Auto Scaling to automatically tailor your computing capacity to your business needs. Furthermore, it optimizes traffic routing by dynamically allocating incoming requests based on current workload patterns, which significantly improves the stability and performance of your application.
+     * Attaches server groups to a scaling group. To seamlessly adjust the number of instances in response to changes in your business workload or to maintain the uninterrupted accessibility of your application, you can call the AttachServerGroups operation. By attaching Application Load Balancer (ALB), Network Load Balancer (NLB), or Gateway Load Balancer (GWLB) server groups to your scaling group, this operation enables Auto Scaling to automatically tailor your computing capacity to your business needs. Furthermore, it optimizes traffic routing by dynamically allocating incoming requests based on current workload patterns, which significantly improves the stability and performance of your application.
      *
      * @param request - AttachServerGroupsRequest
      * @returns AttachServerGroupsResponse
@@ -1516,6 +1516,9 @@ class Client extends openapi_core_1.default {
         if (!$dara.isNull(request.instanceType)) {
             query["InstanceType"] = request.instanceType;
         }
+        if (!$dara.isNull(request.instanceTypeCandidateOptions)) {
+            query["InstanceTypeCandidateOptions"] = request.instanceTypeCandidateOptions;
+        }
         if (!$dara.isNull(request.instanceTypeOverrides)) {
             query["InstanceTypeOverrides"] = request.instanceTypeOverrides;
         }
@@ -1677,26 +1680,26 @@ class Client extends openapi_core_1.default {
      * @remarks
      * A scaling group is a group of Elastic Compute Service (ECS) instances that can be used for similar purposes.
      * You can create only a limited number of scaling groups in a region. To check the quota of the scaling groups, go to Quota Center.
-     * A scaling group does not immediately take effect after you create the scaling group. You can call the [EnableScalingGroup](https://help.aliyun.com/document_detail/25939.html) operation to enable a scaling group. You can trigger scaling events and execute scaling rules only in scaling groups that are in the Enabled state.
+     * A scaling group does not immediately take effect after you create it. You can call the [EnableScalingGroup](https://help.aliyun.com/document_detail/25939.html) operation to enable a scaling group. You can trigger scaling events and execute scaling rules only in scaling groups that are in the Enabled state.
      * If you want to attach a Classic Load Balancer (CLB, formerly known as SLB) instance and an ApsaraDB RDS instance to the scaling group that you want to create, the scaling group, the CLB instance, and the ApsaraDB RDS instance must reside in the same region. For more information, see [Regions and zones](https://help.aliyun.com/document_detail/40654.html).
      * If you attach a CLB instance to the scaling group that you want to create, Auto Scaling automatically adds the ECS instances in the scaling group to the backend server groups of the CLB instance. You can specify the following types of server groups to add ECS instances:
      * *   Default server group: ECS instances in this group process frontend requests. If no listeners are configured for vServer groups or primary/secondary server groups, the frontend requests are forwarded to the ECS instances in the default server group.
      * *   vServer group: If you want to forward different requests to different backend servers, or you want to forward requests based on domain names or URLs, you can specify vServer groups.
-     * >  If you specify both the default server group and multiple server groups simultaneously, Auto Scaling adds the ECS instances in your scaling group to these server groups concurrently.
-     * The default weight of each ECS instance as a backend server is 50. If you want to attach a CLB instance to the scaling group that you want to create, make sure that the CLB instance meets the following requirements:
+     * >  If you specify both the default server group and multiple VServer groups, the ECS instances are added to these server groups.
+     * The default weight of each ECS instance as a backend server is 50. The CLB instance must meet the following requirements:
      * *   The CLB instance is in the Active state. You can call the [DescribeLoadBalancers](https://help.aliyun.com/document_detail/2401696.html) operation to query the status of CLB instances.
-     * *   Health check must be enabled on all listener ports configured for the CLB instance. Otherwise, the scaling group will fail to be created.
-     * If you attach Application Load Balancer (ALB) or Network Load Balancer (NLB) server groups to the scaling group that you want to create, Auto Scaling adds the ECS instances in your scaling group to the ALB or NLB server groups to process the access requests forwarded by the corresponding ALB or NLB instances. You can attach multiple ALB or NLB server groups to a scaling group. Make sure that the ALB or NLB server groups belong to the same virtual private cloud (VPC). For more information, see [AttachAlbServerGroups](https://help.aliyun.com/document_detail/266800.html) or [AttachServerGroups](https://help.aliyun.com/document_detail/600535.html).
-     * If you attach an ApsaraDB RDS instance to the scaling group that you want to create, Auto Scaling automatically adds the private IP addresses of the ECS instances in your scaling group to the IP address whitelist of the ApsaraDB RDS instance. Before you attach an ApsaraDB RDS instance to your scaling group, make sure that the ApsaraDB RDS instance meets the following requirements:
-     * *   The ApsaraDB RDS instance is in the Running state. You can call the [DescribeDBInstances](https://help.aliyun.com/document_detail/610396.html) state to query the status of ApsaraDB RDS instances.
-     * *   The number of IP addresses in the IP address whitelist of the ApsaraDB RDS instance does not reach its upper limit. For more information, see [Configure a whitelist](https://help.aliyun.com/document_detail/43185.html).
-     * If you set MultiAZPolicy for the scaling group that you want to create to COST_OPTIMIZED, the following rules apply:
-     * *   If you use OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, and SpotInstancePools to specify the instance allocation mode under the cost optimization policy, Auto Scaling prioritizes the implementation of the specified instance allocation mode during scale-out events.
+     * *   All listening ports configured for the CLB instance must be health check. Otherwise, the scaling group fails to be created.
+     * If you attach Application Load Balancer (ALB), Network Load Balancer (NLB), or Gateway Load Balancer (GWLB) server groups to the scaling group that you want to create, Auto Scaling adds the ECS instances in your scaling group to the ALB or NLB server groups to process the access requests forwarded by the corresponding ALB or NLB instances. You can specify multiple ALB, NLB, or GWLB server groups, but the server groups must belong to the same VPC as the scaling group. For more information, see [AttachAlbServerGroups](https://help.aliyun.com/document_detail/266800.html) or [AttachServerGroups](https://help.aliyun.com/document_detail/600535.html).
+     * If you associate an RDS instance with the scaling group, the scaling group will automatically add the internal IP addresses of ECS instances that join the scaling group to the access whitelist of the RDS instance. The RDS instance must meet the following requirements:
+     * *   The RDS instance must be in the Running state. You can call the [DescribeDBInstances](https://help.aliyun.com/document_detail/610396.html) operation to view the status of the specified RDS instance.
+     * *   The number of IPs in the RDS instance\\"s access whitelist cannot exceed the upper limit. For more information, see [Configure a whitelist](https://help.aliyun.com/document_detail/43185.html).
+     * If the MultiAZPolicy for the scaling group is set to COST_OPTIMIZED, the following rules apply:
+     * *   When you specify OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, and SpotInstancePools parameters (i.e., defining the instance allocation method under the cost optimization policy), Auto Scaling will prioritize this allocation method during scaling operations.
      * *   If you do not specify OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, or SpotInstancePools, Auto Scaling preferentially creates instances of the lowest-priced instance type based on the cost optimization policy.
      * If you set `Tags.Propagate` to true, the following rules will apply:
-     * *   Tags that you add to the scaling group cannot be propagated to existing instances in the scaling group. Tags that you add to the scaling group are propagated to only new instances.
-     * *   If you specify instance tags in the scaling configuration that is used to create instances and propagate the tags that you add to the scaling group to the instances, all tags exist at the same time.
-     * *   If the tag key that you specify in a scaling configuration and the tag key that you add to the scaling group of the scaling configuration are the same, the tag value that you specify in the scaling configuration is preferentially used.
+     * *   Tags added to the scaling group will only propagate to newly created instances and will not affect instances already running within the scaling group.
+     * *   If instance tags are specified in the scaling configuration and the scaling group’s tags are propagated to the instance, all tags will coexist.
+     * *   If the tag key specified in the scaling configuration matches a tag key in the scaling group, the tag value from the scaling configuration will take precedence.
      *
      * @param request - CreateScalingGroupRequest
      * @param runtime - runtime options for this request RuntimeOptions
@@ -1874,26 +1877,26 @@ class Client extends openapi_core_1.default {
      * @remarks
      * A scaling group is a group of Elastic Compute Service (ECS) instances that can be used for similar purposes.
      * You can create only a limited number of scaling groups in a region. To check the quota of the scaling groups, go to Quota Center.
-     * A scaling group does not immediately take effect after you create the scaling group. You can call the [EnableScalingGroup](https://help.aliyun.com/document_detail/25939.html) operation to enable a scaling group. You can trigger scaling events and execute scaling rules only in scaling groups that are in the Enabled state.
+     * A scaling group does not immediately take effect after you create it. You can call the [EnableScalingGroup](https://help.aliyun.com/document_detail/25939.html) operation to enable a scaling group. You can trigger scaling events and execute scaling rules only in scaling groups that are in the Enabled state.
      * If you want to attach a Classic Load Balancer (CLB, formerly known as SLB) instance and an ApsaraDB RDS instance to the scaling group that you want to create, the scaling group, the CLB instance, and the ApsaraDB RDS instance must reside in the same region. For more information, see [Regions and zones](https://help.aliyun.com/document_detail/40654.html).
      * If you attach a CLB instance to the scaling group that you want to create, Auto Scaling automatically adds the ECS instances in the scaling group to the backend server groups of the CLB instance. You can specify the following types of server groups to add ECS instances:
      * *   Default server group: ECS instances in this group process frontend requests. If no listeners are configured for vServer groups or primary/secondary server groups, the frontend requests are forwarded to the ECS instances in the default server group.
      * *   vServer group: If you want to forward different requests to different backend servers, or you want to forward requests based on domain names or URLs, you can specify vServer groups.
-     * >  If you specify both the default server group and multiple server groups simultaneously, Auto Scaling adds the ECS instances in your scaling group to these server groups concurrently.
-     * The default weight of each ECS instance as a backend server is 50. If you want to attach a CLB instance to the scaling group that you want to create, make sure that the CLB instance meets the following requirements:
+     * >  If you specify both the default server group and multiple VServer groups, the ECS instances are added to these server groups.
+     * The default weight of each ECS instance as a backend server is 50. The CLB instance must meet the following requirements:
      * *   The CLB instance is in the Active state. You can call the [DescribeLoadBalancers](https://help.aliyun.com/document_detail/2401696.html) operation to query the status of CLB instances.
-     * *   Health check must be enabled on all listener ports configured for the CLB instance. Otherwise, the scaling group will fail to be created.
-     * If you attach Application Load Balancer (ALB) or Network Load Balancer (NLB) server groups to the scaling group that you want to create, Auto Scaling adds the ECS instances in your scaling group to the ALB or NLB server groups to process the access requests forwarded by the corresponding ALB or NLB instances. You can attach multiple ALB or NLB server groups to a scaling group. Make sure that the ALB or NLB server groups belong to the same virtual private cloud (VPC). For more information, see [AttachAlbServerGroups](https://help.aliyun.com/document_detail/266800.html) or [AttachServerGroups](https://help.aliyun.com/document_detail/600535.html).
-     * If you attach an ApsaraDB RDS instance to the scaling group that you want to create, Auto Scaling automatically adds the private IP addresses of the ECS instances in your scaling group to the IP address whitelist of the ApsaraDB RDS instance. Before you attach an ApsaraDB RDS instance to your scaling group, make sure that the ApsaraDB RDS instance meets the following requirements:
-     * *   The ApsaraDB RDS instance is in the Running state. You can call the [DescribeDBInstances](https://help.aliyun.com/document_detail/610396.html) state to query the status of ApsaraDB RDS instances.
-     * *   The number of IP addresses in the IP address whitelist of the ApsaraDB RDS instance does not reach its upper limit. For more information, see [Configure a whitelist](https://help.aliyun.com/document_detail/43185.html).
-     * If you set MultiAZPolicy for the scaling group that you want to create to COST_OPTIMIZED, the following rules apply:
-     * *   If you use OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, and SpotInstancePools to specify the instance allocation mode under the cost optimization policy, Auto Scaling prioritizes the implementation of the specified instance allocation mode during scale-out events.
+     * *   All listening ports configured for the CLB instance must be health check. Otherwise, the scaling group fails to be created.
+     * If you attach Application Load Balancer (ALB), Network Load Balancer (NLB), or Gateway Load Balancer (GWLB) server groups to the scaling group that you want to create, Auto Scaling adds the ECS instances in your scaling group to the ALB or NLB server groups to process the access requests forwarded by the corresponding ALB or NLB instances. You can specify multiple ALB, NLB, or GWLB server groups, but the server groups must belong to the same VPC as the scaling group. For more information, see [AttachAlbServerGroups](https://help.aliyun.com/document_detail/266800.html) or [AttachServerGroups](https://help.aliyun.com/document_detail/600535.html).
+     * If you associate an RDS instance with the scaling group, the scaling group will automatically add the internal IP addresses of ECS instances that join the scaling group to the access whitelist of the RDS instance. The RDS instance must meet the following requirements:
+     * *   The RDS instance must be in the Running state. You can call the [DescribeDBInstances](https://help.aliyun.com/document_detail/610396.html) operation to view the status of the specified RDS instance.
+     * *   The number of IPs in the RDS instance\\"s access whitelist cannot exceed the upper limit. For more information, see [Configure a whitelist](https://help.aliyun.com/document_detail/43185.html).
+     * If the MultiAZPolicy for the scaling group is set to COST_OPTIMIZED, the following rules apply:
+     * *   When you specify OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, and SpotInstancePools parameters (i.e., defining the instance allocation method under the cost optimization policy), Auto Scaling will prioritize this allocation method during scaling operations.
      * *   If you do not specify OnDemandBaseCapacity, OnDemandPercentageAboveBaseCapacity, or SpotInstancePools, Auto Scaling preferentially creates instances of the lowest-priced instance type based on the cost optimization policy.
      * If you set `Tags.Propagate` to true, the following rules will apply:
-     * *   Tags that you add to the scaling group cannot be propagated to existing instances in the scaling group. Tags that you add to the scaling group are propagated to only new instances.
-     * *   If you specify instance tags in the scaling configuration that is used to create instances and propagate the tags that you add to the scaling group to the instances, all tags exist at the same time.
-     * *   If the tag key that you specify in a scaling configuration and the tag key that you add to the scaling group of the scaling configuration are the same, the tag value that you specify in the scaling configuration is preferentially used.
+     * *   Tags added to the scaling group will only propagate to newly created instances and will not affect instances already running within the scaling group.
+     * *   If instance tags are specified in the scaling configuration and the scaling group’s tags are propagated to the instance, all tags will coexist.
+     * *   If the tag key specified in the scaling configuration matches a tag key in the scaling group, the tag value from the scaling configuration will take precedence.
      *
      * @param request - CreateScalingGroupRequest
      * @returns CreateScalingGroupResponse
@@ -2262,7 +2265,7 @@ class Client extends openapi_core_1.default {
         return await this.deleteAlarmWithOptions(request, runtime);
     }
     /**
-     * DeleteDiagnoseReport
+     * Deletes a health diagnosis report for a scaling group.
      *
      * @param request - DeleteDiagnoseReportRequest
      * @param runtime - runtime options for this request RuntimeOptions
@@ -2288,7 +2291,7 @@ class Client extends openapi_core_1.default {
         return $dara.cast(await this.callApi(params, req, runtime), new $_model.DeleteDiagnoseReportResponse({}));
     }
     /**
-     * DeleteDiagnoseReport
+     * Deletes a health diagnosis report for a scaling group.
      *
      * @param request - DeleteDiagnoseReportRequest
      * @returns DeleteDiagnoseReportResponse
@@ -3018,6 +3021,8 @@ class Client extends openapi_core_1.default {
         return await this.describeElasticStrengthWithOptions(request, runtime);
     }
     /**
+     * Instance creation and deletion statistics.
+     *
      * @param request - DescribeInstanceCreateAndDeleteStatisticsRequest
      * @param runtime - runtime options for this request RuntimeOptions
      * @returns DescribeInstanceCreateAndDeleteStatisticsResponse
@@ -3063,6 +3068,8 @@ class Client extends openapi_core_1.default {
         return $dara.cast(await this.callApi(params, req, runtime), new $_model.DescribeInstanceCreateAndDeleteStatisticsResponse({}));
     }
     /**
+     * Instance creation and deletion statistics.
+     *
      * @param request - DescribeInstanceCreateAndDeleteStatisticsRequest
      * @returns DescribeInstanceCreateAndDeleteStatisticsResponse
      */
@@ -3623,6 +3630,8 @@ class Client extends openapi_core_1.default {
         return await this.describeScalingActivityDetailWithOptions(request, runtime);
     }
     /**
+     * The distribution of scaling activities in different states over a period of time.
+     *
      * @param request - DescribeScalingActivityStatisticsRequest
      * @param runtime - runtime options for this request RuntimeOptions
      * @returns DescribeScalingActivityStatisticsResponse
@@ -3671,6 +3680,8 @@ class Client extends openapi_core_1.default {
         return $dara.cast(await this.callApi(params, req, runtime), new $_model.DescribeScalingActivityStatisticsResponse({}));
     }
     /**
+     * The distribution of scaling activities in different states over a period of time.
+     *
      * @param request - DescribeScalingActivityStatisticsRequest
      * @returns DescribeScalingActivityStatisticsResponse
      */
@@ -4426,7 +4437,7 @@ class Client extends openapi_core_1.default {
         return await this.detachLoadBalancersWithOptions(request, runtime);
     }
     /**
-     * Detach server groups from a scaling group. To seamlessly adjust the number of instances in response to changes in your business workload or to maintain the uninterrupted accessibility of your application, you can call the DetachServerGroups operation. By detaching Application Load Balancer (ALB) or Network Load Balancer (NLB) server groups from your scaling group, this operation enables Auto Scaling to automatically tailor your computing capacity to your business needs. Furthermore, it optimizes traffic routing by dynamically allocating incoming requests based on current workload patterns, which significantly improves the stability and performance of your application.
+     * Remove one or more SLB server groups from a scaling group. Supported server group types include Application Load Balancer (ALB), Network Load Balancer (NLB), and Gateway Load Balancer (GWLB), which can dynamically adjust SLB policies and help improve high availability of the system.
      *
      * @param request - DetachServerGroupsRequest
      * @param runtime - runtime options for this request RuntimeOptions
@@ -4473,7 +4484,7 @@ class Client extends openapi_core_1.default {
         return $dara.cast(await this.callApi(params, req, runtime), new $_model.DetachServerGroupsResponse({}));
     }
     /**
-     * Detach server groups from a scaling group. To seamlessly adjust the number of instances in response to changes in your business workload or to maintain the uninterrupted accessibility of your application, you can call the DetachServerGroups operation. By detaching Application Load Balancer (ALB) or Network Load Balancer (NLB) server groups from your scaling group, this operation enables Auto Scaling to automatically tailor your computing capacity to your business needs. Furthermore, it optimizes traffic routing by dynamically allocating incoming requests based on current workload patterns, which significantly improves the stability and performance of your application.
+     * Remove one or more SLB server groups from a scaling group. Supported server group types include Application Load Balancer (ALB), Network Load Balancer (NLB), and Gateway Load Balancer (GWLB), which can dynamically adjust SLB policies and help improve high availability of the system.
      *
      * @param request - DetachServerGroupsRequest
      * @returns DetachServerGroupsResponse
@@ -5842,6 +5853,9 @@ class Client extends openapi_core_1.default {
         if (!$dara.isNull(request.instancePatternInfos)) {
             query["InstancePatternInfos"] = request.instancePatternInfos;
         }
+        if (!$dara.isNull(request.instanceTypeCandidateOptions)) {
+            query["InstanceTypeCandidateOptions"] = request.instanceTypeCandidateOptions;
+        }
         if (!$dara.isNull(request.instanceTypeOverrides)) {
             query["InstanceTypeOverrides"] = request.instanceTypeOverrides;
         }
@@ -6391,6 +6405,8 @@ class Client extends openapi_core_1.default {
         return await this.modifyScheduledTaskWithOptions(request, runtime);
     }
     /**
+     * Queries the historical monitoring data of a scaling group that uses predictive scaling rules.
+     *
      * @param request - QueryHistoricalMetricRequest
      * @param runtime - runtime options for this request RuntimeOptions
      * @returns QueryHistoricalMetricResponse
@@ -6439,6 +6455,8 @@ class Client extends openapi_core_1.default {
         return $dara.cast(await this.callApi(params, req, runtime), new $_model.QueryHistoricalMetricResponse({}));
     }
     /**
+     * Queries the historical monitoring data of a scaling group that uses predictive scaling rules.
+     *
      * @param request - QueryHistoricalMetricRequest
      * @returns QueryHistoricalMetricResponse
      */
@@ -6447,6 +6465,8 @@ class Client extends openapi_core_1.default {
         return await this.queryHistoricalMetricWithOptions(request, runtime);
     }
     /**
+     * Queries predicted monitoring data.
+     *
      * @param request - QueryPredictiveMetricRequest
      * @param runtime - runtime options for this request RuntimeOptions
      * @returns QueryPredictiveMetricResponse
@@ -6495,6 +6515,8 @@ class Client extends openapi_core_1.default {
         return $dara.cast(await this.callApi(params, req, runtime), new $_model.QueryPredictiveMetricResponse({}));
     }
     /**
+     * Queries predicted monitoring data.
+     *
      * @param request - QueryPredictiveMetricRequest
      * @returns QueryPredictiveMetricResponse
      */
@@ -6503,6 +6525,8 @@ class Client extends openapi_core_1.default {
         return await this.queryPredictiveMetricWithOptions(request, runtime);
     }
     /**
+     * Queries the information about a prediction task.
+     *
      * @param request - QueryPredictiveTaskInfoRequest
      * @param runtime - runtime options for this request RuntimeOptions
      * @returns QueryPredictiveTaskInfoResponse
@@ -6548,6 +6572,8 @@ class Client extends openapi_core_1.default {
         return $dara.cast(await this.callApi(params, req, runtime), new $_model.QueryPredictiveTaskInfoResponse({}));
     }
     /**
+     * Queries the information about a prediction task.
+     *
      * @param request - QueryPredictiveTaskInfoRequest
      * @returns QueryPredictiveTaskInfoResponse
      */
@@ -6556,6 +6582,8 @@ class Client extends openapi_core_1.default {
         return await this.queryPredictiveTaskInfoWithOptions(request, runtime);
     }
     /**
+     * Queries the predicted number of instances in a scaling group.
+     *
      * @param request - QueryPredictiveValueRequest
      * @param runtime - runtime options for this request RuntimeOptions
      * @returns QueryPredictiveValueResponse
@@ -6607,6 +6635,8 @@ class Client extends openapi_core_1.default {
         return $dara.cast(await this.callApi(params, req, runtime), new $_model.QueryPredictiveValueResponse({}));
     }
     /**
+     * Queries the predicted number of instances in a scaling group.
+     *
      * @param request - QueryPredictiveValueRequest
      * @returns QueryPredictiveValueResponse
      */
@@ -7160,7 +7190,7 @@ class Client extends openapi_core_1.default {
         return await this.setGroupDeletionProtectionWithOptions(request, runtime);
     }
     /**
-     * Sets instance health. At times, the automatic health check system might not sufficiently determine the precise health status of your Elastic Compute Service (ECS) instances or elastic container instances. To overcome this, you can call the SetInstanceHealth operation to swiftly pinpoint problematic instances and resolve issues. This operation is designed to more precisely align with real-world business requirements and tackle O\\&M hurdles efficiently.
+     * Sets instance health. At times, the automatic health check system might not sufficiently determine the precise health status of your Elastic Compute Service (ECS) instances or elastic container instances. To overcome this, you can call the SetInstanceHealth operation to swiftly pinpoint problematic instances and resolve issues. This operation is designed to more precisely align with real-world business requirements and tackle O\\\\\\&M hurdles efficiently.
      *
      * @remarks
      * Auto Scaling detects and removes unhealthy ECS instances or elastic container instances from their scaling groups. To prevent a specific instance from being removed, you can put it in either the Standby or Protected state. For more information, see [EnterStandby](https://help.aliyun.com/document_detail/459345.html) and [SetInstancesProtection](https://help.aliyun.com/document_detail/459342.html).
@@ -7201,7 +7231,7 @@ class Client extends openapi_core_1.default {
         return $dara.cast(await this.callApi(params, req, runtime), new $_model.SetInstanceHealthResponse({}));
     }
     /**
-     * Sets instance health. At times, the automatic health check system might not sufficiently determine the precise health status of your Elastic Compute Service (ECS) instances or elastic container instances. To overcome this, you can call the SetInstanceHealth operation to swiftly pinpoint problematic instances and resolve issues. This operation is designed to more precisely align with real-world business requirements and tackle O\\&M hurdles efficiently.
+     * Sets instance health. At times, the automatic health check system might not sufficiently determine the precise health status of your Elastic Compute Service (ECS) instances or elastic container instances. To overcome this, you can call the SetInstanceHealth operation to swiftly pinpoint problematic instances and resolve issues. This operation is designed to more precisely align with real-world business requirements and tackle O\\\\\\&M hurdles efficiently.
      *
      * @remarks
      * Auto Scaling detects and removes unhealthy ECS instances or elastic container instances from their scaling groups. To prevent a specific instance from being removed, you can put it in either the Standby or Protected state. For more information, see [EnterStandby](https://help.aliyun.com/document_detail/459345.html) and [SetInstancesProtection](https://help.aliyun.com/document_detail/459342.html).