HyperDX：把日志、链路和会话回放压进 ClickHouse 的观测平台

它解决的是工具割裂和数据成本两个问题

HyperDX 的出发点很直接：生产环境出问题时，工程师要在日志系统、APM、会话回放和异常跟踪之间来回切换，自己把线索拼起来。README 里明确说，现有工具要么太贵，要么需要全职 SRE 才能搭起来。HyperDX 把日志、指标、链路、错误和会话回放放进同一个界面，并且直接跑在 ClickHouse 上。它的目标用户是那些已经为 ClickHouse 付过钱、想让同一套基础设施承担可观测性负载的团队。它不是一个从零开始的存储引擎，而是 ClickHouse 之上的查询和可视化层，这个定位决定了它的成本和能力边界。

Schema 无关的查询机制：SQL 可选，语法贴近直觉

HyperDX 不要求预定义表结构，它声称 schema agnostic，直接查询你现有的 ClickHouse schema。查询语法支持类似 level:err 这样的属性搜索，也支持原生 JSON 字符串查询，SQL 不是必须的。这意味着你可以用接近自然语言的方式过滤日志，而不需要记住字段名。底层还是 ClickHouse 的 SQL，但 HyperDX 把它包了一层。README 强调它针对 ClickHouse 做了搜索和可视化优化，比如 event deltas 用来分析趋势异常，dashboard 支持高基数事件而不需要复杂查询语言。这种设计对不熟悉 SQL 的开发者友好，但代价是，如果你需要精细控制查询计划，最终还是得回到 SQL。

一条命令启动，但生产部署要读 ClickStack 文档

本地体验非常简单。README 给出的命令是：docker run -p 8080:8080 -p 4317:4317 -p 4318:4318 docker.hyperdx.io/hyperdx/hyperdx-all-in-one。启动后访问 http://localhost:8080 就能看到 UI。这个 all-in-one 镜像包含 ClickHouse、HyperDX、OpenTelemetry Collector 和 MongoDB，适合测试。但生产部署不是这么回事，README 明确指向 ClickStack 的部署文档，那套体系由 ClickHouse 官方维护。如果你已经有自己的 ClickHouse 实例，或者想用 ClickHouse Cloud，需要去 clickhouse.com 的文档里找对应方案。防火墙要开三个端口：8080 给 UI，8000 给 API，4318 给 OTel Collector。测试环境建议至少 4GB 内存和 2 核。

OpenTelemetry 是接入的默认路径，SDK 覆盖常见语言

HyperDX 兼容 OpenTelemetry，这是它降低接入成本的关键。你不需要装专有 agent，只要把 OpenTelemetry SDK 指向 HyperDX 启动时自带的 Collector，地址是 http://localhost:4318。README 列出的支持语言包括 JavaScript、Python、Java、Go、Ruby、PHP、.NET、Elixir、Rust，以及 Kubernetes。这意味着你现有的 OpenTelemetry 埋点可以复用。同时 HyperDX 也提供自己的 Browser、Node.js 和 Python SDK，文档链接指向 ClickHouse 的 ClickStack 文档。对于已经用 OpenTelemetry 的团队，迁移成本很低；对于还没埋点的团队，选择 OpenTelemetry 本身就是一种长期投资。

CLI 和 TUI：终端用户和 AI agent 的入口

HyperDX 没有把终端用户晾在一边。它提供了一个 npm 包 @hyperdx/cli，安装后可以运行 hdx auth login 和 hdx tui。TUI 支持 vim 风格按键，能搜索、live tail 和查看 trace waterfall。更值得注意的是它宣称 agent-friendly，支持 raw SQL 查询、NDJSON 输出和 Drain log pattern mining，这些是为脚本和 AI agent 准备的。这意味着你可以把 HyperDX 的数据接进自动化流程，而不只是人看 UI。对于运维自动化或者想用大模型分析日志的团队，这是一个实际的加分项。但 CLI 的完整命令参考在 packages/cli 的 README 里，需要单独阅读。

一个真实的限制：匿名使用数据默认开启

README 里有一节专门讲 HyperDX Usage Data，它说 HyperDX 会为开源部署收集匿名化使用数据。这个数据用于支持项目发展和让开源产品适应不同环境。原文在 truncated 处截断，所以具体收集了什么、如何关闭，需要去部署文档里查。这是一个明显的隐私边界。如果你的组织对数据外发敏感，哪怕是匿名数据，也得先确认关闭方法。另一个限制是，HyperDX 不是全托管的 SaaS，它需要你自己维护 ClickHouse 和 MongoDB，除非你用 ClickHouse Cloud。对于不想碰基础设施的团队，这可能是错误的选择。

替代方案：Elastic 系和托管 APM 的取舍

如果把 HyperDX 和 Elastic 的 Kibana 做对比，README 自己就说了，它像是 ClickHouse 的 Kibana。Kibana 跑在 Elasticsearch 上，查询语法是 Lucene 和 ES DSL，而 HyperDX 跑在 ClickHouse 上，查询语法更接近属性和 JSON 操作。Elasticsearch 的生态更成熟，插件和文档都多，但资源消耗通常更高。另一个替代是商业 APM 如 Datadog 或 New Relic，它们提供全托管体验，但价格随数据量上涨，这正是 HyperDX 想解决的痛点。HyperDX 的取舍是：你接受自己运维 ClickHouse，换取更低的存储成本和统一的查询层。如果你已经有 Elasticsearch 团队，迁移到 ClickHouse 不一定是净收益。

维护与升级：版本节奏快，但文档分散

从 recent releases 看，HyperDX 的发布频率不低，2026 年 8 月底有多个包更新，包括 @hyperdx/otel-collector@2.37.0、@hyperdx/hdx-eval@0.3.3 和 @hyperdx/common-utils@0.28.0。这意味着它不是一个停滞的项目，但频繁发布也带来升级成本，尤其是当你自己部署 all-in-one 镜像时，需要跟踪新版本。文档分散在 ClickHouse 的 ClickStack 体系里，而不是集中在 hyperdx.io，这会让排查问题变得麻烦。许可证是 MIT，对商业使用友好，但 README 没有提到任何商业支持渠道，只有 Discord 和 GitHub Issues。如果你需要 SLA 级别的支持，HyperDX 开源版可能不够。

编辑结论

HyperDX 适合那些已经拥有 ClickHouse 集群、希望在不引入独立日志存储的情况下统一日志、链路和会话回放的团队，尤其是中小型后端团队，他们愿意用 OpenTelemetry 标准做埋点，并且能接受一个相对年轻的界面。不适合完全没有 ClickHouse 经验、要求开箱即用 SaaS 体验、或者对数据采集有严格合规要求的组织，因为匿名使用数据默认开启，且部署文档分散在 ClickHouse 的 ClickStack 体系里。采用前需要验证三件事：第一，你的 ClickHouse 版本是否匹配 HyperDX 的查询优化，尤其是 JSON 字符串查询和 event delta 分析；第二，防火墙需要开放 8080、8000 和 4318 三个端口，确认你的网络策略允许；第三，阅读部署文档中关于匿名数据收集的部分，决定是否需要关闭。HyperDX 的价值在于把 ClickHouse 变成可观测性后端，而不是重新发明存储，所以它的成败取决于 ClickHouse 的运维水平，而不是这个项目本身的代码量。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes