AIOps质量#Trace#定位：复旦CodeWisdom团队的微服务trace分析与故障诊断

内容简介

本文主要介绍论文《Graph-Based Trace Analysis for Micro-service Architecture Understanding and Problem Diagnosis》，由复旦大学CodeWisdom团队、eBay统一监控团队（UMP）、北京大学软件工程研究所共同发表。该篇论文采用图方法对微服务系统中的trace数据进行聚合和分析，并用于eBay监控场景的故障诊断。论文链接如下：

Graph-based trace analysis for microservice architecture understanding and problem diagnosis

基于图的微服务trace分析与故障诊断

1 统一监控平台与微服务调用链分析

云原生最近很热门，阿里在19年左右就实现了内部业务全面上云，腾讯也正逐步推广内部业务上腾讯云。谈云原生，离不开如下四点：

1）微服务：低耦合+高内聚，本质上是将应用/产品功能拆分成若干个低耦合的，可以被独立部署、更新和重启的微服务，微服务之间可以通过rpc远程调用实现通信。 2）DevOps：包含自动化发布管道、CI工具等，实现微服务的快速部署。 3）持续交付：不影响用户使用服务的情况下，频繁将新功能快速发布到生产环境。 4）容器化：无需用户关注每个微服务所使用的技术栈，所有服务都被封装到容器内，进行统一的管理和维护（k8s现在也很热门）。

微服务架构在独立部署、快速交付和灵活扩展上表现出极大的优势，但随时也会带来新的问题。服务间的调用关系变得异常复杂，原本集中的日志数据如今分散在不同（微服务部署的）宿主机上。当微服务架构出现系统性风险时，排查风险和故障诊断相比于传统的项目会更加困难。

微服务trace分析，可以用来排查风险和诊断故障。同一次业务请求下，所有微服务之间的远程调用所组成的有向图，可视作一条trace。基于微服务trace，可分析服务间的依赖关系，并用于定位故障根因。

微服务trace分析的挑战：

1）微服务规模大，难以实时分析海量的trace数据（eBay的微服务系统每天会产生1500亿条trace）； 2）trace获取难度大，容易出现断链和错链。

文章提出GMTA和GMTA Explorer来应对上述挑战，并用于解决eBay场景的微服务trace监控和故障诊断。GMTA基于图的思想对trace数据进行聚合、处理和存储，提供高效的查询接口。GMTA Explorer在GMTA的基础之上提供了（静态trace & 动态trace的）可视化、调用链对比视图以及错误链查询等功能，辅助用户定位异常根因。

2 方法详情

2.1 GMTA

GMTA的整体架构如下图所示，主要由处理模块（Processing）、存储模块（Storage）和访问模块组成（Access）。

处理模块：基于Flink的流式处理框架实现，从分布式系统中获取原始的微服务调用日志，并将其组装成trace流、path流和business流。 存储模块：结合图数据库和实时分析数据库，以支持灵活高效的trace数据访问。 访问模块：提供三个级别的trace数据访问接口：trace level、path level和business flow level。

trace、path和business flow的详细含义，可参考下图。

trace：业务请求日志中通常会打trace id（用来标记一次业务请求的id，一次业务请求所流经的所有微服务会打上同一个trace id），通过trace id来聚合一次业务请求所流经的微服务，会形成一条trace。 path：同一种业务请求在不同时间段执行，会形成多条trace。但是这些trace所流经的微服务是相同的，业务请求所流经的微服务有向图，就是path（path可以理解为类，trace是path的实例）。 business flow：如下图所示，我们想知道与“createOrder”相关的所有业务路径（包含红色和绿色两条路径），这些路径共同组成business flow。

识别与处理trace、path和business flow的手段如下：

trace：给定时间窗口，按trace id对分布式系统内的微服务调用日志进行聚合。在生成trace时，会对无效trace进行修复，trace修复主要针对两个场景：无效操作名称（如上图中的createOrder）和断链。无效节点修复主要通过正则表达式等手段来进行匹配和替换。断链修复则主要trace没有根节点或trace有多个根节点的场景。同时还会根据微服务调用的错误日志来识别EP链（Error Propagation Trace，错误链） path：每实时出现一条trace时，根据trace访问的微服务名称和操作名称进行哈希，生成路径ID。如果路径ID已经存在，那么更新路径的属性（如trace数、平均延迟等）。如果路径不存在，便为这条trace创建一个新路径。 business flow：由业务开发运维人员按需求制定。业务流可以是调用某个微服务与当前操作之前/之后会调用某个微服务 的任意组合。

trace、path和business的数据存储结构如下图所示：

trace数据存储在分析型数据库。 path数据存储在图数据库中，通过ServiceName， OperationName和Path ID等维度完成两个数据库的关联。 已生成的business flow也会存储到分析型数据库，当用户生成新的business flow时，会现在图数据库中完成匹配，然后把映射关系存储到分析型数据库中。

2.2 GMTA Explorer

如下图所示，GMTA Explorer提供4类主要功能。前面两个可视化相关功能主要用于系统架构理解、后面两个功能主要用于故障诊断。

trace、path和business flow的可视化样式，如下图所示（就是看图理解架构.....）。

错误链的对比 可参考下图，对比展示正常时期和异常时期的EP链，帮助SRE快速定位异常。

3 案例详情

3.1 性能对比

性能对比如下图所示，其中OTD-R是业内常用手段，ATD-R是eBay之前实现的方案。

3.2 GMTA帮助SRE诊断故障的案例

SRE在GMTA Explorer平台是看到如下样式，成功定位到故障源于服务c，最终排查发现是服务c最近一次发布引入了故障代码。