指标真的要退场了吗？一次关于可观测性未来的深度反思

当我收到告警时，我会打开指标仪表板。这一点从未改变。指标依然是快速判断系统是否处于异常状态的最快方式，尤其是在面对那些已知的故障模式，以及可以提前合理预期的问题时。

但更多时候，我无法预见所有问题。我花了大量时间查看以 traces 和 logs 为核心构建的仪表板，或直接深入搜索，甚至借助 LLM 智能体与我一起协助排查。很多时候，作为开发者，根本没有告警触发。只是某位用户或支持工程师反馈某些功能感觉变慢或异常。在这种情况下，指标往往给不出太多信息。没有告警触发，没有阈值被突破。一切看起来都很正常，哪怕实际上并非如此。

在 ClickStack 中，搜索与分析事件是核心的用户体验，因为这正是工程师在实际调查和解决问题时最常采用的方式。

因此，我认为，我们对监控与可观测性中“指标”角色的理解即将发生转变。指标仍然重要，但它们不会再是监控技术栈的核心组成部分。随着对结构化数据进行聚合汇总 (rollups) 变得更加低成本且更加原生——尤其是在像 ClickHouse 这样的列式数据库中——指标开始更像是一层优化机制和辅助功能，而不再是主要的交互界面或核心工作方式。

从技术角度来看，指标本质上是预聚合的统计数据。它们的存在，是为了将极高吞吐量的信号压缩为易于存储且查询高效的形式。当原始数据的产生速率高到无法直接处理时，这一点至关重要。鉴于 Prometheus 的广泛使用，下面我们以它为例进行说明。

例如，CPU 使用率通常以滚动聚合的形式采集，而不是记录每一个原始事件。我们不会记录每一条 CPU 指令或每一次上下文切换，而是使用类似 Prometheus 风格的指标，在一定时间区间内累计 CPU 时间，并按照较为粗粒度的维度（例如 core 或 mode）进行拆分。这样可以生成一组规模小且稳定的时间序列，从而实现高效查询。

node_cpu_seconds_total {  instance="node-17",  cpu="2",  mode="user"}

这个单一计数器代表了在特定主机和核心上跨数百万次操作累计的 CPU 时间，在控制基数规模的同时，依然保留了足够的上下文信息，用于判断系统健康状况。

我们不会为每一个 CPU 周期生成一条事件，也不会记录每一次磁盘操作。CPU 时间、内存使用量、文件系统利用率——这些指标将继续以 metrics 的形式存在，因为替代方案既无法扩展，也没有必要提供那样的精细度。指标之所以有效，还因为它们是经过精心设计和筛选的。从历史上看，这一点尤为重要。有人判断延迟、错误率、饱和度、队列深度和吞吐量是关键指标；有人在代码中实现了相应的埋点，以合理的精度对它们进行度量。正是这种人为判断，使指标在告警场景中表现出色。一个指标之所以存在，通常意味着有人已经认定它在运维层面具有重要意义。

但这些优势，也带来了明显的局限性。

在指标系统中，通常需要有意识地限制甚至丢弃基数。高基数维度会被约束或直接移除，以控制成本与系统复杂度。这意味着，当需要调试单个请求、错误或异常时，仍然不得不回到更高基数的 logs 或 traces 中进行排查。

一个典型场景是 Kubernetes 服务中的单请求延迟。如果延迟指标按 pod ID、request ID 或 user ID 进行标记，那么随着 pod 的频繁变动和流量波动，基数会无限增长，最终迫使这些维度在指标系统中被移除。实践中，你往往会得到类似这样的结果：

http_request_duration_seconds_bucket {  service="checkout",  method="POST",  status="500",  le="500ms"}

pod ID、request ID 或 trace ID 等标签被刻意排除，因为一旦加入，就会产生数百万条时间序列。当某个具体请求或某个 pod 出现异常时，指标曲线依然平滑，对排查毫无帮助，因此我们只能跳转到 logs 或 traces 中寻找真正的根因。

关联性也是指标的一个薄弱环节。指标通常与 traces 和 logs 分散在不同系统中。将低基数的时间序列与高基数的事件数据进行关联，要么根本不支持，要么操作复杂到让团队望而却步。仅凭指标，很少能够还原完整的事实。从指标跳转到日志或追踪，是工程师日常最常见的操作流程，但目前大多只是通过各种折衷方案拼接而成。

真正的可观测性，将 logs、metrics 与 traces 整合到一个统一且可关联的视图中，为工程师提供诊断问题所需的精确时间、服务以及资源上下文。

最后，指标必须在开发阶段提前定义。必须有人决定要监控什么、如何聚合，以及在代码中的哪个位置进行埋点。当问题是可预期、需求清晰时，这种方式运作良好。但当真正关键的问题，往往是在系统出现故障后才显现时，这种方式就显得力不从心。

这些问题并非单纯的工具缺陷，而是这种抽象模型本身所带来的必然结果。

随着指标的局限性日益显现，可观测性技术栈的其他部分也在不断演进。如今，我们拥有带有丰富高基数上下文的结构化事件和 traces，也拥有能够高效存储这些数据的列式数据库，并具备极高的压缩率——让用户可以以更高保真度保存更多数据。与其分别生成 logs 和 metrics，一个结构化事件就可以同时承载两者的信息。

{  "timestamp": "2026-02-10T14:03:27Z",  "service": "checkout",  "pod_id": "checkout-7c9f8d6b4f-k2m9p",  "trace_id": "4f8c2a9e3d",  "request_id": "req-91827",  "latency_ms": 842,  "status_code": 500,  "cpu_ms": 37,  "memory_bytes": 52428800,  "level": "error",  "message": "Checkout request failed due to upstream timeout"}

包含 metrics 的示例日志行

这些数据可以在多个维度上进行聚合汇总 (rollups)。在像 ClickHouse 这样的系统中，这类汇总是自动完成的、增量维护的，并且成本足够低，可以作为默认能力使用，同时原始数据依然保留，可用于高保真度的问题排查。

原始结构化事件：

基于同一份数据自然生成的汇总结果：

当具备了这样的能力后，我们就有理由去思考：指标是否还需要被当作一种独立的、一等重要的产物来看待？

如果结构化事件能够被高效汇总，那么指标本质上就相当于一个响应更快的缓存查询结果。你既可以保留高基数的原始数据，又可以维护低基数的聚合结果，使其行为类似传统指标。不同之处在于，这些聚合不再需要预先写死在 SDK 中或显式上报——它只是加速真实数据上常见查询的一种技术手段。

这实际上重新定义了指标的角色。它们不再是“事实来源”，而是一种性能优化方式。用户关注的是哪些查询值得加速，哪些数据值得被完整记录。原始事件描述了真实发生的情况；指标只是众多可能的汇总视图之一。

这种转变同样改变了“筛选与设计”的方式。过去，指标之所以有效，是因为必须有人在开发阶段就提前决定什么是重要的，定义要采集什么，以及如何进行聚合。当关键问题是明确且可预见时，这种模式运作良好；但当真正重要的问题只有在系统出故障后才浮现时，这种模式就会显得力不从心。

在拥有更丰富、高基数的可观测性数据之后，筛选和建模可以推迟到更靠后的阶段。工程师可以从原始事件出发，探索真实发生的情况，然后再决定哪些维度和聚合方式值得固化为运维实践，而不是一开始就做出假设。这使排查过程更加灵活，也降低了早期判断失误所带来的成本。

随着 LLM 越来越多地参与到可观测性工作流中，这种转变将更具力量。AI 智能体可以直接探索原始数据，发现潜在模式，并自动推荐有价值的聚合方式，而无需在埋点阶段就提前做出所有决定。从某种意义上讲，这与数据领域从 ETL 向 ELT 的演进类似——数据先被摄取，再赋予结构与语义，而不是在摄取前就完全定义好。

答案是：既是，也不是。我依然认为指标会继续存在。有些信号本质上就是聚合结果（例如 CPU、内存、磁盘使用情况）。有些告警场景也需要简单、稳定的阈值判断。但随着列式数据库中的聚合汇总能力越来越快、越来越低成本，可以预见，指标将从可观测性的核心组织方式，转变为众多优化手段中的一种。

围绕丰富数据、灵活汇总能力以及日益强大的分析能力构建的可观测性技术栈，更适合面向这样的未来：在那里，最关键的问题往往无法提前预知；对生产系统的理解，也不再依赖于一开始就判断正确，而更多依赖于事后能够提出更精准的问题。

Meetup 活动讲师招募

我们正为深圳活动招募讲师，如果你有独特的技术见解、实践经验或 ClickHouse 使用故事，非常欢迎你加入我们，成为这次活动的讲师，与大家分享你的经验。

/END/

试用阿里云 ClickHouse企业版

轻松节省30%云资源成本？阿里云数据库ClickHouse 云原生架构全新升级，首次购买ClickHouse企业版计算和存储资源组合，首月消费不超过99.58元（包含最大16CCU+450G OSS用量）了解详情：https://t.aliyun.com/Kz5Z0q9G