You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/azure-monitor/alerts/alerts-create-new-alert-rule.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -343,7 +343,7 @@ To edit an existing alert rule:
343
343
|Field |Description |
344
344
|---------|---------|
345
345
|Enable upon creation| Select for the alert rule to start running as soon as you're done creating it.|
346
-
|Automatically resolve alerts (preview) |Select to make the alert stateful. When an alert is stateful, the alert is resolved when the condition is no longer met for a specific time range. The time range differs based on the frequency of the alert:<br>**1 minute**: The alert condition isn't met for 10 minutes.<br>**5-15 minutes**: The alert condition isn't met for three frequency periods.<br>**15 minutes - 11 hours**: The alert condition isn't met for two frequency periods.<br>**11 to 12 hours**: The alert condition isn't met for one frequency period.|
346
+
|Automatically resolve alerts (preview) |Select to make the alert stateful. When an alert is stateful, the alert is resolved when the condition is no longer met for a specific time range. The time range differs based on the frequency of the alert:<br>**1 minute**: The alert condition isn't met for 10 minutes.<br>**5-15 minutes**: The alert condition isn't met for three frequency periods.<br>**15 minutes - 11 hours**: The alert condition isn't met for two frequency periods.<br>**11 to 12 hours**: The alert condition isn't met for one frequency period. <br><br>Note that stateful log alerts have these limitations:<br> - they can trigger up to 300 alerts per evaluation.<br> - you can have a maximum of 5000 alerts with the `fired` alert condition.|
347
347
|Mute actions |Select to set a period of time to wait before alert actions are triggered again. If you select this checkbox, the **Mute actions for** field appears to select the amount of time to wait after an alert is fired before triggering actions again.|
348
348
|Check workspace linked storage|Select if logs workspace linked storage for alerts is configured. If no linked storage is configured, the rule isn't created.|
Copy file name to clipboardExpand all lines: articles/azure-monitor/alerts/alerts-overview.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -77,6 +77,10 @@ The alert condition for stateful alerts is `fired`, until it is considered resol
77
77
78
78
For stateful alerts, while the alert itself is deleted after 30 days, the alert condition is stored until the alert is resolved, to prevent firing another alert, and so that notifications can be sent when the alert is resolved.
79
79
80
+
Stateful log alerts have these limitations:
81
+
- they can trigger up to 300 alerts per evaluation.
82
+
- you can have a maximum of 5000 alerts with the `fired` alert condition.
83
+
80
84
This table describes when a stateful alert is considered resolved:
Copy file name to clipboardExpand all lines: articles/azure-monitor/alerts/alerts-types.md
+4-1Lines changed: 4 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -129,7 +129,10 @@ Log alerts can measure two different things, which can be used for different mon
129
129
-**Table rows**: The number of rows returned can be used to work with events such as Windows event logs, Syslog, and application exceptions.
130
130
-**Calculation of a numeric column**: Calculations based on any numeric column can be used to include any number of resources. An example is CPU percentage.
131
131
132
-
You can configure if log alerts are [stateful or stateless](alerts-overview.md#alerts-and-state). This feature is currently in preview.
132
+
You can configure if log alerts are [stateful or stateless](alerts-overview.md#alerts-and-state). This feature is currently in preview.
133
+
Note that stateful log alerts have these limitations:
134
+
- they can trigger up to 300 alerts per evaluation.
135
+
- you can have a maximum of 5000 alerts with the `fired` alert condition.
133
136
134
137
> [!NOTE]
135
138
> Log alerts work best when you're trying to detect specific data in the logs, as opposed to when you're trying to detect a lack of data in the logs. Because logs are semi-structured data, they're inherently more latent than metric data on information like a VM heartbeat. To avoid misfires when you're trying to detect a lack of data in the logs, consider using [metric alerts](#metric-alerts). You can send data to the metric store from logs by using [metric alerts for logs](alerts-metric-logs.md).
Copy file name to clipboardExpand all lines: articles/azure-monitor/autoscale/autoscale-get-started.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@ title: Get started with autoscale in Azure
3
3
description: "Learn how to scale your resource web app, cloud service, virtual machine, or Virtual Machine Scale Set in Azure."
4
4
ms.author: edbaynash
5
5
ms.topic: conceptual
6
-
ms.date: 04/10/2023
6
+
ms.date: 11/29/2023
7
7
---
8
8
# Get started with autoscale in Azure
9
9
@@ -75,7 +75,7 @@ Follow the steps below to create your first autoscale setting.
75
75
76
76
:::image type="content" source="./media/autoscale-get-started/instance-limits.png" lightbox="./media/autoscale-get-started/instance-limits.png" alt-text="A screenshot showing the configure tab of the autoscale setting page with configured rules.":::
77
77
78
-
You have successfully created your first scale setting to autoscale your web app based on CPU usage. When CPU usage is greater than 70%, an additional instance is added, up to a maximum of 3 instances. When CPU usage is below 20%, an instance is removed up to a minimum of 1 instance. By default there will be 1 instance.
78
+
You have successfully created your first scale setting to autoscale your web app based on CPU usage. When CPU usage is greater than 70%, an additional instance is added, up to a maximum of 3 instances. When CPU usage is below 20%, an instance is removed up to a minimum of 1 instance. By default there will be 1 instance.
79
79
80
80
## Scheduled scale conditions
81
81
@@ -121,7 +121,7 @@ You have now defined a scale condition for a specific day. When CPU usage is gre
121
121
122
122
### View the history of your resource's scale events
123
123
124
-
Whenever your resource has any scaling event, it is logged in the activity log. You can view the history of the scale events in the **Run history** tab.
124
+
Whenever your resource has any scaling event, it's logged in the activity log. You can view the history of the scale events in the **Run history** tab.
125
125
126
126
:::image type="content" source="./media/autoscale-get-started/run-history.png" lightbox="./media/autoscale-get-started/run-history.png" alt-text="A screenshot showing the run history tab in autoscale settings.":::
127
127
@@ -135,7 +135,7 @@ You can make changes in JSON directly, if necessary. These changes will be refle
135
135
136
136
### Cool-down period effects
137
137
138
-
Autoscale uses a cool-down period with is the amount of time to wait after a scale operation before scaling again. For example, if the cooldown is 10 minutes, Autoscale won't attempt to scale again until 10 minutes after the previous scale action. The cooldown period allows the metrics to stabilize and avoids scaling more than once for the same condition. For more information, see [Autoscale evaluation steps](autoscale-understanding-settings.md#autoscale-evaluation).
138
+
Autoscale uses a cool-down period. This period is the amount of time to wait after a scale operation before scaling again. The cool-down period allows the metrics to stabilize and avoids scaling more than once for the same condition. Cool-down applies to both scale-in and scale-out events. For example, if the cooldown is set to 10 minutes and Autoscale has just scaled-in, Autoscale won't attempt to scale again for another 10 minutes in either direction. For more information, see [Autoscale evaluation steps](autoscale-understanding-settings.md#autoscale-evaluation).
Copy file name to clipboardExpand all lines: articles/azure-monitor/autoscale/autoscale-understanding-settings.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ description: This article explains autoscale settings, how they work, and how th
4
4
author: EdB-MSFT
5
5
ms.service: azure-monitor
6
6
ms.topic: conceptual
7
-
ms.date: 11/02/2022
7
+
ms.date: 11/29/2023
8
8
ms.subservice: autoscale
9
9
ms.custom: ignite-2022
10
10
ms.author: edbaynash
@@ -120,7 +120,7 @@ The following table describes the elements in the preceding autoscale setting's
120
120
| rule | scaleAction | Action |The action to take when the metricTrigger of the rule is triggered. |
121
121
| scaleAction | direction | Operation |"Increase" to scale out, or "Decrease" to scale in.|
122
122
| scaleAction | value |Instance count |How much to increase or decrease the capacity of the resource. |
123
-
| 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. |
123
+
| scaleAction | cooldown | Cool down (minutes)|The amount of time to wait after a scale operation before scaling again. The cooldown period comes into effect after a scale-in or a scale-out event. 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. |
124
124
125
125
## Autoscale profiles
126
126
@@ -242,7 +242,7 @@ There are three types of autoscale profiles:
242
242
243
243
## Autoscale evaluation
244
244
245
-
Autoscale settings can have multiple profiles. Each profile can have multiple rules. Each time the autoscale job runs, it begins by choosing the applicable profile for that time. Autoscale then 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.
245
+
Autoscale settings can have multiple profiles. Each profile can have multiple rules. Each time the autoscale job runs, it begins by choosing the applicable profile for that time. Autoscale then 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. After a scale action occurs, the autoscale job waits for the cooldown period before it scales again. The cooldown period applies to both scale-out and scale-in actions.
Copy file name to clipboardExpand all lines: articles/dns/delegate-subdomain.md
+28-33Lines changed: 28 additions & 33 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,72 +5,67 @@ services: dns
5
5
author: greg-lindsay
6
6
ms.service: dns
7
7
ms.topic: how-to
8
-
ms.date: 09/27/2022
8
+
ms.date: 11/28/2023
9
9
ms.author: greglin
10
10
---
11
11
12
12
# Delegate an Azure DNS subdomain
13
13
14
-
You can use the Azure portal to delegate a DNS subdomain. For example, if you own the contoso.com domain, you may delegate a subdomain called *engineering* to another separate zone that you can administer separately from the contoso.com zone.
14
+
You can use the Azure portal to delegate a DNS subdomain. For example, if you own the *adatum.com* domain, you can delegate a subdomain called *engineering.adatum.com* to another separate zone that you can administer separately from the adatum.com zone.
15
15
16
-
If you prefer, you can also delegate a subdomain using [Azure PowerShell](delegate-subdomain-ps.md).
16
+
You can also delegate a subdomain using [Azure PowerShell](delegate-subdomain-ps.md).
17
17
18
18
## Prerequisites
19
19
20
-
To delegate an Azure DNS subdomain, you must first delegate your public domain to Azure DNS. See [Delegate a domain to Azure DNS](./dns-delegate-domain-azure-dns.md) for instructions on how to configure your name servers for delegation. Once your domain is delegated to your Azure DNS zone, you can delegate your subdomain.
20
+
To delegate an Azure DNS subdomain, the parent public domain must first be delegated to Azure DNS. See [Delegate a domain to Azure DNS](./dns-delegate-domain-azure-dns.md) for instructions on how to configure your name servers for delegation. Once your domain is delegated to Azure DNS, you can delegate a subdomain.
21
21
22
22
> [!NOTE]
23
-
> Contoso.comis used as an example throughout this article. Substitute your own domain name for contoso.com.
23
+
> The `adatum.com` zone is used as an example of a parent DNS zone and `engineering.adatum.com` is used for the subdomain. Substitute your own domain names for these domains.
24
24
25
-
## Create a zone for your subdomain
25
+
## Delegate a subdomain
26
26
27
-
First, create the zone for the **engineering** subdomain.
27
+
The **engineering.adatum.com** subdomain can already exist. If it doesn't exist, it is created.
28
28
29
-
1. From the Azure portal, select **+ Create a resource**.
29
+
To delegate the **engineering** subdomain under **adatum.com**:
30
30
31
-
1. Search for **DNS zone** and then select **Create**.
31
+
1. From the Azure portal, search for **DNS zones** and select the **adatum.com** parent zone.
32
+
2. Select **+ Child zone** and enter **engineering** next to **Name**. The **Create DNS zone** window opens.
32
33
33
-
1. On the **Create DNS zone** page, select the resource group for your zone. You may want to use the same resource group as the parent zone to keep similar resources together.
34
+

34
35
35
-
1. Enter `engineering.contoso.com` for the **Name** and then select **Create**.
36
+
3. If desired, change the **Subscription** and **Resource group**. In this example, we use the same subscription and resource group as the parent zone.
37
+
4. Select **Review create**, and then select **Create**.
38
+
5. When deployment is complete, select **Go to resource** to view the new delegated zone: **engineering.adatum.com**.
36
39
37
-
1. After the deployment succeeds, go to the new zone.
40
+
[](./media/delegate-subdomain/child-zone-contents.png#lightbox)
38
41
39
-
## Note the name servers
42
+
6. Select the parent **adatum.com** zone again and notice that an **NS** record has been added with the name **engineering** and contents the same as NS records in the child zone. You might need to refresh the page. These are the Azure DNS nameservers that are authoritative for the subdomain (child zone).
40
43
41
-
Next, note the four name servers for the engineering subdomain.
44
+
[](./media/delegate-subdomain/parent-zone-contents.png#lightbox)
42
45
43
-
On the **engineering** zone overview page, note the four name servers for the zone. You'll need these name servers at a later time.
46
+
## Manual entry of NS records (optional)
44
47
45
-
## Create a test record
46
-
47
-
Create an **A** record to use for testing. For example, create a **www** A record and configure it with a **10.10.10.10** IP address.
48
-
49
-
## Create an NS record
50
-
51
-
Next, create a name server (NS) record for the **engineering** zone.
48
+
If desired, you can also create your subdomain and add the subdomain NS record manually.
52
49
53
-
1. Navigate to the zone for the parent domain.
50
+
To create a new subdomain zone, use **Create a resource > DNS zone** and create a zone named **engineering.adatum.com**.
54
51
55
-
1. Select **+ Record set**at the top of the overview page.
52
+
To create a subdomain delegation manually, add a new NS record set (**+ Record set**option) to the parent zone **adatum.com** with the name: **engineering** and specify each of the nameserver entries that are listed in the subdomain (child) zone.
56
53
57
-
1. On the **Add recordset** page, type **engineering** in the **Name** text box.
54
+
<br><imgsrc="./media/delegate-subdomain/add-ns-record-set.png"alt="A screenshot showing how to add an NS record set."width="50%">
58
55
59
-
1. For **Type**, select **NS**.
56
+
This method doesn't use the **+ Child zone** option, but both methods result in the same delegation.
60
57
61
-
1. Under **Name server**, enter the four name servers that you noted previously from the **engineering** zone.
58
+
## Create a test record
62
59
63
-
1. Select **OK**to save the record.
60
+
Next, create an **A**record in the **engineering.adatum.com** zone to use for testing. For example, create a **www** A record and configure it with a **10.10.10.10** IP address.
64
61
65
62
## Test the delegation
66
63
67
64
Use nslookup to test the delegation.
68
65
69
-
1. Open a PowerShell window.
70
-
71
-
1. At command prompt, type `nslookup www.engineering.contoso.com.`
72
-
73
-
1. You should receive a non-authoritative answer showing the address **10.10.10.10**.
66
+
1. Open a command prompt.
67
+
2. At command prompt, type `nslookup www.engineering.adatum.com.`
68
+
3. You should receive a non-authoritative answer showing the address **10.10.10.10**.
0 commit comments