今天，我来跟大家分享ARMS在全链路追踪领域的最佳实践，分享主要分为四部分。首先，是对分布式链路追踪的整体简介。其次，是对ARMS在分布式链路追踪领域的核心能力进行介绍。然后，介绍如何从0到1构建整套全链路追踪体系。最后，介绍一些最佳实践案例。
什么是分布式链路追踪
首先，什么是分布式链路追踪。我对分布式链路追踪的理解就是跟踪请求在分布式系统中的流转路径与状态，从而协助开发人员能够进行故障诊断、容量评估、性能瓶颈分析等工作。
我们可以看到典型的链路轨迹追踪例子：比如用户通过手机做了一个下单动作，这个请求会通过移动端来到网关，再到应用层，比如说有交易、下单、支付等等一系列的应用，然后中间也会穿插到去调用云基础设施，这样用户的行为轨迹是能够被清晰还原出来的。
为了更方便的理解这个概念，我们可以把链路追踪和物流追踪做对比。在发送快递物流时，每个快递包裹都会赋予一个唯一的快递单号，对于系统请求来说就是全局唯一的TraceId。通过快递单号来查询快递途径哪些站点，是否有延迟或丢件情况。那么，也同样可以通过TraceId来查询请求在每个系统之间的流转路径和状态。除了快递订单查询之外，还可以把整个物流状态，按照站点去进行汇总统计，来看每个站点吞吐，从而进行物流提效的优化工作。
对于链路追踪来说也是一样的，我们可以把链路数据进行一个统计，然后去看每一个应用或接口的状态，或者去梳理它们之间的强弱依赖。那么，什么样的系统更加需要链路追踪呢？当微服务架构拆分的越精细，服务间依赖越复杂的系统，就更加的需要链路追踪技术，比较典型的就是电商这种。
接下来我们看一下链路追踪作为可观测的三元组之一，就是Traces、Metrics和Logs。其最大价值就是实现了除机器和时间维度之外的用户行为的确定性关联。怎么理解这个事情呢？就是在没有Tracing之前，比如说通过指标或者日志，只能根据数据在同一台机器上，并且在同一个时间点，判断它们应该是在一起的。但这只是弱关联，并不是强关联。而调用链会很明确说明这个请求就是这个数据，就是来到了这个节点，这个信息是一定准确的。通过这种确定性的关联，除了可以将服务应用接口层面的数据关联起来之外，还可以通过打标上下文传递的方式，把一些业务的标签，比如说来自于什么渠道、订单金额等这种直接、间接的数据都关联起来，发挥1+1N的价值。
接下来再看一下链路追踪的应用场景，我对它做了一个初步分级。
从下往上看，最基础级就是通过调用链来还原单次请求的轨迹状态，这是最基本的应用。
再往上，可以对链路数据去做预聚合或后聚合统计的分析，去看整个链路在概率分布上的一些信息，比如说整个服务维度的监控数据，上下游整体的依赖，这是第二级——聚合分析。
第三等级，就是除了调用链数据本身具备的这些链路数据之外，还可以更进一步发挥关联性作用，把一些间接的业务数据，包括容器或者JVM的一些指标信息或者是一些变更的日志事件，也能够通过调用链紧密的关联在一起，形成多维数据关联和分析，最终来实现我们根因定位的能力。
再往后有点像自动驾驶，有了这么多数据，能不能够自动发现其中一些问题？可以结合领域专家经验和恰当的算法，来实现整个诊断流程自动化或者半自动化。
最后一步就是诊断问题的最终目标--保障系统稳定。能不能够把问题诊断和系统恢复两个事关联在一起？从而实现整个系统的故障自愈，进一步提升稳定性。这个就需要与管控系统去融合。目前开源Tracing系统大概是在L1到L3的等级。ARMS我们那边沉淀了很多领域专家经验以及算法可以做到L4等级，ARMS再加上一些应用托管服务进行自动流控降级、弹性扩缩容，把监控和管控系统结合在一起，从而实现故障自愈能力。
接下来我们再看看链路追踪的发展趋势。在年，随着谷歌论文发表，拉开了整个链路追踪的技术序幕，很多厂商都纷纷实现了自己的链路追踪技术。当然，在谷歌之前也有很多其他探索，但谷歌给了后续实现者比较完整的理论基础。同时，通过自身实践，证明了链路追踪的企业级价值，这是开山鼻祖式的奠基。
到了年，因为之前大家厂商纷纷实现自己的链路追踪，这个标准没有统一，就为迁云、上云带来很多问题。因此，开源社区发起了OpenTracing项目，定义了相对比较完善标准的链路的通用规范，也发展出了类似Jaeger这种符合OpenTracing规范的开源实现。到了年，大家考虑到可观测逐渐向一体化发展，光有Tracing也不够，需要把Tracing和指标和日志能够关联在一起，OpenTracing定义就相对比较狭隘，不能满足可观测的需求。所以在年，就是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的成本大概元/天。但如果直接使用ARMS的按量付费，每天大概只需要十几块钱。每GB成本可能只要1毛9不到2毛钱，远远低于开源自建成本。
值得一提的就是，ARMS进入GartnerAPM象限，也是国内唯一的云厂商，Gartner对ARMS的APM评价是中国影响力最强，对开源集成性也非常好，成本也是非常大优势。
如何从0到1建设追踪体系
介绍完产品核心能力之后，来讲讲如何从0到1建设追踪体系。
我们大概可能需要完成这样4步：
第一步，完成整个应用的全链条全链路的上下文透传，从端侧设备开始到后端，然后网关或者是应用等等。这里面的话其实就涉及到异构语言的数据打通和前后端的透传，这一套方案ARMS是都已实现了。
第二步，完成了客户端的这种全链路埋点之后，我们数据要上报上来，就会面临存储和计算的成本，最好的方式就是说能够按需去存储数据，只存有价值的数据来降低成本。
第三步就是数据存储下来之后，肯定还要通过查询再发挥它的价值。这时候遇到的问题就是数据之间的格式不统一，能不能把所有的指标数据转化成一个比方说Prometheus的这种格式，这样指标数据格式相对统一了，Traces能不能支持这种OpenTelemetry的格式，然后是日志支持Loki这种方案。
如果数据格式跟开源保持统一再去做第4步，释放价值就会比较容易。除了产品提供的预置大盘之外，还可以灵活自定义用户档案。当然还可以按照用户的使用习惯，也可以做一些自定义的控制台。同样道理，告警也是一样的，我们可以去用PromQL做一个灵活的自定义的告警，同时我们也支持把数据路由到用户名下的一些存储，比如说SLS下面，这样你想去做一些二次的批量的分析，这些都可以支持。这就是我们从0到1去建设链路追踪体系的大概步骤。
接下来，每个步骤都单独来看。第一步，就是要完成异构应用的全链路的追踪，比如说前端或者说整个透传的格式，或需要采用统一格式，比如说我们可以选择统一的Jaeger格式来透传来我们的协议头，我们前端接入比如说我们可以采用CDN或者NPM两种的这种低代码的接入方式，可以支持外部小程序等各种各样的场景，我们后端如果是JAVA的话，就会优先推进使用ARMSAgent来完成无侵入的这样的一个代码的接入。并且在JAVA的应用上面，我们会提供很多比如说边缘诊断、无损统计的这样一些高阶的能力，非JAVA的话就可以比方说我们可以通过开源的Agent和SDK来接入，然后并且上报到我们的Endpoint上面，当然ARMS也在去兼容SkyWalking的协议格式。
第二步，正如刚才所讲，数据打通之后，需要去进行精准采样和冷热存储分离。但是对于使用者来说，需要去定义我们尾部采样策略，比如说默认的除了错慢全采之外，有没有需要根据业务特征进行采样，或者是按需的去调整数据存储周期。
第三步，就是需要去自定义监控大盘，就除了ARMS提供的默认大盘之外，你还可以基于Grafana，把业务数据、应用数据，甚至容器数据放在一起，来去定制统一监控大盘。比如说双11大促，或日常线上应急场景，都可以去快速地浏览整个业务线的表现，能够快速地定位到问题的大致范围。
第四步，当建立监控之外，还需要有一个比较有效的告警机制，因为大家平时也不太会去一直盯着监控或者是Trace控制台，肯定需要有应急入口，告警其实就是我们运维的第一入口。在这里介绍三个比较典型的告警实践。
比如说公司或者是团队在刚起步或新产品刚上线的时候，很多东西都是比较缺失的。这个时候，我们可以通过ARMS的告警模板能力，把比较通用的应用、容器、中间件的告警能力能够快速地构建出来，解决从0到1的问题。
当团队或者是公司一步步成长起来，数据会越来越多，系统会越来越多。等到膨胀到一定程度时，告警可能分散在多个系统之中。这个时候又会带来效率问题，就可以使用ARMS的告警能力，把多个告警源的数据放在一起去分析，甚至可以去做组合过滤规则。比如，当流量突然激增，性能后端的耗时变高，CPU打满的时候，发出建议扩容或是建议降级的告警通知。
当企业进一步地发展，发展得很好，团队越来越多，人员越来越多。这个时候，可能一个系统会有很多个团队来共同的去协作运维，我们不仅仅需要解决数据爆炸问题，还需要解决人员协同的问题。这个时候就可以基于ARMS的ChatOps能力来解决应急协同问题。
第五步，即使前面都做了之后，还有很多公司有建设自己专属平台的意愿，因为可能大家已经有了比较好的可观测或监控报警方面的经验以及场景沉淀，只需扩充部分这样的能力，是完全可以基于ARMS这种开放数据的能力。无论是通过外部页面的嵌入，还是OpenAPI建设，或是直接把存储开放出来，进行批量数据分析，都可以更好地完成二次开发。
最佳实践
最后，我们来介绍常见实践案例。比如，调用链通常聚合成一个应用维度的拓扑，或者是服务维度的拓扑，但这个时候往往还不够，还可能会更