以Trace为核心的根因分析概述

上一篇文章《【论文调研】根因分析：Micro.X系列》主要是通过阅读以下两篇文章进行的实验流程梳理和相关方法的总结而得来。

• 《MicroRCA: Root Cause Localization of Performance Issues in Microservices》
• 《MicroDiag: Fine-grained Performance Diagnosis for Microservice Systems》

近期一直在学习和复现“根因分析”领域的相关文章，在这里跟大家一起分享下相关内容。这里不在赘述关于“可观测性”和“AIOps”的重要性和必要性，也不过多的陈述在“复杂系统”中进行快速根因诊断的必要性，直接进入到相关算法和系统设计部分。

在智能运维的体系中，用来分析和建模的数据可以笼统的分为：Log + Trace + Metric，这里面的数据量是巨大的，且数据形态是复杂多样，对于企业来说，不仅仅要考虑存储系统的吞吐、以及架构在存储系统之上计算引擎的灵活性，同时也会很关注成本。

基于Trace我们可以做些什么？

业务场景

• 拓扑生成
• 架构梳理
• 各服务的流量估算
• 系统的热点分析
• 链路的性能分析
• 错误的传播分析
• 发布过程中，流量的灰度分析，发布质量的评估

各家根因分析系统（系统+算法）

EMonitor -> 基于Tracing和Metrics的诊断系统

该系统是来自阿里本地生活的故障诊断的分享，在特定场景中可以较好的解决如下问题：

• 哪些入口受到了影响？
• 受影响的入口的本地操作和远程操作的影响如何？
• 受影响的入口都抛出了哪些异常？

在该系统中，无法准确（无法直接根据数据给出，需要推断）的解决如下问题：

• GC问题
• 容器问题
• 变更导致的问题

该诊断系统的上层出发点是源自于观测的核心SLO指标的抖动，去分析是哪些聚合维度的指标的异常导致了当前的扰动，从而定位到需要进一步诊断的下层入口，通过如此反复的确认，得到最终的定位信息。这里提供一张特定的图（来自知乎上的发表过的图）。

通过上述图中的描述，我们可以看到饿了么团队可以完成如下几个能力：

• 大量复杂的数据预处理，通过一定的手段将数据进行清洗后格式化（或者严格要求日志字段格式），较好的完成了Metrics、Logs、Trace的关联跳转；
• 开发了特定的计算策略（OLAP侧或者本地服务侧）支持扰动分析，提供出探寻的候选集；
• 在特定的业务场景中，支持多个服务模块之间的参数调用，得到较为完成的业务侧拓扑；

但是分析下来，里面必定特别多的定制化的操作和对于开发的严格日志结构的要求，且有较大的定制化开发需求，在云上快速拓展有一定的难度。

GMTA Explorer -> 基于Trace的监控和服务诊断

该系统是eBay建立并在企业中落地的诊断系统，这套系统可以解决eBay每天1500亿条Span数据，可以在一定程度上处理Trace数据中的断链和错链问题。这里最核心的概念在如下的图2中已经描述出来了，这里重新提取下：

• BusinessFlow（业务流）：最终是由业务方（使用方）来确定的；
• Path：同一个业务在一段时间内的请求所构成的一个链路，最终是有多条Trace的路径合并出来的（业务请求在微服务系统中流经的节点所构成的Path）

数据流图+算法设计

在上图中，我们可以看到最核心的是要通过Flink计算出单条Trace的Path，然后通过一定的手段（聚类等）实现业务流的生成（Business Flow）。在数据处理的环节有几个重要的手段进行数据的处理：

• 根据特定业务输入，完成一些无效操作名称的替换；
• 根据标准的Trace定义，丢弃一些错误的数据，比如：根节点缺失、多个根节点等；
• 同时要尽可能关联一些错误日志数据，叫做错误传播链（EP Chains, Error Propagation Trace）；

下图较为清晰的描述了几个核心概念之间的关系。

这里我们可以简单说下，产生最终业务流的依赖的数据。根据文中的数据来说，在图数据存储中，时刻更新着当前系统中操作粒度的调用关系图，在分析型存储中按照一定的需求，存储着Path信息和业务流信息。

通过文中这个图，我们可以基本知道分析型存储中的基本结构，其中对于后续分析问题较为重要的两个核心属性是：PathID和BusinessFlowName，其中重中之重的属性值是PathID。那么，我们查看下原文中对于PathID的生成部分的描述。这里我们就要查看下文中的一个SpanHash的策略了。

span
 + serviceName
 + operationName
 + level
 + durations
 + statusCode
 + labels
 + childSpans[]Algorithm 1 SpanHash(span)
+ hash = HashCode(span.serviceName) + HashCode(span.operationName) + span.level * PrimeNumber
+ for each child in span.childSpans do
+     hash += SpanHash(child)
+ end for
+ return hash

这里面一个比较核心的问题在于：如何在海量的Trace数据中，以较小的成本去解决单个span在Trace链路中的level和childSpans的问题？（这个问题本质上将是：底层的存储和计算引擎的选型和问题，文中提到，在eBay中使用的是Neo4j+Druid+Flink进行存储和计算）

还有一点值得称赞的是，该平台的完整度问题，在GMTA Explorer中，提供了很多基础能力，我们一起来看下。

基于上述能力，可以解决不同场景的业务问题

• 作为开发人员，可视化业务流程中服务的依赖关系和依赖项，以确定服务的更改影响。
• 作为架构师，学习与关键业务（例如支付）相关的路径和指标，以支持架构决策。
• 作为 SRE，确认服务行为的变化或模式，并评估业务变化或其他因素对流量、延迟和错误率等指标的影响。

这里就提供下文中的实验例子，由于接口变更导致的服务指标的变化。

可以较为清晰的看到，上部分表达的是某个业务流中有三个核心链路，下面部分表示的是链路归并后的效果，我们可以很清晰的看到，在userCheckout这个链路中calculateMoney的调用接口由"coupon" -> "couponV2"后，可以较清楚的看到，对于createOrder来说，调用量上升了20%，延迟降低了5%。

在工程实践上的一些取舍

• 在后端存储和计算的选型上，不额外的造轮子，选择现有的大数据组件，且经过一些中间层粘合起来使用
• 对于如此大的数据规模，在实际中，也会进行一定的采样（文中提到了1%的采样率写入到Kafka中）
• 对于trace中数据的迟到和完整度的问题，采用Flink去解决
• 对于Flink消费之后的结果，一部分写入到Druid中，一部分直接提取后写入到neo4j中
• 在通过一些UI可视化组件解决后续的交互式分析问题

几点思考

• 这偏文章读下来更多的是偏向介绍数据在系统中的流转，并非过多的在介绍算法本身（单纯的看算法部分缺失不复杂），落地起来较为可行；
• 在PathID生成中，过分依赖Flink的State能力，并没有设计或优化下高效的生成PathID的策略，这里还需要进一步的提升；
• 在文末提到，对数据进行Trace数据的1%的采样，并没有透露出具体的采样策略，因为采样策略对数据质量和数据覆盖度有较为严重的影响；
• 文中提出了Business Flow的概念，这个让我眼前一样，继续探索下，如何能进一步自动生成BusinessFlow的策略，可以通过一个UI让用户可以来管理自己的业务就是很大的进步了；

根因诊断的下一步思考

• 算法侧需求

• Trace场景的数据相对来说较为确定且具体，其中面临的问题也是确定的，这里更多的是是考虑如何在端上可以灵活的按需去采样，去解决后端的存储成本的问题，对于算法侧来说复杂度不是很高；
• 在解决Trace数据后，如何将Metric和Alarm整合在一起，去自动化的做因果分析，这个还是复杂一些的；
• 是否可以在以一步的让AI去学习我们的业务代码，能否将根因结果自动的和代码提交进行诊断，进一步定位到具体的更改（微软等已经在做了一些尝试）

• 下一步更多的需要去考虑多元数据的融合问题，能否在云上提供类似APM中的完整能力，做到简单、易用；
• 现阶段对于平台来说，要解决好信息抽取后的表达和管理工作，为后续的自动化分析和诊断扫清 障碍；

欢迎大家一起讨论

我是来自阿里云日志存储（SLS）团队的悟冥，我们已经提供了基于OpenTelemetry等其它标准协议的Trace数据的存储、计算、分析能力，也欢迎大家使用。

在参考资料中，放了一些阅读过和将要读的文章列表，欢迎大家可以私信我一起讨论，同时也欢迎各位前来实习或者工作，这里留个邮箱：

• 悟冥
• wuming.lgy@alibaba-inc.com

参考资料

• SLS Trace https://help.aliyun.com/document_detail/208889.html
• 【论文调研】根因分析：Micro.X系列 https://zhuanlan.zhihu.com/p/407298025
• EMonitor之根因分析 https://zhuanlan.zhihu.com/p/137555421
• AIOps项目开发实战https://www.shouxicto.com/article/115.html
• 《MicroRCA: Root Cause Localization of Performance Issues in Microservices》
• 《MicroDiag: Fine-grained Performance Diagnosis for Microservice Systems》
• 《MicroHECL: High-Efficient Root Cause Localization in Large-Scale Microservice Systems》
• 《Graph-Based Trace Analysis for Micro-service Architecture Understanding and Problem Diagnosis》
• 《CauseInfer: Automated End-to-End Performance Diagnosis with Hierarchical Causality Graph in Cloud Environment》
• 《CauseInfer: Automatic and Distributed Performance Diagnosis with Hierarchical Causality Graph in Large Distributed Systems》
• 《On Microservice Analysis and Architecture Evolution: A Systematic Mapping Study》
• 《AutoMAP: Diagnose Your Microservice-based Web Applications Automatically》
• 《Self-Adaptive Root Cause Diagnosis for Large-Scale Microservice Architecture》
• 《MS-Rank: Multi-Metric and Self-Adaptive Root Cause Diagnosis for Microservice Applications》
• 《FacGraph: Frequent Anomaly Correlation Graph Mining for Root Cause Diagnose in Micro-Service Architecture》