在线业务问题分析定位利器：小米分布式链路追踪平台（二）

Trace 功能

前一篇 Zander 平台的介绍文章已经介绍过 Trace 基本功能，包括 系统刻画、问题定位、性能分析、风险识别等功能。过去半年，在公司主流 Java 技术栈的 Trace 方面，我们重点推进了如下功能或 feature:

1 基于字节码 Agent 无侵入接入 Java 服务

原有基于 SDK 植入或中间件升级的接入方式存在诸多问题：

• 许多业务线都使用了非基础库版本的数据读写组件，比如各种 Redis Client，各种 Mysql ORM，这导致传统接入方式下 Trace 覆盖不够全面。

• 无论升级中间件还是直接基于 SDK 埋点，都需要修改业务代码（至少是修改 pom.xml 文件），导致接入成本较高。

在这样的背景下，我们研发了基于字节码 Agent 的接入中间件 Zander-APM-Agent，只需要在项目启动时通过 - javaagent 启动参数引入 zander 的 jar 包即可完成接入，实现对代码零侵入。

目前，已经有广告、小米移动服务、小米网交易系统等业务线的部分业务使用 Zander-APM-Agent 在线上接入了 Trace 及其他功能。

使用字节码技术做 Java 技术栈的服务端 APM 产品，已经成为行业通例，有关这方面的技术原理、业务团队关心的性能和稳定性等问题，我们将在后续单独的文章中分享。

2 功能开关远程动态配置

Agent 的接入方式帮助我们解决代码侵入性问题的同时，还针对大量机器上线进行了优化。以往想要修改 zander 中的配置需要重启服务才能生效，对于一个服务部署很多实例的场景操作十分困难。同时重启操作还会短暂影响线上使用。

对此我们研发了动态配置功能，通过 zk 可以远程动态更改特定机器上的配置。整个操作过程无需登录机器，也不会影响线上业务，方便用户对于大量机器的线上操作。

3 路径聚合

调用链分析展示单条调用链维度的信息，路径聚合可以将相同 url 的调用链进行进行聚合，从而对 url 维度数据进行统计。

平台效果如图 1-1 所示，路径分析会将相同 url 的调用链进行聚合，刻画该 url 的调用路径。对于路径中的每个服务会展示对应选择时间范围内的 QPM，调用次数，耗时分位值以及依赖度等情况。

图1-1

4 服务耗时分位值统计

对于业务线来说，服务响应时间平均值往往不能直观展现出问题所在，需要 90,95 等百分位的分位值统计。我们针对业务线这样的统计需求增加了服务分位值统计功能。

如图 1-2，通过 zander 平台路径聚合界面中，点击某个服务即可查询规定时间范围内服务响应时间各个百分位的分位值数据，通过报表的形式直观展示出来。

图1-2

业务日志定位

进入 2018 年，分布式链路追踪领域的趋势，除了服务的可观测性之外，还有什么可以挖掘的点？传统意义上与分布式链路追踪属于同义词的服务端 APM 领域，又有哪些趋势？这是我们团队本年度开始一直在思考的问题。

我们注意到几个趋势：

• APM 厂商产品方向逐步在往业务运营方向转变：从技术难度上讲，APM 厂商做业务运营和增长黑客类厂商的生意近乎没有技术门槛；同时，从开源节流的角度，增长黑客等业务运营手段直接与用户规模、利润规模相关，但是传统的 APM 产品对于企业来讲更多的是成本部门——在有限的资源下，面对依旧蓝海的互联网市场空间，创业公司更愿意将资源投入到能够带来用户增长的技术上。因此，对于 APM 领域的厂商来讲，通过在原有中间件植入和埋点技术上添加诸多与用户行为相关的业务属性，并依次杀入业务运营等领域，是其业务发展中所必然要走的路。

• 从大厂分享的链路追踪平台经验来看，无论淘宝的鹰眼、还是滴滴公司的链路追踪平台，都将基于日志的业务定位功能作为平台在链路分析之外的重点功能来推广宣传。某些文章分享中提到，淘宝的鹰眼平台在升级后可以直接对接给客服团队使用，让客服可以直接基于鹰眼查到用户反馈问题的原因，从而省略技术研发人员的介入，提升问题反馈效率。

• 从公司内对接客户的经历，几乎每个客户都会咨询如何基于 Trace 定位业务问题。更有甚者，部分同事反馈最严重的时候团队要有 20% 的时间用来定位问题。

基于这些趋势，我们反思，传统的 Trace 功能，只是解决了我们常见的故障和问题中技术导致的部分，这部分问题基于传统的日志和打点难以准确的分析定位，而链路追踪正好解决了这个技术难题。但是，在从客服团队反馈到技术团队的 100 次故障中，有多少次是单纯的 Trace 能够解决的呢？我们认为，20% 左右。剩余的 80% 故障则更多的利用关联了 TraceID、用户 ID 和事务 ID 的多项数据进行定位，这些问题可能是技术故障（如超时重试机制不合理）导致的业务问题，也可能是业务逻辑错误导致的技术问题。

基于这些考量，我们在有限的资源下，将有限的研发资源倾斜到业务定位方向，重点开发了结合业务属性、业务日志、Trace 数据的快速搜索功能。

1 字段关联

传统的日志定位通过对日志进行 grep 找到关键日志。对于多机器情况无法确认关键日志在哪台机器上，而且查询内容只能是日志中已有的字段。zander 可以为业务日志关联已有内容之外的信息。

使用 Agent 的接入方式可以方便的将用户业务属性、业务日志自动与调用链的 TraceID 关联起来。比如，如果用户想要关联业务对应的用户 ID 或者事务 ID，只需要在配置中指定，哪个类的哪个方法的第几个参数（图 2-1）作为 UserID 或业务 ID，即可完成字段关联。

图2-1

目前字段关联除了支持 TraceID、用户 ID、事务 ID 三个主要字段，还关联了机器 Ip、对应访问 url 等信息。字段关联支持自定义 Id 关联，可以通过用户需求来进行选择配置。

2 日志拦截

zander 通过 agent 来完成业务日志拦截。将分布在各个机器上的日志统一收集上来，进行综合管理与查询。该功能的技术实现是通过字节码技术对底层 log 组件的拦截，将日志内容、参数信息、方法栈等信息提取出来，结合关联的字段一并写入到对应的结构中上传。

拦截过程只会拦截用户指定的日志级别（比如只拦截 WARN 日志）、包路径下的日志。同时，对于业务中的敏感字段，例如用户 ID 等信息，我们在接入之前要求业务打印日志时进行脱敏，否则不开启日志拦截功能。

3 快速问题定位

通过上述方式开启业务日志拦截之后就可以通过 zander 平台进行使用。当某个用户反馈出现问题时，我们只需要根据该用户的 id 或者订单 ID 就可以搜索到与用户相关请求的所有日志。搜索效果如图 2-2 所示。

图2-2

日志详情中，除了业务日志中原有的 loggerName，日志等级，时间，日志内容，异常栈外（图 2-3），还记录了日志上报机器 ip，对应的 url，以及关联的用户 Id，订单 Id 等信息。并且可以根据用户需求建立自定义搜索字段。

在日志展示基础上，我们做了日志总结的功能。根据用户需求配置自定义的匹配规则和日志解释，通过对关键字段匹配，可以得出对该条日志的解释，然后在日志总结列中展示出来。日志总结是一个需要不断优化调整的功能，最终目的是让客服同学能够跟进用户属性直接获知问题原因，让业务定位不再需要技术人员的参与，解放工程师定位问题的生产力。如有该类需求，欢迎联系刘招帅（ liuzhaoshuai@xiaomi.com ）, 王福（ wangfu@xiaomi.com ）

图2-3

metrics 指标

Metircs 指标目前主要是获取服务 jvm 和应用环境维度的信息数据，通过观测范围时间服务 cpu 使用率 (图 3-1)，内存使用(图 3-2)，以及 gc 情况(图 3-3) 来定位底层问题。该功能需要使用 Agent 方式接入方式，同样支持用户选择开关。

图3-1

图3-2

图3-3

业务规划

针对用户反馈和提议，目前 zander 工作方向分为以下几个方面：

平台方面，我们将继续打磨业务定位功能，以求更好的帮助业务线提升问题定位的效率。

数据层面，我们正在针对每个业务线的每个服务，整合组内服务治理各个平台的数据，将服务相关的多维度数据自动生成报表，发送给业务线用户。

中间件层面，目前正在针对线程池以及定时任务场景的刻画进行适配与优化。由于 zander 中间件中记录调用信息的需要使用 threadLocal 进行透传，threadLocal 在线程池的场景下因为线程复用导致信息透传不准确的问题。我们正在针对并发场景下如何传递 Trace 数据进行相关开发，线程池 Trace 跟踪场景很快能够得到支持。

部分技术原理和业务团队关心的技术细节，我们将在后续文章中不断分享。同时也欢迎各位随时对我们的不足之处提出批评指正。