重磅发布 ClickStack：基于 ClickHouse 的高性能开源可观测性栈

本文字数：5616；估计阅读时间：15 分钟

作者：Mike Shi

本文在公众号【ClickHouseInc】首发

重磅发布 ClickStack

我们今天正式发布 ClickStack —— 一个基于 ClickHouse 构建的全新开源可观测性（Observability）解决方案。ClickStack 提供日志、指标、链路追踪和会话回放等功能的全套体验，即装即用，性能强劲，架构开放，人人可用。

你可以通过查看文档中的《快速开始指南》，开启你的 ClickStack 实践之旅[https://clickhouse.com/docs/use-cases/observability/clickstack/getting-started]。

多年以来，像 Netflix 和 eBay 这样的超大规模技术团队，一直将 ClickHouse 作为可观测性数据存储的首选方案。它的列式结构、高效压缩能力，以及高吞吐量的向量化查询引擎，使其非常适合存储“宽事件” —— 这种记录类型包含丰富的上下文信息，基数高，能够同时统一日志、指标和链路追踪数据。这种被称为“可观测性 2.0”的现代可观测性架构，打破了传统“三大支柱”的模型，省去了整合分散遥测数据源的繁琐。

不过，过去只有拥有充足资源的团队才能在 ClickHouse 之上构建完整的可观测性解决方案。而对于大多数团队来说，他们不得不依赖通用可视化工具，或是第三方构建在 ClickHouse 之上的专有平台。这些工具虽然能实现基础功能，但经常需要撰写冗长复杂的 SQL 查询来完成日常监控任务，而且往往无法充分发挥 ClickHouse 的性能潜力和开放优势。

现在，情况发生了根本改变。借助 HyperDX 的强力支持，ClickStack 正式发布，一个真正的开源可观测性平台应运而生。它内置了 OpenTelemetry 收集器、支持宽事件数据展示的可视化界面、自然语言查询、会话回放、告警等多项功能，一应俱全。

最重要的是，这一切都建立在 ClickHouse 这款备受信赖的高性能、高压缩引擎之上，被全球领先的可观测性团队所采用。

过去，团队往往只能在昂贵的闭源 SaaS 产品和零散的开源组件之间权衡取舍。搜索引擎虽然查询灵活快速，但在大规模部署和高效聚合方面常常力不从心；而指标存储系统虽然具备高效聚合能力，却需要预先定义聚合规则，且缺乏强大的搜索能力。这两种方式都不擅长处理高基数数据，而强行将它们拼凑在一起又会引入额外复杂度，无法从根本上解决问题。

现在有了 ClickStack，你无需再做选择 —— 它兼具高基数宽事件数据的极速搜索与高效聚合能力，可扩展、开源，并真正适合所有团队使用。

ClickHouse 在可观测性领域的演进

可观测性的本质，其实是数据问题

早期使用 ClickHouse 的团队意识到一个关键点：可观测性归根结底是一个数据问题。数据库的选择，决定了整个可观测性平台的成本、可扩展性以及功能边界 —— 无论是自建平台还是创办一家可观测性公司，选对数据库往往是最关键的架构决策。

这正是为什么多年来 ClickHouse 一直是众多可观测性技术栈的核心。从 Netflix、eBay 等业界巨头，到 Sentry、Dash0 这样的新兴可观测性初创企业，ClickHouse 都在大规模支撑日志、指标和链路追踪数据。凭借列式存储架构、高效压缩能力和向量化执行引擎，ClickHouse 在显著降低系统成本的同时，提供了亚秒级查询能力，帮助工程师在面对线上故障时快速定位问题，不再受限于响应迟缓的传统工具。

宽事件 + 列式数据库，就是最优解

在我们此前的文章《基于 SQL 的可观测性现状》中，我们详细探讨了这一趋势。尽管当时还未有统一名称，但它正是今天“可观测性 2.0”的核心理念：以宽事件为基础的统一数据模型，而不是传统的“日志、指标、追踪”三大支柱。长期以来，不同类型数据被分散存储在多个系统中，导致关联复杂、维护繁琐、效率低下。而宽事件通过将所有可观测性信号统一封装到单条记录中，彻底打破了这一格局。

所谓“宽事件”，就是在单条记录中捕捉应用的全部上下文信息：用户标识、服务名称、HTTP 路径、返回状态码、缓存命中与否……所有内容一应俱全。这种统一结构不仅简化了数据管理流程，更是实现高基数数据快速查询与聚合的基础 —— 前提是你的存储引擎足够强大，能够高效压缩和处理这类结构化数据。

尽管一些 No-SQL 系统（例如搜索引擎）也尝试支持宽事件模型，但它们在聚合性能上始终存在短板 —— 虽然擅长搜索、可用于“海量数据中精准定位”，但面对大范围聚合分析场景则力不从心。而 ClickHouse 则始终保持其独门优势：列式存储架构、强大的编解码压缩库，以及专为分析型查询设计的并行执行引擎，让其在处理这类复杂场景时游刃有余。

资源友好，弹性扩展

在 ClickHouse Cloud 中，我们进一步采用了对象存储，实现了计算与存储的解耦。这对于将可观测性平台扩展到 PB 级乃至更大规模，并实现弹性伸缩，是至关重要的一步。为了满足更复杂的业务需求，我们还支持计算资源的多租户隔离 —— 用户可以为不同的工作负载（如数据写入与查询）分配独立的计算节点，虽然它们都在访问相同的数据源。

随着可观测性场景日益多样化，我们也意识到，对半结构化事件提供原生 JSON 支持已成为基础能力。为此，ClickHouse 不断演进，提供了一流的半结构化数据支持，并在此过程中保留了列式存储所带来的查询性能优势。系统会在新数据写入时自动创建列，并自动处理类型升级与列增长。这种写时建模（schema-on-write）机制，恰好满足了可观测性场景对高性能、强压缩和灵活性的三重要求。

OpenTelemetry：行业标准的兴起

ClickHouse 的这轮演进，恰好与 OpenTelemetry（OTel）的快速普及同步。如今，OTel 已成为跨日志、指标与链路追踪数据收集的事实标准。我们也正式加入该生态，开始支持并贡献 ClickHouse 的官方 OpenTelemetry Exporter。

OpenTelemetry 的出现，为整个生态带来了突破性的推进。它为数据的采集与导出提供了一种标准化、厂商无关的统一方式，同时通过 Collector 模块，可直接将数据发送至 ClickHouse —— 使用我们协同社区维护的 Exporter 模块。我们与社区紧密协作，确保该 Exporter 拥有良好的稳定性、可扩展性，并与 ClickHouse 的核心理念深度契合。

我们在早期实践中遇到的最大挑战之一，是如何设计 schema。可观测性数据并不存在统一适用的 schema，每个团队的查询模式、数据保留周期、服务架构都不尽相同。因此，Exporter 提供了默认的日志、指标和链路追踪 schema，适用于大部分通用场景。但我们也鼓励用户根据实际业务情况，对其进行自定义调整与优化。

补齐体验闭环的最后一块拼图

不过我们很快就发现，拥有一个强大的数据库、合理的数据模型和稳定的数据采集机制，还远远不够。工程师真正需要的，是一整套即用型的数据接入、可视化展示、告警能力，以及一个贴合日常工作流的用户界面。在此之前，大多数团队只能依靠 OpenTelemetry 负责采集，再配合 Grafana 展示数据。

这种方式虽然能满足基本需求 —— 事实上，我们自己的可观测性团队也已经用基于 ClickHouse 的方案替换了 Datadog，不仅节省了数百万美元的成本，整体成本压缩比例超过 200 倍。目前，我们内部的日志平台已经积累超过 43 PB 的 OpenTelemetry 数据，相关 schema 和主键设计都针对这一规模精细优化。这个实践充分验证了 ClickHouse 架构在性能与成本上的巨大优势，但我们依然认为，整体体验还有很大优化空间。

我们期待的是一个带有明确产品理念的方案 —— 能让用户更轻松开始使用，并提供清晰的操作路径。最关键的一点，是我们希望拥有一个专为 ClickHouse 打造的用户界面。它不仅能理解 ClickHouse 查询的高效构造方式，还能自动识别宽事件中的模式，提升用户体验的同时，又不掩盖 ClickHouse 强大灵活的底层能力。

此外，尽管我们一直强调 SQL 在推动宽事件可观测性模型中的重要作用，我们也明白，用户的使用习惯同样值得尊重。搜索引擎如 ELK 之所以成功，关键就在于它们提供了直观易用的体验 —— 尤其是那种类似自然语言的日志查询方式。我们也希望将这种体验带给用户，但在此基础上，提供的是由 ClickHouse 引擎驱动的强大能力。

正式集成 HyperDX：ClickStack 的关键拼图

就在我们寻求更完整用户体验的过程中，我们发现了 HyperDX —— 一个专为 ClickHouse 打造的开源可观测性平台。当 HyperDX 于 2024 年底开源其 v2 版本 UI 时，我们第一时间在内部进行了测试，迅速发现它正是 ClickStack 所缺失的那一环。部署过程顺畅，开发体验优秀，界面简洁、功能强大，我们深知用户也应获得同样的体验。

HyperDX 带来了我们一直期待的关键能力：

• 标准化数据采集：从项目初期，HyperDX 就全面支持 OpenTelemetry，与我们在 ClickHouse Exporter 上的长期投入高度一致。
• 开源优先理念：我们始终相信强大的可观测性工具应该对所有开发者开放，HyperDX 也秉持相同哲学。其云原生架构确保了运维上的简单、高效与低成本。

深度为 ClickHouse 优化：不仅仅是遵循标准，HyperDX 团队从一开始就围绕 ClickHouse 进行深度设计，尤其在查询优化方面表现出色，让用户无需自行处理复杂的调优。其 UI 与引擎深度耦合，确保在事故排查等关键场景下提供毫秒级响应能力。

结合 HyperDX 的 UI、内置 OpenTelemetry 数据接入能力，以及为其量身打造的 schema，ClickStack 将采集、存储和可视化整合为一个统一的体验平台。默认 schema 开箱即用，用户无需配置即可获得完整功能 —— 当然，也可以按需自定义字段与结构。

ClickStack 的模块化设计也意味着它可以按需横向扩展。如果你希望提升写入吞吐量，只需增加更多 OpenTelemetry 网关；如果你需要更强大的查询或存储能力，只需扩展 ClickHouse 实例。整个技术栈随着数据与团队规模的增长自如扩展，而无需大改架构。

自收购 HyperDX 以来，我们将重心放在简化产品体验与增强可配置性上。你既可以使用默认 schema 快速上线，也可以引入自定义 schema 满足特定业务需求。正如 ClickHouse 所展现的那样：可扩展性建立在灵活性之上，没有一套 schema 能适配所有用户场景。

与此同时，我们仍坚持 SQL 为核心。SQL 是数据领域的通用语言，对大多数 ClickHouse 深度用户而言，依旧是探索数据最具表现力、最高效的方式。因此，HyperDX 的界面原生支持 SQL 查询 —— 高级用户可以直接操控底层引擎，不做妥协。

为了进一步提升故障排查与数据探索能力，我们还引入了全新功能。例如“事件差异分析”（event deltas），它可以帮助用户迅速识别异常与性能回退。通过对某一字段的唯一值进行抽样比较，系统能直观展现出性能差异与偏移，让用户更容易理解系统中发生了哪些关键变化及其原因。

最重要的是，这一技术栈如今变得前所未有地简单。随着 OpenTelemetry 成为事实标准，所有数据都通过 OTel collector 统一接入。默认配置采用了经过优化的推荐 schema，可快速上手部署；当然，用户也可以根据需求进行修改或扩展。这个架构是为 OpenTelemetry 而生，但并不局限于它 —— 借助开放 schema，HyperDX 同样可以与您现有的数据管道和自定义 schema 无缝集成。

总结与未来展望

ClickStack 标志着 ClickHouse 在可观测性生态建设上的又一次重要进化 —— 一个直观、开源、具备明确设计理念的全栈可观测性解决方案。它将 ClickHouse 高性能列式引擎、OpenTelemetry 的标准化埋点体系，以及 HyperDX 的专属 UI 无缝整合，真正让现代可观测性能力触手可及，人人可用。

我们始终坚持开源开放的理念，确保 ClickStack 无论在单一微服务场景，还是多 PB 级别的大型系统中都可以平稳运行。未来，我们不仅会继续打磨 ClickHouse 数据库核心能力，以适应更高性能的可观测性需求，也会持续推进与 Grafana 等主流工具的集成，让 ClickStack 能与现有可观测性体系无缝衔接。

ClickStack 不只是一个可观测性工具，它是一个统一的基础平台 —— 所有遥测数据信号汇聚于一体，依托高性能的列式引擎，内置自然语言查询、会话回放与告警机制，真正实现即装即用，助力团队更高效地理解和优化系统运行状态。

征稿启示

面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com