本文作者：观测云产品架构师 潘杨

掘金链接：https://juejin.cn/post/7204668263287521317

背景

在监控高度分布式的应用程序时，可能依赖于多个基于云的和本地环境中的数百个服务和基础设施组件，在识别错误、检测高延迟的原因和确定问题的根因都是比较有挑战性的。即使你已经具备了强大的监控和警报系统，但是你的基础设施和应用程序也可能会随着时间的推移而发生变化，这很可能会导致难以可靠地检测异常行为，而对于 7*24 小时不间断运行的后台服务，监控告警是稳定性运行的基石。

很多开发者都有过这样的经历，对服务的每一个指标都做了严格的监控和告警，唯恐漏掉告警导致问题无法发现，导致每天接收到大量的无效告警，告警的泛滥逐渐麻痹了警惕性，结果真实的问题初漏端倪时却被忽略，最终导致了严重的故障。

如何提升告警的有效性，准确识别问题，同时又不至于淹没在大量的无效告警中，正是本文所探讨的内容。

告警是可靠性的基础

首先来看一下告警的重要性，为什么我们需要耗费这么多精力来优化告警。虽然我们都期望一个服务是没有故障的，但事实确是不存在 100% 没问题的系统，我们只能不断提升服务的可靠性，我们期望做到：

1. 对服务当前状态了如指掌，尽在掌控

2. 能够第一时间发现问题，并且快速定位问题原因

要想做到以上两点，只能依赖完善的监控 &告警，监控展示服务的完整运行状态，但是不可能一直盯屏观察，并且也不可能关注到所有方面，要想被动的了解系统状态，唯有通过告警，自动检测异常情况。所以说，告警是团队监控服务质量和可用性的一个最主要手段。

告警面临的现实问题

业务动态变化指标很难设定合适的静态阈值

随着业务的变化，相关的指标往往呈现出以小时、天、周为周期的季节性特征。这些指标本身就起伏不定，导致静态阈值、同比阈值都不好配。而采用偷懒的方式选择对所有应用/接口的响应时间、错误率和调用量等等指标配置成固定阈值自然会产生大量误告警。

相同指标不同应用中阈值不同

以应用响应时间指标为例， 有的接口正常时响应时间可能在 200ms 左右，那么当响应时间大于 300ms 时就可以判定为异常。然而，真实的业务场景中有些接口长期访问量大， 整体指标在 500ms 左右正常波动，所有这时候合适的告警阈值可能是 600ms 左右。而一个应用可能有几百个接口，这时要对所有接口配置合适的阈值，时间成本就会变得非常高。

指标的阈值会随着业务变化

随着公司业务发展、新应用上线，一些指标正常状态的阈值都会不断变化。如果没有及时更新阈值，就很容易产生大量误告警。

告警设置原则

每当告警发生时，运维同学需要暂停手头工作，查看告警。但是这种中断非常影响工作效率，增加研发成本，特别对正在开发调试的同学，影响很严重。所以，每当我们收到告警时，我们希望它能真实的反映出异常，即告警尽可能不误报(对正常状态报警)；每当有异常产生时，报警应该及时发出来，即告警不能漏报(错过报警)。误报和漏报总是一对矛盾的指标。以下是一些告警设置原则：

1. 告警具备真实性：告警必须反馈某个真实存在的现象，展示你的服务正在出现的问题或即将出现的问题

2. 告警表述详细：从内容上，告警要近可能详细的描述现象，比如服务器在某个时间点具体发生了什么异常

3. 告警具备可操作性：每当收到告警时，一般需要做出某些操作，对于某些无须做出操作的告警，最好取消。当且仅当需要做某种操作时，才需要通知

4. 新告警使用保守阈值：在配置告警之初，应尽可能扩大监控告警覆盖面，选取保守的阈值，尽可能避免漏报。

5. 告警持续优化：后续持续对告警进行统计分析，对误报的告警，通过屏蔽、简化、阈值调整、更精准的体现原因等多种方式减少误报，这是一个相对长期的过程。

再以请求失败举例，如仅当请求的失败量超过某一阈值时告警，可能存在多种原因，如一些恶意构造的请求，也触发失败量告警。这样的告警既不具备真实性，也不具备可操作性，因为确实无需任何处理。对于此类情况，我们应该尽可能通过特性加以识别，从而更加精准的区分原因的告警。

告警工具选择

观测云 VS Grafana VS ZABBIX VS Open-falcon VS ARM3.0

Grafana 检测配置

Grafana 除了支持丰富的数据源和图表功能之外，还支持告警功能，该功能也使得 Grafana 从一个数据可视化工具成为了一个真正的监控利器。Grafana 可以通过 Alerting 模块的配置把监控数据中的异常信息进行告警，告警的规则可以直接基于现有的数据图表进行配置，在告警的时候也会把出现异常的图表进行通知，使得我们的告警通知更加友好。

但是 Grafana 的告警的触发条件主要以指标的频率与既定的阈值比较为主，对于离群检测、突变检测等高级高级项相对缺失。

Zabbix 检测配置

zabbix 的检测配置相对较为繁琐，需要大量的自建检测脚本来支持，配置步骤为首先需要新建一个检测场景，在场景中新建监控界面并创建对应主机的触发器来新建检测。

zabbix 的告警规则以表达式为主，支持阈值检测为主，对于离群检测、突变检测等高级高级项相对缺失。

Open-falcon 检测配置

Open-falcon 相对于 zabbix 来说有着强大灵活的数据采集能力，支持自动发现，支持 falcon-agent、snmp、支持用户主动 push、用户自定义插件支持、opentsdb data model like（timestamp、endpoint、metric、key-value tags）和水平扩展能力，支持每个周期上亿次的数据采集、告警判定、历史数据存储和查询但是不支持很多基础的服务器监控插件（如 Tomcat、apache 等等）且功能相对 zabbix 来说还是不够完善。

同样 Open-falcon 的告警的触发条件主要以指标的频率与既定的阈值比较为主，对于离群检测、突变检测等高级高级项相对缺失。

观测云的区间检测监控

随着公司的业务发展、新应用的上线一般的阈值检测已经很难满足我们的需求了。在观测云使用区间检测后每一次检测中，监视器会根据指标过去的值计算出一个正常上限和正常下限，即一个正常区间，然后用指标的当前值（一段时期的均值/最小值/最大值/和值）与这个上限和下限比较。如果满足异常条件，监视器便会给出警告。在此，我们使用局部异常因子算法（Local Outlier Factor-LOF）。这是一种结合了距离因素和密度因素的异常检测算法。在 LOF 中定义了第 k 距离，可达距离，局部可达密度等概念，很好的平衡了距离因素和密度因 素。在监控器中使用此算法，我们需要使用指标的过去值来训练模型，然后计算出一个或是多个区间，而落入此区间的点可以被看做是正常的。

具体的做法是，使用拟合后的模型，在训练集的最大值 max 和最小值 min 之间遍历，如采样 1000 个数据点，或者采样 n 倍的训练集数据点，然后对相邻的正常数据点进行合并，以此来寻找所有潜在的正常区间。采样点数越多，则可能的区间越多。根据需要，我们可以合并比较小的区间。特殊情况下，如当指标的表现比较平稳，我们可以只算出一个正常区间。

如上图中，红线左侧代表我们使用的过去参考值，右侧代表我们需要进行判断的当前值，而绿色阴影部分表示我们根据过去值计算出的一个正常区间，我们可以根据不同的聚合函数和比较方式来到达不同的效果。这样就可以尽量避免无效告警的发生了。

告警工具使用

利用观测云监控器进行区间检测

区间检测配置

基本信息

• 规则名称：检测规则的名称

• 关联仪表板：需要关联的仪表板或是异常事件可能影响到的仪表板

检测配置

1. 检测频率：监控算法的执行周期，目前配置固定与检测区间相关为 5 分钟、5 分钟、15 分钟、30 分钟、1 小时、1 小时

2. 检测区间：每次执行任务时，检测指标查询的时间范围(获取数据范围)

3. 检测指标：监控的指标数据，每次只允许检测一个指标(只支持指标类数据)。

4. 触发条件：设置告警级别的触发条件

• 告警级别：包含紧急（红色）、重要（橙色）、警告（黄色）、无数据（灰色）、正常（绿色）五个等级，每个等级只能设置一个触发条件。

• 触发条件：基于周期范围、异常次数、异常方向以及异常点数占比。若查询结果带单位，则提示单位进位后的结果。

告警级别紧急（红色）、重要（橙色）、黄色（警告）

配置异常方向，异常占比说明如下：

• 异常方向：当前区间检测算法含向上（数据超出区间上沿）、向下（数据超出区间下沿）、向上或向下三种检测标准。

• 异常占比：当前区间检测异常方向异常点数超出区间的占比

告警级别无数据（灰色）、正常（绿色）

配置检测周期，说明如下：

• 检测周期＝检测频率

• 自定义检测周期＝检测频率 * N

1. 无数据（灰色）：无数据状态支持「触发无数据事件」、「触发恢复事件」、「不触发事件」三种配置，需要手动配置无数据处理策略。

检测规则生效后，第一次检测无数据且持续无数据，不产生无数据告警事件；

若检测有数据且在配置的自定义检测周期内，数据上报发生断档，则产生无数据告警事件。可参考以下场景：

1. 正常（绿色）：检测规则生效后，产生紧急、重要、警告异常事件后，在配置的自定义检测周期内，数据检测结果恢复正常，则产生恢复告警事件。可参考以下场景：

注意：恢复告警事件不受告警沉默限制。若未设置恢复告警事件检测周期，则告警事件不会恢复，且一直会出现在「事件」-「未恢复事件列表」中。

事件通知

1. 事件标题：设置告警触发条件的事件名称.

2. 事件内容：设置告警触发条件的事件内容，支持使用预置的模板变量，详情参考 模版变量。

3. 告警策略：当监控器满足触发条件后，立即发送告警信息给指定的通知对象。告警策略中包含需要通知的事件等级、通知对象、以及告警沉默周期。

如何利用好区间检测

当在某些业务场景下当业务出现异常时可能会导致磁盘使用率出现异常，或者时有其他应用写入出现错误时时也可能导致磁盘使用率出现变化，这里以检测磁盘使用率区间异常为例，当发现磁盘使用率快速升高超出区间时就要及时来排查当前 host 可能影响业务的进程了。

检测配置

1. 检测区间：为了更好的检测磁盘使用率的异常增长，检测区间采用获取近 15 分钟的数据作为检测基础来分析异常（可以根据业务重要程度来动态调整）

2. 检测指标：检测指标为目标 host，device 的内存使用率指标

M::`disk`:(AVG(`used_percent`)) BY `host`, `device`

1. 触发条件

• 告警级别紧急（红色）：我们认为当磁盘使用率在最近 15 分钟(5 秒为一个聚合点)出现超出区间的异常数据占比超过 50% 时为紧急的异常事件，需要我们及时的进行人为的干预排查，避免影响到线上业务的正常运行

• 正常（绿色）：当在连续 2 个检测周期(2 次检测结果)内无异常事件产生，我们就认为当前磁盘使用率异常已经排查到具体进程解决了问题

• 无数据（灰色）：当检测指标连续 2 个检测周期(2 次检测)都出现无数据情况时，会触发无数据告警，当出现无数据告警时，要及时的排查采集的相关异常，保证数据采集情况正常

触发事件

创建好监控器之后在以检测频率为 5 分钟一次的任务中，发现业务波动引起内存使用率发生陡升产生异常告警事件

查看事件详情，发现是主机 izbp152ke14timzud0du15z 的磁盘使用率异常点超出区间边界占比达到了 99.45%

也可以通过监控器关联的视图来查看是否能定位问题

也可以通过查看相关进程功能跳转到具体的进程页面进行分析看是那个进程是比较可以的

由分析得出有人在该业务环境进行测试，导致了大量资源占用，通过处理相关进程来进行业务恢复

恢复事件

当持续检测 10 个周期都没发现异常即因为已经经过人为干预处理了异常，事件的异常状态会自动调整为恢复，及未恢复 -1