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.

首页 - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-13 18:38
浙ICP备14020137号-1 $访客地图$