去哪儿网1-5-10故障体系建设：根因分析实践 - 梁成琰

去哪儿网1-5-10故障体系建设：根因分析实践 姓名：梁成琰 GOPS全球运维大会暨研运数智化技术峰会2024·上海站 个人简介 梁成琰 公司职位 梁成琰，去哪儿网资深SRE工程师，目前在基础架构团队从事CICD、可观测性、AIOPS等相关工作。期间推动完成了去哪儿网容器化落地、监控平台升级、根因分析和预案平台的建设。去哪儿网云原生SIG成员，专注于研发效能提升。 故障治理框架 根因架构设计 目录模型持续验证应用实践 未来规划 01 故障治理框架 故障率居高不下 故障发现定位慢 故障恢复慢 责任方、受影响方各自呈现 故障率指标与MTBF、MTTR指标并重结果&过程指标共同呈现 故障治理框架-1-5-10定义 故障治理框架-落地工具 发现 秒级监控雷达智能预警 定位 02 根因分析应用大盘 04 01 故障治理闭环 预案演练强弱依赖演练全链路压测 故障演练预防 攻防演练 变更管家业务巡检 预案系统 03 恢复发布秒级回滚 定位慢-原因分析 信息量大 交互复杂，链路长，难定位信息多，难关注 异常多，难抉择 信息差 中间件问题 单机问题未感知 其他应用事件&变更宿主机问题 查问题工具不熟悉 故障定位-根因分析 解决思路 根因分析系统 根因分析-整体思路 根据可观测性三要素MTL（Metric+Trace+Log）进行分析和建模 Logging:提供系统/进程最精细化的信息，例如某个关键变量、事件、访问记录等，是对应用系统的事件做一条记录，这些记录是我们问题排查，取证的依据 Metrics:提供量化的系统内/外部各个维度的指标，是对某些我们关注事件的聚合，我们可以根据指标设置告警 Tracing:提供了一个请求从接收到处理完毕整个生命周期的跟踪路径，通常请求都是在分布式的系统中处理，所以也叫做分布式链路追踪 。 02 根因架构设计 模拟人的思维 抽象 核心思路： 1.定位范围 2.异常断言 3.关联挖掘 4.剪枝排序 5.结果输出 异常应用断言 异常关联分析 知识图谱构建异常应用分析 聚合分析 01 知识图谱构建 4 异常间关联关系的建立 通过异常指标精确快速找到对应的trace、log异常告警之间的关联关系挖掘 3 应用间关联关系建立 应用调用链路、应用强弱依赖关系 2 资源关联关系建立 应用内部依赖的资源关系如mysql、redis等 物理拓扑感知-应用容器&kvm运行的宿主机、网络环境等 1 基础数据 统一的事件中心、日志、trace、监控指标&告警 02 异常应用断言 异常应用断言 报警&故障 异常应用断言 metric&链路结合 报警 指标trace 异常应用断言-trace筛选 故障期间trace数几千+，如何精确定位到有问题链路 报警 指标trace 误报、闪报、阈值配置不合理人工治理 自动识别无效告警、不做分析（按周、天维度缓存无效告警） 复合指标中有些指标对结果无影响 函数中去除无影响的指标，e.g:asPercent函数只保留分子指标、exclude去除排除的指标等 分析的trace包含非核心链路 根据业务优先级：业务线自定义链路T值、核心链路 异常筛选 qtracer记录链路，如果某次调用超时，或者http/dubbo返回状态码异常，便将此次调用标记为异常，并将trace标记为异常trace T值筛选 T值是去哪儿网大客户端的一个概念，是为了区分各业务线服务的，在请求的时候，会带一个参数qrt称之为T值。不同的T值，对应的业务也不同 拓扑相似度筛选 将拓扑图进行降维，根据特定的规则将拓扑图构建为字符串，转换为字符串的相似度算法 异常应用断言 定位异常应用 应用断言 •trace链路上标记为异常 trace 拓扑构建 按报警应用 划定子图 遍历子图 •报警浓度高于阈值 •P1/P2级别告警 •存在发布/核心配置变更事件 •异常日志同比&环比高于阈值 •api异常率指标高于阈值 03 异常应用分析 runtime分析 KVM&容器:CPU、网络 JVM：fullGC 异常指标单机分析宿主机分析 event分析 发布事件 配置变更压测 ...... middleware分析 01 02 应用 04 03 应用获取对应namespace mysql报警redis报警 mysql慢查询同比环比redis大key log分析 根据traceid从es查询异常日志异常类型权重配置 异常日志同比、环比 全局事件 网络变更基建变更负载均衡全链路压测 链路事件 下游配置变更下游发布 上游qps陡增分析上游特定事件分析 应用自身 配置变更发布 04 异常关联分析 kSigma 斜率相似性 oror 异常单机 异常日志单机占比 离散异常点斜率不同的实例异常占比高的实例 timer类型告警分析策略 额外筛选出告警应用下游耗时大于应用1/2耗时的方法调用 05 聚合分析 01 应用权重 代表当前故障中此应用的异常所占的权重比，表示了此应用影响当前故障的概率大小 02 静态权重 经验权重,根据近期故障原因分布设置 03 动态权重 具体分析到的异常case权重，根据各个根因的严重级别来对自己进行升级，避免真正的根因被淹没掉 04 强弱依赖权重 强弱依赖可以明确表明，A应用调用B应用的m接口是强依赖还是弱依赖，根据此信息可以确认影响概率 应用权重计算 •trace归并:在trace收敛过程中，对多次出现的异常app的权重进行升权 •应用距离:按照告警类型(error、timer)对告警应用进行距离加权,其中error类型的按照链路递归越底层越可能是根因，权重越高 异常日志 同类型异常同比环比计算不同类型异常严重级别判定 运行时 pod异常类型：cpu使用率/OOMpodcpu使用率严重程度 宿主机异常类型-load陡增/宕机/网络异常 动态权重 事件 事件类型权重-发布、配置变更 时间点权重-离告警越近的事件权重越高 中间件 mysql、redis报警级别判定慢查询耗时 慢查询数目同比环比计算 强弱依赖剪枝 •当前告警应用为A，当应用B和应用C都有异常case，而A->B是弱依赖，A->C是强依赖，则倾向认为A的告警由C的异常造成 模型构建-架构 03 模型持续验证 模型验证 1线上真实故障case验证 •系统瞬时故障、故障分析的trace等数据保存到es中，模型迭代时持续回归验证 2结合演练验证准确性 •业务应用接口的强弱依赖演练 •业务攻防演练 •故障混沌演练 3构 境 3构建固定的lab环境 •单应用场景：cpu、网络io、load、redis、mysql、http异常与超时、dubbo异常与超时等 •复杂链路场景：上游、下游应用注入单个异常、多个异常 04 应用实践 核心报警分析 故障根因推送 05 未来规划 未来规划 01 准确率提升 异常日志分析策略优化、模型权重调优、深度结合业务场景定制 02 体系闭环 应对1-5-10治理，根因和故障演练平台、预案平台更好的结合，包括特定场景（单机异常等）的自愈 03 结合业务类变化归因 当前根因分析主要依靠系统类异常分析，业务侧的指标数据变化等无法归因，结合业务侧的归因实践提升根因覆盖范围 Thanks 高效运维社区DevOps时代 荣誉出品