本页内容
把 metrics、logs、traces 放进同一个列存、统一查询、扛住生产规模，这件事已经有人做到了。2026 年，这些方案也都接上了 agent。真正的问题落在了后面一层：agent 成为一等消费者之后，数据库本身要不要跟着变，以及变到哪里。
“统一可观测性”喊了将近八年，业界一度普遍的印象是它还停留在理念阶段。这个印象已经过时了。今天，把三类信号放进同一个列存、统一查询、并且扛住生产规模的方案，是真实存在的。
而且到 2026 年，这些方案几乎都已经把 agent 接了进来。所以这篇文章想讨论的问题，不是“有没有人想到 agent”，而是一个更靠后的问题：当 agent 变成和人并列的一等消费者，被改写的到底是接口，还是数据库本身。
统一存储：已经不是设想了
SigNoz 用单一的 ClickHouse 存 metrics、logs、traces，OTel 原生。ClickStack 更典型：ClickHouse 公司 2025 年 3 月收购 HyperDX，同年 5 月推出 ClickStack，把 OTel Collector、ClickHouse 和查询体验打包成一个开源全栈方案，在同一套体验里关联查询三类信号。
再往前，Honeycomb 多年前就押注任意宽的结构化事件（wide events），理念上最接近终局，底座是自研的列式存储。Charity Majors 在 2024 年有过一个被反复引用的观察：新一代可观测性创业公司普遍转向统一存储模型，宽结构化事件、OTel 原生、常常落在列式数据库上；她的说法是，大家不再做“更便宜的 Datadog”，而是在做“更便宜的 Honeycomb”。
有意思的是，她后来又收回了一部分乐观。2025 年她专门写了一篇《The pillar is a lie》，直言 signal 是技术术语、pillar 是市场术语。到 2026 年 7 月，她的批评更进一步：列存几乎已经成了 2019 年之后新一代可观测性后端的标配，但不少产品仍然沿用三支柱的产品模型，最后卖的还是某种 “Datadog, but cheaper”，而她真正不满的是，这些厂商明明架构更好，却选择不把这件事讲清楚。换句话说，换了存储不等于换了范式。
即便如此，“三信号一个列存”在存储层和体验层，确实正在变成一件被解决、甚至被商品化的事。说“没人做成统一存储”，已经不符合事实。
那为什么还要说，这件事没有真正抵达终点？
两个工程选择，和一个正在被改写的前提
把这些方案摆开看，有三个共同点。前两个是工程选择，可以商榷；第三个是前提，而这个前提正在被改写。
第一，开源阵营里大量产品选择了同一个通用引擎作底座。ClickHouse 是新一代统一方案里最常见的选择之一，Honeycomb 的自研列存则是明显的例外。ClickHouse 是个为通用 OLAP 设计的列存，好用是真好用，但它的设计出发点是通用分析，三类信号各自的访问模式并不在其中。metrics 要为聚合和降采样优化，logs 要为全文检索优化，traces 要为按 ID 点查和树形遍历优化。
这个差距正在被 ClickHouse 自己往回补。TimeSeries 表引擎、PromQL、全文检索，这几年一个个加了进来。补的进度本身也说明了工作量：全文检索已经 GA，但官方明确说它不实现 BM25 一类的相关性打分，目标是加速 token 级过滤，而不是取代专门的搜索引擎；TimeSeries 表引擎和 PromQL 则仍处在实验阶段，ClickHouse 自己在介绍 PromQL 工作时甚至写了一句 “there are dragons here”。
这不是说通用列存做不了可观测性，它显然做得了，而且做得不错。但如果这些 signal-specific 的能力最终一个都躲不掉、都得进到数据库里，那么一个从第一天就以可观测性 workload 为设计目标的统一引擎，应该长什么样？
第二，另一条流行的路，把统一放在了别的层次。Grafana 的 LGTM 栈里，Loki 存日志、Tempo 存 traces、Mimir 存 metrics，Grafana 做可视化。它统一的是体验层和控制层，底层存储引擎保持独立。这是一个清晰的架构选择，代价和收益都很明确：换来的是每类信号可以各自演进，付出的是跨信号的关联要在更上层完成。
第三，也是最容易被忽略的：这些方案在设计之初，面对的消费者都是人。SigNoz 的 explorer、ClickStack 的搜索体验、Honeycomb 的查询界面，背后的假设都是屏幕前坐着一个工程师，他线性地查、盯着 dashboard 思考、在自己脑子里把三类信号关联起来。它们优化的，是让这个人看得更顺。
前两点属于取舍，可以争论。第三点属于另一个层次，它是整套设计的前提。而这个前提，在 2026 年正在被集体改写。
要理解这个局面，得回看它当初怎么分裂的
“三支柱”这个说法用得太顺，顺到它听起来像个自然法则。但它不是谁设计出来的。没有哪个委员会开过会，决定可观测性应该由三类信号构成。metrics、logs 和 traces 沿着不同的问题域和技术路径独立演化，后来才被归进同一个可观测性框架。
metrics 最早，从 RRDtool（1999）到 Graphite（2008 年开源）再到 Prometheus（2012），回答的始终是“系统现在健康吗”。logs 紧随其后，Splunk（2003）、Elasticsearch（2010）解决的是“到底发生了什么”，对应的是倒排索引。traces 最晚也最被动，Google 在 2010 年发表了 Dapper 论文但没开源，真正点火的是 Twitter 2012 年 6 月开源的 Zipkin；它要等微服务普及到一定程度，“一个请求在几十个服务之间怎么流动”才会变成真问题。
图 1：三类信号各自沿着自己的问题域生长，很久之后才被归进同一个框架
关键在于，它们是三个独立问题的三个独立答案。把它们并称为同一个体系的三个视图，是很久以后才追认的说法。而它们的工程约束彼此冲突得很厉害：
| 维度 | Metrics | Logs | Traces |
|---|---|---|---|
| 数据形态 | 时序点 | 文本 / 结构化记录 | span 树 |
| 查询模式 | 聚合、降采样 | 全文检索、过滤 | 按 trace_id 点查 + 因果分析 |
| 基数 | 低（传统场景） | 中高 | 高（trace_id） |
| 保留周期 | 长（可降采样） | 短到中 | 中 |
| 当时常见后端 | 时序库 | 倒排索引 | Cassandra / ES 等 |
在 2010 年代初的技术条件下，一个系统想同时把这三件事做好，基本是逆着工程重力往上推：为其中一类做的优化，往往就是另一类的负担。所以分开做在当时更省力，也更可能做成，把它归因于短视其实是事后诸葛。
真正让这道裂缝固化成一堵墙的，是商业。Splunk 靠日志搜索起家，Datadog 早期立足于基础设施监控，New Relic 靠 APM 打出名气，三家各占一格。而且这道地界几乎是天然画好的：技术上的那道缝，恰好能拿来当市场上的界。对在位者来说，“分”本身就是护城河，统一意味着让出自己定价权最强的那块地。
分裂还不只在供给侧。买方自己也是按三支柱切开的：基础设施监控归 SRE 与基础设施团队，APM 主要是开发团队在用，日志常常落在安全甚至大数据团队手里。预算本来就装在三个口袋里，厂商各守一格，有一半是被需求侧的组织结构喂出来的。
于是一个“当时的工程选择”，慢慢变成了“行业默认的世界观”。
统一的想法，八年前就有人想透了
把这个世界观捅破的人，是当年画出它的人。
2017 年 2 月，Peter Bourgon 参加完那一届 Distributed Tracing Summit，写了篇《Metrics, tracing, and logging》，用一个文氏图厘清三者的边界。这张图成了“三支柱”框架的概念源头，而他想做的只是给一屋子人一套共同词汇。“三支柱”这个更有仪式感的说法是之后才慢慢坐实的，行业厂商则顺势拿它划分了各自的市场。一个用来厘清概念的工具，被当成了“应该如此”的蓝图。
一年半之后，2018 年 8 月，Bourgon 写了《Observability signals》。这一次他反过来问：既然 metrics、tracing、logging 只是观测数据被消费的三种不同模式，那理论上就应该能造一个统一的系统（他叫它 über-system），在入口处接收原始事件，再按数据的“形状”分流。
这里有个常被误读的细节值得澄清：Bourgon 设想的分流终点，是各自 purpose-driven 的后端。他谈的是统一的写入路径和统一的读取模型，并没有要求所有信号挤进同一个物理数据库。今天很多“统一存储”的论述会把他当成祖师爷，但他当年的主张，其实比这更克制、也更接近一种架构分工。
同年 12 月，Ben Sigelman 在 KubeCon 北美讲了《Three Pillars, Zero Answers: We Need to Rethink Observability》。他是 Dapper 论文作者之一、OpenTracing 的共同发起人，早在 2015 年就共同创立了 Lightstep，亲手造过这些柱子，也亲自下场做过产品。他的批评很具体：metrics 受基数限制，维度一多成本压不住；logging 的账是事务速率 × 微服务数量 × 网络和存储成本 × 保留周期，一乘就失控；而更根本的是，三类信号说到底“只是 bits”，当成三根独立的柱子各自堆砌、各自买单不可持续。
2019 年 5 月，OpenCensus 和 OpenTracing 合并成 OpenTelemetry。这是统一第一次在标准层落地，但要泼一盆冷水：OTel 统一的是采集和协议，存储和查询仍然留在原地。它把上游的管子接通了，下游那三个水池还是三个水池。OTel 最被低估的遗产其实是语义约定（semantic conventions）。http.request.method 该叫什么、一个数据库调用的 span 该带哪些标准字段，这些命名沉淀成了行业共识。当时看只是“对齐字段名”的工程琐事，它的价值要到很多年后才兑现，而兑现的场景恰恰是本文后面要讲的 agent。GenAI 语义约定就是这套工作在 agent 时代的延伸，我们在 5 月逐层拆过。
2023 年底，Charity Majors 提出 Observability 2.0：只有一个真相源，任意宽的结构化事件，metrics 和 traces 都只是派生视图。这和 Bourgon 五年前那段推演是同一条思路，原始事件是第一性的，三支柱是次生的。
这套范式也有争议。最常见的反对意见是成本：wide events 把高基数、高维度全保留，单位请求的数据量比任何单一支柱都大，而 metrics 在大规模聚合类 workload 上通常仍然便宜得多，短期内替代不掉。连“2.0”这个命名本身都有争议，Charity 后来对这个 framing 也表示过并不特别喜欢。
到 2026 年夏天，所有人都已经看到 agent 了
如果这篇文章停在这里，接下来顺理成章的一句话应该是：这些方案都是为人设计的，还没有人考虑 agent。
但那样写就错了。
2026 年，这件事已经变成了整个行业的集体动作。SigNoz 在 5 月宣布 agent-native observability，先后推出托管和开源的 MCP server、产品内的 AI teammate，以及一套教 coding agent 怎么用 SigNoz 的 Agent Skills。ClickHouse 在 5 月底的 Open House 上发布了 ClickStack MCP server 和 AI Notebooks，官网直接把 ClickStack 描述成 “observability built for agents”，并明确把它和“dashboard-first、以人为中心的工作流”对立起来。Grafana 在 7 月底的 AI Week 上一次性把六项 AI 能力推到 GA，其中 Assistant Investigations 会自己跨 metrics、logs、traces、profiles 建立假设、并行调查并产出报告。Honeycomb 也已经把自己的平台描述成同时服务开发者和 AI agent。
所以，现在说“别人还没意识到 agent”，是不成立的。大家不仅意识到了，动作还很快。上面这些讲的都是 agent 作为可观测性数据的消费者；agent 本身作为被观测对象是另一道题，我们之前写过。
图 2：三种架构统一在不同深度，而它们在 2026 年都加上了同一层 agent 接入
这里有个细节值得注意。ClickHouse 在讲 ClickStack MCP 的时候提到，他们本来就有一个通用的 ClickHouse MCP server，做 SQL 探索也够用；但在做 AI Notebooks 的过程中他们发现，可观测性的调查工作和一般 BI 不一样，模型面对结构化的调查原语时，表现明显好过面对裸 SQL。于是他们把日志模式分析、trace 离群点排查、跨信号关联这些东西，包装成了给 agent 用的语义化工具，并且公布了内部评测，说专用工具比通用 MCP 减少了工具调用次数、提升了一致性。
这等于从另一个方向承认了一件事：agent 需要的不只是能连上数据，它需要知道这些数据是什么、彼此怎么对应、该怎么问。
问题不是底层要不要变，而是要变到什么程度
行业目前最成熟、也最显眼的变化，首先发生在接入和工作流层：MCP、自然语言查询、自动调查、Agent Skills。
但变化已经开始继续往下走。ClickHouse 谈 agent 场景时，讲的已经不只是接口：高并发的查询能力、不采样的完整 telemetry、更长的保留周期、把 agent 负载和摄入及用户负载隔离开的独立算力，这些都被放进了“为 agent 服务的可观测性”这套论述里。这些不是接口层的话题，它们指向的是引擎和成本模型。
所以问题已经不是底层要不要变，而是要变到什么程度。有几个问题现在都还没有共识：
agent 那种并行、探索式的消费方式，一次调查可能扇出几十上百个查询，其中大部分探到一半就被丢掉。这种 workload 只是执行层要扛的并发压力，还是会反过来改变数据布局和查询规划？
图 3：人一步一步往下钻，agent 一次扇出并丢掉其中大部分分支
可观测性的语义应该留在哪一层？今天公开可见的实现，语义主要存在于 MCP server、Notebook 或产品 API 这一层，最终仍然翻译成针对底层引擎优化过的查询。这些语义是否应该继续停留在工具层，还是有一部分该下沉成数据系统自己能够声明的一等 metadata？OTel 当年把 semantic conventions 沉淀成行业共识，那份遗产究竟在哪一层兑现，目前也还是开放的。
还有一个更朴素的问题：当一个 agent 第一次连上来，它怎么知道这里有什么数据？人可以点开界面翻一翻，agent 需要一个能被程序化理解的入口。
图 4：采集、存储、接入三层都已经有了答案，架构层的答案才刚刚开始出现
统一存储解决的是人类可观测性时代遗留下来的数据割裂。agent 带来的是下一道题：统一起来的数据，是否真的具有统一的语义，能不能被机器高效地理解、探索和消费。
行业已经在接口层给出了第一批答案，架构层的答案则刚刚开始出现，还远没有收敛。关于一个可观测性数据库面对这道题应该做什么、不应该做什么，我们会在后续文章里展开。
参考链接
正文中提到的来源，按出现顺序汇总，方便在公众号等无法跳转的环境里查阅。
- ClickHouse Acquires HyperDX（2025-03）
- Charity Majors, The pillar is a lie（2025-10）
- Charity Majors, Have you heard? Clickhouse is winning the observability wars!（2026-07）
- Open House 2026 Day 1（PromQL 早期预览）
- Google, Dapper, a Large-Scale Distributed Systems Tracing Infrastructure（2010）
- Peter Bourgon, Metrics, tracing, and logging（2017）
- Peter Bourgon, Observability signals（2018）
- Ben Sigelman, Three Pillars, Zero Answers: We Need to Rethink Observability，KubeCon NA 2018（西雅图，2018-12-11）
- OpenTelemetry: The Merger of OpenCensus and OpenTracing（Google Open Source Blog, 2019-05-21）
- Bringing Agent-Native Observability to SigNoz（2026-05）
- Open House observability announcements: MCP server, AI Notebooks, and ClickStack Cloud（2026-05）
- ClickStack AI — Observability built for agents
- Grafana Labs Ships Six Tools That Power Agentic Operations（2026-07）
- Announcing the Managed ClickStack MCP Server（2026-06）
