在 Azure 门户中创建和管理器操作组

操作组是由 Azure 订阅的所有者定义的通知首选项的集合。 Azure Monitor、服务运行状况和 Azure 顾问警报使用操作组来通知用户已经触发了警报。 各种警报可以使用相同的操作组或不同的操作组,具体取决于用户的要求。

本文演示如何在 Azure 门户中创建和管理操作组。

每个操作包含以下属性:

  • 操作类型:执行的通知或操作。 示例包括发送语音呼叫、短信、电子邮件,或者触发各种类型的自动化操作。 请参阅本文下文中的“类型”。
  • Name:操作组中的唯一标识符。
  • 详细信息:因“类型”而异的相应详细信息。

有关如何使用 Azure 资源管理器模板以配置操作组的信息,请参阅操作组资源管理器模板

操作组是“全球”服务,因此不依赖于特定的 Azure 区域。 来自客户端的请求可以由任何区域的操作组服务处理,这意味着如果一个区域的服务宕机,流量将自动由其他区域进行路由和处理。 作为一项全球服务,它可以帮助客户不必担心灾难恢复。

使用 Azure 门户创建操作组

  1. Azure 门户中,搜索并选择“监视”。 “监视”窗格将所有监视设置和数据合并到一个视图中。

  2. 选择“警报”,然后选择“操作组”。

  1. 选择“创建”,并在向导体验中填写相关字段。

配置基本操作组设置

在“项目详细信息”下:

选择在其中保存操作组的“订阅”和“资源组” 。

在“实例详细信息”下:

  1. 输入“操作组名称”。

  2. 输入“显示名称”。 使用此组发送通知时,显示名称被用来代替完整的操作组名称。

    The

配置通知

  1. 单击“下一步: 通知 ”按钮以移动到“通知”选项卡,或选择屏幕顶部的“通知”选项卡。

  2. 定义触发警报时要发送的通知的列表。 为每个通知提供以下信息:

    a. 通知类型:选择要发送的通知的类型。 可用选项是:

    • 向 Azure 资源管理器角色发送电子邮件 - 将电子邮件发送给分配有某些订阅级别 ARM 角色的用户。
    • 电子邮件/短信/推送/语音 - 将这些通知类型发送给特定收件人。

    b. 名称:输入通知的唯一名称。

    c. 详细信息:根据所选的通知类型,输入电子邮件地址、电话号码等。

    d. 常见警报架构:可以选择启用常见警报架构,这可获得在 Azure Monitor 中的所有警报服务中具有单个可扩展和统一的警报有效负载的优势。

    The Notifications tab

配置操作

  1. 单击“下一步: 操作 ”按钮以移动到“操作”选项卡,或选择屏幕顶部的“操作”选项卡。

  2. 定义触发警报时要触发的操作的列表。 为每个操作提供以下内容:

    a. 操作类型:选择自动化 Runbook、Azure Function、逻辑应用、安全 Webhook、Webhook。

    b. 名称:输入操作的唯一名称。

    c. 详细信息:根据操作类型,输入 Webhook URI、Azure 应用或自动化 Runbook。

    d. 常见警报架构:可以选择启用常见警报架构,这可获得在 Azure Monitor 中的所有警报服务中具有单个可扩展和统一的警报有效负载的优势。

    The Actions tab

创建操作组

  1. 如果你愿意,可以浏览“选项卡”设置。 这使你可将键/值对关联到操作组以进行分类,并且该功能可用于任何 Azure 资源。

    The Tags tab

  2. 单击“查看 + 创建”以查看设置。 这将快速验证输入,确保已选择所有必填字段。 如果有问题,将在此处报告。 查看设置后,单击“创建”预配操作组。

    The Review + create tab

注意

当配置操作来通过电子邮件或短信通知某个人员时,该人员将收到确认,指出其已被添加到操作组。

在 Azure 门户(预览版)中测试操作组

在 Azure 门户中创建或更新操作组时,可以测试操作组。

  1. 创建操作规则后,请单击“查看 + 创建”。 选择“测试操作组”。

    The Test Action Group

  2. 选择“示例类型”,然后选择要测试的通知和操作类型,然后选择“测试”。

    Select Sample Type + notification + action type

  3. 如果关闭窗口或选择“返回到测试设置”,同时测试正在运行,则测试将停止,并且不会获得测试结果。

    Stop running test

  4. 测试完成后,将显示“成功”或“失败”测试状态。 如果测试失败,可选择“查看详细信息”以获取详细信息。
    Test sample failed

你可以使用“错误详细信息”部分中的信息来了解问题,以便你可以再次编辑和测试操作组。 为了让你能够在生产环境中启用操作组之前查看操作组是否按预期运行,系统将向你发送主题为“测试”的电子邮件和短信警报。

“测试”电子邮件通知中有关已触发警报的所有详细信息和链接都是用于参考的示例集。

注意

测试操作组中的操作数可能有限。 请参阅速率限制信息一文。

可以在门户上通过操作组选择加入或退出常见警报架构。 可以查找所有示例类型的测试操作组的常见架构示例。 可以在门户上通过操作组选择加入或退出不常见的警报架构。 可以找到不常见的架构警报定义

管理操作组

在创建操作组后,可以通过从“监视器”窗格中的“警报”登陆页选择“操作组”来查看操作组。 选择要管理的操作组:

  • 添加、编辑或删除操作。
  • 删除操作组。

特定于操作的信息

注意

请参阅针对监视的订阅服务限制,了解下面每个项的数值限制。

自动化 Runbook

有关针对 Runbook 有效负载的限制,请参阅 Azure 订阅服务限制

操作组中的 Runbook 操作数可能有限。

电子邮件

将从以下电子邮件地址发送电子邮件。 确保电子邮件筛选正确配置

  • azure-noreply@microsoft.com
  • azureemail-noreply@microsoft.com
  • alerts-noreply@mail.windowsazure.cn

操作组中的电子邮件操作数可能有限。 请参阅速率限制信息一文。

通过电子邮件发送 Azure 资源管理器角色

向订阅角色的成员发送电子邮件。 电子邮件将仅发送给该角色的“Azure AD 用户”成员。 不会将电子邮件发送到 Azure AD 组或服务主体。

通知电子邮件将只发送到主电子邮件地址。

如果你没有在主电子邮件中收到通知,则可以尝试以下步骤:

  1. 在 Azure 门户中,转到“Active Directory”。
  2. 单击“所有用户”(在左窗格中),你将看到用户列表(在右窗格中)。
  3. 选择你要查看其“主电子邮件”信息的用户。

Example of how to review user profile.

  1. 在“联系人信息”下的“用户配置文件”中,如果“电子邮件”选项卡为空白,请单击顶部的“编辑”按钮,然后添加你的“主电子邮件”,然后单击顶部的“保存”按钮。

Example of how to add primary email.

操作组中的电子邮件操作数可能有限。 请参阅速率限制信息一文。

设置电子邮件 ARM 角色时,需要确保满足以下 3 个条件:

  1. 要分配给角色的实体类型需要为“用户”。
  2. 需要在“订阅”级别完成分配。
  3. 用户需要在其“AAD 配置文件”中配置电子邮件。

注意

在将新的 ARM 角色添加到订阅之后,客户可能需要多达 24 小时才能开始接收通知。

事件中心

事件中心操作会将通知发布到 Azure 事件中心。 然后,你可以订阅来自事件接收器的警报通知流。

函数

调用 Azure Functions 中的现有 HTTP 触发器终结点。 若要处理请求,终结点必须处理 HTTP POST 谓词。

定义函数操作时,函数的 httptrigger 终结点和访问密钥会保存在操作定义中。 例如:https://azfunctionurl.chinacloudsites.cn/api/httptrigger?code=this_is_access_key。 如果更改函数的访问密钥,则需要在操作组中删除并重新创建函数操作。

操作组中的函数操作数可能有限。

逻辑应用

操作组中的逻辑应用操作数可能有限。

安全 Webhook

操作组安全 Webhook 操作使你能够利用 Azure Active Directory 来保护操作组和受保护的 Web API(Webhook 终结点)之间的连接。 下面介绍了利用此功能的整个工作流。 有关 Azure AD 应用程序和服务主体的概述,请参阅 Microsoft 标识平台 (v2.0) 概述

注意

使用 Webhook 操作要求目标 Webhook 终结点能够处理不同警报源发出的各种 JSON 有效负载。 如果 Webhook 终结点需要特定的架构,则应使用逻辑应用操作来转换警报架构以满足目标 Webhook 的预期。

  1. 针对受保护的 Web API 创建 Azure AD 应用程序。 请参阅受保护的 Web API:应用注册中的说明进行操作。

    注意

    必须将受保护的 Web API 配置为接受 V2.0 访问令牌

  2. 启用操作组以使用 Azure AD 应用程序。

    注意

    你必须是 Azure AD 应用程序管理员角色的成员才能执行此脚本。

    • 修改 PowerShell 脚本的 Connect-AzureAD 调用以使用 Azure AD 租户 ID。
    • 修改 PowerShell 脚本的变量 $myAzureADApplicationObjectId,以便使用 Azure AD 应用程序的对象 ID。
    • 运行修改的脚本。

    注意

    服务原则必须是 Azure AD 应用程序的所有者角色,才能在操作组中创建或修改安全 Webhook 操作。

  3. 配置操作组安全 Webhook 操作。

    • 从脚本中复制值 $myApp.ObjectId,并将其输入到 Webhook 操作定义中的“应用程序对象 ID”字段。

    Secure Webhook action

安全 Webhook PowerShell 脚本

Connect-AzureAD -TenantId "<provide your Azure AD tenant ID here>"
    
# This is your Azure AD Application's ObjectId. 
$myAzureADApplicationObjectId = "<the Object ID of your Azure AD Application>"
    
# This is the Action Group Azure AD AppId
$actionGroupsAppId = "461e8683-5575-4561-ac7f-899cc907d62a"
    
# This is the name of the new role we will add to your Azure AD Application
$actionGroupRoleName = "ActionGroupsSecureWebhook"
    
# Create an application role of given name and description
Function CreateAppRole([string] $Name, [string] $Description)
{
    $appRole = New-Object Microsoft.Open.AzureAD.Model.AppRole
    $appRole.AllowedMemberTypes = New-Object System.Collections.Generic.List[string]
    $appRole.AllowedMemberTypes.Add("Application");
    $appRole.DisplayName = $Name
    $appRole.Id = New-Guid
    $appRole.IsEnabled = $true
    $appRole.Description = $Description
    $appRole.Value = $Name;
    return $appRole
}
    
# Get my Azure AD Application, it's roles and service principal
$myApp = Get-AzureADApplication -ObjectId $myAzureADApplicationObjectId
$myAppRoles = $myApp.AppRoles
$actionGroupsSP = Get-AzureADServicePrincipal -Filter ("appId eq '" + $actionGroupsAppId + "'")

Write-Host "App Roles before addition of new role.."
Write-Host $myAppRoles
    
# Create the role if it doesn't exist
if ($myAppRoles -match "ActionGroupsSecureWebhook")
{
    Write-Host "The Action Group role is already defined.`n"
}
else
{
    $myServicePrincipal = Get-AzureADServicePrincipal -Filter ("appId eq '" + $myApp.AppId + "'")
    
    # Add our new role to the Azure AD Application
    $newRole = CreateAppRole -Name $actionGroupRoleName -Description "This is a role for Action Group to join"
    $myAppRoles.Add($newRole)
    Set-AzureADApplication -ObjectId $myApp.ObjectId -AppRoles $myAppRoles
}
    
# Create the service principal if it doesn't exist
if ($actionGroupsSP -match "AzNS AAD Webhook")
{
    Write-Host "The Service principal is already defined.`n"
}
else
{
    # Create a service principal for the Action Group Azure AD Application and add it to the role
    $actionGroupsSP = New-AzureADServicePrincipal -AppId $actionGroupsAppId
}
    
New-AzureADServiceAppRoleAssignment -Id $myApp.AppRoles[0].Id -ResourceId $myServicePrincipal.ObjectId -ObjectId $actionGroupsSP.ObjectId -PrincipalId $actionGroupsSP.ObjectId
    
Write-Host "My Azure AD Application (ObjectId): " + $myApp.ObjectId
Write-Host "My Azure AD Application's Roles"
Write-Host $myApp.AppRoles

SMS

有关其他重要信息,请参阅速率限制信息短信警报行为

操作组中的短信操作数可能有限。

注意

如果在 Azure 门户操作组用户界面无法选择你的国家/地区代码,则表示你所在的国家/地区不支持短信。 如果你的国家/地区代码不可用,则可以在用户之声投票以请求添加你的国家/地区。 此时,一个解决办法是使操作组向你所在国家/地区支持的第三方短信提供商调用 Webhook。

受支持国家/地区的定价在 Azure Monitor 定价页中列出。

支持短信通知的国家/地区列表

国家/地区代码 国家/地区名称
61 澳大利亚
43 奥地利
32 比利时
55 巴西
1 加拿大
56 智利
86 中国
420 捷克共和国
45 丹麦
372 爱沙尼亚
358 芬兰
33 法国
49 德国
852 香港特别行政区
91 印度
353 爱尔兰
972 以色列
39 意大利
81 日本
352 卢森堡
60 马来西亚
52 墨西哥
31 荷兰
64 新西兰
47 挪威
351 葡萄牙
1 波多黎各
40 罗马尼亚
7 俄罗斯
65 新加坡
27 南非
82 韩国
34 西班牙
41 瑞士
886 台湾
971 阿拉伯联合酋长国
44 英国
1 美国

语音

有关其他重要行为,请参阅速率限制信息一文。

操作组中的语音操作数可能有限。

注意

如果在 Azure 门户操作组用户界面无法选择你的国家/地区代码,则表示你所在的国家/地区不支持语音呼叫。 如果你的国家/地区代码不可用,则可以在用户之声投票以请求添加你的国家/地区。 此时,一个解决办法是使操作组向你所在国家/地区支持的第三方语音呼叫提供商调用 Webhook。
目前在 Azure 门户操作组中支持语音通知的国家/地区代码只有“+1(美国)”。

受支持国家/地区的定价在 Azure Monitor 定价页中列出。

Webhook

注意

使用 Webhook 操作要求目标 Webhook 终结点能够处理不同警报源发出的各种 JSON 有效负载。 如果 Webhook 终结点需要特定的架构,则应使用逻辑应用操作来转换警报架构以满足目标 Webhook 的预期。

Webhook 使用以下规则进行处理

  • 最多尝试三次 Webhook 调用。
  • 如果在超时期限内未收到响应,或者返回以下 HTTP 状态代码之一,将重试此调用:408、429、503 或 504。
  • 第一次调用将等待响应 10 秒。
  • 第二次和第三次尝试将等待响应 30 秒。
  • 三次尝试调用 Webhook 失败后,任何操作组在 15 分钟内都不会再调用该终结点。

有关源 IP 地址范围,请参阅操作组 IP 地址

后续步骤