滴滴出行海量数据场景下的智能监控与故障定位实践 李培龙 滴滴出行
2020-03-01 419浏览
- 1.滴滴出行海量数据场景下的 智能监控与故障定位实践 李培龙 2017.12
- 2.
- 3.
- 4.
- 5.个人简介 ✦ 2015年加入滴滴 ✧ 质量架构部负责人 ✧ 主要工作 ü 分布式调用链追踪系统、问题定位系统 ü 日志服务平台、智能异常检测系统 ü 全链路压测平台 ✦ 之前供职于百度 ✧ 监控与问题定位系统 ✧ 性能测试与分级发布平台 5
- 6.背景 ✦ 海量指标的产生 ✧ 微服务化&云化：监控指标量级提升约100倍 ✧ 指标维度增加：组合爆炸 ✧ 单机平均指标：约10000 ✦ 关键技术挑战 ✧ 计算与存储 ✧ 异常检测 ✧ 故障定位 6
- 7.内容提纲 一、监控架构 二、异常检测 三、快速定位 7
- 8.滴滴-监控系统概览 ᶃ Hera日志服务 Odin监控平台 ᶄ ᶆ ᶅ BI实时监控 把脉问题定位 ᶇ 8
- 9.① Metric通路 DD-Falcon metrics aggr ✦ 借鉴statsd设计：集成在业务代码内部的埋点上报机制，走UDP协议 ✦ 本机agent聚合：10s粒度聚合，以及维度聚合 ✦ Server端中心聚合：机器粒度聚合 9
- 10.① Metric通路：DD-Falcon时序数据存储 实时降采样 ・rrdtool, 写入时 即完成降采样(平衡读写能力) ・提高 长时间跨度 时的读效率 冷热分离 ・索引与数据分离, 分级索引, 优化索引查询 ・缓存10分钟最新数据, 优化即时查询 数据清洗 ・通过容量控制, 兜底 ・通过多维度自动检测, 主动发现、过滤非ts数据 磁盘读写优化等(由Open-Falcon提供) 10
- 11.②+③ ：日志计算通路 基于流式计算的指标聚合 ✦ 日志在Flink中完成ETL、Join、聚合，仅存聚合指标 ✦ 提供类SQL的流式计算配置化服务 ᶄ ᶅ 基于Druid存储的指标聚合 ✦ 原始数据在Flink完成ETL、Join ✦ 原始指标数据存入Druid ✦ 借助Druid的预聚合及计算能力实现监控指标聚合 11
- 12.④ ODP数据Join介绍 ✦ 接入数据在存储后转换为数据事件，参与流式Join生成通知事件 ✦ 实时：订阅通知事件触发特征查询和特征计算、监控 ✦ 离线：把脉问题定位-离线数据使用
- 13.二、异常检测：背景 ✦ 海量指标的驱动 ✧ 迫使改变传统的人工配置模式，探索模型算法 ✧ 无监督学习，降低标注成本 ✦ 问题定义 ✧ 核心指标：高准召率，基于标注训练或者人工精细化调参 ✧ 非核心指标：低成本接入，中准召率，无标注训练，冷启动，基于反馈自动调整 ✦ 模型算法 ✧ 预测+异常判定 13
- 14.二、异常检测：我们经历的几个阶段 1. 人工配置 2. 单模型 （一阳指） 3. 多模型 （六脉神剑） 4. 通用模型 （独孤九剑） 14
- 15.阶段2（一阳指）：单模型—三阶指数平滑 ✦ 预测：三阶指数平滑（Holt-Winters） ✧ 适用于有趋势和周期性的时序指标 ✧ 模型参数：α/β/γ，截距/斜率/周期平滑系数 ✧ 参数确定： ü 人工配置 ü 自动训练：排除异常点à最大化拟合度 ✦ 异常判定： ✧ 明确上下界：预测值±δ ✧ 固定阈值 ✧ 历史周期点的指数平滑 ✧ 滑动窗口的偏差标准差 15
- 16.阶段2（一阳指）：单模型—三阶指数平滑 ✦ 当前应用情况 ✧ 滴滴核心业务指标：百级别 ✧ 准召率90%+ ✦ 适用场景及局限 ✧ 适用于稳定且有周期的指标 ✧ 指标需连续且无突增突降 ✧ 接入效率偏低
- 17.阶段3（六脉神剑）：多模型，分而治之 ✦ 实现思路 ✧ 根据指标特征自动寻找合适模型 ✧ 自动选择模型参数 ✧ 目前支持类别 ü 阈值类/同环比/趋势类 ✦ 当前应用及效果 ✧ 应用于线上万级别指标 ✧ 召回线上问题50+ ✧ 准确率约60% ✧ 召回率约70%
- 18.阶段3（六脉神剑）：分类 ✦ 趋势类 ✦ 同环比类 ✦ 动态阈值类 ✧ 多周期性 ✧ 有周期性 ✧ 数值分布集中 ✧ 趋势性 ✧ 中低稳定，波动大 ✧ 成功率、时延等指标 ✧ 高稳定，波动小 ✧ 不平滑，有突增突降 ✧ 平滑，无突增突降
- 19.阶段3（六脉神剑）：模型参数训练 动态阈值模型： 加权同环比模型：
- 20.阶段3（六脉神剑）：分类模式的缺陷 ✦ 分类算法：合理性与准确性 ✧ 分类边缘指标与模型的适配性差 ✧ 分类覆盖不全：10%无法分类 ✦ 模型选择及参数训练 ✧ 无标注场景下，参数训练较困难 ✧ 新模型研发成本高，周期长 ✦ 算法架构 ✧ 不够灵活，落地略困难
- 21.阶段4（独孤九剑）：Canary算法---普适性探索 ✦ 核心思路 ✧ 回到“预测+异常判定”的基本思路 ✧ 寻找普适性的回归预测模型，弥补HW缺陷 ü 特征的全面性 ✧ 异常判定：基于残差的概率密度建模 ü 默认阈值的选择 ü 实时标注反馈机制 21
- 22.阶段4（独孤九剑）：Canary算法探索 22
- 23.效果对比：分类算法 vs Canary 准确率 1 ✦ 分类算法 ✧ 准确率：60% ✧ 召回率：68.6% ✧ F-Score：58.5% 0.5 0 召回率 1 0.8 ✦ Canary算法 ✧ 准确率：72.3% ✧ 召回率：78.3% ✧ F-Score：71.3% 0.6 0.4 0.2 0 F-Score 1 0.5 0 23
- 24.三、快速定位 ✦ 定位案例 ✦ 定位技术方案 24
- 25.案例一：特定errorcode报警 25
- 26.案例一：特定errorcode报警---日志详情及Trace关联 26
- 27.案例一：特定errorcode报警---调用拓扑 27
- 28.案例二：趋势类指标报警 28
- 29.案例二：趋势类指标报警---成分分析 29
- 30.案例三：性能报警 30
- 31.案例三：性能报警---链路瓶颈分析 31
- 32.案例四：业务问题定位
- 33.定位技术方案 ✦ 链路追踪与还原 ✧ 用户、订单、请求、调用 ✦ 海量日志治理 ✧ 标准化、云端化、关联分析 33
- 34.链路追踪：用户，订单，请求 APP ✦ 请求链路 ✧ TraceID透传 UserID TraceID abcd123 ✧ 标识唯一一次请求 RouterTraceID:'>TraceID:
