技术应用 | 基于Trace的根因分析实践

文 / 中国平安财产保险股份有限公司安全基础运维部    秦继良

1.基于日志（Logging）。传统日志，我们将所有的业务日志集中采集、展示，并针对一些特定关键字做了告警策略，运维、开发人员可以通过SPL语句对日志做一些聚合、统计，虽然对于查询效率有显著提升，但仍很难从日志中挖掘出真正的异常信息；日志聚类：基于以上痛点，我们针对异常日志进行了聚类分析。可对关键字、结构化数据实时聚合分析统计，并基于聚合分析结果进行实时告警，对于时效性要求较低的异常我们会发送Exception报表，极大简化了研发人员对日志分析的门槛。

2.基于指标（Metrics）。传统指标，指标主要展示了程序最后的执行结果，传统的指标维度并不具备真正的可观测性，开发人员需要拿着结果去猜测和验证导致结果的原因和过程，例如CPU使用率仅代表程序执行后CPU被使用的情况，那么他是如何被使用的以及具体是什么原因导致使用率异常，我们需要通过其他手段来去深入研究和分析，这往往更多的依赖运维、开发人员的经验；多维指标，业务有感的大规模故障来临时，往往伴随的告警风暴的来临，对于业务链路中的关键指标会大范围波动，我们难以从中找出哪些是因哪些是果，往往一个排查方向错误就会耗费大量的时间和精力，为明确导致指标异常的具体根因，我们基于多维度的指标分析，预设一些指标之间的因果关系和故障特征，例如单宿主机故障会导致上面的POD大规模异常、数据库异常会引发应用线程池异常，根据此类多维度的指标因果分析，可以帮助运维、开发人员更容易定位问题。

3.基于链路（Tracing）。传统链路，得益于平安财险研发流程的标准化，绝大部分的应用均使用JAVA技术栈开发，我们在很早起就接入了链路追踪监控，极大地帮助我们解决了一些可观测领域的痛点，我们也通过链路追踪技术快速定位了很多问题，链路所采集的数据虽然比较完善，但早期我们仅仅是将调用链采集的数据展示出来，交由开发自行分析与故障定位，这十分依赖运维、开发人员的经验，面对海量的调用链路信息，未必可以很快找到根因，如果找错了方向，就会延长故障处理的时间。

常用的链路指标包括慢请求、错误请求、慢线程、CPU、内存、GC，下文会重点关注以下两个指标的根因分析。根因分析模块架构图见图1。

图1    根因分析模块架构图

1.错误分析。异常分析功能中，异常对应Java语言的Exception。由于存在Try-Catch机制，在一次接口调用中，异常不一定会被请求方所感知，多次Try-Catch会导致一个接口调用对应多个异常的情况。如果存在没有被捕获的异常，影响到了一次接口调用的返回结果，则构成一次错误。如响应码200正常，但有Exception则统计为正常请求，在堆栈详情页中也可以看到具体的Exception信息，相比于慢请求而言，错误分析是比较好分析和聚类的，分析结果输出见图2。

图2  错误分析

（1）链路维度：当用户找到某个具体的链路，平台会根据用户点选的链路，在堆栈信息中抓到关键的异常信息，系统将当前应用、下游应用、资源等异常总结分析，方便定位报错的归因。

（2）集群维度：当用户无法确定哪个接口产生的异常，系统会基于集群维度对所有的异常请求样本进行聚类分析，并根据预设经验规则给出根因推荐。

2.慢请求分析。通常情况下，运维、研发人员收到慢请求告警，可以通过以下两种方式查看告警。一种是通过散点图框选需要查看的链路信息，在框选动作中可以指定框选出高耗时的请求，但框选出来的请求可能包含多个接口，这些接口并非全都是异常的原因，有的是被影响、被拖累的，按照耗时维度框选出来后，需要对所选接口进行分别查看，这极为耗时耗力，并且有靠运气的成分，运气好可以点到真正根因的接口，运气不好可能需要反复点选，虽然这些接口都是慢请求，但不一定能快速定位到真正的根因；另一种按照接口维度对慢请求次数、占比等进行排序，然后根据经验选取认为可能是根因的接口进行链路查看，这也存在上述同样的问题，排名Top1的不一定是真正的原因，即便运气好找到了有问题的接口，但在接口页面里，还需要继续点选接口对应的请求，一个接口可能有几百个慢请求，这很难选到异常明显的接口。为了解决上述问题，我们在现有链路数据的基础上，做了慢请求的聚类分析，从靠人、靠经验转变为数字化根因分析，分析结果输出见图3。

图3  慢请求分析

（1）链路维度。当用户找到某个具体的链路，平台会根据用户点选的链路，在堆栈信息中抓到关键的数据，系统将当前应用、下游应用、资源等耗时慢的进行总结分析，方便定位慢的归因，当调用数据库慢的情况，会自动提供慢SQL方便分析。支持以下场景：自身执行耗时长；下游耗时长导致本次请求耗时长；资源匮乏导致耗时长；多次调用数据库导致整体耗时长。

（2）集群维度。当用户无法确定哪个接口是慢请求根因，系统会基于集群维度对所有的慢请求样本进行聚类分析，并根据预设经验规则给出根因推荐，支持以下场景：TOP3慢实例以及对应占比；TOP3慢接口以及对应慢Trace；慢Trace中的TOP1慢方法；资源异常的TOP3实例。

（3）火焰图。对于某个trace方法耗时进行分析，我们可以通过火焰图帮助用户直观的查看左边查看拓扑图上各节点的调用顺序和耗时，选择分析某个节点，右边展开该节点详细的span调用关系和耗时。

3.链路下钻。上文讲述了可观测领域的三大支柱，即日志、链路、指标，为更好地提升固定根因分析能力，我们需要将指标、日志、事件通过Trace将关联起来，避免形成数据孤岛。关联日志，新版本Agent已支持常见日志框架如Log4j、LogBack的自动串联，打印出来带有TraceId的日志并上传到日志平台，当用户查看时可关联到对应的日志信息；关联指标，得益于应用的标准化部署以及CMDB数据的自动化更新，我们可以通过应用CMDB数据关联到应用实例的各种指标数据，当用户查看链路或实例信息时可以带出主机、容器、中间件甚至数据库的指标数据，可更快捷地帮助用户定位问题；关联事件，得益于近年来对变更操作的管控与变更信息的治理，我们也积累了大量的变更数据，我们也将版本变更等事件集成到链路里来，方便用户排查异常是否是由相关事件引起的。

自根因分析功能上线以来，帮助我们快速定位了很多生产问题，大幅缩短了MTTR。

案例1：某出单业务监控发现JVM线程数升高，业务反馈出单缓慢，我们通过异常接口的Trace关联日志、指标、事件等数据定位到是下游某公共系统堵塞，并及时启动应急预案避免业务影响扩大。

案例2：某理赔业务监控发现接口响应超时，业务反馈操作缓慢，我们通过根因分析发现其中一个POD发生连续多次Full Gc，并且异常请求都集中在一个POD上，根因分析功能帮助快速定位到了问题，运维人员对故障POD进行了隔离操作，隔离后故障恢复。

在生产环境中，耗时突增的原因有很多，常见的包括负载不均、单节点故障、程序异常和依赖组件故障等，以上仅为相对有代表性的案例。

目前而言，我们努力的方向的是通过Trace进行更多的数据关联，从海量数据中挖掘出有价值的信息，然而这种方式依然存在很多不足，例如无法对小众语言、网络设备、负载均衡器、数据库等进行插桩，部分链路存在盲点。我们也在积极探索eBPF等新的可观测技术，从而实现真正的端到端全链路监控。

（此文刊发于《金融电子化》2024年9月上半月刊）