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.