1、滴滴出行海量数据场景下的 智能监控与故障定位实践2017.12 背景 6 海量指标的产生 微服务化&云化：监控指标量级提升约100倍 指标维度增加：组合爆炸 单机平均指标：约10000 关键技术挑战 计算与存储 异常检测 故障定位 内容提纲 7 一、监控架构 二、异常检测 三、快速定位 滴滴-监控系统概览 8?Odin监控平台 Hera日志服务 BI实时监控 把脉问题定位 9metrics aggr Metric通路 借鉴statsd设计：集成在业务代码内部的埋点上报机制，走UDP协议 本机agent聚合：10s粒度聚合，以及维度聚合 Server端中心聚合：机器粒度聚合 DD-Falcon

2、10实时降采样 实时降采样 rrdtool,写入时 即完成降采样(平衡读写能力)提高 长时间跨度 时的读效率 冷热分离 冷热分离 索引与数据分离,分级索引,优化索引查询 缓存10分钟最新数据,优化即时查询 数据清洗 数据清洗 通过容量控制,兜底 通过多维度自动检测,主动发现、过滤非ts数据 磁盘读写优化等磁盘读写优化等(由Open-Falcon提供)Metric通路：DD-Falcon时序数据存储+：日志计算通路 11 基于流式计算的指标聚合 基于流式计算的指标聚合 日志在Flink中完成ETL、Join、聚合，仅存聚合指标 提供类SQL的流式计算配置化服务 基于基于DruidDruid存储的

3、指标聚合 存储的指标聚合 原始数据在Flink完成ETL、Join 原始指标数据存入Druid 借助Druid的预聚合及计算能力实现监控指标聚合?ODP数据Join介绍 接入数据在存储后转换为数据事件，参与流式Join生成通知事件 实时：订阅通知事件触发特征查询和特征计算、监控 离线：把脉问题定位-离线数据使用 二、异常检测：背景 13海量指标的驱动 迫使改变传统的人工配置模式，探索模型算法 无监督学习，降低标注成本 问题定义 核心指标：高准召率，基于标注训练或者人工精细化调参 非核心指标：低成本接入，中准召率，无标注训练，冷启动，基于反馈自动调整 模型算法 预测+异常判定 二、异常检测：我们

4、经历的几个阶段 141.人工配置 2.单模型（一阳指）3.多模型（六脉神剑）4.通用模型（独孤九剑）阶段2（一阳指）：单模型三阶指数平滑 15预测预测：三阶指数平滑（Holt-Winters）适用于有趋势和周期性的时序指标 模型参数：/，截距/斜率/周期平滑系数 参数确定：人工配置 自动训练：排除异常点最大化拟合度 异常判定异常判定：明确上下界：预测值 固定阈值 历史周期点的指数平滑 滑动窗口的偏差标准差 阶段2（一阳指）：单模型三阶指数平滑 当前应用情况 滴滴核心业务指标：百级别 准召率90%+适用场景及局限 适用于稳定且有周期的指标 指标需连续且无突增突降 接入效率偏低 阶段3（六脉神剑）

5、：多模型，分而治之 当前应用及效果 应用于线上万级别指标 召回线上问题50+准确率约60%召回率约70%实现思路 根据指标特征自动寻找合适模型 自动选择模型参数 目前支持类别 阈值类/同环比/趋势类 阶段3（六脉神剑）：分类 趋势类 多周期性 趋势性 高稳定，波动小 平滑，无突增突降 同环比类 有周期性 中低稳定，波动大 不平滑，有突增突降 动态阈值类 数值分布集中 成功率、时延等指标 动态阈值模型：加权同环比模型：阶段3（六脉神剑）：模型参数训练 阶段3（六脉神剑）：分类模式的缺陷 分类算法：合理性与准确性 分类边缘指标与模型的适配性差 分类覆盖不全：10%无法分类 模型选择及参数训练 无标

6、注场景下，参数训练较困难 新模型研发成本高，周期长 算法架构 不够灵活，落地略困难 阶段4（独孤九剑）：Canary算法-普适性探索 21 核心思路 回到“预测+异常判定”的基本思路 寻找普适性的回归预测模型，弥补HW缺陷 特征的全面性 异常判定：基于残差的概率密度建模 默认阈值的选择 实时标注反馈机制?阶段4（独孤九剑）：Canary算法探索 22 效果对比：分类算法 vs Canary 23 00.51准确率 00.20.40.60.81召回率 00.51F-Score 分类算法 准确率：60%召回率：68.6%F-Score：58.5%Canary算法 准确率：72.3%召回率：78.3

7、%F-Score：71.3%三、快速定位 24 定位案例 定位技术方案 案例一：特定errorcode报警 2526案例一：特定errorcode报警-日志详情及Trace关联 27案例一：特定errorcode报警-调用拓扑 28案例二：趋势类指标报警 案例二：趋势类指标报警-成分分析 29案例三：性能报警 30案例三：性能报警-链路瓶颈分析 31案例四：业务问题定位 33定位技术方案 链路追踪与还原 用户、订单、请求、调用 海量日志治理 标准化、云端化、关联分析 34链路追踪：用户，订单，请求 APPRouterTraceID:abcd123?TraceID:abcd123CSpanID:

8、1001TraceID:abcd123CSpanID:1002TraceID:abcd123CSpanID:1003TraceID:abcd123CSpanID:1004TraceID:abcd123CSpanID:1004TraceID:abcd123CSpanID:1004UserID:efg01TraceID?abcd123?OrderID TraceID?PushUserID?TraceID?abcd123TraceID:abcd123 请求链路 TraceID透传 标识唯一一次请求 用户链路 APP透传UserID到接入层 订单链路 API层：OrderID关联TraceID 司乘数

9、据关联 链路追踪：调用链 链路追踪：内部机制?APPRouter?TraceID:abcd123CSpanID:1001?:TraceID:abcd123SpanID:1001?:Trace?Trace?Trace?Trace?TraceID?abcd123?TraceID?abcd123?TraceID:abcd123CSpanID:1002?:TraceID:abcd123CSpanID:1003?:TraceID:abcd123CSpanID:1004?:?内部透传方案设计 低（无）业务侵入：TLS 挑战：异构链路 多语言支持：php/go/java/c+多协议支持：http/thrift 存储及队列：kafka/BQ/mysql 数据透传服务Tpackage 全链路压测：压测流量标识 分城市发布：城市标识 采样机制引入 细粒度日志/临时排查 日志治理：标准化 日志治理：云端化数据架构