Azure Monitor 中的日志警报

概述

日志警报是 Azure 警报中支持的警报类型之一。 使用日志警报，用户可以通过 Log Analytics 查询按每个设置的频率评估资源日志并基于结果触发警报。 规则可以使用操作组触发一个或多个操作。

先决条件

日志警报运行对 Log Analytics 数据的查询。 首先，你应开始收集日志数据，并查询日志数据以查找问题。 可以使用 Log Analytics 中的警报查询示例主题来了解可发现的内容或开始编写你自己的查询。

Azure 监视参与者是创建、修改和更新日志警报所需的常见角色。 还需要具有对资源日志的访问和查询执行权限。 对资源日志具有部分访问权限可能会导致查询失败或返回部分结果。 详细了解如何在 Azure 中配置日志警报。

查询评估定义

日志搜索规则条件定义开始于：

• 要运行什么查询？
• 如何使用结果？

以下各节介绍了可用于设置上述逻辑的不同参数。

日志查询

用来评估规则的 Log Analytics 查询。 此查询返回的结果用来确定是否将触发某个警报。 查询的范围可以是：

• 特定资源，例如虚拟机。
• 大规模资源，例如订阅或资源组。
• 使用跨资源查询的多个资源。

查询时间范围

时间范围是在规则条件定义中设置的。 它在“高级设置”部分中被称为“替代查询时间范围”。

与 Log Analytics 不同，警报中的时间范围限制为最多两天的数据。 即使在查询中使用更长时间范围的 ago 命令，也将会采用时间范围。 例如，查询最多扫描 2 天，即使文本包含“ago(7d)”也是如此。

如果在查询中使用 ago 命令，则范围会自动设置为两天。 如果查询需要的数据多于警报评估，那么即使查询中没有任何 ago 命令，你也可以手动更改时间范围。

测量

日志警报将日志转换为可计算的数字值。 你可以度量两个不同的事项：

• 结果计数
• 某个值的计算

结果计数

结果计数是默认度量值，当你设置选择了“表行”的“度量值”时会用到它。 适用于处理 Windows 事件日志、Syslog 和应用程序异常等事件。 当评估的时间窗口中发生或未发生日志记录时触发。

当你尝试检测日志中的数据时，日志警报效果最佳。 当你试图检测日志中是否缺少数据时，它的效果就不太好。 例如，对虚拟机检测信号发出警报。

结果计数用例示例

你希望知道你的应用程序何时以错误代码 500（内部服务器错误）做出响应。 可以创建一个警报规则，详情如下：

• 查询：

requests
| where resultCode == "500"

• 聚合粒度：15 分钟
• 警报频率： 15 分钟
• 阈值： 大于 0

然后，警报规则监视所有以错误代码 500 结束的请求。 在过去的 15 分钟，该查询每 15 分钟运行一次。 即使找到一条记录，它也会引发警报并触发所配置的操作。

某个值的计算

在你为 Measure 选择某个数值列的列名时，会使用某个值的计算，并且结果会是你对该列中的值执行的计算。 例如，这会用作 CPU 计数器值。

聚合类型

对多条记录执行的、通过定义的聚合粒度将其聚合为一个数值的计算。 例如：

• “求和”返回度量值列的总和。
• “平均值”返回度量值列的平均值。

聚合粒度

确定用于将多条记录聚合为一个数值的间隔。 例如，如果你指定了 5 分钟，则记录会使用指定的聚合类型按 5 分钟间隔进行分组。

按警报维度拆分

通过将警报分组为唯一的组合，按数字或字符串列将警报拆分为单独的警报。 它是在条件的“拆分依据维度”部分中配置的（限制为六个拆分）。 当大规模（在订阅或资源组范围内）创建以资源为中心的警报时，可以按 Azure 资源 ID 列进行拆分。 按 Azure 资源 ID 列进行拆分会将警报的目标更改为指定的资源。

如果想要在多个 Azure 资源上监视相同的条件，建议按 Azure 资源 ID 列进行拆分。 例如，监视所有虚拟机的 CPU 使用率超过 80%。 在需要范围内的多个资源的条件时，你也可能会决定不进行拆分。 例如，监视到在资源组范围内至少有五台计算机的 CPU 使用率超过 80%。

按警报维度拆分的示例

例如，你想要监视在特定资源组中运行你的网站/应用的多个虚拟机的错误。 可以如下所述使用日志警报规则实现此目的：

• 查询：

  // Reported errors
  union Event, Syslog // Event table stores Windows event records, Syslog stores Linux records
  | where EventLevelName == "Error" // EventLevelName is used in the Event (Windows) records
  or SeverityLevel== "err" // SeverityLevel is used in Syslog (Linux) records
  

• 资源 ID 列：_ResourceId

• 维度：

  • Computer = VM1、VM2（在警报规则定义中筛选值这一做法目前不适用于工作区和 Application Insights。请在查询文本中筛选。）

• 聚合粒度：15 分钟

• 警报频率： 15 分钟

• 阈值： 大于 0

此规则监视在过去 15 分钟内是否有任何虚拟机出现错误事件。 每个虚拟机都会被单独监视，并且会分别触发操作。

警报逻辑定义

定义要运行的查询并对结果进行评估后，你需要定义警报逻辑以及何时触发操作。 以下各节介绍了你可以使用的各个参数：

阈值和运算符

查询结果将转换为一个数字，该数字将依据阈值和运算符进行比较。

频率

运行查询的间隔。 可以设置为一分钟至一天。

触发警报的违规次数

你可以指定警报评估时段和触发警报所需的故障次数。 允许你更好地定义触发警报的影响时间。

例如，如果你的聚合粒度规则定义为“5 分钟”，则只有在过去一小时内发生三次故障（15 分钟）时，你才能触发警报。 此设置由你的应用程序业务策略定义。

状态和解决警报

日志警报可以是无状态的，也可以是有状态的（目前处于预览版阶段）。

每次满足条件时都会触发无状态警报，即使之前已触发过。 警报实例解除后，可以将警报标记为已关闭。 你还可以对操作进行“静音”，以防它们在“警报详细信息”部分中使用“静音操作”选项触发预警规则后的一段时间内触发。

请参阅这个警报无状态评估示例：

时间	日志条件评估	结果
00:05	FALSE	警报不会触发。 没有调用任何操作。
00:10	TRUE	警报触发，操作组被调用。 新警报处于活动状态。
00:15	TRUE	警报触发，操作组被调用。 新警报处于活动状态。
00:20	FALSE	警报不会触发。 没有调用任何操作。 以前的警报保持活动状态。

有状态警报会在每次事件后触发一次并解决。 如果在特定评估期间出现 30 分钟都不符合警报条件的情况（考虑到日志引入延迟），或者出现连续三次评估都不符合警报条件的情况（这是为了减少不稳定情况下出现的干扰），则警报会解除。 例如，如果频率为 5 分钟/次，警报会在 40 分钟后解除；如果频率为 1 分钟/次，警报会在 32 分钟后解除。 通过 Webhook 或电子邮件发出“已解除”通知后，Azure 门户中警报实例的状态（称为“监视状态”）也会设置为“已解除”。

有状态警报功能目前处于预览阶段。 可以使用警报详细信息部分的“自动解决警报”进行设置。

日志警报中的位置选择

日志警报允许设置警报规则的位置。 你可以选择任何受支持的位置，这些位置与 Log Analytics 支持的区域列表相符。

位置会对在哪个区域中评估警报规则造成影响。 查询会针对所选区域中的日志数据执行，但警报服务端到端是全局的。 这意味着警报规则定义、触发的警报、通知和操作不会绑定到警报规则中的位置。 数据会从设置的区域传输，因为 Azure Monitor 警报服务是非区域性服务。

定价模型

每个日志警报规则按照日志查询的评估间隔计费（查询评估越频繁，费用也就越高）。 此外，对于为大规模监视而配置的日志警报，成本还取决于查询所产生的维度所创建的时序数量。

Azure Monitor 定价页上提供了日志警报规则的价格。

计算没有维度的日志警报规则的价格

每隔 15 分钟查询 1 个资源事件的警报规则的价格计算方式为：

每月总价格 = 1 个资源 * 1 个日志警报规则 * 每月每 15 分钟内部日志警报规则的价格。

计算带有维度的日志警报规则的价格

在使用以资源为中心的日志监视的情况下，按 1 分钟频率监视 10 个 VM 资源的警报规则的价格计算方式为：按警报规则收费的价格 + 按维度数量收费的价格。 例如：

每月总价格 = 每月每 1 分钟日志警报规则的价格 + (10 个时序 - 1 个包含的免费时序) * 每月每 1 分钟间隔监视的价格。

大规模日志监视的价格从计划查询规则 API 版本 2021-02-01 开始适用。

在 Azure 账单上查看日志警报使用量

日志警报在资源提供程序 microsoft.insights/scheduledqueryrules 下列出，同时列出的有：

• Application Insights 上的日志警报，显示时带有确切的资源名称以及资源组和警报属性。
• 如果是使用 scheduledQueryRules API 创建的，则 Log Analytics 上的日志警报显示时带有确切的资源名称以及资源组和警报属性。
• 通过旧式 Log Analytics API 创建的日志警报不是被跟踪的 Azure资源，没有强制使用的唯一资源名称。 这些警报仍作为隐藏资源在 microsoft.insights/scheduledqueryrules 上创建，这些资源的资源命名结构为 <WorkspaceName>|<savedSearchId>|<scheduleId>|<ActionId>。 针对旧式 API 的日志警报显示时带有上述隐藏的资源名称以及资源组和警报属性。

后续步骤

• 了解如何在 Azure 中创建日志警报。
• 了解 Azure 日志警报中的 Webhook。
• 了解 Azure 警报。
• 详细了解 Log Analytics。