什么是 Azure Monitor 警报?

当 Azure Monitor 数据指示你的基础结构或应用程序可能出现问题时,警报有助于检测和解决用户注意到问题。

可以针对 Azure Monitor 数据平台中的任何指标或日志数据源发出警报。

此图向你展示了警报的工作原理。

Diagram that explains Azure Monitor alerts.

警报规则会监视你的数据并捕获指示指定资源上发生情况的信号。 警报规则捕获信号并检查信号是否符合条件条件。

警报规则组合:

  • 要监视的资源。
  • 来自资源的信号或数据。
  • 条件。

如果满足警报规则的条件,则会触发警报。 警报会启动关联的操作组并更新警报的状态。 如果要监视多个资源,则会针对每个资源单独评估警报规则条件,并单独为每个资源触发警报。

警报将存储 30 天,并在 30 天保留期后删除。 可以在 Azure 门户的“警报”页上查看所有 Azure 资源的所有警报实例。

警报包括:

  • 操作组:这些组可以触发通知或自动化工作流,让用户知道警报已触发。 操作组可以包括:
    • 电子邮件、短信和推送通知等通知方法。
    • 自动化 runbook。
    • Azure 函数。
    • 逻辑应用。
    • 安全 Webhook。
    • WebHook。
    • 事件中心。
  • 警报条件:这些条件是由系统设置的。 当警报触发时,警报条件会设置为“已触发”。 当导致警报触发的基础条件消除时,警报条件会设为“已解决”。
  • 用户响应:该响应由用户设置,在用户更改它之前不会变化。
  • 警报处理规则:你可以使用警报处理规则在警报被触发时对触发的警报进行修改。 可以使用警报处理规则添加或禁止操作组、应用筛选器或按预定义的计划处理规则。

警报类型

此表提供了每种警报类型的简要说明。 有关每种警报类型以及如何选择最适合需求的警报类型的详细信息,请参阅 Azure Monitor 警报类型

警报类型 描述
指标警报 指标警报会定期评估资源指标。 指标可以是平台指标、自定义指标、Azure Monitor 中的日志转换为的指标或 Application Insights 指标。 指标警报还可以应用多个条件和动态阈值。
日志警报 日志警报允许用户使用 Log Analytics 查询以预定义的频率评估资源日志。
活动日志警报 当发生符合定义条件的新活动日志事件时,将触发活动日志警报。 资源运行状况警报和服务运行状况警报是报告服务和资源运行状况的活动日志警报。
智能检测警报 当 Web 应用程序中存在潜在性能问题和故障异常时,对 Application Insights 资源的智能检测会自动向你发出警告。 可以在 Application Insights 资源上迁移智能检测,以便为不同的智能检测模块创建警报规则。

警报和状态

警报可以是有状态的,也可以是无状态的。

  • 每次满足条件时都会触发无状态警报,即使之前已触发过。
  • 满足规则条件时会触发有状态警报,并且在条件解决之前不会再次触发或触发任何其他操作。

警报将存储 30 天,并在 30 天保留期后删除。

无状态警报

每次满足条件时会触发无状态警报。 所有无状态警报的警报条件始终为 fired

  • 所有活动日志警报是无状态的。
  • 无状态指标警报的通知频率因警报规则的配置频率而异:
    • 警报频率小于 5 分钟:当继续满足条件时,将在 1 到 6 分钟之间发送通知。
    • 警报频率超过 5 分钟:当继续满足条件时,将在配置的频率到两倍于该频率的时间之间发送通知。 例如,对于频率为 15 分钟的警报规则,将在 15 到 30 分钟之间发送通知。

有状态警报

满足规则条件时会触发有状态警报,并且在条件解决之前不会再次触发或触发任何其他操作。 有状态警报的警报条件为 fired,直到它被视为已解决。 当警报被认为已解决时,警报规则会使用 webhook 或电子邮件发送已解决通知,并将警报条件设为 resolved

对于有状态警报,虽然警报本身在 30 天后会删除,但在解决警报之前将会存储警报条件,以防止触发另一个警报,以便在解决警报时发送通知。

监控状态日志警报具有以下限制:

  • 它们在每次评估时最多可以触发 300 个警报。
  • 最多可以有 5000 个具有 fired 警报条件的警报。

此表描述了何时将有状态警报视为已解决:

警报类型 在以下情况下警报即已解决
指标警报 连续三次检查未满足警报条件。
日志警报 在特定时间范围内未满足警报条件。 时间范围因警报频率而异:
  • 1 分钟:10 分钟内未满足警报条件。
  • 5 到 15 分钟:在三个频率周期内未满足警报条件。
  • 15 分钟到 11 个小时:在两个频率周期内未满足警报条件。
  • 11 - 12 小时:一个频率周期内未满足警报条件。

如果你没有为所选资源定义任何警报规则,可以在 Azure 门户启用我们推荐的现成警报规则

系统根据以下内容编译了一个建议的警报规则列表:

  • 资源提供程序对用于监视资源的重要信号和阈值的了解。
  • 指明客户通常针对此资源的哪些方面设置警报的数据。

注意

为以下项启用了建议的警报规则:

  • 虚拟机
  • AKS 资源
  • Log Analytics 工作区

大规模警报

可以使用以下任一方法大规模创建警报规则。 每个选择都存在可能会影响成本及警报规则维护的优点和缺点。

指标警报

可以使用一个指标警报规则监视同一 Azure 区域中存在的同一类型的多个资源。 将为每个受监视的资源发送单独通知。 有关此功能目前支持的 Azure 服务列表,请参阅 Azure Monitor 中的指标警报支持的资源

对于不支持多个资源的 Azure 服务指标警报规则,请利用 Azure CLI 和 PowerShell 等自动化工具或 Azure 资源管理器模板来创建适用于多个资源的同一警报规则。 有关示例 ARM 模板,请参阅适用于 Azure Monitor 中指标警报规则的资源管理器模板示例

每个指标警报规则根据监视的时序数收费。

日志警报

使用日志警报规则监视向 Log Analytics 工作区发送数据的所有资源。 这些资源可以来自任何订阅或区域。 在设置 Log Analytics 工作区以收集日志警报规则所需的数据时,请使用数据收集规则。

还可以使用“按维度拆分”创建以资源而不是以工作区为中心的警报。 在 resourceId 列上拆分时,将为每个满足条件的资源获取一个警报。

使用按维度拆分的日志警报规则根据按查询生成的维度所创建的时序数收费。 如果数据已收集到 Log Analytics 工作区,则无需额外付费。

如果在 Log Analytics 工作区中大规模使用指标数据,则定价将基于数据引入而更改。

将 Azure 策略用于大规模警报

可以使用 Azure 策略大规模设置警报。 这具有轻松实现大规模警报的优势。 可以看到如何使用 Azure Monitor 基线警报实现此功能。

请记住,如果使用策略创建警报规则,则可能会增加维护大型警报规则集的开销。

Azure 用于警报的基于角色的访问控制

只能访问、创建或管理自己有权访问的资源的警报。

若要创建警报规则,必须具备:

  • 对预警规则的目标资源的读取权限。
  • 对在其中创建预警规则的资源组的写入权限。 如果从 Azure 门户中创建预警规则,则默认在目标资源所在的同一资源组中创建预警规则。
  • 对关联到警报规则的任何操作组的读取权限(如果适用)。

这些内置 Azure 角色在所有 Azure 资源管理器范围内均受支持,具有访问警报信息和创建警报规则的权限:

  • 监视参与者:参与者可以创建警报并使用其范围内的资源。
  • 监视读者:读者可以查看警报并读取其范围内的资源。

如果目标操作组或规则位置与两个内置角色的范围不同,请创建具有适当权限的用户。

定价

有关定价的详细信息,请参阅 Azure Monitor 定价

后续步骤