after acrolinx

Author: EdB-MSFT

articles/azure-monitor/autoscale/autoscale-understanding-settings.md

@@ -1,27 +1,26 @@
 ---
-title: Autoscale settings in Azure Monitor
+title: Understanding autoscale settings in Azure Monitor
 description: "A detailed breakdown of autoscale settings and how they work. Applies to Virtual Machines, Cloud Services, Web Apps"
+author: EdB-MSFT
 ms.topic: conceptual
-ms.date: 12/18/2017
+ms.date: 11/02/2022
 ms.subservice: autoscale
-ms.reviewer: riroloff
+ms.custom: ignite-2022
+ms.author: ebayansh
 ---
-# Autoscale settings
+# Understand autoscale settings
 
-Autoscale settings help you provision just the right mount of resources to support the load on your application. Configure autoscale settings to be triggered based on metrics that indicate load or performance, or triggered at a scheduled date and time.  
+Autoscale settings help ensure that you have the right amount of resources running to handle the fluctuating load of your application. You can configure autoscale settings to be triggered based on metrics that indicate load or performance, or triggered at a scheduled date and time. 
 
-This article gives a detailed description of the autoscale settings. 
+This article gives a detailed explanation of the autoscale settings. 
 
 ## Autoscale setting schema
 
-The [Autoscale ARM template resource definition](https://learn.microsoft.com/en-us/azure/templates/microsoft.insights/autoscalesettings?pivots=deployment-language-arm-template#autoscaleprofile-1) contains a description of all template elements.
-
-The example below has the following settings:
-
-- A single, default profile.
-- The profile has two rules. The first rule scales out, the second scales in.
-- The scale-out rule is triggered when the virtual machine scale set's average percentage CPU metric is greater than 85 percent for the past 10 minutes.
-- The scale-in rule is triggered when the virtual machine scale set's average is less than 60 percent for the past minute.
+The following example shows an autoscale setting. This autoscale setting has the following attributes:
+- A single default profile. 
+- Two metric rules in this profile: one for scale-out, and one for scale-in.
+  - The scale-out rule is triggered when the Virtual Machine Scale Set's average percentage CPU metric is greater than 85 percent for the past 10 minutes.
+  - The scale-in rule is triggered when the Virtual Machine Scale Set's average is less than 60 percent for the past minute.
 
 > [!NOTE]
 > A setting can have multiple profiles. To learn more, see the [profiles](#autoscale-profiles) section. A profile can also have multiple scale-out rules and scale-in rules defined. To see how they are evaluated, see the [evaluation](#autoscale-evaluation) section.
@@ -99,29 +98,28 @@ The table below describes the elements in the above autoscale setting's JSON.
 | profiles | name | |The name of the profile. You can choose any name that helps you identify the profile. |
 | profiles | capacity.maximum | Instance limits - Maximum |The maximum capacity allowed. It ensures that autoscale doesn't scale your resource above this number when executing the profile. |
 | profiles | capacity.minimum | Instance limits - Minimum  |The minimum capacity allowed. It ensures that autoscale doesn't scale your resource below this number when executing the profile |
-| profiles | capacity.default | Instance limits - Default  |If there's a problem reading the resource metric, and the current capacity is below the default, autoscale scales out to the default. This ensures the availability of the resource. If the current capacity is already higher than the default capacity, autoscale does not scale in. |
+| profiles | capacity.default | Instance limits - Default  |If there's a problem reading the resource metric, and the current capacity is below the default, autoscale scales out to the default. This ensures the availability of the resource. If the current capacity is already higher than the default capacity, autoscale doesn't scale in. |
 | profiles | rules | Rules |Autoscale automatically scales between the maximum and minimum capacities, by using the rules in the profile. You can have multiple rules in a profile. Typically there are two rules: one to determine when to scale out, and the other to determine when to scale in. |
 | rule | metricTrigger | Scale rule |Defines the metric condition of the rule. |
 | metricTrigger | metricName | Metric name |The name of the metric. |
-| metricTrigger |  metricResourceUri | |The resource ID of the resource that emits the metric. In most cases, it is the same as the resource being scaled. In some cases, it can be different. For example, you can scale a virtual machine scale set based on the number of messages in a storage queue. |
+| metricTrigger |  metricResourceUri | |The resource ID of the resource that emits the metric. In most cases, it is the same as the resource being scaled. In some cases, it can be different. For example, you can scale a Virtual Machine Scale Set based on the number of messages in a storage queue. |
 | metricTrigger | timeGrain | Time grain (minutes) |The metric sampling duration. For example, **TimeGrain = “PT1M”** means that the metrics should be aggregated every 1 minute, by using the aggregation method specified in the statistic element. |
 | metricTrigger | statistic | Time grain statistic |The aggregation method within the timeGrain period. For example, **statistic = “Average”** and **timeGrain = “PT1M”** means that the metrics should be aggregated every 1 minute, by taking the average. This property dictates how the metric is sampled. |
 | metricTrigger | timeWindow | Duration |The amount of time to look back for metrics. For example, **timeWindow = “PT10M”** means that every time autoscale runs, it queries metrics for the past 10 minutes. The time window allows your metrics to be normalized, and avoids reacting to transient spikes. |
 | metricTrigger | timeAggregation |Time aggregation |The aggregation method used to aggregate the sampled metrics. For example, **TimeAggregation = “Average”** should aggregate the sampled metrics by taking the average. In the preceding case, take the ten 1-minute samples, and average them. |
 | rule | scaleAction | Action |The action to take when the metricTrigger of the rule is triggered. |
 | scaleAction | direction | Operation |"Increase" to scale out, or "Decrease" to scale in.|
 | scaleAction | value |Instance count |How much to increase or decrease the capacity of the resource. |
-| scaleAction | cooldown | Cool down (minutes)|The amount of time to wait after a scale operation before scaling again. For example, if **cooldown = “PT10M”**, autoscale does not attempt to scale again for another 10 minutes. The cooldown is to allow the metrics to stabilize after the addition or removal of instances. |
+| scaleAction | cooldown | Cool down (minutes)|The amount of time to wait after a scale operation before scaling again. For example, if **cooldown = “PT10M”**, autoscale doesn't attempt to scale again for another 10 minutes. The cooldown is to allow the metrics to stabilize after the addition or removal of instances. |
+
 
 ## Autoscale profiles
 
 There are three types of autoscale profiles:
 
-- **Regular profile:** The most common profile. If you don’t need to scale your resource based on the day of the week, or on a particular day, you can use a regular profile. This profile can then be configured with metric rules that dictate when to scale out and when to scale in. You should only have one regular profile defined.
-
-    The example profile used earlier in this article is an example of a regular profile. Note that it is also possible to set a profile to scale to a static instance count for your resource.
-
-- **Fixed date profile:** This profile is for special cases. For example, let’s say you have an important event coming up on December 26, 2017 (PST). You want the minimum and maximum capacities of your resource to be different on that day, but still scale on the same metrics. In this case, you should add a fixed date profile to your setting’s list of profiles. The profile is configured to run only on the event’s day. For any other day, autoscale uses the regular profile.
+- **Default profile:** Use the default profile if you don’t need to scale your resource based on a particular date and time, or day of the week, use a regular or default profile. You can only have one default profile. The sample profile used above is an example of a default profile. 
+- 
+- **Fixed date profile:** This profile is relevant for a single date and time. Use the fixed date profile to set scaling rules for a specific event. The profile runs only on the event’s date and time. For all other times, autoscale uses the default profile.
 
     ```json
     "profiles": [
@@ -160,164 +158,42 @@ There are three types of autoscale profiles:
         }
     ]
     ```
-    
-- **Recurrence profile:** This type of profile enables you to ensure that this profile is always used on a particular day of the week. Recurrence profiles only have a start time. They run until the next recurrence profile or fixed date profile is set to start. An autoscale setting with only one recurrence profile runs that profile, even if there is a regular profile defined in the same setting. The following two examples illustrate how this profile is used:
-
-    **Example 1: Weekdays vs. weekends**
-    
-    Let’s say that on weekends, you want your maximum capacity to be 4. On weekdays, because you expect more load, you want your maximum capacity to be 10. In this case, your setting would contain two recurrence profiles, one to run on weekends and the other on weekdays.
-    The setting looks like this:
-
-    ``` JSON
-    "profiles": [
-    {
-    "name": "weekdayProfile",
-    "capacity": {
-        ...
-    },
-    "rules": [{
-        ...
-    }],
-    "recurrence": {
-        "frequency": "Week",
-        "schedule": {
-            "timeZone": "Pacific Standard Time",
-            "days": [
-                "Monday"
-            ],
-            "hours": [
-                0
-            ],
-            "minutes": [
-                0
-            ]
-        }
-    }}
-    },
-    {
-    "name": "weekendProfile",
-    "capacity": {
-        ...
-    },
-    "rules": [{
-        ...
-    }]
-    "recurrence": {
-        "frequency": "Week",
-        "schedule": {
-            "timeZone": "Pacific Standard Time",
-            "days": [
-                "Saturday"
-            ],
-            "hours": [
-                0
-            ],
-            "minutes": [
-                0
-            ]
-        }
-    }
-    }]
-    ```
 
-    The preceding setting shows that each recurrence profile has a schedule. This schedule determines when the profile starts running. The profile stops when it’s time to run another profile.
+- **Recurrence profile:** A recurrence profile is used for a day or set of days of the week.  The schema for a recurring profile doesn't include an end date. The end of date and time for a recurring profile is set by the start time of the following profile. When using the portal to configure recurring profiles, the default profile is automatically duplicated, and restarts at the time that you specify for the recurring profile to end. For more information on configuring multiple profiles, see [Autoscale with multiple profiles](./autoscale-multiprofile.md)
 
-    For example, in the preceding setting, “weekdayProfile” is set to start on Monday at 12:00 AM. That means this profile starts running on Monday at 12:00 AM. It continues until Saturday at 12:00 AM, when “weekendProfile”  is scheduled to start running.
-
-    **Example 2: Business hours**
-    
-    Let's say you want to have one metric threshold during business hours (9:00 AM to 5:00 PM), and a different one for all other times. The setting would look like this:
-    
-    ``` JSON
-    "profiles": [
-    {
-    "name": "businessHoursProfile",
-    "capacity": {
-        ...
-    },
-    "rules": [{
-        ...
-    }],
-    "recurrence": {
-        "frequency": "Week",
-        "schedule": {
-            "timeZone": "Pacific Standard Time",
-            "days": [
-                "Monday", “Tuesday”, “Wednesday”, “Thursday”, “Friday”
-            ],
-            "hours": [
-                9
-            ],
-            "minutes": [
-                0
-            ]
-        }
-    }
-    },
-    {
-    "name": "nonBusinessHoursProfile",
-    "capacity": {
-        ...
-    },
-    "rules": [{
-        ...
-    }]
-    "recurrence": {
-        "frequency": "Week",
-        "schedule": {
-            "timeZone": "Pacific Standard Time",
-            "days": [
-                "Monday", “Tuesday”, “Wednesday”, “Thursday”, “Friday”
-            ],
-            "hours": [
-                17
-            ],
-            "minutes": [
-                0
-            ]
-        }
-    }
-    }]
-    ```
-    
-    The preceding setting shows that “businessHoursProfile” begins running on Monday at 9:00 AM, and continues to 5:00 PM. That’s when “nonBusinessHoursProfile” starts running. The “nonBusinessHoursProfile” runs until 9:00 AM Tuesday, and then the “businessHoursProfile” takes over again. This repeats until Friday at 5:00 PM. At that point, “nonBusinessHoursProfile” runs all the way to Monday at 9:00 AM.
-    
-> [!Note]
-> The autoscale user interface in the Azure portal enforces end times for recurrence profiles, and begins running the autoscale setting's default profile in between recurrence profiles.
-    
 ## Autoscale evaluation
-Given that Autoscale settings can have multiple profiles, and each profile can have multiple metric rules, it is important to understand how an Autoscale setting is evaluated. The Autoscale job runs every 30 to 60 seconds, depending on the resource type. Each time the Autoscale job runs, it begins by choosing the profile that is applicable. Then Autoscale evaluates the minimum and maximum values, and any metric rules in the profile, and decides if a scale action is necessary.
-
 
+Autoscale settings can have multiple profiles. Each profile can have multiple metric rules. Each time the autoscale job runs, it begins by choosing the applicable profile for that time. Then autoscale evaluates the minimum and maximum values, any metric rules in the profile, and decides if a scale action is necessary. The autoscale job runs every 30 to 60 seconds, depending on the resource type. 
 
-Given that Autoscale settings can have multiple profiles, and each profile can have multiple metric rules, it is important to understand how an Autoscale setting is evaluated. The Autoscale job runs every 30 to 60 seconds, depending on the resource type. Each time the Autoscale job runs, it begins by choosing the profile that is applicable. Then Autoscale evaluates the minimum and maximum values, and any metric rules in the profile, and decides if a scale action is necessary.
-### Which profile will autoscale pick?
+### Which profile will autoscale use?
 
-Autoscale uses the following sequence to pick the profile:
-1. It first looks for any fixed date profile that is configured to run now. If there is,autoscale runs it. If there are multiple fixed date profiles that are supposed to run,autoscale selects the first one.
-2. If there are no fixed date profiles,autoscale looks at recurrence profiles. If a recurrence profile is found, it runs it.
-3. If there are no fixed date or recurrence profiles,autoscale runs the regular profile.
+Each time the autoscale service runs, the profiles are evaluated in the following order:
 
-### How does autoscale evaluate multiple rules?
+1. Fixed date profiles
+1. Recurring profiles
+1. Default profile
 
-After autoscale determines which profile to run, it evaluates all the scale-out rules in the profile (these are rules with **direction = “Increase”**).
+The first suitable profile found will be used.
 
-If one or more scale-out rules are triggered,autoscale calculates the new capacity determined by the **scaleAction** of each of those rules. Then it scales out to the maximum of those capacities, to ensure service availability.
+### How does autoscale evaluate multiple rules?
 
-For example, let's say there is a virtual machine scale set with a current capacity of 10. There are two scale-out rules: one that increases capacity by 10 percent, and one that increases capacity by 3 counts. The first rule would result in a new capacity of 11, and the second rule would result in a capacity of 13. To ensure service availability,autoscale chooses the action that results in the maximum capacity, so the second rule is chosen.
+After autoscale determines which profile to run, it evaluates the scale-out rules in the profile, that is, where **direction = “Increase”**.
+If one or more scale-out rules are triggered, autoscale calculates the new capacity determined by the **scaleAction** specified for each of those rules. If there's more than one scale-out rule triggered, autoscale scales to the maximum specified capacity to ensure service availability. 
+For example, There are two rules: Rule1 specifies scale out by 3 instances and rule 2 specifies scale out by 5. IF Both rules are triggered, autoscale will scale out by 5 instances. Similarly, if one rule specifies scale out by 3 instances and another rule, scale out by 15%, the higher of the two instance counts will be used.
 
-If no scale-out rules are triggered,autoscale evaluates all the scale-in rules (rules with **direction = “Decrease”**). Autoscale only takes a scale-in action if all of the scale-in rules are triggered.
+If no scale-out rules are triggered, autoscale evaluates all the scale-in rules, that is, rules with **direction = “Decrease”**. Autoscale only scales in if all of the scale-in rules are triggered.
 
-Autoscale calculates the new capacity determined by the **scaleAction** of each of those rules. Then it chooses the scale action that results in the maximum of those capacities to ensure service availability.
+Autoscale calculates the new capacity determined by the **scaleAction** of each of those rules. To ensure service availability, autoscale scales in by as little as possible to achieve the maximum capacity specified. For example, assume two scale-in rules, one that decreases capacity by 50 percent, and one that decreases capacity by 3 instances. If first rule results in 5 instances and the second rule results in 7, autoscale scales-in to 7 instances. 
 
-For example, let's say there is a virtual machine scale set with a current capacity of 10. There are two scale-in rules: one that decreases capacity by 50 percent, and one that decreases capacity by 3 counts. The first rule would result in a new capacity of 5, and the second rule would result in a capacity of 7. To ensure service availability, autoscale chooses the action that results in the maximum capacity, so the second rule is chosen.
+Each time autoscale calculates the result of a scale action, it evaluates whether that action would trigger the opposite scale action. The scenario where a scale action triggers the opposite scale action is known as flapping. Autoscale may defer a scale action to avoid flapping or may scale by a number less than what was specified in the rule. For more information on flapping, see [Flapping in Autoscale](./autoscale-custom-metric.md)
 
 ## Next steps
-Learn more about autoscale by referring to the following:
+
+Learn more about autoscale by referring to the following articles :
 
 * [Overview of autoscale](./autoscale-overview.md)
 * [Azure Monitor autoscale common metrics](./autoscale-common-metrics.md)
-* [Best practices for Azure Monitor autoscale](./autoscale-best-practices.md)
+* [Autoscale with multiple profiles](./autoscale-multiprofile.md)
+* [Flapping in Autoscale](./autoscale-custom-metric.md)
 * [Use autoscale actions to send email and webhook alert notifications](./autoscale-webhook-email.md)
 * [Autoscale REST API](/rest/api/monitor/autoscalesettings)
-