MicrosoftDocs
Update alerts-create-metric-alert-rule.yml
Current text only tells about filters, but it should also mention possible scope levels too. Also, I can't find any information on the doc about how does alert work for lower-level resources. For example, if an alert is scoped at subscription level, but the condition is met only at its underlying resource group level, what happens? Does subscription-level alert get triggered? Actually this is a tricky question which is asked in Azure certification exam and I believe the documentation should clearly explain it. I've added it to the best of my knowledge, but feel free to edit / correct it:
"Alerts can be scoped at subscription, resource group and resource level. If you scope at e.g. subscription, its underlying resource groups and resources can trigger the alert."
@azarboon : Thanks for your contribution! The author(s) have been notified to review your proposed change.
![prmerger-automator[bot] avatar](https://avatars.githubusercontent.com/u/22479449?v=4 "Published by a pub.dev verified publisher"){kind=small}
Learn Build status updates of commit ec74c43:
:white_check_mark: Validation status: passed
| File | Status | Preview URL | Details |
|---|---|---|---|
| articles/azure-monitor/alerts/alerts-create-metric-alert-rule.yml | :white_check_mark:Succeeded |
For more details, please refer to the build report.
For any questions, please:
- Try searching the learn.microsoft.com contributor guides
- Post your question in the Learn support channel
![learn-build-service-prod[bot] avatar](https://avatars.githubusercontent.com/in/237442?v=4 "Published by a pub.dev verified publisher"){kind=small}
PRMerger Results
| Issue | Description |
|---|---|
| Yaml File(s) | This PR includes changes to .yml file(s) owned by another author. |
@AbbyMSFT
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged" @MicrosoftDocs/public-repo-pr-review-team
Metric alerts don't support firing alerts at a subscription or resource group level. While it's true that for resource types that support multi-resource metric alerts, the scope can be a one or more subscriptions / resource groups / resources, the actual evaluation and the fired alerts are always done at the individual resource level.
Metric alerts don't support firing alerts at a subscription or resource group level. While it's true that for resource types that support multi-resource metric alerts, the scope can be a one or more subscriptions / resource groups / resources, the actual evaluation and the fired alerts are always done at the individual resource level.
Thanks for your answer. I'm not sure whether we are talking about the same thing but in the portal -> Azure Monitor -> Alert -> Alert rule, I can choose the scope to be subscription, resource group or individual resources:
Here, I've chosen a subscription:
Here, I've chosen a resource group:
Today, the UI supports the following scopes:
- Single resource, resource group, or subscription
- Multiple resources (of the same type)
- Multiple resource groups
When using API, there's also an ability to select multiple subscriptions as the scope. We have plans to support this through the UI as well in future releases.
Regardless of the scope defined, the evaluation is always performed on the individual resource level (e.g. the 'Transactions' metric of a Storage Account), or on a dimension combination under the resource (e.g. the 'Transactions' metric of a Storage Account where 'API name' equals 'Get Blobs').
Hope this helps.
Today, the UI supports the following scopes:
- Single resource, resource group, or subscription
- Multiple resources (of the same type)
- Multiple resource groups
When using API, there's also an ability to select multiple subscriptions as the scope. We have plans to support this through the UI as well in future releases.
Regardless of the scope defined, the evaluation is always performed on the individual resource level (e.g. the 'Transactions' metric of a Storage Account), or on a dimension combination under the resource (e.g. the 'Transactions' metric of a Storage Account where 'API name' equals 'Get Blobs').
Hope this helps.
Thanks for explanation. In the first comment, I brought up a question:
if an alert is scoped at subscription level, but the condition is met only at its underlying resource group level, what happens? Does subscription-level alert get triggered?
Given your explanation, I presume the answer is yes. Alerts get triggered because they are evaluated at individual resource level and it doesn't matter what was scope of the alert (i.e. subscription, resource group or resource). Please correct me if I'm wrong.
Regardless, I believe these explanations and nuances should be clearly explained in the doc. Once you clarify my question, I'll make an edit.
In the case described in the certification exam's question, even if the alert rule is defined at the subscription scope, the fired alert will be at the granularity of the offending resource, not the subscription.
I can take this with @AbbyMSFT to clarify this in the doc. @azarboon - Really appreciate your time and effort investment to help improve our docs!
In the case described in the certification exam's question, even if the alert rule is defined at the subscription scope, the fired alert will be at the granularity of the offending resource, not the subscription.
I can take this with @AbbyMSFT to clarify this in the doc. @azarboon - Really appreciate your time and effort investment to help improve our docs!
Thank you for clarifying.
Honestly, I'm surprised why these nuances and edge cases haven't been already addressed in the doc. But it's my pleasure to help you and community in general.
@AbbyMSFT I've edited the PR according to latest info I've received from @harelbr . Can you please tune it further?
Learn Build status updates of commit 13713e1:
:white_check_mark: Validation status: passed
| File | Status | Preview URL | Details |
|---|---|---|---|
| articles/azure-monitor/alerts/alerts-create-metric-alert-rule.yml | :white_check_mark:Succeeded |
For more details, please refer to the build report.
For any questions, please:
- Try searching the learn.microsoft.com contributor guides
- Post your question in the Learn support channel
PRMerger Results
| Issue | Description |
|---|---|
| Yaml File(s) | This PR includes changes to .yml file(s) owned by another author. |
Learn Build status updates of commit f0b59a7:
:white_check_mark: Validation status: passed
| File | Status | Preview URL | Details |
|---|---|---|---|
| articles/azure-monitor/alerts/alerts-create-metric-alert-rule.yml | :white_check_mark:Succeeded |
For more details, please refer to the build report.
For any questions, please:
- Try searching the learn.microsoft.com contributor guides
- Post your question in the Learn support channel
PRMerger Results
| Issue | Description |
|---|---|
| Yaml File(s) | This PR includes changes to .yml file(s) owned by another author. |
You're right, the answer is both.
Thanks, Harel
From: Mahdi Azarboon @.> Sent: Friday, July 5, 2024 10:13 To: MicrosoftDocs/azure-docs @.> Cc: Harel Broitman @.>; Mention @.> Subject: Re: [MicrosoftDocs/azure-docs] Update alerts-create-metric-alert-rule.yml (PR #123568)
@harelbrhttps://github.com/harelbr I just remembered another flavor of this question and I would like to know the answer: Let's say you set alert rules for all administrative operations at both levels: resource group and resource. If you change your vm, which alerts does get triggered? Only at resource level, at resource level or both? I guess the answer is both, but can you please confirm it.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/pull/123568#issuecomment-2210325339, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACPWVZLX2MU2JIDTDSYCDALZKZBPLAVCNFSM6AAAAABKBNP532VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJQGMZDKMZTHE. You are receiving this because you were mentioned.Message ID: @.@.>>
You're right, the answer is both. Thanks, Harel From: Mahdi Azarboon @.> Sent: Friday, July 5, 2024 10:13 To: MicrosoftDocs/azure-docs @.> Cc: Harel Broitman @.>; Mention @.> Subject: Re: [MicrosoftDocs/azure-docs] Update alerts-create-metric-alert-rule.yml (PR #123568) @harelbrhttps://github.com/harelbr I just remembered another flavor of this question and I would like to know the answer: Let's say you set alert rules for all administrative operations at both levels: resource group and resource. If you change your vm, which alerts does get triggered? Only at resource level, at resource level or both? I guess the answer is both, but can you please confirm it. - Reply to this email directly, view it on GitHub<#123568 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACPWVZLX2MU2JIDTDSYCDALZKZBPLAVCNFSM6AAAAABKBNP532VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJQGMZDKMZTHE. You are receiving this because you were mentioned.Message ID: @.@.>>
Thanks @harelbr for clarification. Actually in the meantime, I posted this question on Microsoft Learn and got interesting results: One participant (I believe he is a Microsoft employee, by checking from his LinkedIn), elaborated a different facet of this:
alerts can be stateful or stateless: Stateless alerts fire each time the condition is met, even if fired previously Stateful alerts fire when the rule conditions are met, and will not fire again or trigger any more actions until the conditions are resolved Metric alerts are stateful by default, so other alerts aren't fired if there's already a fired alert on a specific time series.
Is his answer correct or wrong? I mean, does stateless and stateful apply to this situation, i.e. having different alerts at different scopes? Regardless, this point is very nuanced (so that even experts have different opinions on it) and it should be clearly elaborated in the documentation. Once you confirm / reject this, I'll edit the PR.
The comment about stateless and stateful alerts is correct, but it doesn't apply to the scenario you've described.
- We support stateless and stateful alerts today, but only for metric and log alerts. Your question was about alerting on administrative operations from Activity Log, and Activity Log alerts are always stateless.
- If you set up separate alert rules that monitor the same condition, then they'll always fire independently, even if the alert rules are stateful.
Hope this helps.
From: Mahdi Azarboon @.> Sent: Monday, July 8, 2024 11:38 To: MicrosoftDocs/azure-docs @.> Cc: Harel Broitman @.>; Mention @.> Subject: Re: [MicrosoftDocs/azure-docs] Update alerts-create-metric-alert-rule.yml (PR #123568)
You're right, the answer is both. Thanks, Harel From: Mahdi Azarboon @.> Sent: Friday, July 5, 2024 10:13 To: MicrosoftDocs/azure-docs @.> Cc: Harel Broitman @.>; Mention @.> Subject: Re: [MicrosoftDocs/azure-docs] Update alerts-create-metric-alert-rule.yml (PR #123568https://github.com/MicrosoftDocs/azure-docs/pull/123568) @harelbrhttps://github.com/harelbrhttps://github.com/harelbr I just remembered another flavor of this question and I would like to know the answer: Let's say you set alert rules for all administrative operations at both levels: resource group and resource. If you change your vm, which alerts does get triggered? Only at resource level, at resource level or both? I guess the answer is both, but can you please confirm it. - Reply to this email directly, view it on GitHub<#123568 (comment)https://github.com/MicrosoftDocs/azure-docs/pull/123568#issuecomment-2210325339>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACPWVZLX2MU2JIDTDSYCDALZKZBPLAVCNFSM6AAAAABKBNP532VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJQGMZDKMZTHE. You are receiving this because you were mentioned.Message ID: @.@.>>
Thanks @harelbrhttps://github.com/harelbr for clarification. Actually in the meantime, I posted this question on Microsoft Learnhttps://learn.microsoft.com/en-us/answers/questions/1803685/which-alert-gets-triggered?page=1&orderby=Helpful&comment=answer-1572747&sharingId=B418CFC853E05910 and got interesting results: One participant shared the same answer as yours but another one (I believe he is a Microsoft employee, by checking from his LinkedIn), elaborated a different facet of it:
alerts can be stateful or stateless: Stateless alerts fire each time the condition is met, even if fired previously Stateful alerts fire when the rule conditions are met, and will not fire again or trigger any more actions until the conditions are resolved Metric alerts are stateful by default, so other alerts aren't fired if there's already a fired alert on a specific time series.
Is his answer correct or wrong? I mean, does stateless and stateful apply to this situation, i.e. having different alerts at different scopes? Regardless, this point is very nuanced and it should be clearly elaborated in the documentation. Once you confirm / reject this, I'll edit the PR.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/pull/123568#issuecomment-2213377594, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACPWVZJ3GTCFCCENUBNXVA3ZLJFXZAVCNFSM6AAAAABKBNP532VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJTGM3TONJZGQ. You are receiving this because you were mentioned.Message ID: @.@.>>
Thanks a lot for explanation. I've added this PR to incorporate your comments. Please feel free to tune it further or add anything missing. @AbbyMSFT
Also, I've also created a new PR to explain relevant nuances related to statefulness and statelessness. Would be great if you chime in your opinions there so we elaborate it comprehensively and accurately.
Learn Build status updates of commit 01de7b3:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.
| File | Status | Preview URL | Details |
|---|---|---|---|
| articles/azure-monitor/alerts/alerts-create-metric-alert-rule.yml | :x:Error | Details |
articles/azure-monitor/alerts/alerts-create-metric-alert-rule.yml
- Line 85, Column 1: [Error: yaml-syntax-error - See documentation]
While scanning a block scalar, did not find expected comment or line break.
For more details, please refer to the build report.
Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:
- Try searching the learn.microsoft.com contributor guides
- Post your question in the Learn support channel
Learn Build status updates of commit be2b059:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.
| File | Status | Preview URL | Details |
|---|---|---|---|
| articles/azure-monitor/alerts/alerts-create-metric-alert-rule.yml | :x:Error | Details |
articles/azure-monitor/alerts/alerts-create-metric-alert-rule.yml
- Line 85, Column 1: [Error: yaml-syntax-error - See documentation]
While scanning a block scalar, did not find expected comment or line break.
For more details, please refer to the build report.
Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:
- Try searching the learn.microsoft.com contributor guides
- Post your question in the Learn support channel
@AbbyMSFT given that other PR explains the nuances about state, I've reduced the content of this PR. This PR now covers only the scope part. Kindly please review and sign this off, too.
Learn Build status updates of commit 70e0b0f:
:white_check_mark: Validation status: passed
| File | Status | Preview URL | Details |
|---|---|---|---|
| articles/azure-monitor/alerts/alerts-create-metric-alert-rule.yml | :white_check_mark:Succeeded |
For more details, please refer to the build report.
For any questions, please:
- Try searching the learn.microsoft.com contributor guides
- Post your question in the Learn support channel
PRMerger Results
| Issue | Description |
|---|---|
| Yaml File(s) | This PR includes changes to .yml file(s) owned by another author. |
@AbbyMSFT
Can you respond to the comment above?
@MicrosoftDocs/public-repo-pr-review-team
