简介：完整的全链路追踪可以为业务带来三大核心价值：端到端的问题诊断、系统间依赖梳理、自定义标签透传。作者|雅海全链路追踪的价值链路追踪的价值在于“关联”。终端用户、后端应用和云端组件（数据库、消息等）共同构成了链路跟踪的大轨道拓扑图。此拓扑覆盖的范围越广，链接跟踪的价值就越大。全链路跟踪是一种覆盖所有关联IT系统的最佳实践方案，能够完整记录系统间用户行为调用的路径和状态。完整的全链路追踪可以为业务带来三大核心价值：端到端的问题诊断、系统间依赖梳理、自定义标签透传。端到端的问题诊断：VIP客户下单失败、内测用户请求超时，很多终端用户体验问题的根源都追溯到后端应用或云组件异常。而全链路跟踪是解决端到端问题最有效的手段，没有之一。系统之间的依赖关系排序：新服务上线、旧服务退出、机房搬迁/架构升级，IT系统之间的依赖关系错综复杂，超出了人工排序的范围。基于全链路跟踪的拓扑发现使得上述场景的决策更加容易。敏捷且值得信赖。自定义标签透传：全链路压测、用户级灰度、订单溯源、流量隔离。基于自定义标签的分层处理和数据关联催生了繁荣的全链路生态。但是，一旦数据链路断开，标记丢失，也会造成难以预料的逻辑灾难。全链路跟踪的挑战与全链路跟踪解决方案的价值和覆盖范围成正比，其挑战也是如此。为了最大程度保证链路的完整性，无论是前端应用还是云组件，无论是Java语言还是Go语言，无论是公有云还是自建机房，需要遵循同一套链路规范，实现数据互联互通。多语言协议栈统一、前/后台/云（多）端联动、跨云数据融合是实现全链路追踪的三大挑战，如下图所示：1.多语言协议栈统一在云端-native时代，多语言应用架构越来越普遍，利用不同的语言特性来达到最佳的性能和研发体验已经成为一种趋势。但由于不同语言的成熟度存在差异，全链路跟踪无法实现完全的能力一致性。目前业界的主流做法是保证远程调用协议层格式统一，多语言应用在内部实现调用拦截和上下文透传，保证基础链路数据的完整性。然而，大多数线上问题仅靠链路追踪的基础能力是无法有效定位和解决的。在线系统的复杂性决定了一个优秀的Trace产品必须提供更全面有效的数据诊断能力，比如代码级诊断、内存分析、线程池分析、无损统计等等。充分利用不同语言提供的诊断接口，最大限度地发挥发布多语言产品的能力，是Trace不断发展的基础。透传协议标准化：整个链路上的所有应用都需要遵循同一套协议透传标准，保证链路上下文在不同语言的应用之间可以完全透传，不会出现断链、丢失的问题上下文。目前主流的开源透传协议有Jaeger、SkyWalking、ZipKin等。最大限度释放多语言产品能力：除了最基础的调用链功能，链路追踪也逐渐衍生出应用/服务监控、方法栈跟踪、性能分析。但不同语言的成熟度导致产品能力差异较大。例如，Java探测器可以实现许多基于JVMTI的高级边缘端诊断。一个优秀的全链路跟踪解决方案，将最大限度释放各语言的差异化技术红利，而不是一味追求平庸。2、前后端云（多）端联动目前开源的链路追踪实现主要集中在后端业务应用层，用户端和云端组件侧没有有效的追踪方式（例如云数据库）。主要原因是后两者通常由云服务商或第三方厂商提供，取决于厂商对开源兼容性和适配性是否友好。业务方很难直接介入开发。上述情况的直接影响是前端页面响应慢，很难直接定位到后端是哪个应用或服务导致的，无法明确给出确定性根原因。同样，也很难将云组件的异常直接等同于业务应用的异常。尤其是在多个应用共享同一个数据库实例的场景下，需要更多迂回的验证方式，排错效率很低。为解决此类问题，云服务商首先需要更好地支持开源链路标准，增加核心方法嵌入点，支持开源协议栈透传和数据回传（例如阿里云ARMS前端监控支持Jaeger协议透传和方法栈跟踪）。其次，由于不同系统由于所有权等问题可能无法完成全链路协议栈的统一，为了实现多端联动，Trace系统需要提供连接异构协议的解决方案堆栈。异构协议栈连接为了实现异构协议栈（Jaeger、SkyWalking、Zipkin）的连接，Trace系统需要支持两种能力：一是协议栈转换和动态配置。导入的下游外部系统使用ZipKinB3协议。两者之间的Node.js应用可以接收Jaeger协议，向下透传ZipKin协议，保证全链路标记透传的完整性。二是服务端的数据格式转换，可以将上报的不同数据格式转换成统一的格式进行存储，或者在查询端进行兼容。前者的维护成本相对较小，后者的兼容成本较高，但相对更加灵活。3.跨云数据集成许多大型企业出于稳定性或数据安全等因素，选择多云部署。比如国内系统部署在阿里云上，海外系统部署在AWS云上，企业内部涉及敏感数据的系统部署在自建机房等，多云部署成为典型的云部署架构，但不同环境的网络隔离、基础设施的差异也给运维人员带来了巨大的挑战。由于云环境只能通过公网进行通信，为了实现多云部署架构下的链路完整性，可以采用链路数据的跨云上报、跨云查询等方式。无论哪种方式，目标都是实现多云数据的统一可见，通过完整的链路数据快速定位或分析问题。跨云上报链路数据跨云上报相对容易实现，易于维护和管理。是目前云厂商采用的主流方式。例如，阿里云ARMS通过跨云数据上报实现多云数据融合。跨云报表的优点是部署成本低，一套服务器容易维护；缺点是跨云传输会占用公网带宽，公网流量成本和稳定性是重要制约因素。跨云上报更适合主多从架构。大部分节点部署在云环境中，其他云/自建机房只占少量业务流量。自建机房更适合跨云上报，如下图。跨云查询跨云查询是指将原始链路数据存储在当前云网络中，单独发送用户查询，然后将查询结果汇总统一处理，降低公网传输成本。跨云查询的优点是跨网络传输的数据量小，特别是链路数据的实际查询量通常不到原始数据量的万分之一，可以大大节省公网带宽。缺点是需要部署多个数据处理终端，不支持分位数、全局TopN等复杂计算。更适合多主架构，可以支持简单的链路拼接和max/min/avg统计。跨云查询实现有两种模式。一是在云网络内部搭建一套数据集中处理终端，通过内网专线接入用户网络，可以同时处理多个用户的数据；每个用户在专有网络中独立搭建一套数据处理终端。前者维护成本低，容量灵活性大；后者具有更好的数据隔离。其他方法除上述两种方案外，在实际应用中，还可以采用混合方式或只采用透传方式。混合模式是指统计数据通过公网统一上报集中处理（数据量小，精度要求高），而链路数据通过跨云查询检索（数据量大，查询频率低）。只透传模式是指各个云环境之间只有链路上下文可以完全透明传输，链路数据的存储和查询都是独立实现的。这种模式的优点是实施成本极低。每个云只需要遵循同一套透传协议，具体的实现方案可以完全独立。通过相同的TraceId或应用名手动拼接，更适合现有系统的快速集成，改造成本最小。全链路追踪接入实践上一篇文章详细介绍了全链路追踪在各种场景下面临的挑战和解决方案。下面以阿里云ARMS为例，介绍如何从0到1搭建一套集前端、网关、服务器、容器、云组件于一体的完整可观察系统。Header透传格式：统一采用Jaeger格式，Key为uber-trace-id，Value为{trace-id}:{span-id}:{parent-span-id}:{flags}。前端接入：可采用CDN（ScriptInjection）或NPM两种低代码接入方式，支持Web/H5、Weex及各种小程序场景。后端接入：Java应用推荐优先使用ARMSAgent，无侵入式埋点无需修改代码，支持边缘诊断、无损统计、精准采样等高级功能。自定义方法可以通过OpenTelemetrySDK主动埋点。非Java应用推荐通过Jaeger访问，向ARMSEndpoint上报数据。ARMS将兼容多语言应用之间的链路透传和展示。目前阿里云ARMS的全链路追踪方案是基于Jaeger协议，正在开发SkyWalking协议，支持SkyWalking自建用户的无损迁移。前端、Java应用、非Java应用全链路跟踪的调用链效果如下图所示：1、前端接入实战ARMS前端监控支持Web/H5、Weex、支付宝、微信小程序等本文通过CDN使用Web应用以接入ARMS前端监控的方法为例，简单说明接入流程，详细接入参考ARMS前端监控官网文档准则。登录ARMS控制台，在左侧导航栏点击访问中心，点击选择前端Web/H5访问。输入应用名称，点击创建；在SDK扩展配置项区域勾选需要的选项，快速生成插入页面的BI探针代码。选择异步加载，将以下代码复制粘贴到页面HTML元素内的第一行，重启应用。<脚本>!(函数(c,b,d,a){c[a]||(c[a]={});c[a].config={pid:"xxx",imgUrl:"https//arms-retcode.aliyuncs.com/r.png?",enableLinkTrace:true,linkType:'tracing'};with(b)with(body)with(insertBefore(createElement("script"),firstChild))setAttribute("crossorigin","",src=d)})(window,document,"https://retcode.alicdn.com/retcode/bl.js","__bl");为了实现before和after上面的探测代码必须包含以下两个参数：enableLinkTrace:true//表示开启前端链接跟踪功能linkType:'tracing'//表示生成Jaeger协议格式的链接数据，Hearder允许uber-trace-id透传此外，如果API与当前应用非同源，需要添加参数enableApiCors:true，同时后端服务器也需要支持跨域请求和自定义header值。详见前后端链接相关文档。验证前后端链接跟踪配置是否有效，可以打开控制台查看相应API请求的RequestHeaders中是否有uber-trace-id标识。2、Java应用接入实战Java应用推荐接入ARMSJavaAgent，非侵入式探针开箱即用，无需修改业务代码。详细的接入指南请参考ARMS应用监控官网文档。登录ARMS控制台，单击左侧导航栏中的访问中心，单击选择后端Java访问。根据需要选择手动安装、脚本安装或容器服务安装中的任意一种。确保探针按照操作指南下载并解压到本地，正确配置appName、LicenseKey、javaagent启动参数后重启应用。3、非Java应用接入实践非Java应用可以通过开源SDK（如Jaeger）向ARMS接入点上报数据。详细的接入指南请参考ARMS应用监控官网文档。登录ARMS控制台，在左侧导航栏点击访问中心，点击选择后台Go/C++/.NET/Node.js等访问方式。按照操作指南更换接入点，配置完成后重启应用。全链接跟踪只是开始，而不是结束。自2010年谷歌发表Dapper论文以来，链接跟踪已经发展了十多年。然而，关于链接跟踪的书籍或深入的文章一直很少。大多数博客只是介绍一些开源概念或QuickStart。哪些坑该填，哪些地雷该避，很难找到更系统、更全面的答案。全链路跟踪接入只是Tracing的起点。选择适合自己业务架构的方案，可以少走一些弯路。但链接跟踪不仅仅是查看调用链和服务监控。如何向上赋能业务，衍生到业务可观察领域，辅助业务决策？如何与可观察的基础设施向下联动，提前发现资源风险？未来还有很多工作要做，期待更多同学的加入和分享。相关链接1.ARMS前端监控官网文档：https://help.aliyun.com/docum...2.前后端链接相关文档：https://help.aliyun.com/docum...3.ARMS应用监控官网文档：https://help.aliyun.com/docum...4.ARMS应用监控官网文档：https://help.aliyun.com/docum...5、ARMS控制台：https://arms.console.aliyun.c...原文链接本文为阿里云原创内容，未经允许不得转载。
