SLS新版告警自助排查系列之告警监控

前言

在SLS告警中，告警监控通过对数据源的查询监控，然后产生告警，并将告警发送到告警管理，告警管理会对告警进行降噪处理包括合并抑制静默后，在将告警发送给行动管理，最终发送通知到用户配置的接收渠道。在整个过程中，告警监控作为告警的源头，决定着告警是否能准确的发出。在配置告警监控规则时，配置不当或者配置错误都会导致告警不能触发或者不是希望的触发。本文主要介绍在告警监控中如何进行自助排查问题。

在后续的文章中会陆续介绍在告警管理，通知管理，开放告警中问题的自助排查。

自助排查概览

在新版告警中，开启告警规则后，SLS会在用户侧创建两类免费的Logstore。

• 告警规则所在的Project下的告警历史Logstore，名称固定为internal-alert-history，主要存储告警的评估历史及触发状态等。注意，新版告警中通知发送状态不表示通知渠道发送状态，其表示发送给告警管理的状态。

• internal-alert-history中记录了每次评估触发的状态，如果开启了分组评估，则会每个分组记录一条日志。
• 告警历史统计-仪表盘是SLS根据internal-alert-history自动创建在用户侧的告警仪表盘。

• 告警中心Project及告警中心Logstore，告警中心Project格式为sls-alert-主账号uid-区域，告警中心Logstore名称固定为internal-alert-center-log。

• internal-alert-center-log完整的记录了告警的触发状态，告警合并抑制静默状态，通知渠道发送历史。
• 告警链路中心-仪表盘，展示了全局告警链路中心，显示从告警产生到合并抑制静默再到渠道通知的链路状态。
• 告警规则中心-仪表盘，展示了告警监控规则的最新评估状态和合并后的告警的最新状态。
• 告警排障中心-仪表盘，展示了告警配置错误，通知渠道错误，告警监控规则错误的状态。

在配置出问题时，可以优先考虑从上述两个告警历史统计仪表盘和告警排障中心仪表盘查看问题。

告警历史统计仪表盘

如上是告警历史统计仪表盘的截图，其中包含告警名称，触发条件，通知发送状态，是否触发告警，原因等字段，其中比较重要的字段为是否触发告警，原因等。

这里是否触发告警如果为false，这时需要查看原因列，原因列常见的导致未触发告警的描述有：

• Alert condition not met，表示触发条件未满足。
• Notify threshold not reached，表示连续触发阈值未达到。

接下来将对两种常见的原因进行详细的描述。

触发条件

触发条件是针对监控目标来设置的，无论是日志数据还是时序数据，使用SLS统一的查询分析语法，查询后的结果都可以看做是表格数据包含行和列，在经过集合操作后类型还是表格数据。触发条件的本质是查看是否有xx条数据满足了yy条件，这里的xx和yy是需要在触发条件中进行配置的。

下面以一个表格结果为例来讲解触发条件的判断方式：

上述结果为某次评估中查询结果集合操作后的结果。

需求是：status>=500的数据超过3条就告警。从图中可以轻易看出来上述的表格是满足条件的，触发的数据如下图，有5条数据满足status>=500。

这种情况下我们在告警规则配置中触发条件为：

这里触发条件类型，我们选择“有特定条数据匹配”，内容选择 > 3，条件写 status >= 500。这样就满足了我们告警配置的需求。

四种触发条件类型

• 有数据：表示集合操作后的表格结果行数大于0。
• 有特定条数据：表示集合操作后的表格结果的行数满足一定条件，条件可以在规则中配置。
• 有数据匹配：表示集合操作后的表格结果中任意一行满足指定条件即可。
• 有特定条数据匹配：表示集合操作后的表格结果有指定行数满足指定条件，即为例子中类型。

以上四种触发条件类型都可以归结为xx行数据满足yy条件，在告警历史统计中，触发条件会显示在触发条件列，显示格式为Count:行数条件; Condition:数据条件。

对于有数据类型，因为数据条件不需要，所以显示为空。对于行数使用__count__表示。

另外告警历史统计中，对于触发告警的评估，触发条件会显示满足触发条件的数据，将行数和数据替换条件中的变量，比如上述示例会用Count:__count__>3;Condition:status>=500来表示，如果触发告警会显示为Count:[5]>3;Condition:[500]>=500，这里数据如果有多条满足，Condition后面会用第一条满足的数据替换。

四种触发条件在满足和未满足的情况显示方式如下：

通过上面的描述，在排查时，可以根据告警历史统计中的数据来判断触发条件为什么不满足。另外数据条件的写法可以参考[链接]。

连续触发阈值

连续触发阈值，表示连续多少次告警评估都是满足触发条件，是一种监控降噪的手段之一，比如在每分钟监控CPU的使用率，如果CPU偶然高一次可能不需要太在意，但是连续3分钟检查CPU的使用率都比较高，这种情况下需要引起关注。这种情况在告警规则配置中就可以设置连续触发阈值为3，检查频率为1分钟，这样只有连续三次检查CPU使用率都高的情况下，才触发告警。

如上图，检查频率为5分钟，每5分钟评估一次，其中实心箭头表示评估结果为满足触发条件，空心箭头表示不满足触发条件，时间轴向右。连续触发阈值设置为3，从上图可以看出第20分，25分会产生告警并将告警发送给告警管理，其他时间点因为不满足连续触发阈值，不会产生告警。

在告警监控规则页面，连续触发阈值默认为1，表示一次评估中数据满足触发条件，就会触发告警，并将告警发送到告警管理。

所以在遇到这种原因时，可以检查告警配置中的连续触发阈值是否大于1，真实的数据评估是否满足连续触发阈值。

告警排障中心仪表盘

告警排障中心主要包含了全局配置错误，通知渠道错误，告警监控规则错误数。本文主要介绍告警监控规则错误。

在SLS控制台，路径为 告警图标->打开告警中心->告警管理->告警排障中心。

进入告警排障中心后，上方会显示告警监控规则出错数，点击数字，可以进入详情，可以在告警中心project中查看具体的错误。

在页面下方会显示最新的告警监控规则错误的列表，其中包含错误的规则名，错误和详情，也可以点击规则详情，进入告警配置页面进行修改。

在告警监控规则的查询配置中，经常会有一些错误配置，这里简单列举几个常见的情况

• SQL语法错误

• 未开启索引

• 索引不存在

其实对于查询类的错误，只要在SLS控制台的查询框中查询一次，即可看到错误；在配置告警时，先要对查询分析语句进行检测。

总结

通过上述告警历史统计仪表盘和告警排障中心仪表盘，我们可以发现告警监控中的配置错误或者查出告警是否触发的原因。文中列举了比较常见了两种导致告警未触发的情况，包括触发条件和连续触发阈值，着重进行了概念上的阐述和举例，希望通过此文加深读者对SLS告警概念上的理解。

参考

• 告警监控概述【链接】
• 评估表达式语法【链接】
• 使用评估表达式设置触发条件【链接】
• 查询和分析日志【链接】
• 分组评估【链接】

进一步参考

• SLS（日志服务）云原生观测分析平台：https://www.aliyun.com/product/sls
• SLS新版告警文档首页：https://help.aliyun.com/document_detail/207609.html
• 欢迎扫群加入阿里云-日志服务（SLS）技术交流（集团同学请直接搜索群号11702236加入）, 获得第一手资料与支持
• 后续系列直播与培训视频会同步到B站，敬请留意