排查 Azure Monitor 警报的问题
本文讨论 Azure Monitor 警报和通知的常见问题。 在监视数据中发现重要情况时，Azure Monitor 警报会主动通知你。
有关排查 Azure 指标或日志搜索警报的具体信息，请参阅：
故障排除准备工作
如果警报按预期触发，但正确的通知未按预期执行，先测试操作组以确保正确配置。
否则，请使用本文其余部分中的信息排查问题。
我未收到预期的电子邮件
如果你可以在 Azure 门户中看到触发的警报，但未收到你配置的电子邮件，请遵循以下步骤：
是否某个警报处理规则禁止了电子邮件？
在门户中单击触发的警报进行检查，查看“历史记录”选项卡中是否有已阻止的操作组：
操作类型是否为“向 Azure 资源管理器角色发送电子邮件”？
此操作仅查看订阅范围的、类型为“用户”的 Azure 资源管理器角色分配。 请确保已在订阅级别（而不是资源级别或资源组级别）分配角色。
电子邮件服务器和邮箱是否接受外部电子邮件？
验证来自这三个地址的电子邮件是否未被阻止：
- azure-noreply@oe.21vianet.com
- azureemail-noreply@oe.21vianet.com
- alerts-noreply@mail.windowsazure.cn
内部邮件列表或通讯组列表阻止来自外部电子邮件地址的电子邮件的情况很常见。 请确保允许来自上述电子邮件地址的邮件。 若要进行测试，请将一个常规工作电子邮件地址（不是邮件列表）添加到操作组，并查看警报是否到达该电子邮件地址。
相关电子邮件是否被收件箱规则或垃圾邮件筛选器处理了？
请确保没有任何收件箱规则会删除这些电子邮件或将其移动到副文件夹。 例如，收件箱规则可能会捕捉特定发件人或主题中的特定字词。 另请检查：
- 电子邮件客户端（如 Outlook、Gmail）的垃圾邮件设置
- 电子邮件服务器（如 Exchange、Microsoft 365、G-suite）的发件人限制/垃圾邮件设置/隔离设置
- 若有使用电子邮件安全设备（如 Barracuda、Cisco），请检查其设置。
是否意外取消了对操作组的订阅？
警报电子邮件提供从操作组取消订阅的链接。 若要检查是否已意外地从此操作组取消订阅，请执行以下操作之一：
- 在门户中打开操作组，并检查“状态”列：
- 搜索电子邮件中是否有取消订阅确认信息：
若要再次订阅，请使用收到的取消订阅确认电子邮件中的链接，或从操作组中删除电子邮件地址，然后再重新添加。
是否向单个电子邮件地址发送许多电子邮件，从而超过了服务限制？
电子邮件有速率限制，发送给每个电子邮件地址的电子邮件不得超过每小时 100 封。 如果通过此阈值，则不会发送更多电子邮件通知。 检查是否已收到一封表明电子邮件地址暂时存在速率限制的邮件：
如果你想要接收大量通知且不受到速率限制，请考虑使用不同的操作，例如：
- Webhook
- 逻辑应用
- Azure 函数
- 自动化 Runbook
这些操作均不会受到速率限制。
我未收到预期的短信
如果你可以在门户中看到触发的警报，但未收到配置的短信，请遵循以下步骤：
是否某个警报处理规则禁止了该操作？
在门户中单击触发的警报进行检查，查看“历史记录”选项卡中是否有已阻止的操作组：
如果是无意中阻止了操作组，可以修改、禁用或删除警报处理规则。
短信：你的电话号码是否正确？
检查短信操作，以查明国家/地区代码或电话号码中是否有拼写错误。
短信：是否已超出服务限制？
短信的速率限制是每个电话号码每 5 分钟不超过 1 个通知。 如果超过此阈值，将丢弃通知。
- 短信 - 查看短信历史记录，了解其中是否有一条短信表明你的电话号码已受到速率限制。
如果你想要接收大量通知且不受到速率限制，请考虑使用不同的操作，例如以下操作之一：
- Webhook
- 逻辑应用
- Azure 函数
- 自动化 Runbook
这些操作均不会受到速率限制。
短信：是否意外取消了对操作组的订阅？
打开短信历史记录，检查是否已选择禁止传送来自此特定操作组（使用 DISABLE action_group_short_name 回复）或所有操作组（使用 STOP 回复）的短信。
若要再次订阅，请发送相关短信命令（ENABLE action_group_short_name 或 START），或从操作组中删除短信操作，然后重新添加。 有关详细信息，请参阅操作组中的短信警报行为。
你的手机上是否意外阻止了通知？
大多数移动电话允许阻止来自特定电话号码或短代码的呼叫或短信，或阻止来自特定应用（如 Azure 移动应用）的推送通知。 若要检查你的手机上是否意外阻止了通知，请搜索特定于你的手机操作系统和型号的文档，或使用其他手机和电话号码进行测试。
预期操作未触发
如果可以在门户中看到触发的警报，但其配置的操作未触发，请遵循以下步骤：
是否某个警报处理规则禁止了该操作？
在门户中单击触发的警报进行检查，查看“历史记录”选项卡中是否有已阻止的操作组：
如果是无意中阻止了操作组，可以修改、禁用或删除警报处理规则。
是否触发了 Webhook 触发器？
源 IP 地址是否被阻止？
将调用 Webhook 的 IP 地址添加到允许列表中。
你的 Webhook 终结点是否正常工作？
验证已配置的 Webhook 终结点是否正确，以及该终结点是否在正常运行。 检查 Webhook 日志或检测其代码，以便进行调查（例如，记录传入的有效负载）。
Webhook 是否已停止响应或返回错误？
调用 Webhook 操作组时通常遵循以下规则：
- 当调用 Webhook 时，如果第一次调用失败，它将至少再重试 1 次，并且会以不同延迟间隔（5、20、40 秒）最多重试 5 次（5 次重试）。
- 第 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 时，如果第一次调用失败，它将至少再重试 1 次，并且会以不同延迟间隔（5、20、40 秒）最多重试 5 次（5 次重试）。
操作或通知多次发生
如果多次收到针对某个警报的通知（如电子邮件或短信），或者该警报的操作（如 webhook 或 Azure 函数）已触发了多次，请遵循以下步骤：
它是否确实是同一警报？
在某些情况下，会几乎同时触发多个类似的警报。 因此，看起来可能就会像同一警报多次触发了其操作。 例如，活动日志警报规则可能会配置为在事件启动和完成（成功或失败）时触发（不筛选事件状态字段）。
若要检查这些操作或通知是否来自不同警报，请查看警报详细信息，如警报时间戳以及警报 ID 或其相关 ID。 或者，在门户中查看触发的警报的列表。 如果是这种情况，则需要调整警报规则逻辑或配置警报源。
此操作是否在多个操作组中重复？
触发警报时，其每个操作组都是单独处理的。 因此，如果某个操作（如电子邮件地址）出现在多个触发的操作组中，则每个操作组都会调用该操作一次。
若要检查触发的操作组，请检查警报历史记录选项卡。可看到警报规则中定义的两个操作组，以及警报处理规则向警报添加的操作组：
操作或通知存在意外的内容
是否有中断触发了回退电子邮件提供商的使用？
操作组使用两个不同的电子邮件提供程序来确保发送电子邮件通知。 主要电子邮件提供程序有弹性且快速，但偶尔会发生中断。 发生中断时，辅助电子邮件提供程序将处理电子邮件请求。 辅助提供程序只是备用解决方案。 由于提供程序的差异，从辅助提供程序发送的电子邮件可能提供降级的电子邮件体验。 降级会导致电子邮件格式和内容略有不同。 由于两个系统中的电子邮件模板存在差异，因此在两个系统中保持奇偶校验是不可行的。
回退解决方案生成的通知包含如下说明：
“这是降级的电子邮件体验。 这意味着格式设置可能已关闭，或者可能缺少详细信息。 有关降级的电子邮件体验的详细信息，请阅读此处。”
如果通知不包含此注释，并且你收到了警报，但认为其中某些字段丢失或不正确，请检查有效负载格式。
配置警报规则时使用了什么格式？
每种操作类型（电子邮件、Webhook 等）都有两种格式：默认的旧格式和通用架构格式。 创建操作组时，可以指定操作的格式。 操作组中的不同操作可能具有不同的格式。
例如，对于 Webhook 操作：
检查在操作级别指定的格式是否是你需要的格式。 例如，你可能已开发响应警报的代码（Webhook、函数、逻辑应用等），这些代码需要一种格式，但是稍后你或其他人在操作中指定了另一种格式。
另外，检查活动日志警报、日志搜索警报（Application Insights 和日志分析）、指标警报、通用警报架构以及已弃用的经典指标警报的有效负载格式 (JSON)。
日志搜索警报通知中不包含搜索结果。
从日志搜索警报 API 版本 2021-08-01 开始，搜索结果已从警报通知有效负载中删除。 搜索结果仅适用于使用较旧 API 版本 (2018-04-16) 创建的警报规则。 默认情况下，通过 Azure 门户创建新的警报规则将创建具有较新版本的规则。 查看对日志警报规则创建体验的更改，了解使用更新版本的更改和建议调整。
该 MetricValue 字段包含已解析日志搜索警报通知的“null”。
这是设计的结果。 有状态的日志搜索警报使用基于时间的解决逻辑，而不是基于值。 由于并非数值导致警报解决，而是经过的时间，所以 Azure Monitor 将发送 null 指标值。
维度列表为空或警报标题不包含维度名称
如果日志搜索警报规则不返回任何结果，警报可以按预期触发，但维度列表将为空或警报标题不包含维度名称。 当查询不返回任何行时，资源 ID 字段（这是填充维度和标题字段的基础）为空。
活动日志警报中缺少信息
活动日志警报是基于写入到 Azure 活动日志的事件（例如，有关创建、更新或删除 Azure 资源的事件、服务运行状况和资源运行状况事件，或者 Azure 顾问和 Azure Policy 发现的情况）的警报。 如果你收到了基于活动日志的警报，但所需的某些字段丢失或不正确，请首先检查活动日志本身中的事件。 如果 Azure 资源未在其活动日志事件中写入所需字段，则这些字段将不会包含在相应的警报中。
电子邮件、短信或推送通知中缺少自定义属性。
自定义属性仅传递给操作的有效负载，例如 Webhook、Azure 函数或逻辑应用。 通知（电子邮件/短信/推送）中不包含自定义属性。
警报处理规则未按预期发挥作用
如果可以在门户中看到触发的警报，但相关的警报处理规则未按预期发挥作用，请遵循以下步骤：
警报处理规则是否已启用？
检查警报处理规则状态字段，验证是否已启用相关操作角色。 默认情况下，门户只显示已启用的警报规则，但可以更改筛选器以显示所有规则。
如果它未启用，则可以通过选择处理规则并单击“启用”来启用警报处理规则。
它是否为服务运行状况警报？
服务运行状况警报不受警报处理规则的影响。 因此，如果为包含服务运行状况警报的范围配置了警报处理规则，而服务运行状况警报在范围内，则警报处理规则不会影响它们。
警报处理规则是否处理了警报？
在门户中选择触发的警报，并查看“历史记录”选项卡以查看是否已处理警报处理规则。
以下是禁止所有操作组的警报处理规则示例：
以下是添加另一个操作组的警报处理规则的示例：
警报处理规则作用域和筛选器是否与触发的警报匹配？
如果你认为警报处理规则本来应触发但未触发，或者它本来不应触发但确实已触发，请仔细检查警报处理规则作用域和筛选条件并与触发的警报的属性进行比较。
在 Azure 门户中创建、更新或删除警报处理规则时出现问题
如果你在尝试创建、更新或删除警报处理规则时遇到错误，请遵循以下步骤：
检查权限。
你应该拥有监视参与者内置角色，或者与警报处理规则和警报相关的特定权限。
检查警报处理规则参数。