企业如何从 0 到 1 构建整套全链路追踪体系

Posted 2022-02-03 阿里云云栖号

简介：本文将分享 ARMS 在全链路追踪领域的最佳实践，分享主要分为四部分。首先，是对分布式链路追踪的整体简介。其次，是对 ARMS 在分布式链路追踪领域的核心能力进行介绍。然后，介绍如何从 0 到 1 构建整套全链路追踪体系。最后，介绍一些最佳实践案例。

作者 | 涯海&白玙

今天，我来跟大家分享 ARMS 在全链路追踪领域的最佳实践，分享主要分为四部分。首先，是对分布式链路追踪的整体简介。其次，是对 ARMS 在分布式链路追踪领域的核心能力进行介绍。然后，介绍如何从 0 到 1 构建整套全链路追踪体系。最后，介绍一些最佳实践案例。

什么是分布式链路追踪

首先，什么是分布式链路追踪。我对分布式链路追踪的理解就是跟踪请求在分布式系统中的流转路径与状态，从而协助开发人员能够进行故障诊断、容量评估、性能瓶颈分析等工作。 

我们可以看到典型的链路轨迹追踪例子：比如用户通过手机做了一个下单动作，这个请求会通过移动端来到网关，再到应用层，比如说有交易、下单、支付等等一系列的应用，然后中间也会穿插到去调用云基础设施，这样用户的行为轨迹是能够被清晰还原出来的。

为了更方便的理解这个概念，我们可以把链路追踪和物流追踪做对比。在发送快递物流时，每个快递包裹都会赋予一个唯一的快递单号，对于系统请求来说就是全局唯一的 TraceId。通过快递单号来查询快递途径哪些站点，是否有延迟或丢件情况。那么，也同样可以通过 TraceId 来查询请求在每个系统之间的流转路径和状态。除了快递订单查询之外，还可以把整个物流状态，按照站点去进行汇总统计，来看每个站点吞吐，从而进行物流提效的优化工作。

对于链路追踪来说也是一样的，我们可以把链路数据进行一个统计，然后去看每一个应用或接口的状态，或者去梳理它们之间的强弱依赖。那么，什么样的系统更加需要链路追踪呢？当微服务架构拆分的越精细，服务间依赖越复杂的系统，就更加的需要链路追踪技术，比较典型的就是电商这种。

接下来我们看一下链路追踪作为可观测的三元组之一，就是 Traces、Metrics 和 Logs。其最大价值就是实现了除机器和时间维度之外的用户行为的确定性关联。怎么理解这个事情呢？就是在没有 Tracing 之前，比如说通过指标或者日志，只能根据数据在同一台机器上，并且在同一个时间点，判断它们应该是在一起的。但这只是弱关联，并不是强关联。而调用链会很明确说明这个请求就是这个数据，就是来到了这个节点，这个信息是一定准确的。通过这种确定性的关联，除了可以将服务应用接口层面的数据关联起来之外，还可以通过打标上下文传递的方式，把一些业务的标签，比如说来自于什么渠道、订单金额等这种直接、间接的数据都关联起来，发挥 1+1>N 的价值。 

接下来再看一下链路追踪的应用场景，我对它做了一个初步分级。

从下往上看，最基础级就是通过调用链来还原单次请求的轨迹状态，这是最基本的应用。

再往上，可以对链路数据去做预聚合或后聚合统计的分析，去看整个链路在概率分布上的一些信息，比如说整个服务维度的监控数据，上下游整体的依赖，这是第二级——聚合分析。 

第三等级，就是除了调用链数据本身具备的这些链路数据之外，还可以更进一步发挥关联性作用，把一些间接的业务数据，包括容器或者 JVM 的一些指标信息或者是一些变更的日志事件，也能够通过调用链紧密的关联在一起，形成多维数据关联和分析，最终来实现我们根因定位的能力。

再往后有点像自动驾驶，有了这么多数据，能不能够自动发现其中一些问题？可以结合领域专家经验和恰当的算法，来实现整个诊断流程自动化或者半自动化。 

最后一步就是诊断问题的最终目标--保障系统稳定。能不能够把问题诊断和系统恢复两个事关联在一起？从而实现整个系统的故障自愈，进一步提升稳定性。这个就需要与管控系统去融合。目前开源 Tracing 系统大概是在 L1 到 L3 的等级。ARMS 我们那边沉淀了很多领域专家经验以及算法可以做到 L4 等级，ARMS 再加上一些应用托管服务进行自动流控降级、弹性扩缩容，把监控和管控系统结合在一起，从而实现故障自愈能力。

接下来我们再看看链路追踪的发展趋势。在 2010 年，随着谷歌论文发表，拉开了整个链路追踪的技术序幕，很多厂商都纷纷实现了自己的链路追踪技术。当然，在谷歌之前也有很多其他探索，但谷歌给了后续实现者比较完整的理论基础。同时，通过自身实践，证明了链路追踪的企业级价值，这是开山鼻祖式的奠基。

到了 2016 年，因为之前大家厂商纷纷实现自己的链路追踪，这个标准没有统一，就为迁云、上云带来很多问题。因此，开源社区发起了 OpenTracing 项目，定义了相对比较完善标准的链路的通用规范，也发展出了类似 Jaeger 这种符合 OpenTracing 规范的开源实现。到了2019年，大家考虑到可观测逐渐向一体化发展，光有 Tracing 也不够，需要把Tracing和指标和日志能够关联在一起，OpenTracing 定义就相对比较狭隘，不能满足可观测的需求。所以在 2019 年，就是 OpenTeleMetry，然后提出了这样的一个开源项目。将 OpenTracing 和 OpenCensus 进行了融合，能够致力于去解决 Logs 和 Traces、Metrics 三者有机统一。

ARMS 的链路追踪到底具备哪些能力

接下来，我们看一下 ARMS 的链路追踪到底具备哪些能力。首先，我把 ARMS 的能力抽象为四个点：

• 解决接入难的问题。比如说企业有很多不同类型应用，不同语言的应用。除了前端后关联，服务端也有很多如 Java 、Go 等应用。ARMS可以更有效地去完成这些应用的追踪接入。
• 解决诊断难的问题。ARMS 可以提供各种各样的，比如说日志和 Trace 的全息排查，或者是线程剖析这种深度的诊断的能力来帮助你去定位根因。
• 解决运维难的问题。在大规模场景下，链路的探针管理、升级都是比较困难的事情，包括服务端的稳定性托管， ARMS 可以提供稳定可靠的全托管、免运维能力。
• 解决成本高的问题。ARMS 作为云上产品可以按需按量地来使用。随着业务爆发式增长，只需要按量地去付费就可以，也不需要一开始就购买一大批机器或投入比较大人力。

接下来，我们逐一介绍下这四个方面：

首先就是接入难， ARMS 目前提供了 Java 无侵入的探针技术方式，如果你是 Java 应用就可以很快地接入 ARMS。比如说通过一个 -javaagent 的命令，或者是在 ACK 容器服务环境下，通过一个 Annotation 就可以很快地接入。如果是非Java语言，也可以利用开源 SDK 通过修改 Endpoint 快速地接入到 ARMS，从而实现全链路追踪，基本上相当于是开箱即用的。

我们对语言组件的覆盖也是相对比较齐全的，主流组件基本上都有支持。同时， ARMS 完全兼容开源的 OpenTracing、 OpenTelemetry 等各种开源格式。如已接入，迁移到  ARMS 也是非常的方便。

其次，诊断难。在生产环境去诊断问题时，有时不仅仅需要调用链，还需要很多其他的数据一起结合。比如说发现某个应用接口或者是业务出现问题，根据各种各样条件来去筛选出想要的调用链，通过调用链来去追溯上下游，看看问题大概瓶颈点在哪里。如果这个时候出现了比较慢的一些情况，就是接口粒度还不足以定位问题的时候，我们可以通过 ARMS 的线程剖析功能，自动地帮你把慢调用本地完整的方法栈能够获取下来，能够实现代码级定位。如果是业务上出错了，还可以跟业务日志进行关联绑定，能够看到每次调用，每笔请求关联背后业务的行为和日志是什么样的。如果前面这四步仍然不足以去定位根因，还可以结合内存快照或是线程池分析，常见的就是数据库连接打满，或者是线程池打满等。 

除了上面这一整套诊断能力帮助团队完成定位之外，ARMS 也能够通过自动诊断能力解决常见问题。比如说我们经常会遇到一些数据库 mysql 问题，数据库 MySQL 有很多原因比方说服务端原因，服务端的连接池打满，或者是客户端的连接池打满，或者是客户端一次查了特别多数据需要分批等等。面对这些常见的原因，ARMS 都可以自动诊断出来。

解决完诊断难，接下来就是运维难的问题。越是体量越大的公司，这个问题会越严重。ARMS 作为阿里鹰眼的升级，在双十一场景下结合多年验证与优化，沉淀了大量经验，比如说我们的 Agent 是会经过多轮、各种级别的灰度验证，保证我们客户端侧稳定。服务端也会支持比如说多可用区容灾或者是全链路端的 SLO 体系建设，还有包括我们多级的客户支持和 Oncall 应急值班，这些都是可以直接享受到这样的服务，而不需要重新的去建设这样的体系。

在大部分场景下，除了稳定性之外，还经常会遇到海量数据场景下查询性能问题，当数据达到每天几百 TB，数据存储和数据查询的索引可能已失效，无法满足业务要求。ARMS 沉淀了多种性能加速方案，比如说可以实现最基础的就是租户地域隔离，其次数据可以通过应用去做路由存储，如果应用级还不够，还可以再继续根据数据的一些特定的特征，如 TraceId 或者其他特征进一步打散，从而提高并发查询的效率。

第四点就是大家比较关心的成本问题，ARMS 除了自身按需存储之外，还通过冷热数据分离和精准采样方案，进一步降低用户成本。

比如说我们可以把热数据，比如说 30 分钟内数据我们会经常查询，我们可以把它存在热存储里面，满足全量的分析的需求。30 分钟之后的数据进行持久化，比方说 15 天、30 天。这个时候可以仅把其中错、慢或者满足一定业务特征（比如说 VIP 用户的一些链路）存储下来，这样整个存储成本就会比较低，并保持查询体验。

当然，在做链路采样时就无可避免的会遇到指标数据不准的情况。ARMS 通过在客户端完成预聚合，来保证链路数据无论怎么去采样，即使千分之一，但依旧保证指标数据精准性。

这里做个简单对比，如果采用开源方案，最起码需要存储以及流计算处理服务器建设，这种 ES 和 ECS 的成本大概 200 元/天。但如果直接使用 ARMS 的按量付费，每天大概只需要十几块钱。每 GB 成本可能只要 1 毛 9 不到 2 毛钱，远远低于开源自建成本。

值得一提的就是，ARMS 进入 Gartner APM 象限，也是国内唯一的云厂商，Gartner 对 ARMS 的 APM 评价是中国影响力最强，对开源集成性也非常好，成本也是非常大优势。

如何从 0 到 1 建设追踪体系

介绍完产品核心能力之后，来讲讲如何从 0 到 1 建设追踪体系。

我们大概可能需要完成这样 4 步：

第一步，完成整个应用的全链条全链路的上下文透传，从端侧设备开始到后端，然后网关或者是应用等等。这里面的话其实就涉及到异构语言的数据打通和前后端的透传，这一套方案 ARMS 是都已实现了。

第二步，完成了客户端的这种全链路埋点之后，我们数据要上报上来，就会面临存储和计算的成本，最好的方式就是说能够按需去存储数据，只存有价值的数据来降低成本。

第三步就是数据存储下来之后，肯定还要通过查询再发挥它的价值。这时候遇到的问题就是数据之间的格式不统一，能不能把所有的指标数据转化成一个比方说 Prometheus的这种格式，这样指标数据格式相对统一了，Traces 能不能支持这种 OpenTelemetry 的格式，然后是日志支持 Loki 这种方案。

如果数据格式跟开源保持统一再去做第 4 步，释放价值就会比较容易。除了产品提供的预置大盘之外，还可以灵活自定义用户档案。当然还可以按照用户的使用习惯，也可以做一些自定义的控制台。同样道理，告警也是一样的，我们可以去用 PromQL 做一个灵活的自定义的告警，同时我们也支持把数据路由到用户名下的一些存储，比如说 SLS 下面，这样你想去做一些二次的批量的分析，这些都可以支持。这就是我们从 0 到 1 去建设链路追踪体系的大概步骤。

接下来，每个步骤都单独来看。第一步，就是要完成异构应用的全链路的追踪，比如说前端或者说整个透传的格式，或需要采用统一格式，比如说我们可以选择统一的 Jaeger 格式来透传来我们的协议头，我们前端接入比如说我们可以采用 CDN 或者 NPM 两种的这种低代码的接入方式，可以支持外部小程序等各种各样的场景，我们后端如果是 JAVA 的话，就会优先推进使用 ARMS Agent 来完成无侵入的这样的一个代码的接入。并且在 JAVA 的应用上面，我们会提供很多比如说边缘诊断、无损统计的这样一些高阶的能力，非 JAVA 的话就可以比方说我们可以通过开源的 Agent 和 SDK 来接入，然后并且上报到我们的 Endpoint 上面，当然 ARMS 也在去兼容 SkyWalking 的协议格式。

第二步，正如刚才所讲，数据打通之后，需要去进行精准采样和冷热存储分离。但是对于使用者来说，需要去定义我们尾部采样策略，比如说默认的除了错慢全采之外，有没有需要根据业务特征进行采样，或者是按需的去调整数据存储周期。

第三步，就是需要去自定义监控大盘，就除了 ARMS 提供的默认大盘之外，你还可以基于 Grafana，把业务数据、应用数据，甚至容器数据放在一起，来去定制统一监控大盘。比如说双 11 大促，或日常线上应急场景，都可以去快速地浏览整个业务线的表现，能够快速地定位到问题的大致范围。

第四步，当建立监控之外，还需要有一个比较有效的告警机制，因为大家平时也不太会去一直盯着监控或者是 Trace 控制台，肯定需要有应急入口，告警其实就是我们运维的第一入口。在这里介绍三个比较典型的告警实践。

比如说公司或者是团队在刚起步或新产品刚上线的时候，很多东西都是比较缺失的。这个时候，我们可以通过 ARMS 的告警模板能力，把比较通用的应用、容器、中间件的告警能力能够快速地构建出来，解决从 0 到 1 的问题。

当团队或者是公司一步步成长起来，数据会越来越多，系统会越来越多。等到膨胀到一定程度时，告警可能分散在多个系统之中。这个时候又会带来效率问题，就可以使用 ARMS 的告警能力，把多个告警源的数据放在一起去分析，甚至可以去做组合过滤规则。比如，当流量突然激增，性能后端的耗时变高，CPU 打满的时候，发出建议扩容或是建议降级的告警通知。

当企业进一步地发展，发展得很好，团队越来越多，人员越来越多。这个时候，可能一个系统会有很多个团队来共同的去协作运维，我们不仅仅需要解决数据爆炸问题，还需要解决人员协同的问题。这个时候就可以基于 ARMS 的 ChatOps 能力来解决应急协同问题。

第五步，即使前面都做了之后，还有很多公司有建设自己专属平台的意愿，因为可能大家已经有了比较好的可观测或监控报警方面的经验以及场景沉淀，只需扩充部分这样的能力，是完全可以基于 ARMS 这种开放数据的能力。无论是通过外部页面的嵌入，还是 Open API 建设，或是直接把存储开放出来，进行批量数据分析，都可以更好地完成二次开发。

最佳实践

最后，我们来介绍常见实践案例。比如，调用链通常聚合成一个应用维度的拓扑，或者是服务维度的拓扑，但这个时候往往还不够，还可能会更关注某特定场景。

同样是下单场景，有时候关注整体的下单还不够，可能还需要关注某个新渠道或新上线品类。我们可能需要看某个线下零售的渠道，它的下单链路情况是怎么样的。或者是某个新品类，需要把这一部分业务场景单独剥离出来，去做链路染色，从而能够实现这一部分特定业务场景的应用和依赖的梳理。这个就是通过无侵入的业务染色实现的。

第二部分，ARMS Agent 除了做可观测数据之外，同时也具备安全数据、安全行为检测与保护的能力，面对最近比较火的 Log4j2 高危核弹级漏洞，基于 RASP 技术就可以有很好的自我防护能力。即使不改代码，也可以通过动态配置的方式，完成安全防护。除了安全防护之外，RASP 也可以提供攻击溯源或者漏洞定位分析等等能力，相比于传统的防火墙式保护会更有效一些。因为它跟 IDC 防火墙的区别，有点像我们戴口罩和打疫苗这样的一个区别。

第三个场景，在容器场景下实现全景监控，可以把来自于 Prometheus 或者 Loki 或者 eBPF、APM 等端到端数据放在一起，通过 2D、3D 拓扑，进行全程展示和端到端链路的下端分析。同时，我们还提供定期巡检，或是基于专家经验和算法的问题自动诊断和上报，这个就是我们在容器场景下的一个全景监控的最佳实践。

第四个场景，一些架构比较复杂的用户，具备多云以及跨云部署；出于数据安全考虑，也可能会去自建机房进行混合云部署。为了解决前后端、多语言、跨云部署的问题，ARMS 的全链路追踪帮助用户完成复杂场景的全链路追踪挑战，把各种场景的链路串联在一起，最大化去释放链路跟踪价值。

第五部分，就是说 ARMS 最近新上线了 Trace Explore 功能，相对于传统调用链查询和应用服务统计、监控之外，还提供实时获取和分析能力。举个简单例子，我们经常要看耗时大于三秒的请求分布在哪些接口或者是哪些 IP 上面，从而进行慢接口的处理，或单机故障排查诊断。这个时候我们在预聚合的时候，肯定没办法把耗时大于三秒或者是某一个特定的过滤条件等于什么的场景之下，去做一个预先统计。这个时候我们就需要一个灵活的后聚合分析的能力。这个就是 Trace Explorer 能够提供这样的一个价值。除了我们刚刚说的这种单机慢接口之外，如果我们再结合我们的业务指标，比如说我们把我们的一些用户的等级也打到我们的 Attributes 里面对吧？我们就可以去按不同的用户等级来去分析它的一些流量的情况，它响应的一些时延，就能够更方便的低代码的去完成这样的一个自定义的分析。当然，这里还举了一个灰度监控，如果我们在重启之前，比方说我们在环境变量里面注入我们当前的版本，我们就可以看到不同版本之间一个流量和性能的变化。

最后，给出了一些 ARMS 相对于开源做的更好的最佳实践。比如说接口偶发性超时的时候，接口级的调用链，还不足以诊断更新，我们需要完整的方法栈，但是那个问题现场已经过去了，怎么能够自动帮你保存下来呢？那就是可以通过 ARMS 线程剖析自动诊断的这样的一个能力。

当我们微服务或者是数据库的性能值打满时，这个时候可能所有的请求都会变慢，但是你在调用链上也很难直观的去反映出来，因为这种资源类的问题是很难通过链路去记录下来的。这个时候 ARMS 提供的这种池化监控，能够直接分析每一类线程当前情况，并配置告警。除此之外比如说你想分析一些内存泄漏的问题，或者是一些线上运行代码和本地行为不一致的问题，都可以通过白屏化的内存诊断，或者是 Arthas 这种在线调试的这样的一个能力，帮你快速的去定位你的根因。

以上就是今天我们对链路追踪整体的介绍，也涉及到我们对整个全链路追踪的一些最佳的实践，感谢大家！

原文链接

本文为阿里云原创内容，未经允许不得转载。