共计 3665 个字符，预计需要花费 10 分钟才能阅读完成。
狭义上的链路老本，既蕴含应用链路追踪产生的数据生成、采集、计算、存储、查问等额定资源开销，也蕴含链路零碎接入、变更、保护、合作等人力运维老本。为了便于了解， 本大节将聚焦在广义上的链路追踪机器资源老本 ，人力老本将在下一大节（效率）进行介绍。
链路追踪机器老本的组成构造
链路追踪机器老本次要分为客户端和服务端两大类。 链路追踪客户端（SDK/Agent）通常运行在业务过程外部，与业务程序共享 CPU、内存、网络、磁盘等系统资源。链路追踪的客户端开销次要包含链路埋点拦挡、链路数据生成与透传、简略的预聚合或压缩 / 编码等数据处理、数据缓存与上报等。客户端开销通常属于一种隐性开销，短期内不会间接导致资源账单的增长，而是利用业务过程闲置局部的资源。然而，当业务持续增长或者进入峰值周期（如大促），链路追踪耗费的这部分资源最终会引发理论账单的增长。因而，这部分的开销要严格控制在一个正当的水位之内，比方不超过 10%，否则会显著影响业务的失常运行。
链路追踪的服务端机器老本是一种显性的、即时投入的资源老本，也是在评估链路追踪选型计划时（自建、托管）的重要考量因素。 链路追踪的服务端通常由网关、音讯缓冲、流计算、存储与查问端组成，最为人们所熟知与关注的是链路存储模块，许多热点文章探讨的链路尾部采样（Tail-based Sampling）次要影响的就是链路追踪服务端存储老本。然而，在短周期存储（如 3\~7 天）场景下，链路数据接管、缓冲与解决的资源老本占比甚至会超过存储，也是不容忽视的重要组成部分。
此外，还有一块容易疏忽的老本就是客户端与服务端之间的网络传输费用。 特地是在跨公网传输场景下，岂但带宽老本高，而且传输流量会受限，常常须要开启头部采样（Head-based Sampling）来升高链路数据上报量。
近年来，支流开源社区或商业化产品陆续推出了边缘集群解决方案，即在用户网络（VPC）下，部署一套可观测数据对立采集与解决集群，反对多源异构数据标准化、链路数据无损统计、错慢全采等个性，能够进一步升高链路数据上报与长久化存储老本。整体架构如下图所示。
链路追踪机器老本优化
清晰了链路追踪机器老本的组成构造，咱们接下来剖析如何进行针对性优化。在这里，先提出三个问题：“每一条链路数据的价值都相等吗？”、“对链路数据的加工解决是越早越好，还是越晚越好？”、“链路数据的存储时长是越久越好，还是越短越好？”。
为了解答上述疑难，咱们要搞清楚链路数据的用法和价值到底是什么？链路数据次要有三种用法，一是依据特定条件筛选并查问单条调用链明细轨迹，用于具体问题的诊断与定位；二是基于固定的维度进行链路预聚合，提供服务接口等通用粒度的监控与告警；三是基于链路明细进行自定义后聚合，满足个性化的链路剖析需要，如 VIP 客户大于 3S 的慢申请接口散布。
因而，蕴含不同特色的链路数据价值并不相等，错慢链路或含有特定业务特色的链路（统称为要害链路），往往比一般链路的价值更高，被查问的概率更大。 咱们应该记录更多的要害链路，并进步其存储时长；一般链路应该更少记录，并升高存储时长。此外，为了保障统计数据的精确度，咱们应该尽早实现链路数据的预聚合，这样就能够更早的进行链路采样，升高明细数据的整体上报与存储老本。
综上所述，咱们能够从 “链路歪斜采样”、“链路计算左移”、“冷热存储拆散” 等方面进行摸索，尝试以最低的老本，按需记录最有价值的链路数据，实现老本与体验的动态平衡与优化，如下图所示。
链路歪斜采样，记录更有价值的数据
链路数据的价值散布是不平均的。据不齐全统计，调用链的理论查问率通常小于百万分之一，也就是说，每一百万条调用链，只会有一条被理论查问命中，其余链路简直都是有效存储。全量存储调用链不仅会造成微小的老本节约，也会显著影响整条数据链路的性能及稳定性。
因而，链路采样（Trace Samplling）的理念随之诞生。早在 Google Dapper 论文问世的时候，就提出了基于固定比例进行链路采样的办法，并在 Google 外部生产零碎失去了实际测验。比方每 1024 条链路采样记录其中一条，采样比例为 1/1024。然而，固定比例采样仅仅解决了管制链路开销的问题，而漠视了链路价值散布的不平均性，要害链路与一般链路被采样的概率都是雷同的，这就导致许多针对要害链路的查问后果呈现未命中，极大影响了问题排查的效率。
那么，咱们是否提前预测用户行为，只记录会被查问的链路呢？100% 精准预测十分艰难，简直难以实现，然而依据历史行为和畛域教训进行揣测， 优先记录查问概率更大的链路是比拟可行的一种降本计划，这就是链路歪斜采样。
链路歪斜采样通常是针对特定的链路特色（如错、慢、外围接口或自定义业务特色）设置较高的采样比例（如 100%）或流量阈值（如前 N 条 / 分钟），不合乎要害特色的链路以极低的比例采样（如 1%）甚至不采样。如下图所示的阿里云链路追踪自定义采样配置页面，用户能够依据本身须要自在定制特色采样策略，在保障较高的查问命中率（如 50%+）的前提下， 链路数据理论存储量能够达到原始数据量的 5% 左右，极大的节俭了服务端长久化存储的老本。 更多链路采样策略将在实战篇进行具体介绍，比方动静采样。
延长一下思路，咱们在做问题诊断时，除了调用链之外，通常还须要联合日志、异样堆栈、本地办法耗时、内存快照等关联信息进行综合判断。如果每一次申请的关联信息全都记录下来，大概率会造成零碎的解体。因而，借鉴“链路歪斜采样”的理念，抛弃无用或低价值数据，保留异样现场或满足特定条件的高价值数据，精细化的按需存储能力应该成为掂量 Tracing 乃至可观测产品优劣的重要规范之一。如下图所示，阿里云 ARMS 产品提供了慢调用场景下主动保留残缺本地办法栈的能力，能够实现慢调用的行级代码定位。
链路计算左移，提炼数据价值
除了筛选记录更有价值的数据之外，还能够将数据加工计算从服务端“左移”至客户端或边缘集群，提前完成数据价值提炼，如预聚合或压缩编码，这样就能够在满足用户查问需要的前提下，无效节俭数据传输与存储老本。
- 预聚合统计：在客户端进行预聚合的最大益处，就是在不损失数据精度的同时大幅缩小数据上报量。比方，对调用链进行 1% 采样后，依然能够提供精准的服务概览 / 上下游等监控告警能力。
- 数据压缩：对反复呈现的长文本（如异样堆栈，SQL 语句）进行压缩编码，也能够无效升高网络开销。联合非关键字段模糊化解决成果更佳。
冷热存储拆散，低成本满足个性化剖析需要
链路采样和计算左移的思路都是尽可能减少链路明细数据的上报与存储，从而达到降老本的目标。这两种做法能够比拟好的满足单链路查问与通用场景下的预聚合监控告警，但却无奈满足多样化的后聚合剖析需要，比方某个业务须要统计耗时大于 3 秒的接口及起源散布，这种个性化的后聚合剖析规定是无奈穷举的。而当咱们无奈事后定义剖析规定时，貌似就只能采纳老本极高的全量原始数据存储。难道就没有优化的空间么？答案也是有的，接下来咱们就介绍一种低成本解决后聚合剖析问题的计划——冷热存储拆散。
冷热存储拆散的根底在于用户的查问行为满足工夫上的局部性原理。 简略了解就是，工夫越近的热数据查问概率越大，工夫越久的冷数据查问概率越小。例如，因为问题诊断的时效性，50% 以上的链路查问剖析产生在 30 分钟内，7 天之后的链路查问通常集中在错慢调用链。实践根底成立，接下来探讨如何实现冷热存储拆散。
首先，热数据存在时效性，如果只需记录最近一段时间内的热数据，对于存储空间的要求就会降落很多。另外，在私有云环境下，不同用户的数据人造具备隔离性。因而，在用户 VPC 外部的热数据计算和存储计划就具备更优的性价比。
其次，冷数据的查问具备指向性，能够通过不同的采样策略筛选出满足诊断需要的冷数据进行长久化存储。例如错慢采样，特定业务场景采样等。因为冷数据存储周期较长，对稳定性要求较高，能够思考在共享数据中心对立治理。
综上所述，热数据存储周期短，成本低，但能够满足实时全量后聚合剖析需要；而冷数据通过精准采样后数据总量大幅降落，通常只有原始数据量的 1% \~10%，并能够满足大多数场景的诊断诉求。两相结合，实现了老本与体验的均衡最优解。国内外当先的 APM 产品，如 ARMS、Datadog、Lightstep 均采纳了冷热数据拆散的存储计划。
冷热存储拆散的具体实现形式，以及不同存储的选型比对，咱们将在实战篇进行具体解读。下图展现了阿里云链路追踪提供的 30 分钟热数据全量分析的示意图。
小结
随着云原生与微服务架构的衰亡，可观测数据量（Traces、Logs、Metrics）出现爆发式增长态势，越来越多的企业开始器重可观测的老本治理，FinOps 也成为当下风行的一种新型协同范式。全量数据上报、存储、再剖析这种传统计划将面临越来越大的挑战。通过歪斜采样记录更有价值的数据，通过计算左移提炼数据价值，通过冷热存储拆散实现更高性价比的数据价值摸索，将逐步成为云原生时代的支流计划，让咱们一起来摸索实际吧！
点击此处，理解更多链路追踪与可观测产品
