炎炎夏日，当你打开外卖 APP 购买奶茶却发现下单失败；五一佳节，当你自驾游途中发现导航响应缓慢，频繁错过路口；深更半夜，当你辅导孩子功课，却发现 GPT 应用迟迟无法应答。不知你有没有想过，这些程序运行的背后到底是怎样的世界，每一次点击，每一次交互，又到底发生了什么？
如果你是一名 SRE，是否会关注系统的性能瓶颈在哪里？如果你是一名 AppOps，是否关注应用的健康度保持在安全的水位？如果你是一名业务运营，是否关注影响客户行为的关键路径和原因？
上述谜题的答案就是
链路追踪
，通过记录请求在系统中的流转路径与状态，可以真实还原每一次请求的调用轨迹，快速定位错慢根因，并且通过请求粒度的数据关联实现业务影响面分析、业务异常排查等诉求。
链路追踪的价值就在于“关联”，用户终端、网关、后端应用、依赖组件（如数据库、消息、大模型）等共同构成了链路追踪的轨迹拓扑大图。这张拓扑覆盖的范围越广，链路追踪能够发挥的价值就越大。而端到端链路追踪就是覆盖全部关联 IT 系统，能够完整记录用户行为在系统间调用路径与状态的最佳实践方案。
不同开发语言、链路框架的实现不尽相同，真正实现端到端链路追踪，需要解决三个难题：
链路插桩、链路采集与加工、链路上下文透传。
-
链路插桩，顾名思义就是在关键方法执行前后添加链路追踪的埋点代码，从而记录相应的方法名称、耗时、状态等信息。链路插桩是一切的基础，只有已插桩方法才会生成 Trace 链路数据，可以被追溯和观测。但是链路插桩的难点是哪些方法需要插桩？如何低成本的新增或管理插桩逻辑？如何保障链路插桩的准确、性能和稳定？
-
链路采集与加工，就是把已经生成的链路数据收集到指定的后端进行处理与存储，以便后续进行分析。链路采集的难点在于如何确定采集目标并收到完整的链路数据，特别是云产品服务（如网关）生成的链路数据。链路加工的难点在于如何处理非原生 Trace 数据转义（如网关访问日志），或者多源异构链路模型的归一化。
-
链路上下文透传，是最容易被忽视，也是最难处理的问题。目前业界链路透传协议尚未完全统一，常用的主流协议包括 w3c、b3、jaeger 和 skywalking。不同系统之间由于开发语言、开源框架、产品归属等原因最终选择的链路协议不一致是比较普遍的，从而导致调用链断链不全等问题。另外，在迁移链路框架的过程中，也会出现协议不兼容的情况，比如 Skywalking 与 OpenTelemetry。
阿里云 ARMS（含可观测链路 OpenTelemetry 版）目前已经支持用户终端（Web/Andriod/iOS）-> 云网关（ALB/MSE/Ingress/ASM/ApiGateway）-> 后端应用（Java、Go、Python 等）-> 云组件（数据库、消息、大模型等）的端到端全链路打通，如下图所示。
链
路插桩：
Java/Go 等主流语言推荐 ARMS 自研探针，兼容开源提升多语言覆盖度
针对 Java/Go/Python 等主流语言，推荐接入 ARMS 自研探针提升链路插桩的质量、性能、稳定性和易用性。同时，为了更广泛的支持其他语言，可观测链路 OpenTelemetry 版全面兼容 OpenTelemetry、SkyWalking、Zipkin、Jaeger 4 种主流链路框架 10+ 种多语言的链路插桩与数据上报，如下表所示。
ARMS 与可观测链路 OpenTelemetry 数据完全互通，在多语言场景建议结合使用。
ARMS 今年刚刚发布了 JavaAgent 4.0，全面拥抱 OpenTelemetry 生态，探针底座基于 OpenTelemetry 框架进行了全新升级，并额外提供多种资源监控、性能诊断、应用安全等数据。除了更丰富的数据，ARMS JavaAgent 4.0 还支持更加灵活的调用链采样策略、白屏化探针管理、全方位自监控、动态功能降级等高阶特性，更加适合企业级客户的生产环境应用，如下表所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
w3c、jaeger、b3、skywalking、eagleeye
|
|
|
|
|
固定比例采样、流量自适应采样、错慢异常采样、接口级自定义全采
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CPU、RSS 基本持平（ARMS 额外支持更多功能，关闭后性能更优）
|
企业上云的一个痛点问题就是重度依赖云产品服务可用性，端到端链路追踪可以快速定位错慢请求异常节点，提升故障快恢效率，降低业务损失。那么如何接入云产品的调用链路数据呢？
可观测链路 OpenTelemetry 版与阿里云近 10 款云产品深度合作，完成了云产品内部链路插桩与数据上报。对于企业用户来说，只需在相应的云产品控制台一键启用链路追踪开关，就可以直接看到相应的调用链，大幅简化了链路采集成本，ALB 网关、MSE 网关以及 ARMS 用户体验监控的链路追踪接入效果如下图所示 。
受限于产品特性，不同云产品的链路插桩方案有所区别，配套的链路数据采集大致分为两类：
-
Trace 直接/转发上报：以用户体验监控为例，内部实现链路插桩与 Exporter 直连上报，埋点更精细更灵活。
-
日志数据转 Trace：以 ALB 网关为例，后台消费访问日志，再转义成 Trace 数据，侵入性更小。
两种方案各有优劣，通常推荐 Trace 直连/转发上报，此种方案更规范。但是在性能要求高或者旧系统改造困难场景下，可以考虑日志转 Trace（前提条件是在日志中添加 TraceId 等链路上下文）。
目前，已经支持接入链路追踪的云产品、协议及接入指南如下表所示。
|
|
|
|
|
|
|
|
|
w3c、b3、jaeger、skywalking、eagleeye
|
|
|
通过 OpenTelemetry 上报 Android 应用数据
[
4]
|
|
|
|
通过 OpenTelemetry 上报 Swift 应用数据
[
5]
|
|
|
|
|
通过 ALB 链路追踪实现业务全链路分析
[
6]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
使用 Ingress-tracing 实现链路追踪
[
10]
|
|
|
|
|
接入 ARMS 开始监控 Java 应用
[1
1]
|
|
|
|
接入可观测链路 OpenTelemetry 版
[
12]
|
|
|
|
100+ 插件支持，覆盖 RPC、消息队列、数据库、任务调度等各种类型
|
链路上下文透传：
统一阿里云端到端链路协议，自研探针兼容多协议转换
从单个应用组件的视角，完成链路插桩和数据采集，能在控制台上看到对应的 Trace 数据就已经大功告成啦。但是真正的端到端链路追踪必须将上下游的 Trace 以统一的协议进行串联，保证不断链，既有技术层面的挑战，也有协同层面的困难。
