揭秘可观测性三大“拦路虎”：Retention, Sampling, Rollups的真面目！

Mike Shi2026年05月14日约 18 分钟

本文字数：10459；估计阅读时间：27 分钟
作者：Mike Shi

Meetup活动

ClickHouse 上海第3届 Meetup 报名倒计时2天，详见文末海报！

您是否仅仅为了控制成本而对您的链路追踪（trace）进行采样？

您是否对高基数（high-cardinality）指标进行汇总（roll-up），以便使其可查询？

您是否限制了日志（log）的保留（retention）期限，仅仅是因为存储所有数据成本过高？

这些模式在可观测性（observability）领域已司空见惯，甚至常被奉为“最佳实践”；一些供应商甚至将其作为一种“能力”来宣传，实则只是为了掩盖其产品短板。然而，在 ClickHouse，我们认为这些都只是权宜之计，它们反映的是后端系统的局限性，而非工程师的实际需求。

我们是如何走到今天这一步，让 SRE（站点可靠性工程师）们不得不对数据进行筛选、丢弃或聚合？更重要的是，这种现状是否必须一成不变？

本文将探讨保留（retention）、采样（sampling）和汇总（roll-up）这三大约束，它们共同塑造了现代可观测性。这些并非中立的设计选择，而是存储引擎在处理规模、成本和高基数（high-cardinality）数据时面临挑战所强加的局限，同时也是 SaaS 平台将这些局限转嫁给用户的体现。

这些权衡曾经尚可接受。过去，运维人员尚能凭借经验和直觉弥补缺失的数据。然而，这一假设正在瓦解。尽管至少 [90% 的从业者认为利用 AI 来发现异常（anomalies）并辅助根本原因分析（root cause analysis）具有价值](https://grafana.com/observability-survey/#ai-in-observability-transparency-is-key-autonomy-is-the-next)，但现有系统并未针对此提供支持。随着 AI 和智能代理（agent）驱动的工作流日益成为可观测性的核心，采样、聚合以及短期的保留期将带来更大的危害。它们不仅消除了自动化推理所需的上下文信息，还使得智能代理难以自证其结论——而这正是 [超过 95% 的从业者所期望的](https://grafana.com/observability-survey/#observability-practitioners-overwhelmingly-want-ai-to-show-i)。

曾经可以接受的妥协，如今已成为实实在在的限制。要构建能够支持自动化诊断和推理的系统，我们必须消除这些限制。

如果能够消除这些限制，其结果不仅是减少权衡和取舍，更是一种根本上更优秀的可观测性模型：实现无盲区、更快的故障解决时间，并为下一代智能代理驱动的工作流提供完整的上下文信息。

保留：内存税

数据保留是每个可观测性 (observability) 用户首先需要考虑的约束之一。它几乎成为一种自动的考量：日志应该保存多久？追踪应该回溯多远？以及成本是否可承受？

在某种程度上，这种考虑是合理的。并非所有数据都需要无限期存储，并且数据过期 (expire) 也有其正当理由。然而，问题不在于数据保留机制是否存在，而在于它已成为一个核心关注点——这常常迫使团队将数据保留期设定得极短。日志数据通常只能保留 7 到 14 天，而追踪 (traces) 数据由于其体量和/或基数 (cardinality) 更大，处理起来甚至更加激进（即保留时间更短）。

这种现象并非由用户需求驱动，而是源于系统自身的局限。许多系统为了提供查询性能，依赖于基于 SSD 的存储；当与低效的压缩技术相结合时，这使得长期数据保留的成本极其高昂。结果，这些高昂的成本要么由服务提供商承担，要么转嫁给用户，从而迫使最终用户将数据保留视为一个预算问题。

为了延长数据保留期，团队通常会引入分层存储，将数据推送到成本更低但性能更差的存储介质中。尽管这允许更长的保留期，但它增加了系统的复杂性，并且意味着查询历史数据需要进行数据重新激活 (rehydration) 或忍受更慢的查询速度。

然而，情况不应如此。随着高压缩技术和对象存储 (object storage) 的应用，其成本效益将彻底改变。如果我们能以大约每 GB 0.025 美元的价格将数据存储在对象存储上，并结合 50 倍的压缩率，那么原始数据只需典型成本的一小部分即可长期保留。将数据保留期设定为 30 天、60 天，甚至一年，都应该成为默认选项。**数据过期应由合规性或政策驱动，而非成本压力。**

对象存储不应意味着需要管理复杂的存储分层。用户不应该被迫决定哪些数据是“热”数据、“温”数据，或是需要归档到对象存储中的数据。所有数据都应被统一摄入 (ingested) 并平等对待，系统应根据查询模式自动加速频繁访问的数据。引入分层只会增加复杂性和运维负担，让用户不断纠结于“哪些数据该存放在哪里”，而无法从根本上解决问题。

移除这一限制，不仅仅能减轻运维负担，更能解锁全新的工作方式。长期的数据保留能力使得分析季节性模式、历史回归以及此前未曾发现的问题成为可能。通过数月的数据追溯一个单一的日志模式，我们可以了解某个 bug 何时首次出现以及哪些用户受到了影响。

如果数据缺失，Agent 识别周期性模式将面临挑战。

随着 Agent 成为可观测性 (Observability) 工作流的一部分，获取历史背景数据变得至关重要。人工操作员具备过往事件和模式的隐性知识，但 Agent 缺乏此类知识。如果没有长期数据，它们就无法区分异常与预期行为，也无法推断趋势。限制数据保留不仅会降低其可见性，还会制约其功能发挥。

基于这些原因，数据保留是我们遇到的第一个“罪魁祸首”。并非因为数据不应过期，而是因为底层存储系统的高昂成本，导致用户不得不承担决定哪些数据需要保留的重担。

采样 (Sampling)：存在盲区的可观测性

采样 (Sampling) 是我们刻意丢弃数据的开始。与限制可回溯时间长度的数据保留不同，采样则决定了我们能看到哪些数据内容。

采样最常应用于链路追踪 (Trace)，其工作原理是通过有选择地保留事件的一个子集。这通常使用**头部采样 (Head Sampling)** 或**尾部采样 (Tail Sampling)** 来完成。头部采样在 Trace 开始时就做出保留或丢弃的决定，而无需等待 Trace 完全观测完毕。尾部采样则将这一决定推迟到 Trace 完成之后，允许系统保留符合特定条件的 Trace，例如明确标记为错误或具有高延迟的 Trace。尽管尾部采样能获取更多信息再做决策，但这两种方法最终都会丢弃数据，例如可能遗漏那些虽然未明确标记为错误、却能揭示逻辑问题的数据。同样，在日志记录中，错误日志可能会被保留，而高容量的信息日志则会根据服务进行有选择地减少。

头部采样（Head-based sampling）会预先（确定性或随机地）选择链路追踪，这可能导致包含关键错误的链路追踪被丢弃；而尾部采样（Tail-based sampling）则会等待所有 Span，并优先保留那些存在问题的链路追踪。尽管尾部采样更具参考性，但两种方法都会丢弃数据，并有丢失重要信号的风险。

采样机制的目标很明确：它减少了数据写入量，降低了存储开销，并最大限度地减少了查询时需要扫描的数据量。通过这种方式，它实现了成本控制。然而，与数据保留策略（retention）类似，这并非由用户驱动的优化，而是系统强制施加的限制——决定哪些数据值得保留的责任，再次落到了用户身上。

在许多方面来看，采样比数据保留（retention）策略的限制性甚至更强。在较短的数据保留周期内，至少在该周期内，所有可用数据是完整的。与之相比，采样则在数据摄取（ingestion）阶段就降低了数据的保真度（fidelity）。

数据的保真度损失会带来更广泛的影响。现代可观测性（Observability）越来越依赖于丰富的、高基数（high-cardinality）事件，通常会将日志、指标和链路追踪（traces）结合起来，形成统一的“宽事件”（wide events）。这些“宽事件”能够实现更深入的分析、趋势检测以及随时间推移更准确的洞察与推理。然而，采样机制打破了这种模式。通过删除事件，采样会扭曲聚合结果，削弱统计准确性，并限制了执行有意义分析的能力。

通过采样得到的指标可以进行外推（extrapolation），以提供近似结果。尽管这对于许多简单的聚合类型是可行的，但对于其他类型而言则颇具挑战性，并且这始终意味着用户依赖的是估算结果。

与数据保留策略一样，采样再次限制了代理（agents）的有效性。如果没有完整的数据，代理就无法可靠地检测模式、关联信号，也无法对异常进行有效的推理。同样，与数据保留类似，曾经被视为可接受的权衡，如今却演变为一个严峻的限制。

在一个理想的系统中，每一个事件都应以完整的保真度被保留下来，这通过高效的数据压缩和低成本的存储方案得以实现。这确保了当问题出现时，能够获得完整的上下文信息。其结果不仅能让工程师更快地解决问题，还能构建一个支持更深入、更准确分析的系统，这种分析既可以由人类进行，也可以由下一代代理驱动的工作流（agent-driven workflows）来完成。

Roll-ups（数据汇总）：聚合陷阱

Roll-ups 是为了应对 Prometheus 等指标系统所面临的一个常见问题——高基数，而产生的一种实用解决方案。

高基数引发序列爆炸。来源：Observability Engineering: Achieving Production Excellence, Chapter 16. Efficient Data Storage

值得简要定义一下“高基数”（High Cardinality）这一术语。在时间序列数据库（Time Series Databases）中，基数指的是由 `host` 等标签组合而成的唯一时间序列的数量。例如，像 HTTP GET 请求计数这样的指标，可能包含 `host`、`service`、`endpoint` 或 `status_code` 等标签。每个唯一的组合都会形成一个独立的序列。随着这些维度的倍增，序列的数量会极快增长。如上所示，像用户 ID 这样的高基数标签，会单独引发序列爆炸（Series Explosion）。

这正是时间序列模型开始显现其局限之处。像 Prometheus 这样的系统，对中等数量的长期序列运行良好，但对于每个唯一的序列，都会在内存、磁盘和查询时产生额外开销。像 `container_id` 或 `pod_id` 这样短生命周期、高维度的标签，会通过不断创建新序列并频繁更迭，从而加剧这一问题。

这种压力直接导致了数据汇总（Roll-ups）。用户要么选择减少采集的维度数量，但这会造成监控盲点；要么选择将指标预先聚合为更粗粒度的形式，以便于存储和查询。供应商通过对活跃序列数量进行收费来强化这种趋势，将数据存储的架构成本直接转嫁给客户。因此，团队再次被迫将注意力从“想要观察什么”转移到“指标后端能承受什么”。

数据汇总通过将大量细致的序列聚合为数量更少、粒度更粗的指标，从而减少高基数数据，在牺牲精细粒度上下文的前提下提高效率。

然而，数据汇总也伴随着一个严重的代价：它要求你基于预期的日常使用，提前决定未来可能提出的问题，然而在事故期间，最重要的问题往往是未知且临时的。一旦数据被汇总，其原始的精确度便不复存在。如果聚合的粒度过粗，或遗漏了关键维度，将无法恢复原始数据。这导致了另一个可观测性盲点（Observability Blind Spot），并非源于缺乏数据埋点（Instrumentation），而是为了弥补存储层（Storage Layer）的局限性所致。

随着智能体 (agents) 融入工作流，这一问题会进一步加剧。当关键维度缺失时，例如无法根据客户 ID 细分指标，智能体就会陷入僵局。此时，用于定位问题的信号已不复存在。与人类不同，智能体没有直觉或任何回退机制。

这正是聚合操作 (roll-ups) 成为症结所在的原因。它们常被宣传为一种巧妙的优化手段，但在许多情况下，它们只是为了弥补后端系统无法在大规模下处理完整高保真数据而采取的权宜之计。理想情况下，用户**压根无需过度关注基数 (cardinality) 问题**。他们会按原样存储丰富的高维度遥测数据，并且仅在聚合操作确实能加速已知查询时才使用，而不是将其作为系统可用的前提条件。

事实上，一个更好的模型是可行的。如果存储引擎能够高效处理高基数数据，那么聚合操作 (roll-ups) 将从基础性组件转变为可选工具，仅用于选择性地加速某些工作流。这意味着更少的妥协、更少的盲点，以及一个能够完整保留调试、分析以及日益增长的智能体驱动推理所需上下文的系统。

当弊端叠加时

单独来看，数据保留策略 (retention)、采样 (sampling) 和聚合操作 (roll-ups) 都会损害部分数据完整性。当它们结合时，会进一步加剧数据损失，随着数据被采样、聚合并最终丢弃，留下的不再是原始信号，而是经过大幅过滤的版本。系统不仅丢失了数据，更丢失了重要的上下文信息。

这种分层的数据丢失构建了一个脆弱的可观测性模型。许多预料之外的问题常常无法得到解答，根本原因分析也因此沦为猜测，因为它受限于每个阶段侥幸保留下来的数据。对于人工操作员而言，这会导致调查时间延长，并过度依赖直觉和系统理解——虽然延迟了问题解决时间，但仍可控。

然而，对于智能体 (agents) 而言，情况则要严峻得多。由于没有可供回溯的残留知识，缺失的上下文将导致其工作彻底中断。这三个限制的综合影响不仅是可观测性降低，更是从根本上限制了系统被理解和操作的能力。

可观测性的应有面貌

数据保留 (retention)、采样 (sampling) 和数据汇总 (roll-ups) 应该完全消失吗？并非如此。但它们的作用应该发生根本性转变。它们不应再是塑造系统设计或数据收集的主要制约因素，而应是经过深思熟虑、有选择性地应用的优化措施，而非受成本或架构限制所迫的默认选项。

数据汇总在用于加速特定查询或提供对常见聚合数据的快速访问时具有重要价值，但它们应与原始数据并存，而非取而代之。性能与数据保真度之间绝不应成为二选一的选项。全分辨率数据应始终得到保留，而数据汇总则作为优化层发挥作用，而非系统的基础。

采样同样遵循这一原则。在某些情况下，特定事件或日志可能被认为价值不大，因此可以减少收集。但这应是基于数据本身、经过充分考量的决策，而非受限于存储或处理能力的无奈之举。默认情况下，系统应捕获完整的追踪 (traces) 和事件，保留完整的数据保真度，确保在关键时刻不会丢失任何信息。

数据保留也遵循相同的原则。长期存储应成为默认选项，且其成本应足够低，以免成为决策的主导因素。保留策略应由合规性或实际业务需求所驱动，而不是为了严苛地限制存储量。

以列式存储应对挑战

为了应对这些挑战，我们首先需要一个能够经济高效地处理具有完整保真度的高基数数据 (high-cardinality data) 的存储模型。

这正是列式存储 (column-oriented storage) 改变格局的关键所在。可观测性 (Observability) 工作负载本质上是分析型的，需要能够摄入 (ingest) 大量结构化或半结构化事件流，并在此基础上，跨时间、服务、用户、容器和区域对它们进行过滤、聚合和关联分析。

可观测性的核心是一个分析性数据问题，需要通过聚合来生成图表

列式存储系统正是为这种模式而构建的。由于每个列都是独立存储的，查询只会读取它们所需的字段。这显著减少了输入/输出 (I/O) 操作，并使得在大型数据集上执行聚合 (aggregations) 的速度远超行式存储 (row-oriented) 或搜索优先系统 (search-first systems)。

列式数据库独立存储每个列，并通过排序实现高压缩率

列式存储 (Columnar storage) 对可观测性数据 (observability data) 的压缩效果极佳。重复的值和有序的模式能够实现远高于传统方法的压缩率。当与对象存储 (object storage) 结合使用时，这使得数据的长期保留在经济上变得可行。团队可以负担得起更长时间地保留原始数据，并根据合规性 (compliance) 或治理 (governance) 要求使用过期策略 (expiry policies)，而不再是因为系统强制删除上下文信息，避免了将数据保留视为一项持续的预算负担。

通过独立处理每一列，高基数属性的影响被隔离

同样的架构也有助于处理高基数 (high cardinality) 问题。与时间序列系统 (time series systems) 为每个独特的标签组合创建并维护庞大的序列结构不同，列式存储 (column stores) 独立隔离每个字段。像 `userId` 这样的高基数列可能压缩效果不佳，但这种开销仅限于该列本身，不会影响数据集的其余部分。这使得对高维度数据 (highly dimensional data) 进行高效过滤和聚合成为可能，其中用户 ID、请求路径或模型版本等字段仅仅是额外的查询维度，而不再是需要规避的限制。

列式系统 (Columnar systems) 并不能消除基数问题，它们只是将部分开销转移到查询时。对像 `container_id` 这样的高基数维度进行聚合可能需要创建数百万个组，并且计算成本高昂，即使采用磁盘溢出 (disk spilling) 等技术也是如此。然而，这并不是一种常见的可观测性访问模式。实际上，用户很少需要可视化或聚合数百万个不同的序列。大多数工作流程都专注于过滤后的子集 (filtered subsets)、Top-N 结果或聚合视图 (aggregated views)，使得这些最坏情况的查询成为例外而非常态。

这也改变了汇总 (roll-ups) 和采样 (sampling) 的作用。当它们能够加速已知访问模式时，汇总仍有其价值；而对于真正低价值的数据，采样依然有意义。但两者都不再需要成为系统的基础。原始的、全保真数据 (full-fidelity data) 可以保持可用状态，而汇总和采样 [仅用作有针对性的优化](https://clickhouse.com/blog/whats-new-in-clickstack-december-2025#materialized-views-arrive-in-clickstack)。这与当今的可观测性技术栈 (observability stacks) 是一种根本不同的模型，在后者中，这些技术往往只是为了让系统经济上可行或可用而不得不采用。

ClickHouse 为何是最佳选择

ClickHouse 并非唯一能够应对这些挑战的列式数据库 (Columnar Database)。Apache Pinot 和 Apache Druid 等系统也具备许多相同的架构优势，并成功支持了大规模分析工作负载。然而，在可观测性 (Observability) 领域，ClickHouse 凭借其对实时性的专注而独树一帜。

稀疏主索引 (Sparse Primary Indices) 实现了高效过滤，这与可观测性 (Observability) 的访问模式高度契合；同时，并行执行引擎可在大规模数据集上扩展查询。跳过索引 (Skip Indices) 和对全文搜索 (Full-Text Search) 的支持进一步扩展了这些能力，从而支持探索性工作流。

ClickHouse 的稀疏主索引利用列的有序结构跳过大范围数据，显著减少了需要扫描的数据量。

ClickHouse 的存储架构原生支持对象存储 (Object Storage) 和计算与存储分离 (Separation of Compute from Storage)。结合列式压缩 (Columnar Compression)，这使得以低成本保留海量数据成为可能，同时能够根据需求独立扩展计算资源。至关重要的是，这种模型完全消除了对存储分层 (Storage Tiers) 的需求。所有数据都得到统一处理，常用数据会根据查询模式通过缓存 (Caching) 自动加速。这确保了热数据 (Hot Data) 能够高效地提供服务，而无需用户手动决定哪些数据属于热层、温层或归档层。因此，用户能够从所有数据的一致性能和功能对等 (Feature Parity) 中受益，并且无需承担管理分层或在它们之间移动数据的操作开销 (Operational Overhead)。

ClickHouse Cloud 中智能的分布式和节点级缓存会自动加速常用数据，确保常见查询和关键调查路径能够得到快速响应，且无需根据时间等标准进行手动数据分层。

用户还可以为特定的工作负载，例如数据摄取、查询、分析或告警，配置专用计算池，每个计算池都可独立调整规模和优化。这降低了总体成本，同时确保资源与实际使用情况保持一致，而非基于峰值需求进行预留。任何未使用的池都可以处于空闲状态，不产生费用，并且仅在需要时才会被激活。

这些功能已在大规模可观测性部署中得到验证。Tesla、Anthropic、OpenAI 和 Character.AI 等公司依赖 ClickHouse 分析 PB 级 (petabyte scale) 的可观测性数据，这证明了它能够满足现代工作负载的需求。

ClickHouse 在帮助我们开发和发布 Claude 4 方面发挥了关键作用。有了 ClickHouse，数据库运行高效，查询速度快如闪电，并且大幅节省了成本。ClickHouse 在帮助我们创建最先进的语言模型方面已经提供了显著价值。
(https://clickhouse.com/blog/how-anthropic-is-using-clickhouse-to-scale-observability-for-ai-era)

以前，查询过去 10 分钟的数据需要 1-2 分钟。使用 ClickStack 后，其速度之快令人难以置信。性能提升是实实在在的。当你在事故处理过程中深入分析日志时，每一秒都至关重要。(https://clickhouse.com/blog/scaling-observabilty-for-thousands-of-gpus-at-character-ai)

未来：具备列式存储赋能完整上下文的代理

那么，当数据能够长期保留、数据聚合是选择性的、数据采样是可选的时候，世界将呈现出怎样一番景象？

我们不再受限于能够保留哪些数据，而是开始优化如何访问和使用这些数据。高并发变得至关重要，尤其当代理在可观测性工作流中扮演更积极的角色时。这些系统发出的查询量远超人类用户，并且它们期望获得快速、一致的响应。至关重要的是，我们不希望底层数据存储成为代理的瓶颈。相反，我们需要能够以所需的并发度处理查询，同时自身又不会成为瓶颈的系统。

延迟的重要性也日益凸显。智能体循环的速度受限于其最慢的步骤。如果查询需要数秒才能返回，整个推理过程就会减缓，导致交互响应迟钝、效率低下。可观测性不再是交互式工作流，反而更像批处理过程，这从根本上与人类和智能体期望的操作方式背道而驰。

然而，仅仅依靠原始数据是不够的。智能体无法仅通过摄入海量日志或追踪数据就进行有效推理。它们需要快速、结构化的数据摘要。这使得强大且低延迟的数据聚合技术成为必需，同时还需要将摘要处理能力推入数据库内部。日志聚类、模式检测和高速分组等能力成为首要需求，使系统能够将海量数据快速提炼成有意义的信号。

开放性同样至关重要。在此背景下，开放性意味着通过 SQL 等标准且富有表现力的接口，全面开放数据存储的能力。用户和智能体无需依赖专有查询语言或受限 API，即可直接与底层数据模型交互。这一点至关重要，因为大型语言模型 (LLM) 在生成 SQL 方面已展现出极高效率，从而减少了学习领域特定语法所需的定制训练或额外上下文。

与此同时，定义良好的端点和工具对于常见工作流依然重要，为频繁查询提供稳定、高效的访问模式。但这不应是唯一的接口。智能体能够回退到原始 SQL 的能力，是至关重要的“逃生通道”，可实现更深层次的内省和真正的即席调查。

正因如此，专为实时分析设计的系统具备天然优势，在其设计中自然地融入了这些特性。例如，ClickHouse 从最初设计便致力于在高并发场景下提供低延迟的 SQL 聚合能力。一旦消除了数据保留、采样和汇总的限制，这些特性便构成了下一代可观测性的基石，从而在速度、规模和对完整数据进行推理方面实现优化。

结论

可观测性一直受制于诸多限制，迫使用户在成本和性能之间权衡，不得不牺牲数据保真度。随着我们迈向智能体驱动的未来，这些权衡将不再可接受。通过消除这些限制，并采用为全保真数据构建的架构，我们可以从处理折衷方案转变为实现真正的理解。这最终解锁了智能体化可观测性，使系统能够在完整的上下文中进行推理、调查和行动。