分布式链路追踪在字节跳动的实践

综述

字节跳动在发展过程中，逐渐形成了十分复杂的超大规模微服务体系，对后端整体的可观测性解决方案提出了极高的要求。为了解决这个问题，基础架构智能运维团队自研链路追踪系统，将海量 Metrics/Trace/Log 数据进行整合与统一，并在此基础上实现了新一代的一站式全链路观测诊断平台，帮助业务解决监控排障、链路梳理、性能分析等问题。本文将会介绍字节跳动链路追踪系统的整体功能和技术架构，以及实践过程中我们的思考与总结。

什么是分布式链路追踪(Trace) ？

M T L 的关系

可观测性的三大基础数据是 Metrics / Log / Trace。说到这三大件，可能大家会想到当需要监控变化趋势和配置告警时就去用 Metrics；当需要细查问题时去查 log；对于微服务数量较多的系统，还得有 Trace，Trace 也可以看做一种标准结构化的 log，记录了很多固定字段，例如上下游调用关系和耗时，查看上下游调用关系或者请求耗时在链路各节点上的分布可以查看 Trace。

但是如果带着孤立的观点去用这些数据的话，数据的价值会大大降低。举例一个常见的场景，通过 Metrics 得知某服务 SLA 降低，错误率上升，怎么去排查根因呢？先去找错误日志吧，可是我看到的错误日志是不是真的和这个错误率上升有关系呢？得翻翻代码看看这些错误日志都是哪里打出来的，代表什么意思。再去找找有没有错误 Trace？找出来的 Trace 也不太确定是不是和这个错误率上升有关系，还是得看代码确认下。终于通过一行行的代码和数据比对，确认到这个错误是下一层服务返回给我的，把那个服务的负责人拉进来一起排查吧，然后这个群越拉越大，更多的人被拖进来一层一层地查下去，最终定位到是某个底层服务上线了一个变更导致 Panic，错误层层向上传播导致服务 SLA 降低。

这个过程很不美好，需要工程师理解每一项数据的底层逻辑，才能充分利用它们去解决具体问题。而在复杂的大规模微服务系统中，没有单个工程师能够做到熟悉每一个微服务的底层逻辑，因此复杂微服务系统的排障和观测往往是一项有挑战的困难工作。

Trace 是数据的链接纽带

如果所有微服务的监控数据都是遵循统一模型和语义规范并且天生高度关联的呢？

在软件系统中，每秒钟有无数的 Context 在流动。这些 Context 可能是一个实时在线请求，也可能是一个异步处理任务。每个 Context 都会在多个微服务节点中持续传播才能最终完成。所有的监控数据（包括 Metric, Log 等）都源自于某一个 Context。Trace 就是这个 Context 的数据载体，通过标准化的数据模型，记录 Context 在多个微服务中的全部执行过程，并沿途关联上此 Context 上发生的所有事件（包括 Metric, Log 等）。

再回到刚才那个 Case，当我们对某个 Metric 波动发生兴趣时，可以直接将造成此波动的 Trace 关联检索出来，然后查看这些 Trace 在各个微服务中的所有执行细节，发现是底层某个微服务在执行请求过程中发生了 Panic，这个错误不断向上传播导致了服务对外 SLA 下降。如果可观测平台做得更完善一些，将微服务的变更事件数据也呈现出来，那么一个工程师就可以快速完成整个排障和根因定位的过程，甚至不需要人，通过机器就可以自动完成整个排障和根因定位过程。

Trace 不仅仅是用来查看耗时分布甘特图的工具，也是海量监控数据的 Context 链接纽带。基于可靠关联的 Metric / Trace / Log 数据，也构建出强大的可观测性能力，回答监控排障、SLO 调优、架构梳理、流量估算、智能化故障归因等众多复杂问题。

Trace 的采集以及跨服务进程的 Context 传递一般是由微服务框架等基础设施自动完成的，但是要实现最佳效果也需要所有研发工程师的理解和配合。研发工程师在编码的过程中应当有意识地在所有代码执行过程中持续传递 Context。比如在 Golang 中，context.Context 需要在所有函数调用中作为参数持续传递；在 Java 中，一般默认用 Threadlocal 作为 Context 的存储载体，但是如果有多线程或者异步的场景，则需要开发者自行对 Context 进行显式的传递，否则上下文就断了，难以实现有效的追踪和监控。

字节链路追踪系统的挑战与机遇

字节跳动在发展过程中，逐渐形成了十分复杂的超大规模微服务体系，对后端整体的可观测性解决方案提出了极高的要求。

我们面临的挑战包括：

• 线上流量巨大

• 微服务数量巨大，调用关系复杂，迭代变化快

• 研发团队庞大，分工复杂

目前字节跳动有巨大的流量，众多的活跃微服务、容器实例数，以及庞大的研发团队。一个复杂业务链路动辄涉及数百个微服务，有一线业务，有中台，也有基础设施，不同微服务由不同的研发团队开发，同时还有各类横向团队负责整体架构的质量、稳定性、安全和效率等相关工作。不同团队对链路追踪系统都会有不一样的诉求。

同时我们也有着难得的机遇：

• 微服务框架高度统一

  <