你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

行动小组

当 Azure Monitor 数据指示基础结构或应用程序中的潜在问题时，它会触发警报。为了确保及时响应，可以将操作组附加到这些警报上，这些警报是通知首选项和自动操作的集合。

操作组定义了谁收到通知，以及警报触发时采取的措施。它们支持多种通知类型，包括语音呼叫、短信、推送通知、电子邮件和自动作（例如触发 Webhook 或 Azure 函数）。这些组用于 Azure Monitor、 Azure 服务运行状况和 Azure 顾问等服务。

每个操作由以下部分组成：

类型：通知或自动化的类型。
名称：操作组中的唯一标识符。
详细信息：基于操作类型的特定配置。

本文介绍了如何创建和管理操作组。

全局可用性和复原能力

任何区域中的操作组服务都可以处理来自客户端的全局请求。如果操作组服务的一个区域关闭，则流量会自动在其他区域中路由和处理。作为全局服务，操作组有助于提供灾难恢复解决方案。

Note

区域请求依赖于可用性区域冗余来满足隐私要求，并提供类似的灾难恢复解决方案。

可重用性和执行过程

最多可以向单个警报规则添加五个操作组。
操作组是并发执行的，不按特定顺序执行。
多个警报规则可以使用相同的操作组。
操作组由唯一的操作集和要通知的用户定义。
例：若要通过电子邮件通知 User1、User2 和 User3 两个不同的警报规则，只需创建一个作组并将其应用于这两个警报规则。

在 Azure 门户中创建操作组

转到 Azure 门户。
搜索并选择“Monitor”。 “监视”窗格将所有监视设置和数据合并到一个视图中。
选择“警报”，然后选择“操作组”。
从顶部作栏中选择“ 创建 ”。

配置基本操作组设置。在“项目详细信息”部分中：

为“订阅”和“资源组”选择值。
选择区域。

Note

服务运行状况警报仅在全局区域的公有云中受支持。要使作组在响应服务运行状况警报时能够正常运行，必须将作组的区域设置为 “全局”。

Option	Behavior
Global	操作组服务决定操作组的存储位置。操作组至少保留在两个区域中，以确保区域复原能力。可以在任何地理区域中处理操作。因服务健康状况警报而执行的语音、短信和电子邮件操作在出现 Azure 实时站点事件时可复原。
Regional	操作组存储在所选区域中。操作组是区域冗余的。如果需确保操作组的处理流程限定在特定地理边界内，请使用此选项。可以选择以下区域之一来进行操作组的区域处理： • 美国东部 • 美国西部 • 美国东部 2 • 美国西部 2 • 美国中南部 • 美国中北部 • 瑞典中部 • 德国中西部 • 印度中部 • 印度南部我们将继续添加更多区域，以进行操作组的区域数据处理。

Option

Behavior

Global

操作组服务决定操作组的存储位置。操作组至少保留在两个区域中，以确保区域复原能力。可以在任何地理区域中处理操作。

因服务健康状况警报而执行的语音、短信和电子邮件操作在出现 Azure 实时站点事件时可复原。

Regional

操作组存储在所选区域中。操作组是区域冗余的。如果需确保操作组的处理流程限定在特定地理边界内，请使用此选项。

可以选择以下区域之一来进行操作组的区域处理：
• 美国东部
• 美国西部
• 美国东部 2
• 美国西部 2
• 美国中南部
• 美国中北部
• 瑞典中部
• 德国中西部
• 印度中部
• 印度南部

我们将继续添加更多区域，以进行操作组的区域数据处理。

操作组保存在你选择的订阅、区域和资源组中。

在“实例详细信息”部分中，输入“操作组名称”和“显示名称”的值。使用此组发送通知时，显示名称用于代替完整的操作组名称。
配置通知。选择“下一步: 通知”或页面顶部的“通知”选项卡。
定义触发警报时要发送的通知的列表。

对于每个通知：

选择“通知类型”，然后填写该通知的相应字段。可用选项是：

通知类型	Description	Fields
向 Azure 资源管理器角色发送电子邮件	根据订阅成员的角色向其发送电子邮件。请参阅电子邮件。	输入为 Microsoft Entra 用户配置的主电子邮件地址。请参阅电子邮件。
Email	确保正确配置电子邮件筛选和任何恶意软件/垃圾邮件防护服务。电子邮件从以下电子邮件地址发送： • azure-noreply@microsoft.com • azureemail-noreply@microsoft.com • alerts-noreply@mail.windowsazure.com	输入应在其中发送通知的电子邮件。
短信	短信通知支持双向通信。短信包含以下信息： • 要接收此警报的操作组的短名称 • 警报的标题。用户可以回复短信以实现以下目标： • 取消订阅所有操作组或单个操作组的所有短信警报。 • 重新订阅警报 • 请求帮助。有关支持的短信回复的详细信息，请参阅短信回复。	输入短信收件人的国家/地区代码和电话号码。如果无法在 Azure 门户中选择国家/地区代码，则你所在的国家/地区不支持短信。如果你的国家/地区代码不可用，则可以在分享想法投票以请求添加你的国家/地区。临时解决方案（你所在国家/地区未获得支持时适用）：将操作组配置为调用 Webhook，指向支持你所在国家/地区的第三方短信服务商。
Azure 应用推送通知	将通知发送到 Azure 移动应用。	在“Azure 帐户电子邮件”字段中，输入配置 Azure 移动应用时用作帐户 ID 的电子邮件地址。
Voice	语音通知。	输入通知收件人的国家/地区代码和电话号码。如果无法在 Azure 门户中选择国家/地区代码，则你所在国家/地区不支持语音通知。如果你的国家/地区代码不可用，则可以在分享想法投票以请求添加你的国家/地区。在支持你的国家/地区之前，作为一种解决方案，可配置操作组以向支持你所在国家/地区的第三方语音呼叫提供商调用 Webhook。

选择是否要启用通用警报架构。通用警报架构的优点是一种单一可扩展且的警报有效负载，可用于 Azure Monitor 中的所有警报服务。有关通用架构的详细信息，请参阅通用警报架构。
选择“确定”。

配置操作。选择“下一步：操作”。或选择页面顶部的“操作”选项卡。

定义触发警报时要触发的操作的列表。选择一个操作类型，并输入每个操作的名称。

操作类型	Details
自动化操作手册	使用自动化 Runbook 根据指标自动执行任务。例如，在达到相关预算中的特定阈值时关闭资源。有关自动化 Runbook 有效负载限制的信息，请参阅自动化限制。
事件中心	事件中心操作将通知发布到事件中心。它是支持 Azure 专用链接和网络安全外围（NSP）的唯一作类型。有关事件中心的详细信息，请参阅 Azure 事件中心 - 大数据流式处理平台和事件引入服务。你可以订阅来自事件接收器的警报通知流。事件中心支持跨租户功能，最高支持 API 版本 2023-09-01-preview*
Functions	在函数中调用现有的 HTTP 触发终结点。有关详细信息，请参阅 Azure Functions。定义函数操作时，函数的 HTTP 触发终结点和访问密钥会保存在操作定义中，例如 `https://azfunctionurl.azurewebsites.net/api/httptrigger?code=<access_key>`。如果更改函数的访问密钥，则必须在操作组中移除并重新创建函数操作。终结点必须支持 HTTP POST 方法。函数必须有权访问存储帐户。如果它没有访问权限，则密钥不可用，并且无法访问函数 URI。了解如何还原对存储帐户的访问权限。
ITSM	ITSM 操作需要 ITSM 连接。若要了解如何创建 ITSM 连接，请参阅 ITSM 集成。
逻辑应用程序	可以使用 Azure 逻辑应用来生成和自定义用于集成的工作流，以及自定义警报通知。
确保 Webhook 安全	使用安全 Webhook 操作时，必须使用 Microsoft Entra ID 来保护操作组与终结点（即受保护的 Web API）之间的连接。请参阅配置安全 Webhook 的身份验证。安全 Webhook 不支持基本身份验证。如果使用的是基本身份验证，请使用 Webhook 操作。
Webhook	如果使用 Webhook 操作，则目标 Webhook 终结点必须能够处理不同警报源发出的各种 JSON 有效负载。无法通过 Webhook 操作传递安全证书。若要使用基本身份验证，必须通过 URI 传递凭据。如果 Webhook 终结点需要特定的架构（例如 Microsoft Teams 架构），请使用逻辑应用操作类型来控制警报架构以满足目标 Webhook 的预期。有关重试 webhook 操作所用规则的信息，请参阅 Webhook。

显示“创建作组”对话框中“操作”选项卡的屏幕截图。“操作类型”列表中显示了多个选项。

（可选）如果要将键值对分配给操作组以对 Azure 资源进行分类，请选择下一步：标记 或标记选项卡。否则，请跳过此步骤。
选择“查看 + 创建”以查看设置。此步骤会快速检查输入，以确保输入所有必需信息。如果有问题，将在此处报告。在查看设置后，选择“创建”以创建动作组。

Note

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

在 Azure 门户中测试操作组

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

在 Azure 门户中创建操作组。

Note

在测试之前，必须创建和保存操作组。如果要编辑已存在的操作组，则先保存对操作组进行的更改，然后再进行测试。
在 操作组 页面上，选择一个操作组，然后从顶部操作栏中选择测试。
选择示例类型以及要测试的通知和操作类型。然后选择“测试”。
如果关闭窗口或选择“返回到测试设置”，而此时测试正在运行，则测试将停止，你不会获得测试结果。
测试完成后，将显示“成功”或“失败”测试状态。如果测试失败，而你想要获取详细信息，请选择“查看详细信息”。

你可以使用“错误详细信息”部分的信息来了解问题。然后，你可以再次进行编辑、保存更改并测试操作组。

运行测试并选择通知类型时，会收到主题中带有“测试”字样的消息。这些测试提供了一种方法，用于在生产环境中启用操作组之前检查操作组是否按预期工作。测试电子邮件通知中的所有详细信息和链接都来自示例参考集。

将托管身份与 Azure 操作组配合使用（预览版）

Azure操作组现在支持托管标识，以便在调用下游服务时进行安全无凭据的身份验证。此功能现已以预览版提供。

执行以下步骤以在操作组中使用现有托管身份：

将操作组配置为对操作组中的每个操作使用首选身份。
确保将所需的角色分配给所选标识。
为进行身份验证的调用授予对资源（操作类型）的托管标识访问权限。请参阅使用 Azure 门户授予对资源的托管标识权限。

支持的动作类型

下表列出了托管身份支持的动作类型：

操作类型	托管标识支持	角色分配名称	角色 ID
自动化操作手册	是的	自动化参与者	f353d9bd-d4a6-484e-a77a-8050b599b867
Azure 函数	否
事件中心	是的	Azure 事件中心数据发送方	2b629674-e913-4c01-ae53-ef4638d8f975
ITSM	否
逻辑应用	是的	Logic App 贡献者	87a39d53-fc1b-424a-814c-f7e04687dc9e
安全 Webhook	否
Webhook	否

Note

如果使用 Azure 门户配置托管标识，角色分配将自动添加到您的标识中。对于 PowerShell、CLI 或 SDK 配置，必须手动分配角色。

测试操作组的角色要求

下表描述了“测试操作”功能所需的角色成员身份要求：

角色成员身份	现有操作组	现有资源组和新操作组	新资源组和新操作组
订阅参与者	Supported	Supported	Supported
资源组参与者	Supported	Supported	不適用
操作组资源参与者	Supported	不適用	不適用
Azure Monitor 参与者	Supported	Supported	不適用
自定义角色 ¹	Supported	Supported	不適用

¹ 自定义角色必须添加 Microsoft.Insights/ActionGroups/* 权限，该权限还允许用户更新和删除作组。若要添加限制，使用户只能测试操作组，请在自定义角色的 JSON 选项卡下添加以下内容：

{
    "properties": {
        "roleName": "",
        "description": "",
        "assignableScopes": [
            "/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}"
        ],
        "permissions": [
            {
                "actions": [
                    "Microsoft.Insights/ActionGroups/*"
                ],
                "notActions": [
                    "Microsoft.Insights/ActionGroups/write",
                    "Microsoft.Insights/ActionGroups/delete"
                ],
                "dataActions": [],
                "notDataActions": []
            }
        ]
    }
}

Note

可以按时间段运行有限数量的测试。如要检查哪些限制适用于你的情况，请参阅 Azure Monitor 服务限制。
在门户中配置操作组时，可以选择加入或退出常见警报架构。
- 如要查找所有示例类型的常见架构示例，请参阅测试操作组的常见警报架构定义。
- 若要查找非通用架构警报定义，请参阅测试作组的非通用警报架构定义。

使用资源管理器模板创建操作组

可以使用 Azure 资源管理器模板配置操作组。使用模板，可以自动设置可以在某些类型的警报中重复使用的操作组。这些操作组可确保警报触发时所有相应的当事方可以收到通知。

基本步骤如下：

以 JSON 文件的形式创建一个描述如何创建操作组的模板。
使用任意部署方法部署模板。

操作组资源管理器模板

若要使用资源管理器模板创建操作组，需要创建 Microsoft.Insights/actionGroups 类型的资源。然后，填充所有相关属性。以下是两个用于创建操作组的示例模板。

模板 1

此模板介绍如何为操作组创建资源管理模板，其中这些操作定义在模板中是硬编码的。

展开以查看模板

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "actionGroupName": {
      "type": "string",
      "metadata": {
        "description": "Unique name (within the Resource Group) for the Action group."
      }
    },
    "actionGroupShortName": {
      "type": "string",
      "metadata": {
        "description": "Short name (maximum 12 characters) for the Action group."
      }
    }
  },
  "resources": [
    {
      "type": "Microsoft.Insights/actionGroups",
      "apiVersion": "2021-09-01",
      "name": "[parameters('actionGroupName')]",
      "location": "Global",
      "properties": {
        "groupShortName": "[parameters('actionGroupShortName')]",
        "enabled": true,
        "smsReceivers": [
          {
            "name": "contosoSMS",
            "countryCode": "1",
            "phoneNumber": "5555551212"
          },
          {
            "name": "contosoSMS2",
            "countryCode": "1",
            "phoneNumber": "5555552121"
          }
        ],
        "emailReceivers": [
          {
            "name": "contosoEmail",
            "emailAddress": "devops@contoso.com",
            "useCommonAlertSchema": true

          },
          {
            "name": "contosoEmail2",
            "emailAddress": "devops2@contoso.com",
            "useCommonAlertSchema": true
          }
        ],
        "webhookReceivers": [
          {
            "name": "contosoHook",
            "serviceUri": "http://requestb.in/1bq62iu1",
            "useCommonAlertSchema": true
          },
          {
            "name": "contosoHook2",
            "serviceUri": "http://requestb.in/1bq62iu2",
            "useCommonAlertSchema": true
          }
        ],
         "SecurewebhookReceivers": [
          {
            "name": "contososecureHook",
            "serviceUri": "http://requestb.in/1bq63iu1",
            "useCommonAlertSchema": false
          },
          {
            "name": "contososecureHook2",
            "serviceUri": "http://requestb.in/1bq63iu2",
            "useCommonAlertSchema": false
          }
        ],
        "eventHubReceivers": [
          {
            "name": "contosoeventhub1",
            "subscriptionId": "replace with subscription id GUID",
            "eventHubNameSpace": "contosoeventHubNameSpace",
            "eventHubName": "contosoeventHub",
            "useCommonAlertSchema": true
          }
        ]
      }
    }
  ],
  "outputs":{
      "actionGroupId":{
          "type":"string",
          "value":"[resourceId('Microsoft.Insights/actionGroups',parameters('actionGroupName'))]"
      }
  }
}

模板 2

此模板介绍如何创建在部署模板时将 Webhook 配置信息作为输入参数的模板。

展开以查看模板

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "actionGroupName": {
      "type": "string",
      "metadata": {
        "description": "Unique name (within the Resource Group) for the Action group."
      }
    },
    "actionGroupShortName": {
      "type": "string",
      "metadata": {
        "description": "Short name (maximum 12 characters) for the Action group."
      }
    },
    "webhookReceiverName": {
      "type": "string",
      "metadata": {
        "description": "Webhook receiver service Name."
      }
    },    
    "webhookServiceUri": {
      "type": "string",
      "metadata": {
        "description": "Webhook receiver service URI."
      }
    }    
  },
  "resources": [
    {
      "type": "Microsoft.Insights/actionGroups",
      "apiVersion": "2021-09-01",
      "name": "[parameters('actionGroupName')]",
      "location": "Global",
      "properties": {
        "groupShortName": "[parameters('actionGroupShortName')]",
        "enabled": true,
        "smsReceivers": [
        ],
        "emailReceivers": [
        ],
        "webhookReceivers": [
          {
            "name": "[parameters('webhookReceiverName')]",
            "serviceUri": "[parameters('webhookServiceUri')]",
            "useCommonAlertSchema": true
          }
        ]
      }
    }
  ],
  "outputs":{
      "actionGroupResourceId":{
          "type":"string",
          "value":"[resourceId('Microsoft.Insights/actionGroups',parameters('actionGroupName'))]"
      }
  }
}

管理操作组

创建操作组后，可以在门户中查看它：

转到 Azure 门户。
在“监视”页中，选择“警报”。
选择“操作组”。
选择要管理的操作组。您可以：
- 添加、编辑或删除操作。
- 删除操作组。

通知的服务限制

电话号码或电子邮件可以包含在许多订阅的操作组中。当向特定电话号码、电子邮件地址或设备发送过多通知时，Azure Monitor 使用速率限制来暂停通知。通过速率限制，确保警报处于管理且可操作状态。

速率限制适用于短信、语音、推送和电子邮件通知。所有其他通知操作不受速率限制。速率限制应用于所有订阅。达到阈值后就会应用速率限制，即使消息发送自多个订阅也是如此。当电子邮件地址受速率限制时，将会发送一条通知，以告知已应用速率限制以及速率限制的过期时间。

有关速率限制的信息，请参阅 Azure Monitor 服务限制。

向 Azure 资源管理器发送电子邮件

使用 Azure 资源管理器发出电子邮件通知时，可以向订阅角色的成员发送电子邮件。电子邮件将发送给 Microsoft Entra ID 中属于该角色的用户或组成员。这包括对通过 Azure Lighthouse 分配的角色的支持。

Note

操作组仅支持向以下角色发送电子邮件：所有者、贡献者、读者、监控者、监控读取者。

如果主电子邮件未收到通知，请配置 Email Azure 资源管理器角色的电子邮件地址：

在 Azure 门户中，转到“Microsoft Entra ID”。
在左侧菜单中选择 “用户 ”以显示所有用户的列表。
选择要查看哪些用户的主电子邮件。
在“属性”下的用户配置文件中，查看联系人信息中的电子邮件值。如果该值为空，请执行以下操作：
1. 在页面顶部，选择 “编辑属性”。
2. 输入一个电子邮件地址。
3. 在页面顶部，选择“保存”。

每个操作组的电子邮件操作数可能有限。如要检查哪些限制适用于你的情况，请参阅 Azure Monitor 服务限制。

设置 Azure 资源管理器角色时，请执行以下操作：

将类型为“用户”或“组”的实体分配给角色。
在订阅级别进行分配。
确保在用户的 Microsoft Entra 个人资料中为其配置了电子邮件地址。

Note

客户在向其订阅添加新的 Azure 资源管理器角色后，可能需要等待长达 24 小时的时间才能开始接收通知。

短信

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

有关速率限制的信息，请参阅 Azure Monitor 服务限制。
有关在作组中使用短信通知的重要信息，请参阅 Azure 门户中“创建作组”中的步骤 9 下的表。

Note

如果无法在 Azure 门户中选择国家/地区代码，则你所在的国家/地区不支持短信。如果你的国家/地区代码不可用，则可以在分享想法投票以请求添加你的国家/地区。同时，作为一种解决方法，请配置操作组以调用 Webhook 来联系在你所在国家/地区提供支持的第三方短信提供方。

短信回复

这些回复支持短信通知。短信收件人可以使用以下值回复短信：

REPLY	Description
禁用 `<Action Group Short name>`	禁用来自操作组的进一步短信
启用 `<Action Group Short name>`	重新启用来自操作组的短信
STOP	禁用来自所有操作组的进一步短信
START	重新启用来自所有操作组的短信
HELP	将向用户发送带本文链接的回复信息。

Note

如果用户取消订阅短信警报，然后将其添加到新的作组，则他们会收到该新作组的短信警报，但仍未订阅所有以前的作组。

每个操作组的 Azure 应用操作数可能有限。

提供短信通知支持的国家/地区

展开以查看列表

国家/地区代码	Country
61	Australia
43	Austria
32	Belgium
55	Brazil
1	Canada
56	Chile
86	China
420	捷克共和国
45	Denmark
372	Estonia
358	Finland
33	France
49	Germany
852	香港特别行政区
91	India
353	Ireland
972	Israel
39	Italy
81	Japan
352	Luxembourg
60	Malaysia
52	Mexico
31	Netherlands
64	新西兰
47	Norway
351	Portugal
1	波多黎各
40	Romania
7	Russia
65	Singapore
27	南非
82	韩国
34	Spain
41	Switzerland
886	台湾
971	UAE
44	英国
1	美国

Voice

每个操作组的语音操作数可能有限。有关速率限制的重要信息，请参阅“Azure Monitor 服务限制”。

Note

如果无法在 Azure 门户中选择国家/地区代码，则你所在的国家/地区不支持语音呼叫。如果你的国家/地区代码不可用，则可以在分享想法投票以请求添加你的国家/地区。此时，一个解决办法是将操作组配置为向某个在你所在的国家/地区提供支持的第三方语音呼叫提供商调用 Webhook。如果某个国家/地区标有星号 \，则呼叫来自美国电话号码。

提供语音通知支持的国家/地区

展开以查看列表

国家/地区代码	Country
61	Australia
43	Austria
32	Belgium
55	Brazil
1	Canada
56	Chile
86	China*
420	捷克共和国
45	Denmark
372	Estonia
358	Finland
33	France
49	Germany
852	香港*
91	India*
353	Ireland
972	Israel
39	Italy*
81	Japan*
352	Luxembourg
60	Malaysia
52	Mexico
31	Netherlands
64	新西兰
47	Norway
351	Portugal
40	Romania*
7	Russia*
65	Singapore
27	南非
82	韩国
34	Spain
46	Sweeden
41	Switzerland
886	Taiwan*
971	阿拉伯联合酋长国*
44	英国
1	美国

有关受支持国家/地区的定价的信息，请参阅 Azure Monitor 定价。

Webhook

Note

如果使用 Webhook 操作，则目标 Webhook 终结点必须能够处理不同警报源发出的各种 JSON 有效负载。 Webhook 终结点还必须可公开访问。无法通过 Webhook 操作传递安全证书。若要使用基本身份验证，必须通过 URI 传递凭据。如果 Webhook 终结点需要特定的架构（例如 Microsoft Teams 架构），请使用逻辑应用操作来转换警报架构以满足目标 Webhook 的预期。

调用 Webhook 操作组时通常遵循以下规则：

调用 Webhook 时，如果第一次调用失败，则会重试至少 1 次，并在各种延迟间隔（5、20、40 秒）最多重试 5 次（5 次）。

Attempts	Delay
介于第 1 和第 2 之间	5 秒
介于第 2 和第 3 位之间	20 秒
介于第 3 和第 4 位之间	5 秒
介于第 4 到第 5 之间	40 秒
介于第 5 到第 6 之间	5 秒

在尝试调用 Webhook 的重试都失败之后，在 15 分钟的时间内，没有操作组会调用该终结点。
重试逻辑假定可以重试调用。状态代码 408、429、503、504 或 HttpRequestException、WebException TaskCancellationException 允许重试调用。

配置安全 Webhook 的身份验证

安全 Webhook 操作通过使用“AZNS AAD Webhook”Microsoft Entra 应用程序租户中的服务主体实例，向受保护 API 进行身份验证。若要使操作组正常工作，必须将此 Microsoft Entra Webhook 服务主体添加为目标 Microsoft Entra 应用程序上角色的成员，该角色需授予对目标终结点的访问权限。

有关 Microsoft Entra 应用程序和服务主体的概述，请参阅 Microsoft 标识平台 (v2.0) 概述。按照以下步骤来利用安全 Webhook 功能。

Note

SecureWebhook 不支持基本身份验证。要使用基本身份验证，必须使用 Webhook。

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

Note

自 2024 年 3 月 30 日起，Azure AD 和 MSOnline PowerShell 模块已弃用。若要了解详细信息，请阅读有关弃用的更新。在此日期之后，对这些模块的支持仅限于到 Microsoft Graph PowerShell SDK 的迁移帮助和安全性修复。弃用的模块将持续运行至 2025 年 3 月 30 日。

我们建议迁移到 Microsoft Graph PowerShell，以便与 Microsoft Entra ID（以前称为 Azure AD）进行交互。有关常见迁移问题，请参阅迁移常见问题解答。注意：2024 年 6 月 30 日之后，MSOnline 版本 1.0.x 可能会遇到中断。

为受保护的 Web API 创建 Microsoft Entra 应用程序。有关详细信息，请参阅受保护的 Web API：应用注册。将受保护的 API 配置为由守护程序应用调用，并公开应用程序权限，而不是委托的权限。

Tip

将受保护的 Web API 配置为接受 V2.0 访问令牌。有关此设置的详细信息，请参阅 Microsoft Entra 应用清单。
要使操作组能够使用 Microsoft Entra 应用程序，请使用遵循此过程的 PowerShell 脚本。
Note
- 必须被分配Microsoft Entra 应用程序管理员角色才能运行此脚本。
- 必须为服务主体分配 Microsoft Entra 应用程序的 所有者角色，以便能够在操作组中创建、修改或测试安全 Webhook 操作。
配置安全 Webhook 操作。
1. 复制脚本中的 $myApp.ObjectId 值。
2. 在 Webhook 操作定义的“对象 ID”框中，输入复制的值。

保护 Webhook PowerShell 脚本

Note

先决条件：安装 Microsoft Graph PowerShell SDK

如何运行

将以下脚本复制并粘贴到计算机。
替换你在应用注册中的 tenantId 和 ObjectID。
另存为 *.ps1
从计算机打开 PowerShell 命令并运行 *.ps1 脚本。

展开以查看脚本

Write-Host "================================================================================================="
$scopes = "Application.ReadWrite.All"
$myTenantId = "<<Customer's tenant id>>"
$myMicrosoftEntraAppRegistrationObjectId = "<<Customer's object id from the app registration>>"
$actionGroupRoleName = "ActionGroupsSecureWebhook"
$azureMonitorActionGroupsAppId = "461e8683-5575-4561-ac7f-899cc907d62a" # Required. Do not change.

Connect-MgGraph -Scopes $scopes -TenantId $myTenantId

Function CreateAppRole([string] $Name, [string] $Description)
{
    $appRole = @{
        AllowedMemberTypes = @("Application")
        DisplayName = $Name
        Id = New-Guid
        IsEnabled = $true
        Description = $Description
        Value = $Name
    }
    return $appRole
}

$myApp = Get-MgApplication -ApplicationId $myMicrosoftEntraAppRegistrationObjectId
$myAppRoles = $myApp.AppRoles
$myActionGroupServicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$azureMonitorActionGroupsAppId'"

Write-Host "App Roles before addition of new role.."
foreach ($role in $myAppRoles) { Write-Host $role.Value }

if ($myAppRoles.Value -contains $actionGroupRoleName)
{
    Write-Host "The Action Group role is already defined. No need to redefine.`n"
    # Retrieve the application again to get the updated roles
    $myApp = Get-MgApplication -ApplicationId $myMicrosoftEntraAppRegistrationObjectId
    $myAppRoles = $myApp.AppRoles
}
else
{
    Write-Host "The Action Group role is not defined. Defining the role and adding it."
    $newRole = CreateAppRole -Name $actionGroupRoleName -Description "This is a role for Action Group to join"
    $myAppRoles += $newRole
    Update-MgApplication -ApplicationId $myApp.Id -AppRole $myAppRoles

    # Retrieve the application again to get the updated roles
    $myApp = Get-MgApplication -ApplicationId $myMicrosoftEntraAppRegistrationObjectId
    $myAppRoles = $myApp.AppRoles
}

$myServicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$($myApp.AppId)'"

if ($myActionGroupServicePrincipal.DisplayName -contains "AzNS AAD Webhook")
{
    Write-Host "The Service principal is already defined.`n"
    Write-Host "The action group Service Principal is: " + $myActionGroupServicePrincipal.DisplayName + " and the id is: " + $myActionGroupServicePrincipal.Id
}
else
{
    Write-Host "The Service principal has NOT been defined/created in the tenant.`n"
    $myActionGroupServicePrincipal = New-MgServicePrincipal -AppId $azureMonitorActionGroupsAppId
    Write-Host "The Service Principal is been created successfully, and the id is: " + $myActionGroupServicePrincipal.Id
}

# Check if $myActionGroupServicePrincipal is not $null before trying to access its Id property
# Check if the role assignment already exists
$existingRoleAssignment = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $myActionGroupServicePrincipal.Id | Where-Object { $_.AppRoleId -eq $myApp.AppRoles[0].Id -and $_.PrincipalId -eq $myActionGroupServicePrincipal.Id -and $_.ResourceId -eq $myServicePrincipal.Id }

# If the role assignment does not exist, create it
if ($null -eq $existingRoleAssignment) {
    Write-Host "Doing app role assignment to the new action group Service Principal`n"
    New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $myActionGroupServicePrincipal.Id -AppRoleId $myApp.AppRoles[0].Id -PrincipalId $myActionGroupServicePrincipal.Id -ResourceId $myServicePrincipal.Id
} else {
    Write-Host "Skip assigning because the role already existed."
}

Write-Host "myServicePrincipalId: " $myServicePrincipal.Id
Write-Host "My Azure AD Application (ObjectId): " $myApp.Id
Write-Host "My Azure AD Application's Roles"
foreach ($role in $myAppRoles) { Write-Host $role.Value }

Write-Host "================================================================================================="

将 Runbook 操作从“运行方式帐户”迁移到“运行方式托管标识”

Note

Azure 自动化运行方式帐户已于 2023 年 9 月 30 日停用，这会影响使用操作类型自动化 Runbook 创建的操作。停用后，不支持链接到运行方式帐户 Runbook 的现有操作。但是，这些 Runbook 将继续执行，直到自动化帐户的“运行方式”证书过期。

若要确保可以继续使用 Runbook 操作，需要：

通过添加操作类型为“自动化 Runbook”的新操作来编辑操作组，然后从下拉列表中选择相同的 runbook。

Note

下拉菜单中的所有 5 个 runbook 均已在后端重新配置，以使用托管标识而不是运行方式帐户进行身份验证。将启用自动化客户中的系统分配托管标识，并自动分配订阅层级的 VM 参与者角色。
删除链接到“运行方式帐户”Runbook 的旧 Runbook 操作。
保存操作组。

后续步骤

获取警报概述，了解如何接收警报。
了解有关 ITSM 连接器的详细信息。
了解活动日志警报 webhook 架构。

反馈

此页面是否有帮助？

Last updated on 2026-04-24

通过

行动小组

全局可用性和复原能力

可重用性和执行过程

在 Azure 门户中创建操作组

在 Azure 门户中测试操作组

将托管身份与 Azure 操作组配合使用（预览版）

支持的动作类型

测试操作组的角色要求

使用资源管理器模板创建操作组

操作组资源管理器模板

管理操作组

通知的服务限制

向 Azure 资源管理器发送电子邮件

短信

短信回复

提供短信通知支持的国家/地区

Voice

提供语音通知支持的国家/地区

Webhook

配置安全 Webhook 的身份验证

保护 Webhook PowerShell 脚本

如何运行

将 Runbook 操作从“运行方式帐户”迁移到“运行方式托管标识”

后续步骤

反馈

其他资源