朱颖航 Linkedsee灵犀 LinkedAIOps根因溯源互联网落地案例分享

CodeWarrior

2019/07/08 发布于 编程 分类

GIAC2019 

文字内容
1. AIOps根因溯源产品 在互联网的落地实践 朱颖航 Linkedsee灵犀
2. AIOps根因溯源产品 在互联网的落地实践 朱颖航 Linkedsee灵犀
3. SLA仍然是运维No.1 KPI • 投入最大;且始终充满挑战 故障排查仍然是MTTR最大瓶颈 借款业务年度MTTR(min) 借款业务年度SLA 100.000% 99.903% 99.905% 99.502% 400 200 250 137.7368421 101.8 17年 18年 0 99.000% 17年 18年 19年 某BAT企业运维工作量统计 故障定位时间占比 内外客服, 15% 容量管理, 15% 发布变更, 30% 故障处理, 40% 发现+处理 时间 56% 故障定位时间 故障定位 时间 44% 发现+处理时间 19年
4. 故障现状越来越复杂 故障原因占比-概要 故障关联性占比 业务 24% 单点故障 其他疑难杂症, 19% 基础设 施 业务 76% 关联故障 故障原因占比-具体 程序, 24% 安全问题, 5% 服务器硬 件 , 15% • IT基础设施是一套复杂的系统 内外网质 量, 33% • 这个系统呈齿轮状运转,相互依存 • 已经几乎不存在单点型故障 基础设施 网络硬件, 5% IDC风火 水电, 4% IDC风火水电 程序 服务器硬件 网络硬件 内外网质量 安全问题 其他疑难杂症
5. 通常运维组织解决问题的思路 1、长期持续监控建设 2、不断细化的组织分工 A业务运维 应用运维 B业务运维 运维 服务器运维 系统运维 网络运维 数据库运维 3、交互频繁的团队协作
6. 现状痛点1:海量的告警+告警噪音=大量被浪费的人力
7. 现状痛点2:消失的告警=大幅滞后的故障发现时间
8. 现状痛点3:多人协同+专家依赖=排查问题又幸运又低效 9:55以后出现大量请 求错误 错误最多的为基金搜索 页面 首页和基金购买页错误 数量正常 故障定位5分 钟 联系对应变 更人员 变更回滚后 正常 应用运维人员B 最近变更操作人 网络管理员 运维主管 应用运 维 onCall 人员 查找到最近 时间DNS变更 记录 搜索服务服务器性 能正常 搜索前端模块异常日 志聚合后发现搜索连 接大量超时 搜索服务模 应用运维人员A 块 onCall人员 研发人员 理财抢购研发负责人 故障定位50+ 分钟
9. LinkedAIOps数据源
10. 多重故障溯源 指标异常检测 1 通过算法将包括指标异常检测、日志异常检 通过算法自动学习和建立动态基 测、故障根因推荐等多种数据关联,实现快 线,提前感知和发现异常 日志异常检测 2 通过算法自动分析业务运行日志 4 速故障定位 智能故障溯源 平台 一键排障 通过最简单的一键排障入口,实现最高效的 5 故障排查 异常,提前感知和发现潜在故障 告警降噪聚类 3 基于算法的告警降噪和聚类,实 现90%以上的降噪效果 大屏展示 通过直观的关键运维分析数据的展示,实时 掌控关键业务的运行健康状态 6
11. 产品功能 - 统一数据接入和治理 实时性 是否 必需 接入 系统告警(含 IAAS+PAAS层) 开源工具(Zabbix、 Open-falcon、 可推荐行业内厂商;或 Prometheus)、 帮助客户部署 Pinpoint、APM、 API 秒级 是 业务告警 BPM、API 可通过日志数据帮客户梳理 秒级 是 日志 ELK、Rsyslog、 Syslog 可推荐行业内厂商;或 帮助客户部署 分钟级 否 指标(含业务指标和 系统指标) 开源工具(Zabbix、 可帮助客户梳理 Open-falcon)、 API 分钟级 否 工单 Jenkins、ITSM、 API 分钟级 否 数据源 支持的对接方式 客户若当前无此数据源 暂无推荐和代为部署能力
12. 产品功能 - 指标异常检测 n 使用基于深度学习的异常检测算法, 替代传统基于固定阈值的监控方案 n 特点: • 学习历史数据,分析当前指标 曲线趋势是否异常 n 优势: • 零阈值,不再需要配置阈值 • 告警准确率高 • 更早发现异常情况 • 可适应业务发展带来的趋势变 化
13. 产品功能 – 日志异常检测 n 对故障时段的日志做聚类形成日志模 式,并与正常时段的日志模式做对比, 发现异常日志行为,定位故障原因 n 价值: • 出现故障后迅速定位原因,减少 MTTR • 弥补现有监控规则覆盖不到的故 障情况 n 算法特点: • 无需对日志做解析 • 针对监控规则没覆盖的场景,价 值大,准确率高
14. 产品功能 - 告警降噪和辅助增强 n 基于统一数据接入后的统一告警中心 n 去重降噪,将告警量减少90% n 增加基于日志异常检测和指标异常检测 的新告警 n 异常检测算法,将告警准确率提升 至70%
15. 产品功能 - 告警聚合 n 将1个事实故障衍生的所有 相关告警都聚类成1个故障 n 以此作为故障处理的第一站
16. 产品功能 – 多重故障溯源 n 直接推荐根因 n 关联日志、指标、 调用栈、工单数 据等辅助排查
17. 指标异常检测算法 • 发现系统和业务指标的异常情况(异常上涨/下跌) • 难点: Ø 如何定义基线 Ø 根据基线如何定义异常 • 基线定义方法: Ø 规则 Ø 回归:基于时序分解
18. 指标异常检测——基于时序分解确定基线 • 插值补缺 • 平滑降噪 • 局部加权非参数模型 • 季节性周期分解:年、季、月、周、日 • 差分滑动平均自回归模型
19. 指标异常检测——无监督算法如何确定异常 • 基于统计学 Ø 基于分布的估计 召回率较高 Ø 对数似然估计 准确率中等 Ø 基于周期环比 • 效果: 基于机器学习: Ø VAE Ø 孤立森林 Ø EWMA Ø 逻辑回归
20. 指标异常检测——有监督异常检测 • 特征工程(140+): Ø 统计特征 Ø 拟合特征 Ø 分类特征 • 分类器(F1>0.65): Ø XGBoost Ø DNN Ø GBDT
21. 指标异常检测——模型设计 • 在线模型: Ø 对接监控系统拉取最新数据(延迟<10min) Ø 实时判断是否异常(延迟<10s) • 离线模型: Ø 对每条曲线重新训练和定阶(每半小时)
22. 日志异常检测算法 • 对故障时段的日志做聚类形成日志模式,并与正常时段的日志模式 做对比,发现异常日志行为,定位故障原因 • 价值: Ø 出现故障后迅速定位原因,减少MTTR Ø 弥补现有监控规则覆盖不到的故障情况 • 算法特点: Ø 无需对日志做解析 Ø 针对监控规则没覆盖的场景,价值大,准确率高
23. 日志异常检测算法处理步骤 • 初步聚类:层次聚类(专利) • 频繁词权重计算 • 词与词的依赖权重计算 • 多次迭代 • 聚类内模式提取 • 性能:每秒 3 万+条日志
24. 故障消息聚类(一) 故障聚类:将同一个故障引发的告警聚类为故障模式 一、故障消息相似度,特征包括: • 时间:窗口(白天窗口,夜间窗口、节假日窗口) • 描述:停止词、行业同义词(互联网、金融)、实体、动作 • 主机/服务:拓扑距离、数据链路距离 • 级别: • Agent:
25. 故障消息聚类(二) 故障聚类:将同一个故障引发的告警聚类为故障模式 二、故障消息中关键词的关联性: • disk 80% usage • network failure 三、历史数据学习 • 故障消息之间的关联性、主机之间的关联性 • 分析故障 MTTR,调整聚类时间窗口
26. 故障消息聚类评价指标
27. 故障根因定位 根因分析假设:历史故障越频繁,异常程度越高的数据越可能是根 因,难点是如何计算数据的异常程度,即信息熵 • 故障消息的信息熵:消息内容、来源主机、时间 • 日志的信息熵:错误日志的数量、日志模式对比(专利) • 变更:一上线就挂,信息熵高 • 时序指标:预测、异常检测(无监督/有监督)
28. 客户案例一 • 某业务因Redis内存超限发生故障 • 2月16日Redis故障回放 • 08:58 大屏人员看到告警 “xxxx-总体API异常” • 09:09 大屏人员联系业务RD • 09:25 业务RD通知系统运维,初步确定为Redis问题 • 09:35 系统运维确认问题为Redis节点内存使用超限 • 09:40 解决问题,业务逐步恢复正常
29. 客户案例一:效果-告警聚类
30. 客户案例一:根因排查可节省15~20分钟
31. 客户案例二 • 某业务因机器负载过高出现失败 • 15:51 业务监控报出总体API异常 • 16:41 业务方反馈部分业务访问Redis异常 • 16:50 运维确认一台Haproxy节点压力过高 • 之后运维开始修复操作
32. 客户案例二:结果展示-告警聚类
33. 客户案例二:结果展示-时间轴
34. 客户案例二:实时定位异常指标
35. 客户案例二:异常检测算法: 可提前大屏监控51分钟,提前业务侧101分钟发出告警
36. 试运⾏客户使⽤场景 • 使用触发条件: Ø 客户收到原监控系统发出的告警,需要寻找根因或确定告警影响范围时, 登陆产品 • 产品使用方法: Ø 根据收到告警的时间、关键字、主机信息,在情境中心的最前面找到描 述相同的情境,点击查看分析结果详情 • 分析结果使用方法: Ø “关联指标”列表的最前面会显示异常指标和所在主机,点击查看趋势 图可做人工确认 Ø 出现业务告警时,“关联日志”中显示为 “new” 和数量突增的日志需 要引起关注,可通过日志模式文本判断根因和故障影响范围
37. • 场景选择方法: Ø 在试运行汇报现场,客户现场使用产品,找到最近收到的告警在 产品中的位置,查看产品分析结果 • 最近告警和故障内容: Ø 业务做了消息推送,导致短时间内客户大量访问,触发系统层中 间件和消息队列负载过高的告警 • 客户对产品输出的期望: Ø 希望产品能将本次故障涉及的很多条告警聚类到一起 Ø 希望产品能发现故障关联的主机有 CPU 异常升高,且故障之前 一天没有异常
38. 试运⾏场景⼀:客户从该页的2371情境找到与告警短信对应的 Rabbitmq告警,共花费了⼗秒钟左右
39. 试运⾏场景⼀:关联告警,合并效果客户认为符合预期
40. 试运⾏故障⼀ Ø 故障集中在 mq-01, mq-02两台机器,模型认为 mq-01 cpu 出现异常,符合 预期,客户希望查看指标趋势⼈⼯确认是否异常 Ø 异常出现的时间点与推送时间有⼗分钟左右延迟,符合预期,说明成功召回异 常;且推送之前模型认为未出现异常,说明模型没有发⽣误报
41. LinkedSee灵犀公司介绍 智能IT运营专家 公司成立于2015年12月 公司愿景:让所有的中国 企业拥有BAT级的IT运营能 力 核心创业团队来自: 百度 公司总部:北京 分支机构:上海 深圳 南 京 济南 西安 目标市场:互联网 金融 能源 运营商 政府 企业 融 资: 1亿元人民币 投资方: 红点资本 君联资本 天善资本 中经合资本 百度风投
43. 欢迎关注msup微信公众账号 关注大会微信公共账号,及时了解大会动态、 日程及每日更新的案例! 关注公众号获得 更多案例实践