智能运维的集中告警平台实战思路 —— 紧耦合还是宽融合？

作者：擎创科技产品总监 Daniel

本文是节选，如感兴趣可留言一起探讨。

（ 我们在确定一个产品的思路和方向时，经常面临截然不同的选择。如同此文探讨的集中告警平台是否应跟集中监控平台紧绑定或松融合，具体的实战案例或许也提供一些方向。作为吃瓜群众，本博主从来支持各自发展、偶尔连接，做灵活性大的产品。且看银行客户怎么做的）

案例背景概述：（股份制商业银行）

不破不立：

• 近年来随着中美关系微妙变化，传统国外厂商监控软件的本地化支撑能力日趋减弱，愈来愈接近改造的边缘
• 行内首当其冲的是Tivoli为代表的的传统基础监控，替换势在必行。信创发展也成为了集中监控告警平台改造的另外一个契机

顺势而为：

• 由于ECC值班告警平台需要具有直观、快速、界面中文等特点，行内原来就并未采用原有Tivoli内置的告警平台，而是引入一套以简单可用，以开源为基础的快捷告警平台。
• 原有平台的告警处置以确认、分派、流转为主。随着监控对象和范围的扩大，压缩、关联等能力都有迫切需要进一步提升，因此改造监控的同时完成一体化监控告警管理是非常有必要的。
• 在改造集中监控平台的同事完成集中告警平台的优化与改造顺理成章。

---

方案探索 --- 紧耦合还是宽融合

集中监控告警整体方案在推进中遇到了一个选型设计的小问题，究竟应该将集中告警内嵌耦合于集中监控平台，还是应该独立构建集中告警平台，然后与集中监控平台实现融合打通？

无论是传统集中监控平台，还是新一代信创的集中监控平台，都在监控中会内嵌一个告警中心，毕竟监控的结果是触发告警，需要有告警的集中汇聚点。于是，很容易得到的结论就是：为什么不节省些成本，直接采用这个被耦合的告警中心呢？成本低，一体化，实施快，应该还是不错的选择。

紧耦合的模式确实会带来不少问题：

• 主营与副业

主流的监控平台注重的稳定，可靠，全覆盖，告警虽然重要，但是在监控平台的眼里，如何更高效的采集，如何对象化拆解，如何找到监控对象相互之间的调用关联是无疑是重中之重。于是出发点不同造成了普遍的共识是耦合型的告警平台是监控平台的副业，是监控主营业务下的附属品。这就为紧耦合后告警平台的后续发展带来隐忧。

对比下历史，这种主营与副业恰好解释了为什么当年Omnibus会在事件管理平台领域横扫四大传统管理厂商，成为一个垂直领域的王者。

• 视角主义

虽然每个监控平台的目标都是完美的全覆盖，但IT环境的复杂度决定了Manage Everything ≈ Manage Nothing。于是现实中的监控平台几乎没有全覆盖+全完美的，APM，云原生、系统监控、网络监控，可谓八仙过海，各显神通。

紧耦合的告警平台往往考虑的更多的是自家的监控，对于外延式的其他监控平台的集成度和融合度就显得有些捉襟见肘。

• 从Ack到赋能

告警平台与20年前相比，已经不能仅仅停留在确认（Ack），简单压缩这个层面上了。今天的平台无论是智能化还是规则驱动，其本质应该需要赋能，构建个性化沉淀闭环，才能真正在运维体系中达到效率的提升和效益的显现。而这就需要更加专注的在告警平台上投入，但似乎调研了很多家的监控平台，能把告警平台做到赋能层面的似乎鲜有所闻。 

综合来看，如果需要一个低成本速效药那么买一送一的模式应该是不错的选择，但是从长治久安的角度出发，垂直域深耕的一个独立告警平台无疑是一个不错的选择。

---

现状梳理

为了做出一个更加贴合实际的选择，行方对现有告警平台和处置遇到的问题从若干维度进行了梳理：

• 噪音告警 --- 麻痹疏漏是顽症

从实际数据来看，平均每天原始告警20000+，告警量是1000多条，真正关注的告警不超过100条，主要关注业务类、指标类告警。因此需要确保关键告警不能被淹没和遗漏。

• 关联聚合 --- 告警压缩能力略显单一

原有系统只能通过全局关键字进行压缩。典型问题就是对于F5网络设备告警中IP地址没有的告警将无法进行压缩，而每天F5网络告警200+条，无效告警100+条。

• 个性关注 --- 告警筛选灵活度不够

外包值班管理员对告警的筛选有个性化要求，原有的模式相对简单，导致常有告警遗漏电话通知。每月约有近10+条告警漏通知，其中还不乏少量重要告警。

• 复盘分析 --- 缺乏闭环沉淀

由于行方晚上均为外包人员，而外包人员知识量匮乏，缺乏沉淀确实导致提示不够，时常值班人员遇到告警，会有不知所措的瞬间。

• 处置一体化：

告警的处置通常需要快速联动，确认告警的有效性的前提是足够的支撑数据能够便捷地被整合，就好比坐在运维驾驶舱内能看到即时仪表盘。而关联信息可能是来自业务监控平台，也可能需要到日志平台二次确认，这些有助于分析处置一体化的信息在原有平台上很难被整合。

基础必备能力：

综合现状来看，无论方案内耦合还是外独立，都需要解决以下几个基础维度的问题

• 告警数据灵活降噪：

  • 对于无效告警需要用灵活的模式去处置，比如针对性的过滤，维护期关联等

  • 针对不同源端告警，可以采用不同形式的压缩方式进行降噪。数据质量虽然参差不齐，但在数据治理改造完之前，需要分而治之

  • 通过个性化标签或者增强压缩等形式，有效减少告警通知量

• 告警识别有效聚焦：

  • 每个人根据自身角色定义不同的个性化值班台，快速构建自己所关注的告警

  • 对于一些告警固有的特征通过算法或统计规律进行适度提示

• 告警信息沉淀集成：

  • 相似告警的提示，提供历史处理借鉴

  • 告警一体化、个性化的全息视图，为告警补充更多的已知信息和知识

… … 

---

实战落地：

项目的推进从纸面逐步落到实战，最终还是选择了独立的统一告警平台。毕竟寸有所长，尺有所短，把“专业的事情交给专业的人去做”。独立的告警平台构建也能赋予了告警治理更灵活的手段，更个性化的场景构造能力。虽然治理改造的工作也并非一蹴而就，但短短几个月的时间,现有20多套数据源全部集成到告警辨析中心，实现行内告警统一管理与处置：

• 有效将噪音告警，通过过滤、语义压缩结合个性化数据源规则压缩，最终个性化供给用户真正关注的内容，将每天2w+条原始告警压缩至200-条告警。

  • 以2022年11月某日18:36分发生的F5告警为例，主要包括2类告警，分别是端口down和无可用服务。两套系统并行阶段，由于原系统只能通过全局的固定关键字进行压缩，旧平台共计产生了18条告警。经过新平台压缩后生成6条告警，降噪12条无效告警。虽然还不能一举登峰，但优化效果

• 不同运维人员拥有不同的磁贴看板，例如“已通知未解决”、“电话通知”、“待处理”，“电话通知”、“临时待处理”、“变更中”，根据不同看板快速定位自己所关注的告警，分钟级别查找缩短到秒级。有效区分哪些挂起的告警，哪些告警是需要电话通知的告警。避免瞬时海量告警爆发导致关键告警淹没。

• 能够通过历史相似告警的解决方案提示信息，外包人员能够从之前历史经验中快速了解问题的处置方案，在最近一个月时间内，在数据库宕机异常、文件系统异常问题上的使用，使得运维人员在处置效率上提升了46%。

• ... ... 限于具体故障场景的私密性，这里不便展开。

本项目还在继续进行，不同的项目独立集中告警平台的构建由于出发点不同，实际的内容也远远不止这些。有些更关注的是前后打通，有警必达；有的关注告警自动化开单；有的关注场景联动；还有的关注一体化外围信息聚合助力问题解决。

只是万丈高楼平地起，无论哪种视角，无论是紧耦合还是宽融合，告警平台需要把基础打扎实了，与源端管理配合，在告警信息侧尽可能高效原子化解耦，后续在上层告警侧针对性分析才能有据可依，有数可析。