1. 论文基本信息

1.1. 标题

Mint: Cost-Efficient Tracing with All Requests Collection via Commonality and Variability Analysis

1.2. 作者

• Haiyu Huang (黄海宇), Sun Yat-sen University (中山大学)
• Cheng Chen (陈成), Alibaba Group (阿里巴巴集团)
• Kunyi Chen (陈坤一), Alibaba Group (阿里巴巴集团)
• Pengfei Chen (陈鹏飞)*, Sun Yat-sen University (中山大学) (*通讯作者)
• Guangba Yu (余广坝), Sun Yat-sen University (中山大学)
• Zilong He (何子龙), Sun Yat-sen University (中山大学)
• Yilun Wang (王一伦), Sun Yat-sen University (中山大学)
• Huxing Zhang (张虎兴), Alibaba Group (阿里巴巴集团)
• Qi Zhou (周琦), Alibaba Group (阿里巴巴集团)

1.3. 发表期刊/会议

Proceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 1 (ASPLOS '25), March 30-April 3, 2025, Rotterdam, Netherlands. ASPLOS (Architectural Support for Programming Languages and Operating Systems) 是计算机体系结构、编程语言和操作系统交叉领域内的顶级会议之一，具有很高的学术声誉和影响力。

1.4. 发表年份

2025年

1.5. 摘要

分布式追踪 (Distributed traces) 包含有价值的信息，但其巨大的数据量对追踪框架的设计提出了核心挑战：如何在保留必要追踪信息和减少追踪数据量之间取得平衡。为了解决这一权衡问题，以往的方法通常采用“1或0”的采样 (sampling) 策略：保留采样的追踪 (sampled traces)，同时完全丢弃未采样的追踪 (unsampled ones)。然而，基于对真实生产追踪数据的实证研究，作者发现“1或0”策略实际上未能有效平衡这一权衡。

为了实现更平衡的结果，作者将策略从“1或0”范式 (paradigm) 转向“共性 + 变异性”范式 (commonality + variability paradigm)。“共性 + 变异性”范式的核心是首先将追踪解析为共同模式 (common patterns) 和可变参数 (variable parameters)，然后聚合这些模式并过滤参数。作者提出了一个成本高效的追踪框架 Mint，它在代理端 (agent side) 实现了“共性 + 变异性”范式，从而实现所有请求的捕获。实验结果表明，Mint 可以在捕获所有追踪并保留更多追踪信息的同时，优化追踪存储（平均减少到2.7%）和网络开销（平均减少到4.2%）。此外，实验还证明 Mint 轻量化 (lightweight) 到足以用于生产环境。

1.6. 原文链接

/files/papers/6901a5ae84ecf5fffe471752/paper.pdf 此链接为 PDF 文件链接，表明论文已发布或作为预印本提供。根据 ACM Reference Format，它将在 ASPLOS '25 会议上发表。

2. 整体概括

2.1. 研究背景与动机

2.1.1. 核心问题与重要性

随着软件系统变得日益庞大和复杂，分布式追踪 (Distributed Tracing) 已成为一个关键基础设施，它提供了对系统端到端运行时行为 (end-to-end runtime behavior) 的可见性 (visibility)。追踪数据在性能分析 (profiling systems)、异常检测 (detecting anomalies) 和故障诊断 (diagnosing failures) 等方面具有极高的价值。

然而，这些追踪数据往往体量巨大，导致其收集、存储和处理成本高昂，尤其是在生产环境中。例如，阿里巴巴的一个大型电子商务系统每天会产生约 18.6-20.5 PB 的追踪数据，这带来了巨大的存储和网络开销。如何在保留必要的追踪信息和减少追踪数据量之间取得平衡，是追踪框架设计中的一个核心挑战。

2.1.2. 现有研究的挑战与空白 (Gap)

当前处理追踪数据量大的主流方法是追踪采样 (trace sampling)，即只保留一部分追踪数据。这些方法通常采用“1或0”的采样策略：完全保留被采样的追踪，而完全丢弃未被采样的追踪。这种策略存在以下两个主要局限性：

1. 完全丢弃未采样追踪的弊端： 尽管采样方法试图通过特定规则保留有价值的追踪，但实证研究发现，被丢弃的追踪也可能在未来被站点可靠性工程师 (Site Reliability Engineers, SREs) 查询，因为需要分析的追踪特性往往是不可预测的。例如，研究发现当前采样策略导致约 27.17% 的查询未命中率 (query miss rate)，这严重阻碍了 SRE 的诊断过程。
2. 缺乏对单个追踪数据量的有效压缩： 以前的追踪数据缩减方法只减少追踪的数量，而没有对每个单独的追踪进行轻量化处理。然而，每个追踪都可能包含比调试级别日志 (debug-level log) 更详细的信息，使得对追踪数据进行基于其特征的压缩变得必要。通用压缩工具 (如 gzip, bzip2) 和现有的日志压缩技术对于追踪数据效率低下，因为追踪具有拓扑数据结构 (topological data structure)，这些方法未能充分利用追踪的这一特性。

2.1.3. 论文的切入点与创新思路

为了解决上述局限性，本文的创新点在于：

1. 策略范式转变： 将追踪开销缩减策略从“1或0”范式 (paradigm) 转向“共性 + 变异性”范式 (commonality + variability paradigm)。
2. 利用追踪特性： 通过对阿里巴巴真实生产追踪数据的实证研究，发现追踪数据中广泛存在共性和变异性 (commonality and variability)，并且这些特性可以在不同层次上被利用。
   • 共性 (Commonality)： 通过构建共同模式 (common patterns)，可以低成本地聚合和存储所有追踪的基本信息。
   • 变异性 (Variability)： 通过提取参数 (parameters)，可以更好地过滤并高效记录差异化部分。
3. 代理端处理： 在代理端 (agent side) 实现这一新范式，从而同时节省网络带宽和存储空间，并实现所有请求的捕获 (all requests capturing)。

2.2. 核心贡献/主要发现

本文的主要贡献可以总结为以下几点：

1. 实证研究： 对真实系统中的追踪数据进行了实证研究，并提出了三个有助于追踪缩减任务的观察结果。

2. 提出新范式： 指出当前基于“1或0”范式的追踪缩减方法的局限性，并引入“共性 + 变异性”范式，以更低的成本保留更多的追踪信息。

3. 设计并实现 Mint 框架： 提出了一个实用的分布式追踪框架 Mint，该框架在代理端应用“共性 + 变异性”范式，实现了成本高效的所有请求保留。

4. 实验验证： 进行了广泛的实验来评估 Mint，证明了其在减少追踪数据量、捕获所有请求方面的有效性，并评估了其效率，表明它是一个实用的工具。

5. 生产环境部署： Mint 已在阿里巴巴的生产环境中部署超过两个月，成功减少了追踪数据量，同时捕获了所有请求，并显著提升了用户体验和分析能力。

   主要发现包括：

• Mint 可以捕获所有追踪并保留更多追踪信息，同时将追踪存储开销平均减少到 2.7%，网络开销平均减少到 4.2%。
• Mint 在查询响应能力上，即使是未采样追踪也能提供近似信息，并显著提高了下游根因分析 (Root Cause Analysis, RCA) 方法的准确率（平均从 25% 提升到 50%）。
• Mint 在阿里巴巴生产环境中的部署显示其计算开销（CPU 使用率增加约 0.86%）和延迟增加（平均 0.21%）都在可接受范围内，证明其轻量化和可伸缩性。
• 跨度间 (inter-span) 和追踪间 (inter-trace) 两个层面的共性与变异性分析都对追踪压缩有显著贡献。

3. 预备知识与相关工作

3.1. 基础概念

3.1.1. 分布式追踪 (Distributed Tracing)

分布式追踪是一种提供对现代微服务 (microservice) 架构中请求端到端 (end-to-end) 行为可见性的技术。它通过在请求流经各个服务时收集数据，并将其关联起来，形成一个完整的追踪链 (trace chain)。

• 追踪 (Trace): 表示一个完整的请求从开始到结束在分布式系统中经历的端到端执行路径。一个追踪由一个唯一的追踪 ID (trace ID) 标识。
• 跨度 (Span): 追踪中的一个基本工作单元，代表在特定服务或组件中执行的某项操作（如一个函数调用、一个数据库查询、一个 HTTP 请求）。每个跨度有自己的 ID (span ID)，并且通常会记录其父跨度 ID (parent ID)，从而形成一个树状结构来表示请求的调用关系。
• 跨度结构 (Span Structure): 通常包含三个部分：
  • 拓扑部分 (Topology part): 包含指示跨度在整个追踪中位置的信息，如 span ID, parent ID, trace ID。
  • 元数据部分 (Metadata part): 包含客户端库 (client library) 自动获取并附加到跨度的预定义基本信息，如服务名称、操作名称、开始时间、持续时间、状态码等。
  • 属性部分 (Attributes part): 用户可以添加的额外详细信息，如调试信息、错误代码、SQL 查询内容等，以键值对 (key-value) 形式存在。

3.1.2. 采样 (Sampling)

采样是分布式追踪中用于减少数据量的一种常用技术，通过选择性地收集一部分追踪数据来降低成本。

• 头采样 (Head Sampling): 在追踪生命周期的早期（即请求刚开始时）就决定是否采样。一旦决定，该追踪及其所有后续跨度都会被采样或丢弃。优点是简单高效，缺点是无法根据追踪的完整上下文（如错误或异常）进行智能决策。
• 尾采样 (Tail Sampling): 在追踪的所有跨度都被收集到后端 (backend) 之后，根据追踪的完整信息（如是否包含错误、持续时间是否异常等）来决定是否采样。优点是可以保留有价值的异常追踪，缺点是所有追踪数据都需要先传输到后端，因此无法减少网络开销。
• 回溯采样 (Retroactive Sampling): 结合了头采样和尾采样的优点。它在代理端进行早期决策，但允许在发现追踪是“有趣”的（例如出现错误）之后，追溯性地收集完整的追踪信息。这通常通过在代理端缓存追踪数据并在需要时上传“面包屑 (breadcrumbs)”或完整数据来实现，旨在减少网络开销同时保留关键追踪。

3.1.3. 布隆过滤器 (Bloom Filter)

布隆过滤器 (Bloom Filter) 是一种空间效率极高的概率型数据结构，用于判断一个元素是否可能在一个集合中。

• 原理： 它通过使用多个哈希函数 (hash functions) 将元素映射到一个位数组 (bit array) 中的多个位置，并将这些位置的位设置为 1。
• 查询： 要查询一个元素是否存在，将其通过相同的哈希函数映射到位数组，并检查所有对应位是否都为 1。如果所有位都为 1，则元素可能存在（有假阳性）；如果有任何一个位为 0，则元素一定不存在（无假阴性）。
• 特点：
  • 空间效率高： 占用空间远小于存储实际元素。
  • 概率性： 存在假阳性 (false positives)，即报告元素存在但实际上不存在。假阳性率 (false positive rate) 可通过调整位数组大小和哈希函数数量来控制。
  • 无假阴性： 绝不会报告元素不存在而实际上存在。
  • 不可删除： 一旦元素被添加，通常不能从布隆过滤器中删除，因为删除一个位可能会影响其他元素的查询。

3.1.4. 最长公共子序列 (Longest Common Subsequence, LCS)

最长公共子序列 (LCS) 是一个经典的计算机科学问题，用于找出两个序列中共同的最长子序列，且该子序列不必是连续的。在字符串相似度计算中，它常用于衡量两个字符串（或词元序列）的相似程度。LCS 越长，表示两个字符串的共同结构越多，相似度越高。

3.1.5. 正则表达式 (Regular Expression)

正则表达式 (Regular Expression, 简称 regex 或 regexp) 是一种强大的文本模式，用于描述、匹配和处理字符串。在日志或追踪数据处理中，正则表达式常用于从结构化或半结构化文本中提取特定的可变参数 (variable parameters) 或识别共同的文本模式。例如，一个 SQL 查询字符串 INSERT INTO users (id, name) VALUES (1, 'Alice') 可以用正则表达式 $INSERT INTO \w+$(\w+,?)+$VALUES$(\d+,?)+ 来匹配，并提取其中的表名、字段和值作为参数。 ## 3.2. 前人工作 ### 3.2.1. 分布式追踪框架 (Distributed Tracing Frameworks) - **经典框架：** Magpie [6]、X-trace [13]、Dapper [52]、Pinpoint [41]、Pivot [36] 等。这些框架奠定了分布式系统端到端可见性的基础。 - **流行开源框架：** Jaeger [24]、OpenTelemetry [43]、Zipkin [1] 等。这些框架已被广泛采用，OpenTelemetry 更是致力于提供统一的 API 和 SDK，并建立了 OTLP [46] 标准来标准化追踪数据的格式和传输。 - **分析应用：** 利用端到端可见性，前人工作在性能分析 [20, 38, 51]、异常检测 [32, 42, 59] 和故障诊断 [15, 16, 35, 57] 等领域进行了大量研究。 ### 3.2.2. 追踪数据缩减方法 (Trace Reduction Methods) 随着追踪数据量的增长，研究者提出了多种缩减方法 [25, 27, 29]。主流方法是基于采样的策略： - <strong>头采样 (Head Sampling) [25, 52]:</strong> 在追踪开始时决定是否采样。 - <strong>尾采样 (Tail Sampling) [17, 23, 28, 29]:</strong> 在追踪结束后，根据其完整上下文决定是否采样。 - <strong>回溯采样 (Retroactive Sampling) [60]:</strong> 最近提出的方法，结合了早期决策和后期追溯收集。 **Mint 强调这些采样方法都基于“1或0”策略，即完全保留或完全丢弃，这是其主要局限性。** ### 3.2.3. 日志专用压缩器 (Log-specific Compressors) 日志数据与分布式追踪数据有相似之处，但缺乏追踪的拓扑结构。鉴于日志数据的高冗余性，许多日志压缩方法被提出： - **基于特征提取：** LogArchive [8]、Cowic [31]、MLC [12] 通过从日志数据中提取特征进行压缩。 - **基于解析器分离：** LogZip [34] 和 RoughLogs [37] 通过构建模型识别冗余。CLP [50] 将日志解析为模式 (schemas)，将变量存储为字典和非字典。LogGrep [54] 利用静态和运行时模式将日志数据结构化为细粒度单元。 **Mint 指出，由于分布式追踪和日志在格式和结构上的显著差异 [52]，直接将日志压缩方法应用于追踪数据无法达到理想效果。** ## 3.3. 技术演进 分布式追踪技术从早期的全量收集 (如 Dapper) 发展到为了应对大规模数据量而引入的各种采样策略（头采样、尾采样、回溯采样）。这些采样策略的核心思想都是通过减少追踪的数量来降低开销。然而，所有这些采样方法都面临一个共同的挑战：如何在减少数据量的同时，不丢失关键的、非预期的分析所需信息。 Mint 的工作代表了这一领域的进一步演进。它认识到“1或0”的采样策略在实际应用中存在局限性，特别是在查询未采样追踪时的高未命中率。因此，Mint 提出了一种新的“共性 + 变异性”范式，旨在突破传统采样的限制，实现“所有请求捕获 (all requests capturing)”并保留“近乎完整 (near-full)”的追踪信息，同时大幅降低开销。这标志着从简单地“丢弃”数据到“智能地分解和聚合”数据的转变。 ## 3.4. 差异化分析 Mint 的方法与现有工作的核心区别和创新点在于： 1. **突破“1或0”采样范式：** 现有采样方法（OT-Head, OT-Tail, Hindsight, Sieve）无论如何优化采样规则，最终都将未采样的追踪完全丢弃。Mint 则通过“共性 + 变异性”范式，确保所有请求的基本信息都被保留，避免了查询未命中问题。对于未采样的追踪，Mint 提供近似信息 (approximate traces)，而不仅仅是“无结果”。 2. **两级粒度压缩：** - **与采样方法的区别：** Mint 不仅减少追踪数量（通过参数过滤），还通过模式聚合轻量化了每个追踪本身。这是现有采样方法所不具备的。 - **与日志压缩的区别：** Mint 充分利用了追踪数据的拓扑结构，在跨度间 (inter-span) 和追踪间 (inter-trace) 两个层面进行共性与变异性分析。这使得其压缩效率远高于不考虑拓扑结构的日志压缩器。 3. **代理端处理的深度与效果：** Mint 在代理端进行深度解析、模式提取和参数过滤，这比 Hindsight 仅上传“面包屑”更进一步，能够在源头大幅减少网络带宽和存储开销，而 OT-Tail 和 Sieve 等尾采样方法则无法降低网络开销。 4. **成本效益与信息保留的平衡：** Mint 在极大地降低了存储（2.7%）和网络（4.2%）开销的同时，能够捕获所有请求并保留更多的追踪信息，显著提升了下游根因分析的准确率，实现了更好的成本效益与信息保留之间的平衡。 # 4. 方法论 Mint 的核心思想是将其追踪开销缩减策略从传统的“1或0”采样范式转变为“共性 + 变异性”范式。该方法在代理端 (agent side) 对追踪数据进行深度处理，通过解析出共同模式 (common patterns) 和可变参数 (variable parameters)，然后聚合这些模式并智能地过滤参数，从而实现所有请求的捕获，同时显著降低存储和网络开销。 ## 4.1. 方法原理 Mint 的基本原理基于一个观察：分布式追踪数据中存在大量的重复结构（共性）和少量变化的细节（变异性）。通过识别并提取这些共性作为模式，可以大大减少存储冗余。而对于变异性部分，则可以根据其重要性进行选择性保留和过滤。 - **共性利用：** 将追踪的结构和固定内容抽象为模式，这些模式可以被多个追踪共享，只需存储一次。例如，相同的服务调用路径、相同的日志格式或 SQL 模板。 - **变异性利用：** 将追踪中动态变化的部分（如具体的数值、用户 ID、错误消息中的变量）识别为参数。这些参数可以被单独存储，并且可以根据采样策略进行选择性上报。 Mint 在代理端实现这一范式，意味着数据缩减发生在源头，从而同时优化网络带宽和后端存储。 ## 4.2. 核心方法详解 (Mint's Tracing Walkthrough) Mint 的工作流程分为六个主要步骤，如原文 Figure 5 所示。  *该图像是论文中图5的示意图，展示了Mint系统的追踪流程。整个流程包括生成原始Span、解析参数、模式识别与分组、周期性上传样本和参数，突出了Commonality与Variability分析在Agent端的实现过程。* Figure 5. An overview of Mint's tracing walkthrough. ### 4.2.1. (1) 追踪数据生成 (Trace Data Generating) 当一个带有追踪 ID (trace ID) 的请求通过一个应用程序节点 (application node) 时，Mint 的客户端 API (client API) 会生成追踪数据，即跨度 (spans)。与现有框架不同，Mint 不会立即记录或上报这些跨度，而是将其重定向到<strong>跨度解析器 (Span Parser)</strong>。 ### 4.2.2. (2) 跨度间级别解析 (Inter-Span Level Parsing) 跨度解析器分析跨度级别 (span level) 的共性 (commonality) 和变异性 (variability)，将传入的跨度解析为<strong>模式 (pattern)</strong> 和<strong>参数 (parameters)</strong>（如 Figure 5 中的蓝色和红色部分）。 - 解析出的模式会更新<strong>跨度模式库 (Span Pattern Library)</strong>，并编码成一个模式 ID (pattern ID)。 - 解析出的参数则暂时存储在代理端的<strong>参数缓冲区 (Params Buffer)</strong> 中。 这个解析过程本身又分为离线和在线两个阶段。 #### 4.2.2.1. 离线阶段：预热跨度解析器 (Offline Stage: Warming up Span Parser) 为了获得可接受的在线解析性能，Mint 首先在离线阶段对 Span Parser 进行构建和预热。这一阶段通过随机采样近期生成的 $m$ 个原始跨度（在实现中为 5,000 个）来完成。  *该图像是论文中图6所示的离线阶段示意图，展示了原始跨度的属性聚类、模式提取、属性解析器生成到跨度模式形成的流程。* Figure 6. The offline stage of span parser. Figure 6 展示了跨度解析器的离线构建过程。其核心思想是为跨度的每个属性 (attribute) 训练一个单独的解析器，然后将不同属性的模式组合成一个完整的跨度模式。 - <strong>集群与模式提取 (Clustering and pattern extracting):</strong> 由于不同属性具有不同的语义，Mint 为每个属性训练独立的解析器，以避免无意义的比较。模式提取根据数据类型进行： - **对于字符串值属性：** Mint 使用最长公共子序列 (Longest Common Subsequence, LCS) 来计算字符串值之间的相似度。给定两个字符串 `s _ { 1 }` 和 `s _ { 2 }`，其相似度 $\delta ( s _ { 1 } , s _ { 2 } )$ 计算如下： \delta ( s _ { 1 } , s _ { 2 } ) = \frac { | L C S ( s _ { 1 } , s _ { 2 } ) | } { \operatorname* { m a x } ( | s _ { 1 } | , | s _ { 2 } | ) } 其中： - $\delta ( s _ { 1 } , s _ { 2 } )$ 表示字符串 `s _ { 1 }` 和 `s _ { 2 }` 之间的相似度。 - `LCS ( s _ { 1 } , s _ { 2 } )` 表示字符串 `s _ { 1 }` 和 `s _ { 2 }` 的最长公共子序列。 - $| \cdot |$ 表示字符串序列中词元 (token) 的数量（在实现中，词元是单词）。 - $\operatorname* { m a x } ( | s _ { 1 } | , | s _ { 2 } | )$ 表示 `s _ { 1 }` 和 `s _ { 2 }` 中词元数量的最大值。 对于采样跨度中相同字符串类型属性的所有可能值，Mint 将相似度高于某个阈值（在实现中为 0.8）的值聚类成集合 $C = \{ C _ { 0 } , . . . , C _ { n } \}$。对于每个聚类 `C _ { i }`，Mint 提取能够表示该聚类中所有字符串的最短正则表达式，作为该聚类的模式 `P _ { i }`。 - **对于数值属性：** Mint 采用基于指数区间的分桶方法 (bucketing approach)。首先选择一个精度参数 $\alpha$（在实现中为 0.5）。对于每个数值 $d$，它被存储在桶 `B _ { i }` 中，其中索引 $i$ 的计算方式为： i = \left\lceil \log _ { \gamma } ( d ) \right\rceil 其中： - $i$ 是数值 $d$ 所属桶的索引。 - $\lceil \cdot \rceil$ 是向上取整函数。 - $\gamma$ 是用于定义指数区间范围的基数，其计算方式为： \gamma = \frac { 1 + \alpha } { 1 - \alpha } - $\alpha$ 是精度参数。 通过这种方法，数值被聚类到桶 $B = \{ B _ { 0 } , . . . , B _ { n } \}$ 中。每个桶 `B _ { i }` 由一个区间模式 $( { \mathrm { l o w e r } } _ { i } , { \mathrm { u p p e r } } _ { i } ]$ 表示。例如，桶 `B _ { 0 }` 包含 `(0, 1]` 范围内的值。 - <strong>解析器构建 (Parsers building):</strong> 完成上述步骤后，Mint 为每个属性 `A _ { i }` 提取了一系列模式 $P = \{ P _ { 1 } , . . . , P _ { n } \}$，并使用这些模式构建了一个解析器 $\mathcal { P } _ { i }$： - 对于数值属性，$\mathcal { P } _ { i }$ 是一个固定的映射公式 $i = \lceil \log _ { \gamma } ( x ) \rceil$，用于确定每个解析值 $d$ 对应的模式。 - 对于字符串属性，Mint 使用一个前缀树 (prefix tree) 来存储所有模式（即正则表达式）。由于不同模式可以共享多个前缀词元 (prefix tokens)，它们的路径可能重叠，这有助于减少模式的存储开销并提高在线阶段的匹配效率。 - <strong>模式组合 (Patterns combination):</strong> Mint 将同时出现的不同属性的模式组合起来，形成一个<strong>跨度模式 (span pattern)</strong>，并为其分配一个模式 ID（在实现中生成一个 UUID 作为模式 ID）。例如，如果一个跨度有两个属性 `A _ { 1 }` 和 `A _ { 2 }`，且 `A _ { 1 }` 的模式 `P _ { 11 }` 总是与 `A _ { 2 }` 的模式 `P _ { 23 }` 同时出现，则 `SP = [ P _ { 11 } , P _ { 23 } ]` 就是一个跨度模式。Mint 将这些跨度模式存储在<strong>模式库 (Pattern Library)</strong> 中。 #### 4.2.2.2. 在线阶段：匹配与解析 (Online Stage: Matching and Parsing) 当 Mint 被用于系统追踪时，它会对新生成的原始跨度执行在线解析。  *该图像是图7，展示了跨度解析器的在线阶段示意图，说明了原始跨度经过属性解析器生成属性向量，再与模式库进行匹配、解析及更新，最终输出模式ID和参数。* Figure 7. The online stage of span parser. Figure 7 展示了跨度解析器的在线阶段。 - <strong>分层属性解析 (Hierarchical attribute parsing, HAP):</strong> HAP 是在线解析过程的核心。Mint 并行解析传入跨度的每个属性： 1. 使用相应的属性解析器（通过在前缀树上搜索或通过映射公式计算）查找匹配的模式。 2. 将匹配的模式作为<strong>共同部分 (common part)</strong>，并根据该模式提取<strong>可变部分 (variable part)</strong>。对于字符串属性，变量使用正则表达式提取；对于数值属性，计算与区间下限的差值。 如果在在线阶段出现新的跨度模式（例如，由于系统变更），相应的解析器会自动更新以包含新模式。HAP 过程具有高度并行性，以满足在线阶段对低延迟的要求，因为不同的属性解析器独立运行。 - <strong>跨度模式映射 (Span pattern mapping):</strong> 解析完传入跨度的每个属性后，Mint 组合这些解析出的属性模式，并与模式库中的跨度模式进行匹配。如果找到一致的模式，则返回相应的模式 ID。如果未找到，则将新模式添加到模式库并分配新的模式 ID，从而使模式库能够根据最新数据进行更新。 通过上述步骤，Mint 将原始跨度解析为模式和参数。模式被聚合并存储在模式库中，而参数则暂时存储在参数缓冲区中，直到它们被传输或丢弃。 ### 4.2.3. (3) 追踪间级别解析 (Inter-Trace Level Parsing) 在跨度解析完成后，Mint 代理会根据跨度之间的父子关系（如 Figure 4 所示的 `parent ID`）将具有相同追踪 ID 的跨度链接起来，形成一个<strong>子追踪 (sub-trace)</strong>。一个子追踪代表了请求在同一节点上的追踪片段。  *该图像是论文中的示意图，展示了Mint框架如何通过子追踪模式存储追踪的拓扑信息，并利用布隆过滤器高效存储每个子追踪模式的元数据。* Figure 8. Mint uses a sub-trace pattern to store the topology information of a sub-trace. It also uses a Bloom Filter to efficiently store the trace metadata for each sub-trace pattern. - <strong>模式提取 (Pattern extracting):</strong> 对于传入的子追踪，Mint 会将其拓扑信息编码成一个向量，该向量捕获了子追踪中跨度的顺序和层级关系，作为其模式。每个维度代表一个父子关系。例如，对于 Figure 8 中的子追踪，其编码向量可以是 $[b1e6 -> {ek35, mx7v}], [ek35 -> {p8sz}]$。需要注意的是，子追踪模式中的每个元素都是一个<strong>跨度模式 ID (span pattern ID)</strong>，它对应着一个跨度模式。这意味着子追踪模式不仅包含拓扑信息，还包含了跨度内容的模式信息。 - <strong>匹配或更新 (Matching or updating):</strong> 对于传入子追踪的模式，Mint 会在<strong>拓扑模式库 (Topo Pattern Library)</strong> 中搜索精确匹配。如果找到匹配项，则将其用作匹配模式。如果未找到，则将该模式添加到拓扑模式库中作为匹配模式。通过聚合模式，具有相同拓扑模式的追踪数据只需要存储一次其拓扑信息。 - <strong>元数据挂载 (Metadata Mounting):</strong> 在查询时，用户通常通过追踪元数据（例如，追踪 ID）来请求追踪信息。因此，需要记录追踪元数据与其关联模式之间的匹配关系。Mint 为每个子追踪模式附加一个<strong>布隆过滤器 (Bloom Filter)</strong>，用于存储属于该模式的所有追踪的元数据，如 Figure 8 右侧所示。 布隆过滤器是一种基于二进制压缩的、空间效率高且具有概率特性的数据结构，用于测试一个元素是否是集合的成员。通过使用布隆过滤器，Mint 可以以较低的存储成本和较高的查询效率确定一个追踪属于哪些模式。虽然布隆过滤器可能错误地指示一个追踪属于某个模式（假阳性），但它绝不会遗漏实际属于该模式的追踪（无假阴性），从而确保了追踪的连贯性 (trace coherence)。布隆过滤器的假阳性问题可以通过多个代理之间的上游-下游验证来缓解。 ### 4.2.4. (4) 基本信息上传 (Basic Information Uploading) 通过上述两个级别的解析，Mint 将追踪数据分为三部分存储在代理端： 1. 存储在<strong>模式库 (Pattern Library)</strong> 中的跨度模式和子追踪模式。 2. 存储在布隆过滤器中并挂载在相应子追踪模式上的、用于检索的追踪元数据。 3. 暂时存储在<strong>参数缓冲区 (Param Buffer)</strong> 中的可变参数。 Mint 的核心设计原则之一是避免完全丢弃任何追踪，这与“1或0”范式不同。因此，Mint 代理会定期将完整的模式库和布隆过滤器上传到后端。这确保了用户可以查询和检索每个追踪的信息，而不会遗漏任何一个。由于广泛存在的共性，数百万个追踪通常只有数百个模式。因此，存储模式的成本显著低于存储原始追踪数据（在实验中约为 0.5%）。 ### 4.2.5. (5) 关键追踪采样 (Key Traces Sampling) 对于可变参数，Mint 根据其关联追踪的重要性来决定是否将其发送到后端。如果一个追踪被标记为已采样 (sampled)，Mint 会将分布在不同节点上的所有该追踪的可变参数发送到后端。这样，Mint 后端就可以利用参数和模式来重建已采样追踪的完整信息。 Mint 兼容现有的采样规则。用户可以通过在请求生成时随机标记一些追踪为已采样来采用头采样。或者，他们可以最初将所有追踪标记为已采样，并在后端进行过滤以实现尾采样。 此外，Mint 还提供了为“共性 + 变异性”范式设计的两个采样器，提供了更全面的采样。与回溯采样 [60] 类似，Mint 的采样器在代理端执行偏向采样 (biased sampling)。然而，Mint 更进一步，不仅针对有症状的追踪 (symptomatic traces)，还针对具有罕见执行路径的追踪。这些采样器的设计细节将在 4.4 节中介绍。 ### 4.2.6. (6) 参数上传 (Parameters Uploading) 一旦一个追踪在某个代理上被标记为已采样，该追踪分布在不同代理上的所有参数都会通过代理间的通信发送到后端，从而确保追踪的连贯性。 ## 4.3. Mint 实施架构 (Mint Implementation Architecture) Mint 由几个组件组成，包括部署在应用程序主机上的多个 **mint-agent** 和 **mint-collector**，以及一个带有分布式追踪存储引擎的统一 **mint-backend** 和用于查询及可视化的<strong>前端 (frontend)</strong>。Figure 9 展示了 Mint 的实现架构。  *该图像是图9，展示了Mint的实现及其用于捕获和查询追踪的系统架构示意图，描述了从应用服务到Mint-agent，再到Mint-backend的流程及数据处理方式。* Figure 9. Implementation of Mint and use Mint to capture and query for traces. ### 4.3.1. Mint Agent (mint-agent) mint-agent 使用 Java 实现，代码量约 2.5 KLOC。它支持多种追踪协议（例如 OpenTelemetry [43]、Zipkin [1] 和 Jaeger [24]），因为 Mint 后续的解析操作与原始追踪数据生成解耦。 - <strong>模式库 (Pattern Library):</strong> 每个 mint-agent 在共享内存中分配和维护一个模式库，用于存储追踪模式和存储在布隆过滤器中的元数据。当系统稳定时，跨度和拓扑模式的数量会收敛，因此模式存储空间不会无限增长。当系统发生变化时，开发者可以通过 Mint 的重建接口 (reconstruct interface) 重建模式。 布隆过滤器会随着追踪数量的增长而增长，因此 Mint 为每个布隆过滤器预分配了一个固定大小的缓冲区（默认为 4 KB）。当缓冲区满时，布隆过滤器会被上报并重置。Mint 使用 Guava 库 [19] 实现布隆过滤器，默认将 `falsePositiveProbability` 参数设置为 0.01。 - <strong>参数缓冲区 (Params Buffer):</strong> mint-agent 在共享内存中保留一个固定大小的缓冲区（默认为 4 MB），用于暂时存储追踪参数。参数缓冲区作为一个 FIFO 队列运行，具有相同追踪 ID 的参数被分组到一个块中。新生成的追踪参数块被添加到队列末尾。当缓冲区满时，队列头部的块会被弹出。 ### 4.3.2. Mint Collector (mint-collector) mint-collector 使用 Java 实现，代码量约 0.8 KLOC。 - 它定期（默认每 1 分钟）上报模式库中的模式。 - 布隆过滤器一旦达到其大小限制（平均每 1.2 秒），就会立即上报。 - 对于存储在参数缓冲区中的参数，Mint 使用为“共性 + 变异性”范式设计的两个采样器来过滤并决定是否采样一个追踪（也可以适应其他采样规则，如头采样或尾采样）。 - 一旦一个追踪在代理端被标记为已采样，Mint 会通过后端通知所有主机上的收集器，检查并上报该追踪的所有参数，确保追踪连贯性。 #### 4.3.2.1. 症状采样器 (Symptom Sampler) 症状采样器通过监控参数缓冲区中的可变参数并采样异常值来针对有症状的追踪。 - **数值参数：** 采样超出 95 百分位 (P95) 的异常值。 - **字符串参数：** 采样包含异常词语的值，异常词语列表由用户定义。 #### 4.3.2.2. 边缘案例采样器 (Edge-Case Sampler) 边缘案例采样器针对具有罕见执行路径的追踪。它监控模式库中的拓扑模式 (topology patterns)，以跟踪与每个拓扑模式匹配的追踪数量，从而提高不常见追踪的采样概率。例如，如果 99% 的追踪遵循模式 A，而 1% 的追踪遵循模式 B，则边缘案例采样器会优先采样遵循模式 B 的追踪。 ### 4.3.3. Mint Backend and Querier (mint-backend 和 Querier) Mint 后端使用分布式追踪存储引擎和查询器实现。分布式追踪存储引擎支持并行和大规模存储以及查询上报的追踪数据。为了使 Mint 的存储引擎与现有追踪框架兼容，Mint 将模式数据（即近似追踪）和参数的数据格式设计得与传统追踪相似，并且这种存储方法在查询时不需要解压缩。 #### 4.3.3.1. 查询逻辑 (Query Logic) 当用户使用追踪元数据（例如追踪 ID）向 Mint 查询追踪信息时： 1. Mint 首先检查每个布隆过滤器中是否存在追踪的元数据。 2. 如果找到，则表明与该布隆过滤器对应的模式是该追踪的一个片段（即子追踪）。 3. Mint 根据不同片段的开始和结束操作之间的匹配关系，将这些子追踪重建成一个完整的<strong>近似追踪 (approximate trace)</strong>。 4. 如果该追踪被标记为未采样，查询器直接返回近似追踪。 5. 如果该追踪被标记为已采样，则近似追踪的精确参数已被发送到后端。使用这些参数和近似追踪，可以重建并返回查询追踪的精确信息。 Figure 10 展示了一个查询未采样追踪以获取近似追踪的示例。变量被 $^•<*^•$ 掩码，数字被分桶映射。  *该图像是论文中的界面截图示意图，展示了一个分布式追踪系统的Trace详情，包括Trace ID、时间、总响应时长及各组件调用的时间线和细节信息，如HTTP方法和参数，数值采用分桶映射且变量部分被掩码处理。* Figure 10. An example of querying an unsampled trace to get an approximate trace, variables are masked by $^ \bullet < ^ { \ast } > ^ { \bullet }$ and numbers are bucket-mapped. # 5. 实验设置 作者通过实验评估了 Mint 的有效性、效率和可伸缩性，主要关注以下研究问题： - Mint 在减少追踪数据方面有多有效？ - Mint 在保留更多追踪信息（所有请求捕获）方面有多有效？ - Mint 的共性与变异性分析对追踪压缩的贡献有多大？ - Mint 的性能和可伸缩性如何？ ## 5.1. 数据集 实验使用了三套分布式系统：两个开源微服务基准 (benchmark) 和一个来自阿里巴巴的真实生产微服务系统。 - **OnlineBoutique (OB) [18]:** 一个基于 Web 的电子商务应用程序，包含 10 个用各种编程语言实现的微服务，通过 gRPC 进行通信。 - **TrainTicket (TT) [14]:** 提供铁路票务服务的系统，涉及 45 个服务，通过同步 REST 调用和异步消息传递进行通信。 - **部署环境：** OnlineBoutique 和 TrainTicket 应用程序部署在一个拥有 12 台虚拟机 (VM) 的 Kubernetes 平台。每台 VM 配备 8 核 2.10GHz CPU，16GB 内存，运行 Ubuntu 18.04。 - **阿里巴巴生产微服务系统：** 包含 Web 服务、MongoDB [39] 访问和 MySQL [40] 访问。用于评估 Mint 在生产环境下的开销和可伸缩性。 - **阿里巴巴数据集用于压缩比评估：** 选择了阿里巴巴的 6 个子系统，生成真实世界的追踪数据，每个子系统具有不同的 API 数量和调用深度。这些数据集的详细描述如原文 Figure 13 所示。  *该图像是图表，展示了阿里巴巴六个数据集的基本信息及不同数据集的API分布情况。左侧为表格，列出了每个数据集的追踪数、API数量及平均深度；右侧为雷达图，呈现各数据集中八个API的调用分布。* Figure 13. Description of 6 datasets in Alibaba. ## 5.2. 评估指标 对论文中出现的每一个评估指标，进行以下说明： 1. <strong>网络开销 (Network Overhead):</strong> - **概念定义：** 衡量在追踪过程中，应用程序节点与追踪后端之间传输追踪数据所消耗的网络带宽。较低的网络开销意味着更少的网络资源占用和潜在的更高吞吐量。 - **数学公式：** 该指标通常直接以每单位时间的数据量来衡量。例如，MB/min。 \text{网络开销} = \frac{\text{传输数据总量}}{\text{时间}} - **符号解释：** - $\text{传输数据总量}$: 在特定时间内从应用程序节点传输到追踪后端的所有追踪数据的总字节数或兆字节数。 - $\text{时间}$: 测量网络传输的持续时间。 2. <strong>存储开销 (Storage Overhead):</strong> - **概念定义：** 衡量追踪数据最终存储在持久化存储设备（如 Elasticsearch）中所占用的空间大小。较低的存储开销直接影响到数据存储成本。 - **数学公式：** 该指标通常以总数据量来衡量，例如 GB 或 PB。 \text{存储开销} = \text{存储在后端的数据总量} - **符号解释：** - $\text{存储在后端的数据总量}$: 在追踪后端持久化存储的所有追踪数据的总字节数、千兆字节数 (GB) 或拍字节数 (PB)。 3. <strong>查询响应能力 (Query Response Ability):</strong> - **概念定义：** 评估追踪框架对用户查询的响应能力。分为三种情况： - <strong>精确命中 (Exact Hit):</strong> 框架能够返回所查询追踪的完整信息。 - <strong>部分命中 (Partial Hit):</strong> 框架能够返回所查询追踪的近似信息（例如，拓扑结构和模式，但缺少详细参数）。 - <strong>未命中 (Miss):</strong> 框架完全无法返回任何有关所查询追踪的信息。 - **数学公式：** 通常以命中数量或命中率（占总查询数的百分比）来表示。 \text{命中率} = \frac{\text{命中数量}}{\text{总查询数量}} \times 100% - **符号解释：** - $\text{命中数量}$: 某一特定类型的命中（精确命中或部分命中）的总数。 - $\text{总查询数量}$: 用户发起的查询总数。 4. <strong>下游分析的有效性 (Effectiveness for Downstream Analysis) / Top-1 准确率 (Top-1 Accuracy, A@1):</strong> - **概念定义：** 衡量追踪框架所捕获和保留的追踪数据对于后续的根因分析 (Root Cause Analysis, RCA) 任务的价值。Top-1 准确率特指在故障诊断中，根因分析方法将实际根因排在预测列表第一位的比例。 - **数学公式：** A@1 = \frac{\text{正确识别的根因数量}}{\text{总故障数量}} - **符号解释：** - `A@1`: Top-1 准确率，表示根因分析方法在多大程度上能够将实际根因作为其首要预测。 - $\text{正确识别的根因数量}$: 根因分析方法成功地将其预测的第一个根因与真实根因匹配的故障实例数量。 - $\text{总故障数量}$: 进行评估的故障实例总数。 5. <strong>计算开销 (Computational Overhead):</strong> - **概念定义：** 衡量追踪框架在应用程序节点上运行时所消耗的 CPU 资源。通常表示为 CPU 使用率的增加百分比。 - **数学公式：** \text{CPU 使用率增加} = \frac{\text{启用追踪时的 CPU 使用率} - \text{无追踪时的 CPU 使用率}}{\text{无追踪时的 CPU 使用率}} \times 100% - **符号解释：** - $\text{启用追踪时的 CPU 使用率}$: 应用程序启用追踪框架时所监测到的 CPU 使用率。 - $\text{无追踪时的 CPU 使用率}$: 应用程序未启用任何追踪框架时所监测到的基线 CPU 使用率。 6. <strong>延迟 (Latency):</strong> - **概念定义：** 衡量追踪框架对系统请求处理时间的影响，包括端到端请求延迟 (end-to-end request latency) 和追踪数据查询延迟 (query latency)。 - **数学公式：** \text{延迟增加} = \frac{\text{启用追踪时的延迟} - \text{无追踪时的延迟}}{\text{无追踪时的延迟}} \times 100% - **符号解释：** - $\text{启用追踪时的延迟}$: 启用追踪框架时，请求或查询的响应时间。 - $\text{无追踪时的延迟}$: 未启用任何追踪框架时，请求或查询的基线响应时间。 - 通常还会报告 P95（第 95 百分位）延迟，以衡量最慢的 5% 请求的性能。 7. <strong>压缩比 (Compression Ratio):</strong> - **概念定义：** 衡量 Mint 或其他压缩工具在不损失信息或在可接受范围内减少信息后的数据量。它是原始数据大小与压缩后数据大小的比值。 - **数学公式：** \text{压缩比} = \frac{\text{原始数据大小}}{\text{压缩后数据大小}} $$ - 符号解释： - $\text{原始数据大小}$: 压缩前的数据总大小。 - $\text{压缩后数据大小}$: 经过压缩处理后的数据总大小。 - 更高的压缩比表示更有效的数据缩减。

5.3. 对比基线

为了评估 Mint 的有效性和性能，论文将其与多种基线方法进行了比较：

1. OpenTelemetry under head-sampling (OT-Head) [48]:

   • 描述： 使用 OpenTelemetry 代理对所有基准应用程序进行插桩 (instrumentation)，并通过 OpenTelemetry Collector 收集追踪数据，存储在 Grafana Tempo 和 Elasticsearch [11] 中。头采样率设置为 5%。
   • 代表性： 是当前业界广泛采用的追踪数据收集和采样策略。

2. OpenTelemetry under tail-sampling (OT-Tail) [44]:

   • 描述： OpenTelemetry 的尾采样策略作为一个用户定义的过滤器。为了确保有效性，所有注入基准中的异常请求都被标记为 is_abnormal，允许尾采样根据此标签进行过滤。
   • 代表性： 另一种主流的采样策略，旨在保留有价值的异常追踪。

3. Hindsight [60]:

   • 描述： 一个实现回溯采样 (retroactive sampling) 的追踪框架。由于 Hindsight 与 OpenTelemetry 兼容，实验在每个应用程序节点上配置 OpenTelemetry 代理与 Hindsight 触发器。使用 Hindsight 论文中指定的默认参数和配置。
   • 代表性： 近年来提出的先进采样方法，旨在平衡网络开销和信息保留。

4. Sieve [23]:

   • 描述： 一种在线尾采样方法，使用鲁棒随机切割森林 (robust random cut forest, RRCF) 来采样不常见的追踪。通过 OpenTelemetry 代理和收集器生成追踪，并将其重定向到 Sieve 采样器进行过滤和保留。
   • 代表性： 针对不常见追踪的智能采样方法。

5. OpenTelemetry with 100% sampling rate (OT-Full):

   • 描述： OpenTelemetry 代理和收集器以 100% 的采样率收集所有追踪数据。
   • 代表性： 作为不进行任何追踪数据缩减的参考基线，用于衡量其他方法的缩减效果。

6. 日志专用压缩器 (Log-specific compressors):

   • 描述： 用于评估 Mint 无损压缩能力的基线，包括 LogZip [33]、LogReducer [55] 和 CLP [50]。这些工具也基于数据特性消除冗余。

   • 代表性： 现有的、与追踪数据有一定相似性的数据（日志）的压缩方法。

     为了确保实验的公平性：

• 在评估追踪数据缩减有效性时，所有基准中的 5% 流量都被注入 is_abnormal 标签，所有偏向采样 (biased sampling) 方法都基于此字段进行采样，以确保每个追踪系统捕获一致数量的追踪。
• 在评估保留追踪信息有效性时，将追踪缩减预算设置为 5%，即每个框架最终保存的追踪数据量是原始大小的 5%。

6. 实验结果与分析

6.1. 核心结果分析

6.1.1. 追踪数据缩减的有效性 (Effectiveness in Reducing Trace Data)

该实验评估了 Mint 在减少追踪数据方面的有效性，通过测量 Mint 和四个基线追踪框架在 OnlineBoutique 和 TrainTicket 基准上的网络 (network) 和存储 (storage) 开销。OT-Full (100% 采样率的 OpenTelemetry) 作为无追踪缩减的参考。

该图像是图表，展示了图11中OnlineBoutique和TrainTicket两个基准下不同 tracing 方法的网络及存储开销随请求吞吐量的变化情况，比较了 OT-Full、OT-Head、OT-Tail、Sieve 和 Insight 几种方案的性能。

Figure 11. Tracing network and storage overhead on OnlineBoutique and TrainTicket Benchmarks.

Figure 11 展示了实验结果。可以看出，与基线方法相比，Mint 在网络和存储两方面都显著减少了追踪开销。

• OT-Head (OpenTelemetry with head-sampling): 头采样在追踪生命周期开始时随机选择并保留采样的追踪。因此，其网络和存储开销相对 OT-Full 减少到采样率的比例（5%）。
• OT-Tail (OpenTelemetry with tail-sampling) & Sieve: 尾采样在后端决定并移除未采样的追踪。因此，它无法减少网络开销，与 OT-Full 相似，但可以将存储开销减少到与异常率大致相同的水平。
• Hindsight: Hindsight 在代理端早期执行偏向采样，从而减少了网络和存储开销。然而，由于需要传输“面包屑 (breadcrumbs)”，其网络开销略高于头采样。
• Mint: Mint 在代理端进行追踪缩减，从而降低了网络和存储开销。此外，Mint 通过基于共性进行压缩，进一步优化了追踪存储，减少了追踪数据量。
  • 结果： 平均而言，Mint 将存储开销减少到 2.7%，将网络开销减少到 4.2%。这表明 Mint 在数据缩减方面具有卓越的性能。

6.1.2. 保留更多追踪信息的有效性 (Effectiveness in Retaining More Trace Information)

该实验旨在证明 Mint 能够在捕获所有请求并保留更多追踪信息的同时，与现有追踪框架在相同数据量下进行比较。通过两个方面衡量保留追踪信息的质量：查询响应能力和追踪数据的分析价值。为了公平比较，所有追踪框架保存的追踪数据量都被控制在原始大小的 5%。

6.1.2.1. 查询响应能力 (Query Response Ability)

实验通过随机选择阿里巴巴三个子系统，连续监控 14 天。使用 OpenTelemetry 收集所有请求数据，并将其重定向到 Mint 和四个基线框架进行处理。同时，记录用户每天查询的追踪 ID，并对这些查询应用到各个框架。

• 精确命中 (exact hit): 返回查询追踪的完整信息。

• 部分命中 (partial hit): 返回查询追踪的近似信息。

• 未命中 (miss): 未返回任何信息。

  该图像是图表，展示了阿里巴巴用户查询的命中次数在14天内的变化，表明Mint能响应所有请求，涵盖不同种类命中数及总命中数的趋势。

Figure 12. Hit number for user queries in Alibaba during 14 days, demonstrating Mint can respond to all requests.

Figure 12 展示了实验期间每个追踪框架响应查询的命中次数。红色虚线“Total”代表该期间每天的用户查询总数。

• 结果： 在考虑部分命中 (partial hits) 时，Mint 响应了所有查询，这意味着它能为每个追踪提供至少近似的信息。
• 在仅考虑精确命中 (exact hits) 时，Mint 仍然优于所有基线方法，响应了更多的查询。 这强有力地证明了 Mint 在“所有请求捕获”方面的能力，即使对于未采样追踪，也能提供有价值的信息，解决了传统“1或0”策略的查询未命中问题。

6.1.2.2. 下游分析的有效性 (Effectiveness for downstream analysis)

为了模拟真实世界的微服务问题分析，在 OnlineBoutique 和 TrainTicket 基准上进行了混沌工程 (chaos engineering)，注入了 56 个故障（故障类型如原文 Table 2 所示）。然后，将 Mint 和四个基线部署在基准微服务上捕获追踪数据，并使用三个经典的基于追踪的根因分析 (RCA) 方法（MicroRank [57]、TraceRCA [30]、TraceAnomaly [35]）进行分析，计算分析结果的 Top-1 准确率 (A@1)。

以下是原文 Table 2 的内容：

以下是原文 Table 3 的内容：

Table 3. Comparison of the effects of different tracing frameworks in downstream root cause analysis's accuracy.

Table 3 展示了不同追踪框架和 RCA 方法组合下的 A@1 结果。

• 结果： Mint 显著提高了下游根因分析的准确率，与基线方法相比，平均准确率从约 25% 提高到约 50%。
  • 分析： MicroRank [57] 和 TraceRCA [30] 需要足够数量的常见追踪 (common-case traces) 来进行谱分析 (spectrum analysis) 以识别根因。TraceAnomaly [35] 通过将异常追踪与正常模板进行比较来定位根因，这也需要足够的常见追踪来建立正常模板。
  • 传统的“1或0”采样策略完全丢弃了常见追踪，严重削弱了这些 RCA 方法的性能，导致 A@1 低于 38%。
  • Mint 采用“共性 + 变异性”方法，在相同追踪存储大小下，保留了所有追踪的基本信息和边缘案例的详细信息，从而全面提升了 RCA 方法的性能。

6.1.3. Commonality and Variability 分析的贡献 (Contribution of Commonality and Variability Analysis)

该实验旨在评估 Mint 的无损压缩能力，并与日志专用压缩工具进行比较。强调追踪压缩需要压缩后的数据可以直接用于检索和查询，无需解压缩。通用压缩工具不适用于此场景。

以下是原文 Table 4 的内容：

Table 4. Comparison in terms of Compression Ratio.

Table 4 展示了在六个数据集上五种方法的压缩比。

• 结果： Mint 在压缩比方面平均优于两个基线日志压缩方法 14.90 到 28.38。这表明 Mint 更有效地考虑了追踪数据独特的拓扑结构，实现了更高的压缩性能。
• 消融研究 (Ablation Study): 为了单独评估 Mint 在两个层面（跨度间和追踪间）的有效性，设计了两个变体：
  • w/o Sp (Mint without inter-span level parsing): 没有跨度间级别解析的 Mint。
  • w/o Tp (Mint without inter-trace level parsing): 没有追踪间级别解析的 Mint。
  • 结果： Mint 显著优于其两个消融变体，压缩比平均提高了 8.45 到 26.45。这证明了跨度间和追踪间两个级别的解析都对追踪压缩有贡献。

6.1.4. Mint 开销与可伸缩性 (Mint Overhead and Scalability)

6.1.4.1. 端到端追踪开销 (End-to-End Tracing Overhead)

为了验证 Mint 的实用性，在阿里巴巴的生产微服务系统上进行了评估。创建了三个相同的副本，分别安装了 Mint、OpenTelemetry (头采样) 或无追踪框架。控制 Mint 和 OpenTelemetry 的采样率均为 10%。进行了 14 次负载测试，以评估不同请求吞吐量和 API 请求下的性能。

该图像是图表，展示了阿里巴巴生产微服务系统在14次负载测试中的追踪开销，包括入口和出口网络带宽、CPU使用率及内存使用情况，比较了No-Tracing、OT-Head和Mint三种方案的性能差异。

Figure 14. Tracing overhead during 14 load tests on Alibaba's production microservices system.

Figure 14 展示了实验结果。

• Figure 14 (a) 表明在 14 次测试中，所有三个副本接收到的流量相同。
• Figure 14 (b) 表明 Mint 通过压缩有效减少了追踪数据流量，出口网络带宽仅增加了 2.88%（与无追踪相比）。相比之下，OT-Head 增加了 19.35%。
• Figure 14 (c) 显示 Mint 在追踪期间的计算开销是可接受的，平均 CPU 使用率比无追踪增加了 0.86%，比 OT-Head 少了 0.39%。
• Figure 14 (d) 表明 Mint 的存储开销也同样可接受，与 OT-Head 相似，平均比无追踪增加了 1.8%。
• 结论： Mint 的计算、网络和存储开销在生产环境中都是可接受的。

6.1.4.2. 延迟 (Latency)

评估了使用 Mint 进行追踪对端到端请求延迟和查询追踪延迟的影响。

该图像是图表，展示了阿里巴巴生产微服务系统中端到端请求延迟和查询延迟的对比情况。左图(a)表现不同方案下请求延迟的时间变化，右图(b)显示了查询延迟在不同日期的波动。数据分别用于验证No-Tracing、OT-Head和Mint三种方案的性能。

Figure 15. End-to-End request latency and query latency on Alibaba's production microservices system.

Figure 15 (a) 显示，对于不同类型的请求，使用 Mint 使请求延迟平均增加了 0.21%，这是完全可接受的。 Figure 15 (b) 表明，使用 Mint 进行查询平均比使用 OpenTelemetry 多花费 4.2% 的时间，但 P95 延迟低于 1 秒，满足生产环境要求。

6.1.4.3. 模式提取性能 (Pattern extraction performance)

为了测试跨度解析器 (Span Parser) 和追踪解析器 (Trace Parser) 的模式提取能力，收集了阿里巴巴云五个子系统在一小时内生成的原始追踪数据，并记录了提取的模式数量。

以下是原文 Table 5 的内容：

Table 5. Pattern extraction results of Span Parser and Trace Parser on 5 sub-services in Alibaba Cloud.

Table 5 显示，Span Parser 和 Trace Parser 都有效地从不同子系统的追踪数据中聚合了模式。

• 结果： 从原始日志数量到跨度级别模式的压缩比范围为 6,681 到 13,362。
• 从原始日志数量到追踪级别模式的压缩比范围为 15,780 到 30,842。 这表明模式提取组件在识别和聚合共性方面表现出色，为整体数据缩减奠定了基础。

6.2. 消融实验/参数分析

6.2.1. 参数敏感性 (Parameter Sensitivity)

Mint 的主要参数是跨度解析器 (Span Parser) 中的相似度阈值 (similarity threshold)。较高的阈值会导致更多的模式但更少的参数。实验使用了阿里巴巴两个子服务的原始追踪数据，设置相似度阈值为 0.2、0.4、0.6 和 0.8，以探索其对模式和参数总存储大小（未采样和压缩）的影响。

该图像是一个折线图，展示了图16中在相似度阈值为0.2、0.4、0.6和0.8时，两个子服务的模式和参数总存储大小随阈值变化的趋势。

Figure 16. The total storage size of patterns and parameters with the similarity threshold at 0.2, 0.4, 0.6, and 0.8.

Figure 16 显示，随着相似度阈值的增加，模式和参数的总存储大小会减小。

• 分析： 过高的相似度阈值会减少同一模式内跨度之间的差异，从而削弱参数提取的有效性。
• 默认设置： 考虑到总存储大小和参数提取有效性，Mint 将默认相似度阈值设置为 0.8。在大多数情况下，默认设置会产生令人满意的结果。

6.2.2. 消融实验 (Ablation Study)

在 6.1.3 节中，对 Mint 的消融研究（w/o Sp 和 w/o Tp）已经证明，跨度间级别解析和追踪间级别解析都对追踪压缩贡献显著。

• w/o Sp：表示 Mint 在没有进行跨度间级别解析（即没有将跨度内容抽象为模式和参数）时的性能。
• w/o Tp：表示 Mint 在没有进行追踪间级别解析（即没有对子追踪拓扑进行模式化）时的性能。 实验结果（Table 4）显示，完全版本的 Mint 在压缩比上显著优于这两个变体，平均提高了 8.45 到 26.45。这进一步验证了 Mint 的两级“共性 + 变异性”分析是其高效压缩的关键。

7. 总结与思考

7.1. 结论总结

本文提出了一种创新的“共性 + 变异性”范式用于分布式追踪数据缩减，并设计实现了成本高效的追踪框架 Mint。Mint 的核心在于其在代理端对追踪数据进行双层解析：

1. 跨度间级别解析： 将单个跨度分解为共同模式和可变参数。
2. 追踪间级别解析： 对子追踪的拓扑结构进行模式化，并利用布隆过滤器挂载追踪元数据。 通过聚合模式和智能过滤参数，Mint 实现了所有请求的捕获，并能够保留近乎完整的追踪信息。

实验结果强有力地证明了 Mint 的有效性：

• 显著降低了追踪开销：存储开销平均减少到 2.7%，网络开销平均减少到 4.2%。
• 提升了信息保留能力：即使对于未采样的追踪也能提供近似信息，解决了传统采样策略导致的查询未命中问题。
• 增强了下游分析效果：将根因分析 (RCA) 方法的 Top-1 准确率平均提高了 25% 至 50%。
• 轻量化和可伸缩：在生产环境部署中，Mint 引入的计算开销（CPU 增加 0.86%）和延迟增加（请求延迟增加 0.21%）均在可接受范围内。 Mint 已在阿里巴巴的大型云提供商环境中成功部署，用户反馈表明它显著改善了用户体验并促进了深入分析。

7.2. 局限性与未来工作

论文中指出了 Mint 的一些局限性，并暗示了可能的改进方向：

1. 布隆过滤器 (Bloom Filter) 的假阳性 (False Positives)： 布隆过滤器存在假阳性，即可能错误地指示一个追踪属于某个模式。虽然论文提到可以通过“多个代理之间的上游-下游验证 (upstream-downstream verification)”来缓解，但具体如何实施以及其对整体性能和复杂性的影响并未详述。
2. 模式重建 (Pattern Reconstruction)： 当系统发生变更时，旧的模式可能会过时，需要触发 Mint 的重建接口来重新构建模式。目前这似乎是一个手动或周期性触发的过程，自动化和动态适应系统变更的能力可以进一步提升。
3. 参数过滤的粒度： 虽然 Mint 提供了症状采样器 (Symptom Sampler) 和边缘案例采样器 (Edge-Case Sampler)，但参数过滤的规则和智能性仍有提升空间。例如，如何更精细地定义“异常词语”或“不常见执行路径”，以及如何应对多维度参数的复杂关联。

7.3. 个人启发与批判

7.3.1. 个人启发

• 范式转换的价值： Mint 从“1或0”采样策略向“共性 + 变异性”范式的转变是其最大的创新点。这提醒我们，在面临数据量巨大且信息价值分布不均的问题时，与其简单地“丢弃”一部分数据，不如尝试“解构”数据，保留其基本骨架（共性）并有选择地保留其细节（变异性）。这种思维方式在处理其他大规模监控数据（如日志、指标）时也具有借鉴意义。
• 多层次数据结构的利用： 追踪数据固有的层级和拓扑结构是其区别于普通日志的关键。Mint 能够同时在跨度内容（跨度间级别）和跨度调用关系（追踪间级别）上利用共性和变异性，这展示了对领域特定数据结构深度理解的重要性。
• 代理端处理的决定性作用： 将复杂的解析和数据缩减逻辑前置到代理端，是实现网络和存储开销显著降低的关键。这对于资源受限或网络带宽昂贵的生产环境尤其重要。
• 近似信息 (Approximate Information) 的实用价值： 即使是近似追踪，也能为 SRE 提供重要的诊断线索，避免了完全未命中查询的窘境。这在实际故障诊断场景中具有极高的实用价值，因为它在成本和信息完整性之间找到了一个非常实际的平衡点。

7.3.2. 批判

• 模式演进与维护： 虽然论文提到当系统变化时需要重建模式，但实际生产环境中，微服务系统是高度动态的。如何高效、自动化地检测系统模式的变化，并触发模式的增量更新或重建，是一个复杂的挑战。频繁的重建可能会带来额外的计算开销和潜在的离线时间。
• 布隆过滤器假阳性的潜在影响： 尽管论文声称可以通过上游-下游验证来缓解假阳性，但在极端情况下，如果假阳性率较高或验证机制不够完善，可能会导致查询结果中包含不相关的子追踪片段，增加 SRE 的分析负担，甚至误导诊断。此外，如何量化和控制这种“误导”的成本是一个重要问题。
• 参数过滤规则的智能化： 症状采样器和边缘案例采样器依赖于用户定义的异常词语列表或基于统计的异常值检测。这些规则的维护和自适应能力对于复杂多变的生产环境至关重要。例如，如何自动识别新的异常模式，或者在系统行为正常漂移时动态调整“正常”的阈值，是需要进一步探索的方向。
• 跨语言和异构环境的挑战： Mint 的 Java 实现可能在特定场景下表现良好，但对于多语言、异构技术栈的微服务系统，不同语言的代理实现和模式解析器的一致性与性能维护将是一个不小的挑战。
• 与现有工具链的集成： 虽然 Mint 兼容 OpenTelemetry 等协议，但其后端存储和查询接口是定制化的。在实际应用中，如何与现有的观测平台 (observability platforms)、日志管理系统等进行无缝集成，以提供统一的分析体验，是推广过程中的一个实际考量。