《张永涛-基于业务链可观测性的根因定位实践.pdf》由会员分享,可在线阅读,更多相关《张永涛-基于业务链可观测性的根因定位实践.pdf(32页珍藏版)》请在三个皮匠报告上搜索。
1、基于业务链可观测性的根因定位主讲人:张永涛演讲嘉宾介绍张永涛日志易售前架构师 带队研发智能运维平台,实现每天10TB+数据的交易链路追踪、黄金指标异常检测、监控告警、实时采集、解析、存储、检索、脱敏、备份还原、审计等功能 参与国有大行应用监控项目的落地,并协助将落地方案推广到其他银行 多年大数据开发和项目管理经验CONTENT目录2023K+01目标、现状、问题达到的目标效果解决方案+案例实践0203Part 01目标、现状、问题 目标 现状 问题目标故障发现1 分钟故障定位3 分钟故障修复5 分钟故障处理的理想目标:1、3、5(或 1、5、10)现 状目前以下监控工具,都有了,或者有几种:1
2、.基础资源性能监控工具Zabbix2.网络监控工具NPM3.应用性能监控工具APM4.业务全链路监控工具5.数据库监控工具6.日志监控工具7.指标监控工具Prometheus8.智能运维:指标异常检测、日志异常检测、根因分析8.仪表盘展示工具grafana9.大屏展示工具10.统一事件管理平台(告警收敛、告警合并)云原生时代-运维新问题复杂度软件开发生命周期阶段传统架构(基于大的应用)云原生架构(基于微服务)操作复杂度增加构建部署运行运维传统架构与云原生架构对比 传统架构:以大的应用为主,架构设计、部署复杂度较高,但后续运行和管理操作复杂度较低 云原生架构:以微服务架构为主,架构设计和部署简便
3、,但后续运行和维护操作复杂度大大增加。云原生架构带来的新挑战包括:线上流量大 微服务数量多,关系复杂 服务上线迭代快 研发团队庞大,分工更细更复杂运维指导思想的演进ITIL服务价值链可用性性能安全性可维护性DevOps软件生命周期协同交付速度(敏捷开发)交付质量Google SRE服务可用性性能评估健康度混沌工程(故障注入)ITSM网管CMDBAPM、NPM、BPM基于图数据的业务CMDBAnsible、PuppetJenkinsGitlab可观测性ELKPrometheuseBPF.可观测性(Observability)可观测性应运而生:随着软件的复杂度增加,跨团队合作越来越多,团队间的沟通
4、或排障,也需要提高效率,防止推诿;因此需要拿数据说话,对可观测性数据的需求,也越来越突出 可观测性的价值:从系统外部输出,来推断、衡量系统内部状态,将复杂的系统黑盒白盒化 可观测性数据分为三类:指标(Metrics)、调用链(Tracing)、日志(Logging)请求范围内的事件能够聚合的指标请求范围内的链路记录事件低流量高流量请求范围内的指标能够聚合的事件例如,错误数请求范围内的、能够聚合的事件运维难题及解决方案一、运维常见难题在运维过程中,一种常见的难题:无法在告警风暴出现时,迅速并精确地定位故障的根因。尽管有传统的解决方案,例如,多指标的根因分析和告警合并,但运维仍面临高误报率的问题二
5、、为什么需要做基于业务链可观测性的根因定位1.重要性:运维工作的核心目标是保证业务的正常运行。因此,运维团队需要优先关注业务系统的运维状态2.必要性:由于业务的快速发展,业务系统的快速迭代变更,可能导致意外故障3.实践经验:通过分析自身几百个客户案例,我们发现40%60%的故障是由业务接口或方法的代码问题引起的基于业务链的根因定位方法,能够更有效地解决运维过程中的问题,准确地找出故障的源头,从而使我们能更快、更有效地解决故障Part 02达到的目标效果 效果1:告警根因列表 效果2:横向纵向告警根因定位 效果3:横向端到端监控效果1:告警根因列表 提供告警根因列表,通过企业微信等,给相关人员发
6、送通知,相关人员按照告警根因列表进行确认效果2:横向纵向告警根因定位【效果】业务端到端调用链的异常分析能力,在本次异常事件处理中起到关键作用,做到2分钟发现问题,3分钟定位根因,故障定位效率显著提升【场景描述】2023年5月15日 14:45左右,手机银行的商品详情页面,出现响应缓慢问题,其对应的接口同时出现平均耗时异常的告警,当时平均耗时达到20971.14毫秒,远远超过正常值(一般为420毫秒左右)【横向】基于服务调用链数据,通过自研的根因分析算法的推荐机制,快速定位到耗时异常的子服务:rule_IProductRuleCheckHintCSV_checkDependRelation耗时4
7、3719.00ms的异常20971.14ms【纵向】进行分层关联立体影响分析,通过服务、应用、中间件、数据库、主机、网络等资源层全面联动,准确定位到问题原因:进程rule-app-g2-srv1在14:42出现内存溢出,导致商品详情页面缓慢效果3:横向纵向监控系统总体健康状况各层健康状况异常告警(颜色对应级别)业务系统告警业务系统运行态势关键指标趋势变化 横向端到端+纵向分层监控:监控业务、应用、数据库、中间件、主机、网络 各层资源运行的健康度 既能总览业务系统整体运行状况,也能查看关键指标的变化,还可以通过钻取、跳转方式追根溯源Part 03解决方案和案例实践 整体解决方案 告警补全 观察易
8、 横向+纵向告警根因定位原理 案例介绍整体解决方案补全告警数据(用于故障发现)+横向告警根因定位+纵向告警根因定位 1.补全告警数据:全面监控各种关键指标 2.进行基于业务链路的横向告警根因定位(前提:Skywalking、Opentelemetry等插码)3.进行基于多层指标的纵向告警根因定位(前提:需要接入和补全基础资源、数据库、中间件等监控告警)验证“告警根因列表”的准确性:通过混沌工程进行故障演练补全告警数据3412对业务层、应用层、中间件层、数据库层、服务器层、网络层、存储层等,构建多层黄金指标监控体系核对黄金指标监控体系告警数据依据积累的实践经验,综合整理出了一系列客户常用的关键指
9、标核对经验指标包括业务链路数据插码采集业务指标数据对统一事件管理平台的历史故障(故障台账)进行分析,发现缺失的监控项,把告警补全核对历史故障告警补全-核对黄金指标监控体系序号架构层级细分层级延迟流量错误饱和度1SAAS业务层业务请求耗时交易量交易错误数、交易成功率并发用户数2应用层接口请求、Full GC耗时 接口请求量、日志量错误返回码、OOMFull GC次数,CPU、内存使用率3PAAS数据库SQL慢查询并发连接数ORA错误类型等CPU、内存使用率4中间件请求耗时并发连接数Exception类型CPU、内存使用率5容器平均延迟流量容器错误POD CPU、内存使用率6IAAS负载均衡平均延
10、迟并发连接数、流量HTTP错误码CPU、内存使用率7网络设备平均延迟带宽使用率、网络流量 丢包率、网口状态CPU、内存使用率8存储平均延迟读写IO磁盘错误存储使用率9虚拟机平均延迟数据传输速率虚拟机错误率虚拟机资源利用率10服务器服务器服务调用延迟服务器数据处理速率服务器硬件错误率服务器CPU、内存利用率 对照下面的黄金指标监控体系,发现告警缺失,把缺失的监控告警补全 构建黄金指标监控体系:对业务层、应用层、中间件层、数据库层、服务器层、网络层、存储层等,构建多层黄金指标监控体系,全景数据化度量运维的健康度用户感知基础架构越往上告警级别越高-越往下越可能是根因业务链路数据:插码序号APM对比项
11、PinpointZipkinJaegerSkyWalkingOpentelemetry1兼容OpenTracing否是是是是2客户端支持语言Java、PHP、PythonJava、C#、Go、JavaScript、Ruby、Scala、PHPJava、C#、Go、PHP、Node.js、Python、C+Java、.NET、Node.js、PHP、Python Java、Python、Go、.NET、Ruby、JavaScript、PHP3存储HBaseElasticsearch、MySQL、内存、CassandraElasticsearch、MySQL、内存、CassandraH2、MySQ
12、L、OpenSearch、ElasticSearchElasticsearch、Beaver、Jaeger、Prometheus4传输协议支持ThriftHTTP、MQudp、HTTPgRPC、HTTPgRPC、HTTP5实现方式字节码注入,无侵入拦截请求,侵入拦截请求,侵入字节码注入,无侵入字节码注入,无侵入6扩展性低高高中高7Trace查询不支持支持支持支持支持8告警支持支持需要结合其他工具需要结合其他工具支持部分支持,需要结合其他工具9JVM监控支持需要结合其他工具需要结合其他工具支持部分支持,需要结合其他工具10性能损失高中中低中等告警补全-核对经验指标 依据积累的实践经验,综合整理出
13、了一系列客户常用的关键指标 将这些指标纳入监控范围,以此来补全监控告警后端采用国产化架构产品-观察易后端以日志易平台为基础,提供数据海量数据的标准化、检索、可视化等能力。数据的存储使用自研搜索引擎Beaver,具备对Tracing、Logging以及Metric数据的存储。数据的计算采用自研Flink流计算平台,提供图形化编排流式大数据处理任务的能力。支持灵活的扩展统计分析视图,形成各类有效的可观测性视图 支持针对指标基于智能运维进行KPI异常检测 支持鲲鹏、飞腾、海光、兆芯+麒麟OS架构描述支持对接各类原数据,支持用于自定义格式的Tracing数据以及各类开源软件产品的Tracing数据,通
14、过流式数据技术,形成统一标准的Open Tracing的数据。Rizhiyi PlatformSearch Processing LanguageLogriverTracingRizhiyi agent观察易日志易前端SkywalkingZipkinJaeger文件UDP/TCPHTTP网管(Metric)BPMAPMElasticsearchHadoopJDBCMetricLoggingBeaverLynxee PlatformFornaxee Platform流式计算KPI异常检测观察易 观察易对接 Opentelemetry、Skywalking、网管、Zabbix 等运维工具的数据,整
15、合链路关系、事件和指标,实现根因定位,以及统一分析、展示横向纵向告警根因定位横向告警根因定位:对业务调用链中的关键业务指标进行全面监控,接收到告警信息后,进行横向根因分析,以便精确识别出业务层级的根因告警纵向告警根因定位:以业务层的根因告警根为切入点,通过时间维度进行关联分析,找出该告警所涉及的服务、应用、主机、网络、数据库以及中间件的告警信息,通过根因计算,确定最终的告警根因列表,以便更准确地解决故障问题横向告警根因定位:根因分析算法流程纵向告警根因定位-原理介绍节点重要性/历史发生频数发生时间告警级别0.8(权重,归一化得到)(1-0.8)*0.9(0.9为权重,归一化得到)(1-0.8)
16、-a*权重(归一化得到)0.7(权重)(0.8-0.7)*0.8(0.8为权重)(0.8-0.7)-a*权重0.6(权重)(0.7-0.6)*0.7(0.7为权重)(0.7-0.6)-a*权重 1.根因告警的计算原理告警根因概率的计算,模拟人工判断的逻辑,具体如下:(1)告警关联的上下游服务节点越多,越可能是告警根因(2)时间越早,越可能是告警根因(3)告警的历史发生频数越少,越可能是告警根因(4)告警等级越高,可能是告警根因 2.根因告警计算的实现方法(1)如果有拓扑关系:依次累加计算 节点重要性、发生时间、告警级别等(2)如果没有拓扑关系:依次累加计算 告警的历史发生频数、发生时间、告警级
17、别等注:对于数据库等重要的服务,可以单独调整告警权重,赋予较高的权重值验证故障定位效果序号故障类别测试场景场景描述1应用服务故障OOM导致JVM虚拟机停止模拟JVM堆内存溢出导致java进程挂掉,导致应用服务不可用2应用服务故障JVM FULL-GC导致性能卡顿模拟JVM频繁FULL-GC,导致应用服务性能卡顿3应用服务故障JVM自定义异常模拟特定类的特定方法返回自定义值或者抛出自定义异常,导致应用服务响应异常4应用服务故障服务内部故障导致服务不可用故障 模拟服务可正常开启服务端口,但无法正常响应请求故障5应用服务故障服务阻塞故障模拟具体服务内部出现阻塞问题6应用服务故障服务性能故障模拟具体服
18、务内部出现性能问题7基础设施故障CPU满载故障模拟依赖的数据库、中间件故障,无法提供服务8基础设施故障内存满载故障模拟CPU高负载故障,导致应用服务卡顿9基础设施故障磁盘占用满模拟内存高负载故障,导致应用服务卡顿10 基础设施故障网络延迟模拟磁盘空间占用满,导致应用服务异常11 基础设施故障网络丢包模拟网络延迟,导致交易耗时明显增加12 依赖故障依赖数据库/中间件不可用故障模拟网络丢包,导致交易耗时增加或异常 通过混沌工程,提供故障演练场景,验证故障定位的准确性,示例如下案例:业务调用链故障诊断-用户收益 用户的最大收益是:有效缩短了故障发现、故障定位、故障修复的时长1.使用日志易之前,依赖人
19、工定位,处理周期耗时长2.使用日志易以后,故障发现、定位、处理,告警知识库的积累,逐渐实现了一部分自动化使用日志易前演进使用日志易后案例:业务调用链故障诊断-用户痛点 用户面临的核心问题:在应对系统故障的过程中,处理时间长且精力消耗巨大。情况概述:由于业务日志数据量巨大和业务调用关系的复杂性,需要从数TB级别的日志中筛选出有价值的信息,这是一项具有挑战性的任务TB级别的日志处理、指标计算能力调用关系复杂资源对象多,难以有机结合,共同定位问题故障处理流程繁琐重点业务:120+重点业务平均调用节点数:170+涉及主机:2000+涉及应用:700+涉及中间件:若干涉及数据库:8套重点数据库案例:业务
20、调用链故障诊断-建设路线引入日志易智能运维引入某厂商和日志易的AI能力,成功建立起一套完整的运维指标体系,并构建了涵盖应用、操作系统、主机、中间件、数据库等8000多个指标的基础指标库。借助AI算法,进行准确的指标异常检测,提前识别并预防运维数据的异常,有效降低了故障率2020-2021年常规业务关联分析通过日志易平台,有效地整合家庭宽带业务数据,实现日志的储存与搜索、业务关联分析,以及基础业务监控告警等多项功能2019-2020年探索故障诊断、故障自愈及根因分析以2020年的运维指标体系为基础,在2021年大力推动了AIOps下的故障诊断、故障自愈,以及基于调用链的根因分析能力。经过不断尝试
21、与改进,逐步建立了一套完善的AIOps体系,并成功将其推广至各省分公司2021-2022年2022-2023年调用链故障定位目标:对调用链涉及的重点业务,进行故障预测,将问题阻挡在发生前以容器部署的CRM系统为试点,构建新的监控体系,对云上的服务进行监控案例:业务调用链故障诊断-落地场景【效果】业务端到端调用链的异常分析能力,在本次异常事件处理中起到关键作用,做到2分钟发现问题,3分钟定位根因,故障定位效率显著提升【场景描述】2023年5月15日 14:45左右,手机银行的商品详情页面,出现响应缓慢问题,其对应的接口同时出现平均耗时异常的告警,当时平均耗时达到20971.14毫秒,远远超过正常值(一般为420毫秒左右)【横向】基于服务调用链数据,通过自研的根因分析算法的推荐机制,快速定位到耗时异常的子服务:rule_IProductRuleCheckHintCSV_checkDependRelation耗时43719.00ms的异常20971.14ms【纵向】进行分层关联立体影响分析,通过服务、应用、中间件、数据库、主机、网络等资源层全面联动,准确定位到问题原因:进程rule-app-g2-srv1在14:42出现内存溢出,导致商品详情页面缓慢THANKS