AIOps对监控报警架构的挑战

1. AIOps对监控报警架构的挑战周伟范⽉林百度基础架构部

2.

3. • 背景介绍 • 报警系统业务模型 • 异常判断⼦系统 • 事件管理⼦系统 • 通告发送⼦系统 • 总结

4. 百度Noah报警系统报警系统故障发生发现通告止损定位恢复总结监控系统支撑多种上层业务 • 内部监控平台 • 公有云监控服务BCM • 私有云运维监控产品NoahEE • 百度AIOps智能运维产品面临巨大架构挑战 • 数据量：五千万数据点/秒 • 报警配置：百万级别 • 报警事件量：千万/每天 • 报警时效性：秒级

5. 使命：精准告警 pv 遇到的问题： 1. 四则运算无法满足业务所有需求（准确率<50%） 2. 核心告警经常被遗漏，故障不能及时发现和处理 3. 机房故障等原因会造成报警风暴，淹没核心告警 100 1 1 1 真实的需求： 1. 升级异常判断算法，提高准确率 2. 报警分级/报警认领/逐级通告，防止告警遗漏 3. 报警合并，抑制报警风暴

6. 需求1：落地AIOps算法的挑战离线验证场景：PV流量指标的突升突降检测 𝑧 − 𝑠𝑐𝑜𝑟𝑒 = 𝑦 − 𝑓(𝑥) 𝑓(𝑥) Case回溯 ~𝑁(0,1) 其中f 𝑥 依赖根据历史数据训练得到的模型 AIOps算法落地难点： • 算法不固定，不断迭代 • 强依赖模型，模型变更频繁 • 算法资源消耗千差万别 ④ 发布上线月级别 QA测试 ① 工程实现 ③ ②

7. 需求2：报警管理的挑战如何能提供一个标准的报警模型，应对繁琐的需求？

8. 需求3：报警⻛暴的挑战如何将运维工程师从报警风暴中解救出来？

9. • 背景介绍 • 报警系统业务模型 • 异常判断⼦系统 • 事件管理⼦系统 • 通告发送⼦系统 • 总结

10. 报警系统业务模型 pv 100 1 1 1

11. • 背景介绍 • 报警系统业务模型 • 异常判断⼦系统 • 事件管理⼦系统 • 通告发送⼦系统 • 总结

12. 异常判断的需求目标：迭代周期从月级别减少为天级别 ① 线上和线下保持一致环境 Ø 相同的运行界面，保证输入和输出的数据模型一致 Ø 不需要改写算法，保证线上/线下相同运行逻辑 ② 小流量测试 Ø 真实流量测试，验证线上/线下一致 Ø 性能和资源评估，验证稳定性 ③ 算法和模型分离，提高模型迭代效率

13. 策略运⾏平台 • 提供一致的算法开发接口，保证在线上和线下的运行环境一致离线环境 • 支持离线回溯Case，进行算法评估策略运行平台 • 提供小规模数据的运行环境，能够快速验证算法在线上的真实运行效果近线环境 • 评估资源消耗和稳定性 • 提供稳定可靠的算法运行环境在线环境 • 异常判断结果发到事件管理子系统

14. 策略运⾏平台架构图 ⑤ / cache ② ④ ③ DB ①

15. 关键设计：状态恢复 p 问题：Failover时，如何快速恢复算法的运行状态 p 分析：谁应该负责状态的恢复 Ø 平台方：需要恢复全部状态，成本高，稳定性差 Ø 开发方：增加用户开发成本 p 方案：将近期的数据重新运行，自动恢复运行状态 Ø AIOps算法只依赖数据和模型 Ø AIOps算法运行速度很快

16. • 背景介绍 • • 报警系统业务模型异常判断⼦系统 • 事件管理⼦系统 • 通告发送⼦系统 • 总结

17. 什么是报警事件监控策略（平响⾼）：latency_avg > 800 事件基本特征： latency_avg Ø 持续性 • 异常时间、恢复时间 Ø 事件与通知 1:N • 报警通知、重复提醒、恢复通知等认领事件 800 Ø 认领对象-事件 t1 异常开始报警事件：平响⾼重复提醒 t2 异常结束 t

18. 多维度报警事件监控策略（分省份分运营商平响⾼）：latency_avg {isp=*, province=*} > 800 事件基本特征： Ø 持续性 • 异常时间、恢复时间 latency_avg 北京移动⼴东电信 Ø 事件与通知 1:N • 报警通知、重复提醒、恢复通知等 800 Ø 认领对象-事件河北联通 t1 t2 t3 t4 ⼴东电信平响⾼北京移动平响⾼ t Ø 策略与事件 1:N • 策略+维度

19. 报警事件状态 latency_avg 重复提醒策略满⾜/ 重复发送异常通知平响过⾼ 800 策略异常/ 发送异常通知 t1 t2 异常重复提醒 t3 t4 认领正常 t 异常⽤户认领/ 发送认领⼴播认领策略正常/ 发送正常通知正常策略正常/ 发送正常通知

20. 报警升级策略判定正常/ 正常通知[0级] 重复提醒策略满⾜/ 异常通知[0级] 策略异常/ 异常通知[0级] 异常 L0 正常通知[01级] 重复提醒策略满⾜/ 升级L1通知[01级] x分钟未认领/ 升级L1通知[01级] 升级 L1 y分钟未恢复/ 升级L1通知[01级] ⽤户认领/ 认领⼴播[0级] x分钟未认领/ 升级L2通知[012级] 正常通知[012级] 升级 L2 y分钟未恢复/ 升级L2通知[012级] ⽤户认领/ 认领⼴播[01级] 认领 L0 重复提醒策略满⾜/ 升级L2通知[012级] 正常⽤户认领/ 认领⼴播[012级] 认领 L1 认领 L2 正常通知[012级] 正常通知[0级] 正常通知[01级] 策略判定正常/

21. 事件状态机引擎 Ø 模型抽象 • 基本元素：状态、条件、动作 • 多种需求⼀个模型 Ø 可扩展性强 • 状态机描述⽂件，⾃由定义状态机⾏为 Ø 引擎式运⾏ • 实例化事件，event=new StateMachine（config） Ø 运维成本低 • 逻辑清晰，表达⼒强，避免⼤量 if else

22. • 背景介绍 • • 报警系统业务模型异常判断⼦系统 • 事件管理⼦系统 • 通告发送⼦系统 • 总结

23. 报警合并 Ø按部署架构合并 • 相同实例、服务、集群 • 相同机器、机房 Message1 Message2 instance1 服务 A instance2 instance3 ... ... instanceX Message3 合并前 MessageX "tags": [{ "key": "instance", "value": " instance1 " }, { "key": "host ", "value": "host1.nj01" }, { "key": "idc ", "value": "nj01" }] 合并后 • 报警等级 – 严重 • 策略信息 – service.a.all:instance:FATAL – 实例类型报警 • 异常实例个数 – 100 • 异常实例列表 – 0.opr-zty5-000-cc.A.bjdc – 1.opr-zty5-000-cc.A.bjdc – ... • 时间 – 2019-11-02 16:49:36 • 报警详情链接 – http://dwz.cn/…

24. 报警合并 Ø跨部署架构的合并 • 上下游关系 • 离线策略挖掘 serviceC:policy3 serviceB serviceA:policy1 t serviceB:policy2 serviceA serviceA:policy1 serviceB:policy2 serviceD:policy4 挖掘窗⼝策略关联关系表 serviceA:policy1 à serviceB:policy2

25. 合并机制合并缓存报警消息 Message Info 报警源触发时刻 Fire Time 最⼤等待时⻓ Linger Time A:Policy1 5 20 合并后 Package A:Policy2 10 20 A:Policy1 40 A:Policy2 B:Policy3 15 A:Policy3 20 20 C:Policy4 25 60 A:Policy3

26. 总结 Ø 关键指标 • 异常检测准确率 90 %、召回率 99 % • 报警时效性 2 秒（99分位值） • 报警短信量削减 85 % Ø 报警能⼒ • ⽆数据报警 • 报警升级、认领、回调 • 报警合并、流控 Ø 商业化产品 • 公有云监控产品BCM • 私有云运维产品NoahEE • 百度AIOps智能运维产品 AIOps智能运维公众号

27.

28.