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

全链路监控在根因分析和业务监控中的应用 群核科技（酷家乐）云原生观测与SRE技术专家/何碧宏 讲师介绍 何碧宏 目前为群核科技（酷家乐）云原生观测与SRE团队负责人、技术专家，稳定性委员会成员，参与SRE、公司SaaS系统稳定性保障工作。此前在诺基亚工作十年，参与过诺基亚DevOps平台的架构和搭建。 演讲提纲 •群核科技（酷家乐）SaaS系统及云原生观测系统（Tetris）简介 •全链路系统监控 •Why-大型微服务系统遇到的问题 •How-基于调用链与图数据库构建实时全链路系统监控 •全链路系统监控在警报风暴根因分析、全链路优化、变更影响分析中的应用 •全链路业务监控 •Why-系统监控vs业务监控 •How-全链路业务监控系统的建设历程 •How-业务监控几大重点工程的突破 •全链路业务监控系统在前后端串联、业务影响分析、多集群海外业务监控中的应用 •定位时长缩短90%-基于全链路监控系统的自动化根因分析实践 •全链路监控系统及魔方语言自动化根因分析系统应用后效果 家居家装商业空间地产建筑设计渲染营销展示生产对接施工落地Coohom 全空间云设计软件平台 服务覆盖200多个国家和地区 2B为主系统大型微服务架构 服务分布式部署在腾讯云、各渲染、内网、自建机房、海外等八个机房以及公有云 典型客户 AIOps 异常检测 故障预测根因分析 流量预测 时序指标预测大模型 前端监控系统 前端异常监控 前端性能监控 前端监控SDK 前端埋点 前端日志 埋点系统 Tetris云原生观测系统 根因分析 魔方语言 告警拓扑图图数据库 全链路监控 警报切面图鲲鹏诊断 私有云监控 应用监控 主机监控硬件监控 公有云监控 中间件监控专线监控 网络监控 告警系统 告警计算引擎 告警处理系统告警规则管理 企信通知 Alertmanager 告警发送系统告警事件管理 短信电话通知 业务监控 业务埋点业务链路 故障定义 故障与工单 统一查询层 调用链系统 日志系统 指标系统 hunterSDK 日志SDK 埋点系统farosSDK f ilebeat 天级指标秒级指标 kafka 分钟级指标 esdruid flink clickhouse thanosprometheus 对象存储 故障定位难 业务异常时，下游可能多个 服务有异常，但下游服务的异常并不一定跟当前业务异常有关；底层服务或基础设施故障时，往往引发大规模警报风暴，应急手忙脚乱，定位难 全链路优化难 一个业务或功能，下游调用 链路非常复杂漫长，下游服务也被多个上游和业务调用，如何找到准确的优化点、以及全链路的核心依赖，进行全链路优化，难度高 变更影响评估难精准测试难 一个API被多个上游和业务使用，一次变更，如何评估影响到了哪些服务、哪些功能和业务，进而进行端到端、全链路精准测试，不是一件容易的事 需要构建一个系统，帮助全链路故障根因定位、优化、变更评估 一个典型的API复杂调用链路 一个API的下游调用依赖拓扑图 几十个下游服务，十几个不同类型中间件 一个典型的警报风暴故障 一个API的故障 十几个下游服务都有异常，告警异常数数百个 基于调用链技术，实时写入，近实时的调用拓扑关系 微服务 写入缓存 根因分析 微服务 微服务 调用链Span kafka Flink 图数据库 拓扑图关系 查询 API分析 变更影响分析 实时调用链数据流实时解析写入图数据库 微服务 AIOps API及应用全链路拓扑图的构建：基于调用链与图数据库构建 A invoke B 实现技术要点： Span1：服务A API=POST/A 调用服务B API=GET/B Span2： •APOST:/A •BGET/B A invoke B invoke C •APOST:/A Span3： 服务A API=POST/B 调用服务D API=POST/D A invoke BD •DPOST/D C 1.图的构成：节点与关系 2.节点包含前端页面、前端微服务、网关、后端微服务、中间件、基础设施等多种类型，使用标签区分，每种类型的节点有不同的标签 3.服务节点有type、name、cmdb、环境名、 stage、集群信息等标签 4.对于API拓扑图，节点是API 5.每个节点有唯一的hash，用于判断是否需要新建新节点，hash由上面标签生成 服务B API=POST/B 调用服务C API=POST/C •BGET/B •CPOST/C 3个Span随机顺序写入，完成后，即构成了完整的API调用拓扑图 6.调用链数据量非常大，采用采样机制，以整条调用链为单位采样解析写入图数据库 7.在写入图数据库的客户端，需要使用缓存，避免短时间内相同的节点重复写入，减少图数据库的压力 8.每个节点都记录更新时间，设置超期时间，定期清理过期的关系，太久没有更新，可能是微服务代码变更失效了 全球化架构：跨区域多机房多集群基础设施及应用关系实时拓扑图的构建 腾讯云集群 AWS集群（全球多个Region） 实例1 主机1 实例1 服务 实例2 主机 服务 主机2 实例2 实例3 跨集群专线 国内自建渲染集群 百度云 主 机 GPU1 GPU2 主 机 4080 4080 其它公有云 线下集群 实例1 主 机 GPU1 GPU2 主 机 4090 4090 服务 主机 实例2 构建服务、实例、主机与集群、网络、专线间的实时关系，用于基础设施类故障的根因分析 图数据库拓扑图能力 基于图数据库构建的拓扑图获得的能力 A invoke H invoke D invoke invoke F invoke B invoke 我 J E invoke invoke 属于 G invoke 主机 invoke C 属于 K 集群 属于 机房 连接 专线 查询上游 查询下游 查询关系 • • • 查询直接上游 查询所有上游查询指定类型、标签上游 广泛用于变更影响 分析上 • • • 查询直接下游 查询所有下游查询指定类型、标签下游 广泛用于应用与业 务故障的根因分析 与定位 • • • 服务与主机 主机与集群集群与专线、网络 广泛用于基础设施 问题的根因分析与定位、变更影响评 估 根因分析中的应用：警报拓扑图 案例：定位Hbase引发的故障 1.按依赖拓扑图展示所有上下游，当某个节点有故障时，特别标记，在警报风暴时，能很快速识别底层应用的故障 2.拓扑图中可查看任意结点的所有相关指标、日志、调用链、警报、上下游服务、中间件、存储、宿主机等数据，故障时，快速定位根因节点 根因分析中的应用：基于警报切面图与警报拓扑图的排查路径 点击进入警报拓扑图，分析根因 1 警报切面图看全局 2 重点警报警报拓扑图分析 警报切面图分级查看故障的业务影响、关键服务、组件、基础设施是否有异常 选择可疑警报，进入警报拓扑图，进一步分析链路上的问题 基于全链路API调用拓扑图实现API全链路分析、优化 高耗时、错误API治理 API架构、复杂调用链路优化 基于API调用拓扑图分析： • • • • • • 强弱依赖的梳理 降级、限流、熔断配置的梳理 调用放大（上游一次调用调用下游多次）、错误重试、循环依赖的治理简化、缩短、合并调用链路 依赖的中间件的梳理、依赖的中间件的必要性 跨机房、跨集群、跨专线调用的服务，尤其对于涉及海外业务的服务 基于耗时、错误率查询出待优化API： •网关API •各服务重点API •前端业务卡顿、报错依赖的API 进入该API的全链路拓扑图 逐个分析拓扑图中各依赖节点的指标，分析主要问题点 基于全链路API调用拓扑图实现变更影响分析 代码变更-->API变更-->所有上游 API-->所有网关API-->所有前端页面 扩缩容、隔离、实例挂掉 实例-->服务-->所有上游 变更影响 分析 配置变更-->所属服务-->所 有上游 主机、网络设备、网络、专线 变更，基于图数据库的所属关 系评估 变更是故障的主要根因之一，故障的变更根因分析与变更分析类似 系统监控 业务监控 系统监控有成熟的开源监控体系系统监控有成熟的指标采集体系，各种exporter+prometheus，部署后也有现成的看板直接查看 故障发现主要基于系统指标，有业界标准 比如CPU、内存、线程数等指标，都有业界标准的异常 识别标准 保障对象主要为系统 主要保障服务、主机、网络、系统等 业务监控数据更多样，需定制配置，更复杂 业务埋点需要基于业务情况进行设计，需识别出业务数据、业务流程、业务链路的异常，不少需定制化设计算法 主要靠业务埋点、以及业务异常数据发现 系统有异常，并不一定业务表现有异常；业务有异常，不一定系统指标有异常，业务逻辑类故障难发现难调查，MTTR高 以客户、业务为中心，重点保障重点客户、核心链路SaaS系统对于重点客户的保障，往往级别很高，需要对重点客户重点保障，提升重点客户的业务故障定位能力和效率很重要；同样核心业务链路也是重点保障内容之一 构建一个全链路业务监控系统，帮助全链路发现、定位业务故障 使用Clickhouse存储提效，开发原文埋点系统，改造调用链实现全保留，精细用户行为回溯系统建设等 1 业务监控基础工程大改造升级 对核心业务、故障定义进行埋点、指标监控 定义核心业务、故障定义指标，进行埋点3 对业务链路、业务指标创建告警规 则，实现告警 业务链路告警、监控5 对业务链路、业务功能进行梳理，并对业务链路和功能进行分级，区分核心、重点链路，对核心链路进行故障定义梳理，重点保障 2梳理业务链路、核心业务、故障定义 建设全链路业务监控系统，将梳理的核心业务链路、业务功能、故障定义、埋点的指标录入系统，并实现前端、业务埋点、后端全链路系统的串联 4 建设业务链路系统，串联前后端及业务 基于全链路业务监控系统，在业务发生故障时，基于链路进行分析定位 6业务链路的全链路分析、故障定位 业务监控几大基础工程重点突破 用户行为精细回溯 业务监控基础工程重点攻关 •成为前端老大难问题的分析定位利器，回溯故障发生前的所有操作和指标数据 •尤其是大对象、大设计方案、特殊参数类故障，定位能力大大提升，定位时长缩短 •记录与分析用户的每一个操作及操作链路，以及相关的日志、指标、调用链，尤其是前端卡顿、OOM、崩溃等重要事件 •解决了Prometheus高基数指标问题 •复杂计算公式的支持，大大提升了对业务数据、业务流程、业务逻辑类异常的发现 •对重点用户实现用户级、方案级精细指标埋点和故障定位 •调查问题不再缺调用链 •基于调用链，可以查看故障时的每一个请求的参数、各链路耗时、错误信息、请求次数等 •串联前后端，从前端异常到后端的全链路分析 调用链全采样保留 •采用Flink实时分析，Clickhouse存储了所有调用链，并对重要链路分级存储 原文埋点系统 •基于Clickhouse的原文埋点系统，既支持原始记录数据查询，又支持秒级、分钟级、天级复杂计算公式的聚合指标查询，实现指标-原始记录的联合下钻分析 Clickhouse替代ES改造 •单位存储成本降低60%，性能提升50%以上 •节省出来的机器，支持更多的业务和数据 •改造原有系统，大范围使用Clickhouse替代es 业务故障的发现及前后端串联定位 自动推送业务链路拓扑图截图，可视化 前端业务故障，拓扑图串联前后端，并标识可能的后端根因节点 大型警报风暴中，业务受损情况发现与评估 大型警报风暴中，识别哪些业务可能受到了影响，并自动识别对应的开发负责人，业务恢复时，有针对性的进行功能验证 复杂跨多集群海外业务故障定位 前端业务 网络 A集群后端服务 B集群后端服务 •海外业务的调用链路非常复杂，跨越多个集群和专线，有些集群的流量又同时包含海外与国内流量，故障定位一直是难点 •接入全链路业务系统后，很多故障已经能够可视化的快速定位 自动学习积累专家定