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

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

Accueil - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-15 17:58
浙ICP备14020137号-1 $Carte des visiteurs$