HyperDX：把日志、追踪与会话回放放到同一处排障

它解决什么问题

HyperDX 是一个开源可观测性平台，核心目标是帮助工程师在生产故障中更快建立线索。它把日志、指标、追踪、错误和会话回放放在同一套界面中，并以 ClickHouse 作为数据基础、以 OpenTelemetry 作为重要接入方式。对于已经使用 ClickHouse，或希望把多类遥测数据放在统一查询入口的团队，它值得纳入评估。

项目也被定位为 ClickStack 的组成部分。完整部署可以包含 ClickHouse、HyperDX、OpenTelemetry Collector 和 MongoDB；如果已有 ClickHouse 实例，也可以根据官方部署文档选择相应方案。仓库 README 同时给出了本地测试建议：至少准备 4GB 内存和 2 个 CPU 核心。这个数字只适用于测试建议，不应直接当作生产容量规划。

图片来源：hyperdx。项目公开截图，界面可能随版本变化。

已知功能与适合人群

HyperDX 支持在既有 ClickHouse schema 之上工作，减少了必须先重塑全部数据模型的压力。功能包括全文搜索、属性搜索、可选 SQL 查询、原生 JSON 字符串查询、异常事件趋势分析、告警、实时查看日志和追踪，以及面向高基数事件的仪表盘。它还覆盖从 HTTP 请求到数据库查询的应用性能监控场景。

需要跨日志、追踪和前端会话线索排查问题的开发团队、平台工程师和 SRE，可能更容易从这种统一入口中受益。数据接入方面，官方列出了 Browser、Node.js 和 Python SDK，并说明可通过 OpenTelemetry 接收来自 Kubernetes、JavaScript、Python、Java、Go、Ruby、PHP、.NET、Elixir 和 Rust 等生态的遥测数据。实际接入范围、字段映射和采集完整性仍应按目标项目逐项确认。

不习惯离开终端的用户还可以关注 HyperDX CLI。官方说明它提供交互式 TUI，可进行搜索、实时查看和追踪瀑布图，也能输出仪表盘图块与临时图表。CLI 的 0.7.0 release 新增了堆叠折线或堆叠面积时间序列显示类型。

采用前的限制与部署考虑

首先，HyperDX 不是“安装后自动拥有数据”的工具。应用仍需完成 SDK 或 OpenTelemetry 埋点，并把数据发送到对应实例；没有可靠采集、字段规范和保留策略，统一界面并不能替代遥测治理。若使用现有 ClickHouse，还应提前核对 schema、数据量、查询模式和保留周期，而不是只看 UI 是否能够启动。

其次，完整栈涉及多个组件。团队需要明确 ClickHouse、Collector、MongoDB 与 HyperDX 的职责、备份方式、升级路径和网络边界。README 提到防火墙场景需要处理 UI、API 和 OpenTelemetry Collector 相关端口；具体生产暴露方式、身份认证、反向代理和高可用设计，应以正式部署文档和自身环境验证为准。本文没有来源支持的生产容量、性能或安全结论。

此外，开源部署会收集匿名使用数据，项目说明可通过设置 USAGE_STATS_ENABLED 为 false 选择退出。组织在上线前应把这一行为纳入隐私、合规和网络审查。项目采用 MIT License，但依赖组件、数据留存以及会话回放中的敏感信息仍需要单独审查。

总体而言，HyperDX 更适合希望统一查询多类遥测、已经使用或愿意采用 ClickHouse，并能投入接入与运维工作的团队。它是否适合生产，不能仅凭功能清单判断，应先用代表性数据验证查询体验、采集完整性、成本与运行边界。

资料来源

• GitHub repository metadata
• Project README
• Official release
• Official project page

资料核对日期：2026-10-23