Based on the changes in YARN metrics within the cluster, select the metrics from the past that align with business fluctuations, configure specific thresholds, and then save and apply the settings. Once business activity changes, the corresponding rules will be triggered. The selected metrics should be inversely related to capacity changes, so after scaling activities occur, the change in instance numbers can reduce the corresponding metrics.
Example:
To configure the scale-out rule: if the average value of AppsPending#root is greater than or equal to 1 within 300 seconds and this occurs consecutively 2 times, a scale-out action will be triggered. This can effectively reduce the number of pending tasks in the queue.
Scale-out/Scale-in rules: Configure based on actual conditions. For details on other rule configuration items and usage instructions, refer to Setting Load-based Scaling. 1.1 For each rule, you can configure multiple metric conditions. Scaling can be triggered when all rules reach their thresholds simultaneously or when any rule reaches its threshold.
1.2 To avoid frequent scaling activities that lead to resource waste, you can configure a cooling period for the rule. During the cooling period, even if the scaling conditions are met, no scaling activity will occur.
1.3 Configure an active time (the current rule takes effect within a customized time range). Different scaling rules are allowed to be combined, and you can set different scaling conditions for different time periods.
Note:
1. During peak order placement, scale-out may result in the actual number of scale-out machines failing to reach the elastic target quantity due to resource contention. It is recommended to enable the "Achieve Targets as Possible" policy for your scale-out rules.
2. When the scale-in action is triggered, nodes may still be executing tasks. To avoid immediate release of the nodes, it is recommended that you enable graceful scale-in. For more details, see Graceful Scale-In.