【链路追踪】采样那些事儿

微信邦

为什么需要采样

随着越来越多的企业步入数字化转型，IT 系统也逐步向分布式、微服务化发展。面对海量和请求和服务间复杂的依赖关系，链路追踪系统通过收集、汇聚、串联、分析请求链路，为我们提供了端到端的业务实时监控能力。
但当业务量级不断增长，链路数据也会随之增多，或早或晚，我们终将面临一个决策：是否还要全量采集调用链？一方面，全量采集可以让我们不错过任何一个系统异常，并且每一个异常的发生，我们都可以通过完整的请求链路，快速定位根因；另一方面，我们无法否认全量采集会给每个业务实例的网络 I/O 以及链路处理的计算和存储层带来压力。采样是目前解决这类问题最快速且主流的方式。
但是具体以什么样的采样策略？如何在可控的资源开销内，保证最大概率保留事故相关链路，支持高效的故障排查和性能监控？我们将在下文中重点探讨。


采样的原理有哪些

如上文讨论的，采样是大多数链路追踪系统必须要讨论的命题，它已经是主流调用链追踪系统的必备组成部分。采样的算法和策略学术界有很多相关的研究，但我们基本可以按照采样实施的时机，将他们分成如下三类：

• 头部采样：Head-based sampling
• 尾部采样：Tail-based sampling
• 单元采样：Unitary sampling
  
  
  

它们的示意图如下所示：

头部采样【原理】这种采样策略是在入口服务接收到请求时决定整条链路是否保留，这个标记会随着链路 context，被透传到链路下游的所有相关服务。对于标记不保留的链路，所有对应的 Span 会在客户端被丢弃，不会上报到调用链追踪系统后台。
【优势】采样发生在客户端，可以显著降低挂载在业务服务器上的代理对业务服务器资源（网络 I/O 的开销）；同时因为 Span 直接被丢弃，也降低了服务端的存储和计算开销。
【劣势】采样实施在链路产生初期，命中异常和慢响应的几率低，会影响故障排查。
【增强】配合异常回溯上报，即每个链路节点服务在上报代理处缓存窗口期内的 Span 信息，下游链路出现异常后，可以动态扭转上游链路的采样状态，保证完整异常链路留存。当然这种缓存机制，相应也会对业务服务器产生较大的内存开销  。
尾部采样【原理】这种采样策略是在请求处理完成时决定整条链路是否保留。客户端会将所有 Span 都上报到调用链追踪系统后台，后台根据一定预设的规则，决定哪些链路被保留。
【优势】采样实施在链路产生后，可以精准采集异常、慢响应或者根据一些业务逻辑能够辅助故障排查的链路；有效减少链路存储产生的相关资源成本。
【劣势】采样发生在调用链追踪系统后台，对业务服务器资源（网络I/O的开销）的压力无缓解。
单元采样【原理】各个业务模块自主决定是否上报当前节点，单个节点的采样决策不影响链路上的其他服务。
【优势】避免整体业务链路采样决策影响，节点的异常信息可以精准上报；有效降低上报客户端和调用链追踪系统后台的资源压力。
【劣势】链路连贯性无法保证，无法支持根据上下游进行有效根因分析。

如何有效制定采样策略

如上文讨论的内容，不同的采样策略各有优劣，实际应用中我们很难通过单一的采样策略达到效率和成本的平衡。从系统资源消耗上看，单位链路的上报、计算、存储成本是固定的，但是我们都清楚不是所有链路带给我们的价值都相同。
简单来说，大部分的系统中我们对异常链路的关注远大于成功链路；对于写操作的关注大于读操作；对于一些核心的业务逻辑的关注大于资源层面的调度。为了增加我们监控系统的边际收益，首先要明确系统中各种链路的价值，再以此为依据，因时因地配置或调整我们的采样策略。
比如对于核心的业务逻辑，或者重大事件保障期间，我们更偏好通过尾部采样的方式，确保对于异常链路可以百分之百留存，因为通常这种紧要关头，往往没有很长的时间去复现问题，完整保留事故现场，可以在最短的时间内解决前台反馈的问题（可能是提出工单在线等待的客户，可能是重大事件期间主要承压的上游业务系统）；
对于一些资源层，或者边缘的业务，可以采取头部采样/单元采样的方式，配置适当的采样比例。对于这类组件/模块，当我们假设采样比例的是均匀的，我们可以接受在指标或者发现采样链路异常后，再去复现/处理异常。

腾讯云应用性能观测-采样配置

腾讯云应用性能观测（APM）作为一个适配多协议，多语言的调用链追踪系统，提供了灵活且强大的后台采样配置能力。结合我们上述讨论的典型场景，您可以在配置您选择的接入客户端采样率，在 APM 后台进一步配置尾部采样策略，保证精准的命中率、高效的故障排查，同时也可以有效降低您的链路存储成本。下图为某用户采样存储成本和上报数量对比图：

• 异常、慢响应链路全保留
  
  

异常和慢调用链路无疑是每个开发人员一定会关注的链路，在 APM 控制台，您只需在【系统配置】中，选择开启对异常链路全采集，输入慢调用的容忍值，就可以立刻将所选择的业务系统下所有异常和慢响应的事故现场，全部捕获；与此同时，我们还支持您配置一个兜底采样率，即在把异常、慢调用以及您自定义的一些特殊业务相关采样规则后，对于所有其他请求，抽样采集。以便和同期的异常链路进行对比分析，更快定位到逻辑偏差。

• 核心业务逻辑全保留
  
  

一个组织内部的诸多服务中，也会有核心业务逻辑和一些日常会话逻辑的区分。比如对于电商后台服务，下单的全流程可能比我们拉取商品列表或者用户信息接口的优先级要高。对于这类的业务逻辑，APM 支持您通过服务、接口以及 TAGS（标签）的维度，精准把核心业务工作流过滤出来，通过对这些业务相关的链路配置更高或者100%的采样率，我们可以确保重要的/难以快速复现的链路故障可以立刻得到分析和解决。

• 重大事件保障全面监控
  
  

还有一个比较常见的运维面临较大压力的场景就是重大事件保障，大一点比如 Qcon（全球软件开发者大会）、广交会这类活动，可能更加关心某一个用户的使用体验是不是可以维持高可用。
此时，您也可以通过 APM，配置一个短期内生效的以 Tags（标签） 维度定位的采样策略，比如定义 resource ID=12345  的这个相关的用户所有的请求需要全部保留，以防出现问题或者故障，可以快速定位，甚至影响审计和定责。点击文末

「阅读原文」

了解腾讯云应用性能观测。

客户端采样操作指引：https://cloud.tencent.com/document/product/1463/63817服务端采样操作指引：https://cloud.tencent.com/document/product/1463/66102