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

2020-03-01 274浏览

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亿元人民币投资方：红点资本君联资本天善资本中经合资本百度风投
42.
43.欢迎关注msup微信公众账号关注大会微信公共账号，及时了解大会动态、日程及每日更新的案例！关注公众号获得更多案例实践