一、背景

一套监控零碎检测和告警是密不可分的，检测用来发现异常，告警用来将问题信息发送给相应的人。vivo 监控零碎 1.0 时代各个监控零碎别离保护一套计算、存储、检测、告警收敛逻辑，这种架构下对底层数据交融十分不利，也就无奈实现监控零碎更宽泛场景的利用，所以须要进行整体规划，从新对整个监控零碎架构进行调整，在这样的背景下对立监控的指标被确立。

以前监控被划分为根底监控、通用监控、调用链、日志监控、拨测监控等几大零碎，对立监控的指标是将各个监控指标数据进行对立计算、对立存储、对立检测、对立告警、对立展现。这里不作赘述，前面会出一期 vivo 监控零碎演进的文章进一步阐明。

下面咱们说了监控对立的大背景。以前各个监控零碎会各自进行告警收敛、音讯组装等工作，为了缩小冗余，须要将收敛等工作由一个服务对立做解决，与此同时告警核心平台也到了更新迭代的阶段，这样就须要建设一个对外部各业务对立提供告警收敛、音讯组装、告警发送的告警平台，有了这个构想，咱们筹备将各零碎告警收敛能力与告警发送能力下沉，将对立告警服务做成一个与各监控服务解偶的通用服务。

二、现状剖析

对于 1.0 时代的监控零碎来说，如图 1 所示各个监控零碎要先进行告警收敛，而后别离和老的告警核心进行对接，能力将告警音讯发送进去。每一套零碎都要独自进行保护一套规定，有很多反复性能建设，而理论这些性能具备高度通用性，齐全能够建设正当模型对异样检测服务生成的异样进行对立解决，从而生成问题，而后进行对立的音讯组装，最初发送告警音讯。

 (图 1 老监控零碎告警流程图）

在监控零碎中一个异样从被检测进去到最终收回告警有几个重要概念：

异样

在一个检测窗口 (窗口大小能够自定义)，一个或几个指标值达到检测规定定义的异样阈值，就产生一个异样。如图 2 所示，检测规定定义当指标值在一个检测窗口为 6 的检测周期内，有 3 个数据点超过阈值就认为有异样，咱们简称这个检测规定为 6 -3，如图所示第一个检测窗口内(蓝色虚线筐内) 只有 6 和 7 两个点的指标值超过阈值 (95)，不满足 6 - 3 的条件，所以第一个检测窗口没有异样。在第二个检测窗口内(绿色虚线框内) 有 6、7、8 三个点的指标值超过阈值(95)，所以第二个窗口就是一个异样。

问题

一个间断的周期内产生的所有同类异样的汇合，咱们称之为问题。如图 2 所示，第二个检测窗口就是一个异样，同时这个异样也会对应有一个问题 A，如果第三个检测窗口也是一个异样，那么这个异样对应的问题也是 A，所以问题和异样是一对多的关系。

告警

当一个问题通过告警零碎将音讯以短信、电话、邮件等形式告知给用户时，咱们称之为一条告警。

复原

当问题对应的异样不满足检测规定定义的异样条件时，就认为所有异样都复原了，同时问题也认为复原了，复原也会发送相应的复原告诉。

 (图 2 时序数据异样检测原理图）

三、掂量指标

一个零碎咱们如何掂量它的好坏，如何晋升它，如何治理它？管理学巨匠彼得·德鲁克曾说“你如果无奈度量它，就无奈治理它(If you can’t measure it, you can’t manage it)”。从这里能够看出，如果想全面治理晋升一个零碎，就须要先对它的各项性能指标有一个掂量，晓得它的薄弱点在哪里，找到病症所在能力隔靴搔痒。

（图 3 运维指标工夫节点关系图）

图 3 是监控零碎经营指标和对应工夫节点关系图，次要体现了 MTTD、MTTA、MTTF、MTTR、MTBF 等指标与工夫节点的对应关系，这些指标对于晋升零碎性能，帮忙运维团队及早发现问题有很高的参考价值。业界有很多云告警平台也很重视这些指标，上面咱们着重介绍一下 MTTA、MTTR 这两个和告警平台关系严密的指标：

MTTA(Mean time to acknowledge, 均匀应答工夫)：

（图 4 MTTA 计算公式）

• t[i] — 监控零碎运行期间第 i 个服务呈现问题后运维团队或者研发人员响应问题的工夫；
• r[i] — 监控零碎运行期间第 i 个服务呈现问题的总次数。

均匀应答工夫是运维团队或者研发团队响应所有问题所破费的均匀工夫。MTTA 度量规范用于掂量运维团队或研发团队的响应能力和警报系统的效率。通过跟踪和最小化 MTTA，项目管理团队能够优化流程，进步问题解决效率，保障服务可用性，晋升用户满意度[1]。

MTTR(Mean Time To Repair, 均匀培修工夫)：

（图 5 MTTR 计算公式[2]）

• t[ri] — 监控零碎运行期间第 i 个服务呈现 r 次告警后服务恢复正常状态的总工夫
• r[i] — 监控零碎运行期间第 i 个服务呈现告警的总次数

均匀修复工夫（MTTR）是修复零碎并将其复原到失常性能所需的均匀工夫。运维或研发人员开始解决异样，MTTR 便开始计算，并且始终进行到被中断的服务完全恢复（包含所需的任何测试工夫）为止。在 IT 服务治理行业中，MTTR 中的 R 并不总是示意培修。它也能够示意复原，响应或解决。只管这些指标都对应 MTTR，然而它们都有各自的含意，因而，要弄清楚要应用哪个 MTTR，有助于咱们更好的剖析了解问题。让咱们简要地看一下它们各自的含意：

1）均匀复原工夫 (Mean time to recovery) 是从零碎告警中复原所需的均匀工夫。这涵盖了从服务异样导致告警到恢复正常的整个过程。MTTR 是掂量整个复原过程速度的指标。

2）均匀响应工夫 (Mean time to respond) 示意从呈现第一个告警开始到零碎从故障中复原到失常状态所需的均匀工夫，不包含告警零碎中的任何提早。该 MTTR 通常用于网络安全中，以掂量团队缓解零碎攻打的效率。

3）均匀解决工夫 (Mean time to resolve) 示意齐全解决系统故障所破费的均匀工夫，包含检测故障、诊断问题以及确保故障不再产生来解决问题所需的工夫。此 MTTR 指标次要用于掂量不可预感事件的解决过程，而不是服务申请。

晋升 MTTA 的外围是找对人、找到人[3]，只有在最短的工夫内找对能解决问题的人才能无效晋升 MTTR。通常在生产实践过程中咱们会遇到“告警泛滥”的问题，大量的告警呈现时须要运维人员或者开发同学去解决，对于应激敏感的同学来说很容易呈现“狼来了”的景象，只有收到告警就会很缓和，同时当大量的告警信息频发骚扰咱们运维人员，会引发告警疲劳，体现为不重要的事件太多，最基本的问题较少，频繁解决一般事件，重要的信息吞没在汪洋大海中。[4]

（图 6 告警泛滥问题图[5]）

四、功能设计

通过下面两个重要指标的剖析，咱们总结出要从 告警数量 、 告警收敛 、 告警降级 等方面着手，缩小告警发送的数量，晋升告警准确性，最终晋升解决问题的效率，升高问题复原时长。上面咱们从零碎和性能层面阐明如何升高告警量，把真正有价值的告警信息发送到用户手中。本文也将重点围绕告警音讯收敛进行解说。

从图 1 中能够看出各个监控零碎中都有很多反复的功能模块，所以针对这些功能模块咱们能够将其抽离进去，如图 7 所示将告警收敛、告警屏蔽、告警降级等能力对立建设在对立告警服务中。这种架构下对立告警服务与检测相干服务齐全解耦，在能力上具备肯定的通用性。例如其它有告警或音讯收敛需要的业务团队想接入对立告警，对立告警要能满足音讯收敛发送的需要，同时也要满足音讯间接发送的需要。对立告警会提供灵便可配置的音讯发送形式，提供简略、多样的性能满足各类需要。

（图 7 对立告警零碎结构图）

4.1 告警收敛

对于告警平台每天会产生数以万计的告警，这些告警对于运维或开发人员都须要去剖析、甄别优先级、并解决故障。数以万计的告警如果不加收敛每条异样都发送告警，势必会增大运维人员的工作压力，当然也不是所有的告警都须要并且有必要发送给运维人员进行解决。所以咱们须要对告警通过多种手段进行收敛，上面咱们从四个方面介绍一下如何进行告警收敛。

首次告警期待

当一个异样产生之后咱们不会立刻去做告警，而是通过期待一段时间才会去做告警发送，个别这个工夫能够通过零碎自定义，这个值如果太大就会影响告警提早，太小不能晋升告警合并成果。例如首次告警等待时间为 5s，当一个服务下节点 1 呈现 A 指标异样，5s 内节点 2 也呈现了 A 指标异样，那么发送告警时节点 1 和节点 2 会被合并到一起发送告警告诉。

告警距离

问题在没有复原前，零碎会依据告警距离的配置每隔一段时间发送一条告警信息，告警距离用来管制告警发送的频率。

异样收敛维度

异样收敛维度用来将同个维度下的异样合并在一起。例如同个节点门路 A 下，通过同一个检测规定产生的异样，会在告警发送的时候依据配置的异样收敛维度合并在一起。

音讯合并维度

当多个异样收敛成一个问题，在发送告警的时候会波及到音讯合并，音讯合并维度就是用来指定哪些维度能够合并。可能这样了解有些艰涩，咱们能够通过图 8 看一下从异样到音讯的转换过程。

如果一个异样有两个维度名字和性别，当这两个异样通过对立告警，咱们会依据配置的收敛策略进行合并，从图中咱们能够看到性别被定义为异样收敛维度，通常异样收敛维度的抉择肯定是两个或两个以上具备雷同的属性的异样，这样在音讯合并后只取雷同属性的同一个值，对应到示例图，咱们会将 ${sex}占位符替换成男。而名字是被定义为告警合并维度，就示意所有异样中名字是都要展现在音讯文本中，所以在音讯合并的时候咱们会将 ${name}占位符对应的信息一一拼接在音讯文本中。

（图 8 音讯文本替换示意图）

4.2 告警认领

当呈现告警后如果有人认领了该告警，那么后续雷同告警只会发送给告警认领人。告警认领次要是为了解决告警有人跟进后，缩小将告警发给其余人员，也能从肯定水平上解决告警被反复解决的问题。被认领的告警能够勾销认领。

4.3 告警屏蔽

对于同一个问题，能够设置告警屏蔽，后续如果有该问题对应的告警产生，那么将不会被发送进来。告警屏蔽能缩小故障在定位解决过程中，或者服务在发版变更过程中造成的告警，能无效缩小有效告警对运维人员造成的困扰，屏蔽能够设置为周期性的，也能够设置为屏蔽某一时段，当然也能够勾销屏蔽。

4.4 告警回调

当告警规定配置了回调，那么当产生告警，就会调用回调接口，使服务或业务恢复正常。告警回调的目标是当某个服务有告警产生，心愿零碎可能通过一些自动化的配置，使服务复原到失常状态，缩短故障复原的工夫，也可能紧急情况下第一工夫疾速复原服务。

4.5 误告标注

对于一个问题，用户能够通过误告标注备注该异样是否为误告警。误告标注的次要目标是通过标注让零碎开发人员晓得异样检测过程中，哪写点还须要晋升优化，进步告警的准确性，为用户提供真实有效的告警提供保障。

4.6 告警降级

当告警产生肯定工夫仍没有复原，那么零碎就会依据配置主动进行告警降级解决，而后将告警降级信息通过配置发送给对应的人员。告警降级肯定水平上是为了缩短 MTTA，当告警长时间未复原，能够认为故障没有及时失去响应，这时就须要更高级别的人员染指解决。

如图 9 所示，每天告警零碎会发送大量的告警，当然这些告警会别离发送给不同服务的告警接管人。告警并不是越多越好，而是应该第一工夫精确反映出服务的异常情况，所以如何晋升无效告警，进步告警准确性，缩小告警量至关重要。通过以上零碎设计和功能设计可能无效缩小反复告警发送。

（图 9 主机监控告警次数图）

五、架构设计

下面咱们从零碎和性能层名解说了如何针对老架构下存在的各种问题进行解决，那么对于这个构想咱们应该用一套什么架构来实现。

上面咱们看下如何设计这套架构。对立告警作为整个监控最初一环，既要满足告警发送能力也要满足业务服务发送告诉的需要，所以对立告警的各种能力要具备通用性。对立告警服务要做到与其它服务低耦合，尤其是与已有监控零碎做到解偶，这样能力真正把通用能力释放出来。服务要能做到依据业务场景的不同适配不同的业务逻辑，比方有的业务须要做告警收敛，有的业务不须要，那么服务要提供灵便的接入形式以实用业务须要。

如图 10 所示，对立告警外围逻辑由收敛服务实现，收敛服务能够生产 kafka 中的异样，也能够通过 RestFul 接口接管推送过去的异样，异样会先通过异样解决生成一个问题，而后将问题和异样存入 MySql 库，通过告警收敛模块问题会被推送到 Redis 延时队列中，延时队列会用来管制音讯出队工夫，音讯从队列取出之后会进行文本组装等操作，最初会通过配置发送进来。

（图 10 对立告警架构图）

配置管理服务用来治理利用、事件、告警等配置信息，元数据同步服务用来从其它服务同步告警收敛所需的元数据。

六、外围实现

对立告警的外围是告警收敛，收敛的目标就是缩小发送反复的告警音讯，防止因为大量的告警对于告警接管人造成告警麻木。

前文曾经说到应用延时队列做告警收敛，延时队列在电商和领取我的项目中应用较多，比方商品下单后 10 分钟未领取就要主动勾销订单。在告警零碎中应用延时队列次要目标是，在肯定的工夫内尽可能多的将同一个问题对应的异样合并在一起，缩小告警发送的数量。举个例，如果一个服务 A 有三个节点，当产生异样时，个别状况下每个节点的异样都会生成一条告警发送进来，然而通过告警收敛时候咱们能够将三个节点的告警合并，由一条告警做告诉。

延时队列有很多种形式实现，这里咱们抉择了 Redis 实现延时队列，选用 Redis 延时队列次要的起因就是其反对高性能的 score 排序，同时 Redis 的长久化个性，保障了音讯的生产和存贮问题。

如图 11 所示，一个问题通过一系列校验去重之后放入 redis 延时队列，队列中到期工夫最小的问题会被排到最后面，同时有一个监听工作一直查看队列中是否有过期的工作，如果有过期的工作会被取出，取出的音讯会通过音讯组装等操作最终造成一条音讯文本，而后依据配置通过不同的通道发送进来。

（图 11 延时工作执行原理图[6]）

七、将来瞻望

基于对立告警服务定位来看，告警服务要能简略、高效、精确的通知运维或者开发人员，哪里有故障须要去解决。所以对于后续服务的建设，应该思考如何进一步缩小人为的配置，加强告警智能化收敛的能力，同时还要加强根因定位的能力，以上通过 AI 的加持可能很好的解决此类问题。目前各大厂商都在向着 AIOps 摸索后退，并且曾经有一些产品投入使用，然而 AIOps 何时大规模落地，就目前来看还须要一段时间。相较于 AI 的应用，以后最紧迫的就是让对立告警串联起上下游服务，从而买通数据，为数据流转铺平道路，加强服务的自动化水平，并且反对从更高维度实现告警发送，为故障的发现和解决提供更精确的信息。

八、参考资料

[1]What are MTTR, MTBF, MTTF, and MTTA? A guide to Incident Management metrics

[2]均匀修复工夫[Z].

[3]运维不容错过的 4 个要害指标！

[4]PIGOSS TOC 智慧服务中心让告警治理更智能

[5]大规模智能告警收敛与告警根因技术实际[EB/OL].

[6]你晓得 Redis 能够实现提早队列吗?

​作者：vivo 互联网服务器团队 -Chen Ningning