开发者学堂课程【业务全链路追踪最佳实践：快速学习如何一键部署 polardb-x】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/945/detail/14749
业务全链路追踪最佳实践
内容介绍
一、课程简介
二、什么是链路追踪
三、ARMS Trace 核心能力介绍
四、如何从 0 到 1 构建链路追踪体系
五、最佳实践案例
一、课程简介
今天分享一下 ARMS 产品在全链路追踪领域的最佳实践。
今天的分享分为四个部分：首先是对分布式追踪的概念简介，其次是对 ARMS 领域一些核心能力的介绍，第三部分介绍一下如何从零到一构建一整套的全链路追踪体系。最后介绍一下最佳的实践案例。
二、什么是链路追踪
首先来看一下第一部分，什么是链路追踪？我对分布式追踪的理解就是跟踪请求在分布式系统中的浏览路径与状态，从而协助开发人员能进行故障诊断，故障分析等等的一些工作。我们可以看到一个典型的链路轨迹追踪的实例：
用户通过他的手机在下端做了一个动作，这个请求会从移动端到网关，再到应用层，比如说交易下单支付等等一些应用。然后也会穿插的调用云的基础设施，这样一个用户的行为轨迹能够被清晰的还原出来。为了更方便理解这个概念，我们可以把链路追踪和物流追踪做一个对比，我们再发送一个快递物流的时候，我们给每一个快递包裹附唯一的一个快递单号，对于请求来说就是全球唯一的 trace id，那么我们会经常通过快递单号来查询快递经过了哪些站点，是否有延迟，同样地我们可以通过 trace id 来查询请求在每个系统的浏览路径和状态，那么除了订单产品之外，我们还可以将整个物流的状态按照站点去做整体的一些汇总统计，去做一些物流提效等等一些优化的工作。对电子追踪也是一样的，我们可以把调用链进行一个统计，去看一些应用的切口的状态，去看它强弱。
微服务架构拆分的越精细，越复杂的系统就越需要电子追踪，类似于电商这种。
接下来看一下，链路追踪作为可观测三人组之一，我理解的它的最大价值是除机器和时间维度之外的用户性关联。
在没有 Tracing 之前，我们比如说通过指标或者日志，我们只能通过两个数在同一台机器上，并且在同一个时间点，应该是在一起的。这个只是一个弱关联，并不是一个强关联，调用链是很明确的告诉你，你是这个请求就是来到了这个节点这个信息，它一定是准确的，那么通过这样一种确定性的关联将服务应用接口的数据关联起来，其实我们还可以通过达标，上下文传递的方式对业务的标签。比如说来自什么渠道，你的定金金额等等，这种直接间接的数据都能关联起来，发挥 1>1>n 的价值。
接下来我们再看一下链路追踪的应用场景，我个人对它做了一个分级，首先我们看最基础的就是第一级能够调用链来还原单侧请求的状态。往上一级就是对链路数据进行后聚合分析，来看整个概率分布上的信息，比如说整个服务的监控数据，上下有一些依赖，这是第二级聚合分析。第三级是除了调用链数据本身，就具备了这些数据之外，我们可以进一步发挥它关联性的作用，把一些进阶的业务，容器或者是变更的日志，事件能够通过调用链紧密的关联在一起，实现多维数据的关联和分析，最终分析定位的能力。
再往后就是像通过增加值，有了这么多的数据，我们能否自动地去发现一些问题。然后结合一些专家经验和一些适合的算法俩实现诊断流程的自动化或者半自动化。最后一个诊断问题的最终目标是保持系统的稳定性，但我们能把问题诊断和关联修复关联在一起，从而实现故障自愈，从而更好地提升我们的稳定性。目前的开源的追踪系统大概是在 L1 到 L3 等级，ARMS 那边我们沉淀了很多领域的专家经验，还有算法，可以做到 L4 这个等级。
ARMS 再加上应用托管服务，比如说阿里云上的，我们可以自动地做一些实例删除，这样把监控和管控系统结合在一起，从而实现故障自愈的能力。
接下来再简单看一下链路追踪的发展趋势，10 年时随着谷歌的论文发表，拉开了链路追踪的序幕，然后很多厂商纷纷实现了自己的链路技术，当然在谷歌之前也有很多的探索，但是谷歌给了后续实践者一个完整的理论基础。Dapper 在谷歌两年的链路追踪的实践证明链路追踪对企业的价值，这是一个奠基。到了 16 年的时候，没有一个统一的标准，整个迁运上有很多的问题。
在 16 年时候，发起了一个 Open Tracing 的项目，定义了一个完整的链路规范，也出现了很多开源的实践，到了 19 年的时候，可观测变成了一体化的方式去发展，光有 Tracing 也不够，Open Tracing 的定义就比较狭隘，与不能满足可观测的需求。所以 19 年的时候，Open Telemetry 提出了这样一个可观测项目，Open Tracing 和 Tracers 进行了融合，能够实现三者的有机统一，目前也是一个比较火的 Tracer 项目。
三、ARMS Trace 核心能力介绍
接下来看一下 ARMS 的内容追踪具备哪些能力，首先我把 ARMS 的能力抽象为四个点，第一个是帮用户解决接入难的问题，有很多不同应用的运用，不同语言的运用，服务端也有很多 Java 或者是 Nods js 等等，ARMS 能够更有效的帮助你完成链路的接入。第二点就是帮你解决诊断难的问题，就是 ARMS 可以提供各种有效的日志，全息的排查，深度的诊断的能力来帮助你定位。第三个就是可以帮助你解决运维难的问题，在大规模的场景下，亮度的探针的管理，升级都是比较难的事情，包括服务信息的托管，ARMS 可以提供一个稳定可靠，全托管免运维的能力。
第四个就是成本高的问题，由于以上产品可以按需按量的提供我们的服务，随着你的业务爆炸式的增长，只需要按量的付费就可以了，不需要投入大批的心血和人力。
接下来我们来具体的看一下这四点，首先接入难就是 ARMS 在目前把我们的整个数据，首先我们提供了 Java Agent 无浸入式的探针方式，如果你是 Java 引入，就可以很快的切入 ARMS，比如说通过一个 Java 式的命令，在 K8S 环境下通过一个可以很快地接入。如果是非 Java 语言，也可以利用开源 SDK，然后通过 pound 进入到 ARMS，实现一个全链的追踪，基本上是开箱即用了。
我们对语言组件的覆盖也是比较齐全的，常用的组件基本都支持，如果是比较新的组件，我们也会以每两周的速度不断地向前，还有 ARMS 是完全兼容开源的 Opencv 等各种各样的开源的格式，如果你已经接入了也是非常的方便。
第二就是解决诊断难的问题，我们在生产环境去诊断一个问题的时候，不仅仅需要调令，还需要许多数据的结合。首先是我们发现某个业务出现问题了，我们可以根据各种各样的条件去筛选出调用链，通过调用链去回溯上下游，看下平均点在哪里，如果出现了一些比较慢的情况，接口还不足以定位问题的时候，我们可以通过 ARMS 这样的功能自动地获取下来，去实现一个好解的代码，因为是业务出错了，还可以跟业务日志进行关联绑定，能够看到每一次调用，每一次关联的请求最后的业务的行为或者指示。如果上述信息还不足以定位根因，可以通过内存，Dapper 的一些工具，比如常见的是数据库打码，也可以用 Arthes 在线版本来帮助你完成一些定位的目标。
除了一整套的目标能帮你完成定位之外，基于前面提到的十年专家的沉淀，结合一些实用的算法，能够完成一些常见问题的自动诊断，比说经常会与带一些数据库的慢 SQL 问题，有很多原因，有时候是客户端的连接池打满了，后者说客户端一插了特别多的数据。需要分批等原因，这些 ARMS 都可以自动的帮你诊断出来。
解决完诊断难，我们经常遇到运维难的问题，特别是体量大的公司，问题会越严重。ARMS 是经过阿里多年的迭代，多年的优化，沉淀了一些 HA 良好的经验，HA 经过多轮，各种级别的验证，保证我们客户端测的稳定，服务端也会支持多可用区容灾，赛后体系建设，我们多起的客户支持和 7-24 小时应急值班，可以是直接享受这两个服务，而不需要从零去建设这个体系。
在 Dapper 除了文件之外，还存在一个海量数据查询性能的问题，比如说，数据达到几百 TB，这么大的原生的数据索引和数据查询可能已经失效了，无法满足需求，而 ARMS 场景下，查询性能加速，比如说实现这几组的用户进行隔离，可以通过应用去进行路由存储，应用不够的话还可以根据数据的特征或者其它一些特征进行数据加载，然后从而提高并发产品的效率。
第四点是大家比较关注的成本的问题，除了 ARMS 自身的按需存储之外，还通过精准采样的方案，进一步降低用户的成本，比如说可以通过热数据，存在热存储里面，满足一个全量分析的一个需求，30 分钟之后的数据，可能需要一个持久化，比如说 30 天。仅仅把其中错的，做得慢的或者比如有一些特征的 VIP 用户链路存储下来，这样整体的制作成本比较低，但是整体的产品体验也会比较好。当然我们在做一个链路反应的时候，就会无可避免的遇到一个指标数据不准的情况，ARMS 通过在客户端完成与聚合来保证无论你的链路数据如何采样，但你的指标数据永远是最精准的。
那么我们可以简单对比一下是采用一个开源的方案，那么我们最起码需要一个存储，需要一些服务，这些 ES 和 ECS 大概一天是两百块钱，如果你是以用户的案例为例的话，直接按照 ARMS 的每天付费的话，大概每天只需要十几块钱，这个是远远低于开源组件的零成本的，不算你的人力，最后值得一提的是今年 ARMS 也是冲入了 Garnter APM 象限，也是国内唯一的云厂商。Gather 对 APM 的评价是中国影响力最强，开源的竞争力也好，成本也有一个非常大的优势。
四、如何从 0 到 1 构建链路追踪体系
首先我们先总览的看一下四步：第一步就是异构应用全链路上下文的透传，就是从端测设备开始到网关以及应用等等。这里面就涉及一个异构语言的数据打通和前后端的透传，这套方案 ARMS 已经实现了，并且有一些最佳案例的指导。
第二步就是完成了客户端的全链路透传之后，就会面临一个计算和存储的成本，最好的方式就是存储有价值的数据来降低成本。
第三部分是我们的数据存储下来之后，还要发挥它的价值，也就是查询。这个时候我们数据之间的格式是否是统一的，是否能把指标数据整理成 Prometheus 这种格式通过这个我们的指标数据就统一了。Traces 能否支持 Open Telemetry，能否支持 Loki 这种方案。如果我们的数据格式是跟开源保持统一的，我们再去做第四步。就是释放价值就会比较容易，我们除了监控我们预置的大盘之外，通过 GRrafana 可以灵活的自定义我们用户的大盘，当然你可以按照用户自己的使用习惯做自己的控制台。同样地，告警也是同样的，我们可以通过做一个灵活的自定义的告警，同时我们也可以把数据录用到用户名下的存储，比如说 SLC，下面你想做一些按批量分析的都是可以支持的。就是我们从零到一建立起 Dapper 文字提取的步骤。，那么我们每一个单独地来看一下。
首先第一步就是完成一个异构应用的全命令的追踪，比如说前端和透传的格式。你可以选择 Jaeger 格式来透传到我们的协议里面。前端接入可以采用 CDN 或 NPM 两种方法的接入方式。
通过外部小程序连入的场景。后端如果是 Java 的话，就会优先使用 ARMS Agent，无侵入的代码的侵入。而且自带 Java 应用上面会提供很多边缘诊断等高阶能力，非 Java 我们可以通过开源的 Jaeger 或者 SK 接入。当然 ARMS 也在兼容地 Skywalking 的一些数据格式。
第二步就是说数据打动之后我们需要对它做一个精准的采样，冷热存储的分离。
这张图就是大概地画了一下冷热存储的方案，对于使用者来说，我们需要更多的定义一下尾部采样的一些策略。默认的除了存储错慢之外，我们需要根据你的一些业务特征进行采样，或者按需的调整一下数据存储的周期，简单的存储的一些配置。
第三部就是我们需要自定义监控大盘，除了 Prome 大盘之外，还可以基于 Grafana,我们可容易把业务的数据，应用的数据，甚至容器的数据放在一起，去统一的定义监控大盘。双十一的线上大促或者线上应急的一些场景我们都可以去浏览整个业务线的表现，能够快速的定义到问题的大概范围。
第四步就是当我们建立监控之外，我们还可以需要有一个比较有效的告警机制，因为大家平时也不会一直盯着监控，肯定有一个应急的入口，告警就是我们运维的第一入口。在这里介绍了三个比较典型的告警的实践，比如说某个公司或产品刚起步的时候，很多东西都是比较缺失的，这个时候可以通过 ARMS 告警模板的能力，去把比较通用的告警容器构建出来，解决一个从零到一的问题。当我们的团队或者公司一步步的发展或者成长，我们的系统会越来越多，等到它告警到一定程度的时候，告警可能在多个系统之中，这个时候又会带来一个效率的问题，这个时候有 ARMS 告警急升的能力，把多个告警源的数据放在一起，甚至可以去做一些组合的过滤规则，比如说当你的流量突然激增，你的性能耗时变高，CPU 打满的时候，这时可以做一些建议扩容或者降级的告警通知，这样就更有效。第三个就是如果我们的企业进一步发展，团队越来越多，人也越来越多，这个时候一个系统可能有多个场景来协作运维，这个时候不仅要解决一个数据爆炸的问题，还需要解决一个人员协同的问题，这个时候就可以基于 ARMS 的 chatops 的能力去解决一些问题。
第五步就是即使前面有很多公司做了以后，建设自己专属平台的意愿，因为已经有了很多可观测的沉淀，只是需要去扩充一部分的能力，那么是完全可以基于 ARMS 开控数据的能力去通过外部页面的切入，通过 openApi 的建设直接把存储开放进来，或者批量的数据分析，都可以帮助用户更好地完成 ARMS 开发。
五、最佳实践案例
1、以业务场景为中心的染色链路
通常的调用链是一个应用维度的拓补，或者是一个服务维度的拓补，这时可能还不够，我们可能比较关注某个特定场景，比如说同样是一个下单的场景，我们看整体的下单还不够，有一个新来的渠道，我们可能需要看一个线下临测的渠道，他的下单链路的情况是什么样的。或者说某一个新品类，公司新上线了一个国际的版块的品类，你可以单独地把这一部分的业务场景剥离出来做一个链路染色，从而实现这部分特定业务场景的依赖的梳理，这是通过一个无侵入的业务染色实现的。
2、保障应用安全的运行时风险识别
除了做可观测数据之外，其实还具备一些安全行为的检测和保护的能力。就是说我们可以基于 RASP 的技术，比如最近比较火的核酸检测漏洞。RASP 技术有一个很好的自我防护能力，即使不改代码还可以通过后台配置的方式完成安全防护。除了安全防护之外，ARMS 也可以提供攻击溯源，或者漏洞定位分析的保护。这比传统的防火墙式的保护更加有效，它跟防火墙的区别类似于戴口罩和打疫苗。
3、容器场景下的全景监控
第三个是前面提到的全链追踪，可以实现全景监控，我们可以把 Promrthues、Lold、APM 等等一些数据放在一起，通过 2D/3D 拓补全景展示，支持端到端链路下钻分析。同时提供了一些定期的资源巡检，基于商家转账的自动金额上报。这个就是容器创建下全景监控的最佳实践。
4、前后端/多语言/跨云部署的全链路追踪方案
还有一些技术比较复杂的拓补，它们可能除了多元之外，还有跨云的部署，比如你的公司在海外有业务，除了阿里云之外，还有 AWS 云。
国内你可能基于数据安全方面的考虑，去做一些自建机房，解决前后端多云跨平台的问题，ARMS 的链路追踪就可以帮助你完成复杂场景的全链路追踪的挑战，能够帮我们把各种场景的链路追踪串联在一起，最大化地去释放链路追踪的价值。
5、链路追踪的大三种玩法：实时后聚合分析
ARMS 最近新上线了一个 Traces apolad 的这个功能，它就是除了传统的样例的查询服务外，还提供了一个实时获取分析的能力，比如说我要看耗时大于三秒的请求，在哪些接口或者哪些 IP 上面，这样做一个 main 接口的梳理，或者做一个排查诊断，这个时候我们在预计过耗时大概进行三秒，去做一个预聚合的统计，这样需要一个灵活地获取分析能力，这个时候需要 Tracers 帮我们提供这样的价值。除了慢接口之外，我们还要结合业务指标，把用户的等级达到 Traces 里面，可以按照用户等级去分析流量的一些情况，还有一些相应的事件，可以低代码的完成自定义的分析，这里面还举了一个灰度监控，再重启之前，比如在环境变量里面注入，我们就可以看到不同版本之间流量和性能的变化。
6、ARMS vs. 开源
最后列举了一个 ARMS 在开源的接口发现超时的时候，经常接口机调用链还不足以完整的放网站，但是那个问题现象已经过去了，怎么能够自动保存下来，就是可以通过 ARMS 的业务剖析，自动诊断的能力。当我们数据库打满的时候，调用链上也很难直观的反应出来，资源类的问题是很难通过链路记录下来的，这时 ARMS 提供的池化监控能够帮你分析每一个池目前水位的情况，并且配置一些告警。如果你想分析一些内存需要的问题或者线上预警代码或者本地行为不一致的问题，都可以通过 ARMS 的百病诊断或者 Arthas 在线调试的能力，能够帮你快速的定位你的根因。
以上就是我们对 ARMS 的介绍，也涉及到全链路追踪最佳实践。
