何碧宏-全链路监控在根因分析和业务监控中的应用

群核科技（酷家乐）云原生观测与SRE技术专家/何碧宏 讲师介绍 何碧宏 目前为群核科技（酷家乐）云原生观测与SRE团队负责人、技术专家，稳定性委员会成员，参与SRE、公司SaaS系统稳定性保障工作。此前在诺基亚工作十年，参与过诺基亚DevOps平台的架构和搭建。 演讲提纲 群核科技（酷家乐）SaaS系统及云原生观测系统（Tetris）简介 •全链路系统监控 •Why -大型微服务系统遇到的问题•How -基于调用链与图数据库构建实时全链路系统监控•全链路系统监控在警报风暴根因分析、全链路优化、变更影响分析中的应用 •全链路业务监控 •定位时长缩短90% -基于全链路监控系统的自动化根因分析实践 •全链路监控系统及魔方语言自动化根因分析系统应用后效果 关于酷家乐（群核科技）关于群核科技（酷家乐）业务及SaaS系统 Why -大型微服务系统遇到的问题 变更影响评估难精准测试难 全链路优化难 故障定位难 一个业务或功能，下游调用链路非常复杂漫长，下游服务也被多个上游和业务调用，如何找到准确的优化点、以及全链路的核心依赖，进行全链路优化，难度高 业务异常时，下游可能多个服务有异常，但下游服务的异常并不一定跟当前业务异常有关；底层服务或基础设施故障时，往往引发大规模警报风暴，应急手忙脚乱，定位难 一个API被多个上游和业务使用，一次变更，如何评估影响到了哪些服务、哪些功能和业务，进而进行端到端、全链路精准测试，不是一件容易的事 需要构建一个系统，帮助全链路故障根因定位、优化、变更评估 Why -大型微服务系统遇到的问题 一个典型的API复杂调用链路 十几个下游服务都有异常，告警异常数数百个 几十个下游服务，十几个不同类型中间件 How -全链路系统监控的构建 基于调用链技术，实时写入，近实时的调用拓扑关系 How -全链路系统监控的构建 API及应用全链路拓扑图的构建：基于调用链与图数据库构建 实现技术要点： Span 3：服务AAPI=POST /B调用服务DAPI= POST /D Span 1：服务AAPI=POST /A调用服务BAPI= GET /B 1.图的构成：节点与关系2.节点包含前端页面、前端微服务、网关、后端微服务、中间件、基础设施等多种类型，使用标签区分，每种类型的节点有不同的标签3.服务节点有type、name、cmdb、环境名、stage、集群信息等标签4.对于API拓扑图，节点是API5.每个节点有唯一的hash，用于判断是否需要新建新节点，hash由上面标签生成6.调用链数据量非常大，采用采样机制，以整条调用链为单位采样解析写入图数据库7.在写入图数据库的客户端，需要使用缓存，避免短时间内相同的节点重复写入，减少图数据库的压力8.每个节点都记录更新时间，设置超期时间，定期清理过期的关系，太久没有更新，可能是微服务代码变更失效了 Span 2：服务BAPI=POST /B调用服务CAPI= POST /C 3个Span随机顺序写入，完成后，即构成了完整的API调用拓扑图 How -全链路系统监控的构建 全球化架构：跨区域多机房多集群基础设施及应用关系实时拓扑图的构建 构建服务、实例、主机与集群、网络、专线间的实时关系，用于基础设施类故障的根因分析 How -全链路系统监控的构建 查询关系 查询下游 查询上游 全链路系统监控应用 根因分析中的应用：警报拓扑图 1.按依赖拓扑图展示所有上下游，当某个节点有故障时，特别标记，在警报风暴时，能很快速识别底层应用的故障2.拓扑图中可查看任意结点的所有相关指标、日志、调用链、警报、上下游服务、中间件、存储、宿主机等数据，故障时，快速定位根因节点 全链路系统监控应用 根因分析中的应用：基于警报切面图与警报拓扑图的排查路径 全链路系统监控应用 基于全链路API调用拓扑图实现API全链路分析、优化 基于耗时、错误率查询出待优化API：•网关API •各服务重点API•前端业务卡顿、报错依赖的API API架构、复杂调用链路优化 基于API调用拓扑图分析：•强弱依赖的梳理 •降级、限流、熔断配置的梳理•调用放大（上游一次调用调用下游多次）、错误重试、循环依赖的治理•简化、缩短、合并调用链路•依赖的中间件的梳理、依赖的中间件的必要性•跨机房、跨集群、跨专线调用的服务，尤其对于涉及海外业务的服务 全链路系统监控应用 基于全链路API调用拓扑图实现变更影响分析 变更是故障的主要根因之一，故障的变更根因分析与变更分析类似 Why -系统监控VS业务监控 业务监控数据更多样，需定制配置，更复杂 系统监控有成熟的指标采集体系，各种exporter +prometheus，部署后也有现成的看板直接查看系统监控有成熟的开源监控体系 业务埋点需要基于业务情况进行设计，需识别出业务数据、业务流程、业务链路的异常，不少需定制化设计算法 主要靠业务埋点、以及业务异常数据发现 系统有异常，并不一定业务表现有异常；业务有异常，不一定系统指标有异常，业务逻辑类故障难发现难调查，MTTR高 SaaS系统对于重点客户的保障，往往级别很高，需要对重点客户重点保障，提升重点客户的业务故障定位能力和效率很重要；同样核心业务链路也是重点保障内容之一以客户、业务为中心，重点保障重点客户、核心链路 构建一个全链路业务监控系统，帮助全链路发现、定位业务故障 How -全链路业务监控系统建设 How -全链路业务监控系统建设 业务监控几大基础工程重点突破 •成为前端老大难问题的分析定位利器，回溯故障发生前的所有操作和指标数据•尤其是大对象、大设计方案、特殊参数类故障，定位能力大大提升，定位时长缩短 用户行为精细回溯 •记录与分析用户的每一个操作及操作链路，以及相关的日志、指标、调用链，尤其是前端卡顿、OOM、崩溃等重要事件•串联前后端，从前端异常到后端的全链路分析 调用链全采样保留 •调查问题不再缺调用链•基于调用链，可以查看故障时的每一个请求的参数、各链路耗时、错误信息、请求次数等 •采用Flink实时分析，Clickhouse存储了所有调用链，并对重要链路分级存储 原文埋点系统 •解决了Prometheus高基数指标问题•复杂计算公式的支持，大大提升了对业务数据、业务流程、业务逻辑类异常的发现•对重点用户实现用户级、方案级精细指标埋点和故障定位 •基于Clickhouse的原文埋点系统，既支持原始记录数据查询，又支持秒级、分钟级、天级复杂计算公式的聚合指标查询，实现指标-原始记录的联合下钻分析 Clickhouse替代ES改造 •单位存储成本降低60%，性能提升50%以上•节省出来的机器，支持更多的业务和数据 •改造原有系统，大范围使用Clickhouse替代es 全链路业务监控系统的应用 业务故障的发现及前后端串联定位 全链路业务监控系统的应用 大型警报风暴中，业务受损情况发现与评估 大型警报风暴中，识别哪些业务可能受到了影响，并自动识别对应的开发负责人，业务恢复时，有针对性的进行功能验证 全链路业务监控系统的应用 复杂跨多集群海外业务故障定位 •海外业务的调用链路非常复杂，跨越多个集群和专线，有些集群的流量又同时包含海外与国内流量，故障定位一直是难点 •接入全链路业务系统后，很多故障已经能够可视化的快速定位 根因分析故障定位进阶-再思考 基于全链路监控系统的魔方语言自动化根因分析 魔方语言-系统架构魔方语言自动化根因分析系统架构 1.可访问公司内部所有数据，不限于监控、大数据、CMDB、DevOps、组织架构等2.融合各数据源数据做重新组合、融合分析3.按照决策调用外部接口，比如DevOps、限流、扩容、隔离、预案系统、警报通知、企业微信等，通知分析结果、提供预案、执行配置的动作 魔方语言-系统架构魔方语言自动化根因分析的效果 大部分典型故障定位时长缩短90%以上 •发现故障20s后，定位到服务和责任人，提供恢复预案供执行 •分析路径精确的，一般能在发现故障后30s内定位完•较复杂的也能在1分钟内定位完 •流量分析定位到爬虫导致故障~ 20分钟-->1分钟内 ~ 5分钟-->25s •变更分析，25s前变更产生大量错误日志 •调用链、流量异常分析、灰度发布对比分析~ 20分钟--> 1分钟内 ~ 10分钟-->20s •定位到网络问题导致警报风暴故障 •定位到单个Pod故障导致警报风暴故障~ 5分钟-->20s 魔方语言自动化根因分析的效果 全链路监控系统及魔方语言自动化根因分析系统应用后效果 魔方语言-系统架构展望未来：基于大模型的智能根因定位方案