ClickStack 2026 年 5 月最新动态

摘要

欢迎阅读 ClickStack 五月更新。

五月和六月初，我们重点提升了仪表盘在调查过程中的实用性。仪表盘的表格链接功能引入了可点击操作，让用户能够直接从聚合视图跳转到搜索页面或相关的仪表盘。同时，作用域过滤器（scoped filters）使得构建多源仪表盘更为便捷，避免了所有过滤器全局生效的困扰。我们也拓展了仪表盘的自定义能力。数字磁贴（Number tiles）现在支持颜色、基于阈值的格式化和自动文本缩放，让重要信号一目了然。服务拓扑图（service map）也获得了重大更新，例如新增延迟百分位数（latency percentiles）、吞吐量指标、服务器端过滤功能，并引入新的焦点模式（focus mode）以探索依赖关系。除了仪表盘功能，我们还添加了一个 Browser RUM 仪表盘模板，对由 ClickHouse TimeSeries Engine 提供支持的 PromQL 进行了实验性支持，并推出了一大批新的 MCP 工具。

OpenHouse 公告

我们还在 Open House 上发布了几项重要的可观测性公告。

AI Notebooks 已面向 Managed ClickStack 用户进入测试阶段，提供了一个持久的调查工作区，工程师可以在其中整合提示（prompts）、查询（queries）、图表、推理和研究发现，并将其汇聚成一个可共享的工件。与此同时，我们还推出了 ClickStack MCP server，将 ClickStack 内部使用的可观测性工作流和调查原语（investigative primitives）开放给外部代理和 AI 工具。

我们还 宣布了 ClickStack Cloud，目前正处于私有预览阶段。ClickStack Cloud 是一个基于 ClickHouse 构建的完全托管的无服务器可观测性平台。

团队无需操心收集器（collectors）、数据摄入基础设施（ingestion infrastructure）、扩缩容策略、存储或 Schema 调优（schema tuning）等繁琐工作，只需将 OpenTelemetry 数据发送至托管端点，即可通过 ClickStack UI 立即开始探索日志、指标和追踪数据。

如果您希望获得由 ClickHouse 提供支持的可观测性，同时又不想操作底层基础设施，那么 ClickStack Cloud 旨在成为您的首选解决方案。

新贡献者

一如既往，感谢我们的新贡献者，并热烈欢迎大家加入社区。无论您是提交 pull request、提出 issue、分享想法，还是帮助他人，每一份贡献都让这个项目变得更好、惠及所有人。

dewly-justice, doyong365, dvjn, jordan-simonovski, nohupped

仪表板操作 (Dashboard actions)

表格往往是调查的起点，而非终点。当用户可以直接从一行数据跳转到工作流的下一步时，一个显示按服务划分的错误计数或按端点划分的延迟图表会变得更加有用。在此之前，点击表格行只能使用该行的“分组依据”(group-by) 值作为过滤器来打开搜索。虽然这很方便，但用户很难控制跳转的目标位置，或者上下文信息如何跨越不同视图传递。

本月，我们为表格组件（table tiles）引入了可配置的仪表板操作。现在，行点击可以针对特定数据源打开一个带有自定义 WHERE 子句的搜索。这两者都支持使用 Handlebars 模板来引用所选行中的值。此外，行还可以直接链接到其他仪表板，从而实现钻取（drilldown）工作流，让用户能够从高层级的操作视图跳转到更具体的仪表板。

此功能旨在像普通网页链接一样运作。配置了操作的行被渲染为 <a href> 元素，允许用户在点击前预览目标。短暂悬停后，ClickStack 会显示一个描述目标的工具提示，例如打开搜索或导航至仪表板。标准的浏览器行为也正常工作，包括在新标签页中打开链接、复制链接地址以及在浏览器状态栏中预览目标。在导入和导出过程中，仪表板和数据源引用也会自动重新映射，使得关联的仪表板可以在不同环境之间无缝迁移，无需手动更新。

数字可视化自定义调色板

数字组件（number tiles）通常是用户在仪表板上首先关注的内容，但在此之前，它们只能显示一个值和一个标签。一个数字是代表健康状态、警告信号还是正在发生的事件，都只能留给查看者自行解读。

数值图块现在支持自定义颜色和基于阈值的格式设置。图块可以被指定为固定颜色，或者配置为按序排列的阈值，当数值超出预设边界时，其外观会自动改变。这使得在仪表盘中直接突出显示关键绩效指标 (KPI)、错误率、延迟目标以及其他运营信号成为可能，而无需用户自行解读数字。

这些设置可在用户界面 (UI)、外部仪表盘 API (Application Programming Interface) 和 MCP 仪表盘工具中访问，确保程序化生成的仪表盘能够使用与手动创建仪表盘相同的视觉提示。我们还改进了数值图块的渲染行为，在空间受限时自动缩放文本，防止数值溢出较小的仪表盘布局。

实验性 PromQL 支持

ClickHouse 一直是日志、追踪和基于事件的指标的天然选择。在面向列的数据库中，宽事件能够实现极佳的压缩，而 ClickStack 的指标体验也一直围绕这一模型构建。与此同时，我们也认识到，某些工作负载拥有其既定的查询语言和操作实践。对于 Prometheus 用户而言，这种语言便是 PromQL (Prometheus Query Language)。

过去几个月里，我们一直在探索 ClickStack 内部原生支持 PromQL 的可能性。我们的目标不是强迫团队放弃现有工作流，而是允许使用许多工程师已经熟悉的语言来查询 Prometheus 风格的指标，同时将这些工作流与日志和追踪一并整合到单一界面中。

该实现基于实验性的 ClickHouse TimeSeries Engine 构建，该引擎 在每次发布中持续增强 PromQL 兼容性和功能。启用后，ClickStack 会预置一个 otel_metrics_ts 表，暴露兼容 Prometheus 的查询端点，并在 UI 中添加一个 PromQL 数据源和图表编辑器。团队可以通过 TimeSeries Engine 查询存储在 ClickHouse 中的指标，也可以配置外部兼容 Prometheus 的端点并通过 ClickStack 代理查询。

媒体链接: https://www.youtube.com/watch?v=Aw94UjX0LQM&t=13s

对于使用 Prometheus 构建指标管线的团队而言，即使他们的日志和追踪数据已位于 ClickStack 中，也一直需要独立的系统来查询这些指标。我们已开始探索如何将 PromQL 查询整合到统一的界面中，而本次发布则带来了这项功能的首次迭代。

这项工作仍处于高度实验阶段，随着底层时序数据库引擎的成熟，其存储模型和 API 接口都可能会持续演进。目前，该功能的覆盖范围正在逐月改善，我们也在积极评估 PromQL 如何更好地融入 ClickStack 的整体体验中。如果你有兴趣测试此功能、参与其未来方向的讨论，或者有希望我们验证的 PromQL 查询语句，我们期待你的反馈。

可配置事件模式

事件模式是理解海量日志和追踪数据最快捷的方法之一。ClickStack 无需用户手动翻阅成千上万甚至数百万条独立事件记录，而是能自动将相似消息聚类成少数具有代表性的组。

借此，用户可以更轻松地识别周期性错误、发现新问题、理解导致流量激增的原因，并快速总结服务生成的事件类型，而无需编写正则表达式或维护繁琐的解析规则。

此前，模式分析仅支持对专用的消息或正文列中的文本进行聚类分析。如果需要分析的值存储在其他位置，例如 URL 路径、异常类型、端点名称或自定义属性等，则无法引导模式分析引擎使用这些数据源。

现在，用户可以直接从事件模式视图中选择任意列作为模式分析的源数据。这使得对更广泛的可观测性数据进行聚类和汇总成为可能，为传统日志消息分析之外的场景开辟了新的工作流程。

浏览器 RUM 体验

许多 ClickStack 用户已经使用 HyperDX Browser SDK 或其他 OpenTelemetry 浏览器代理为其前端进行埋点，收集会话回放、页面性能指标、JavaScript 错误以及用户交互数据。此前，这些用户不得不从零开始构建自己的仪表盘。其中最常见的诉求之一，便是希望拥有类似于 ClickStack 附带的开箱即用 (out-of-the-box) Kubernetes 仪表盘的浏览器可观测性体验。

本月，我们将在仪表板库中推出一个浏览器 RUM (Real User Monitoring) 仪表板模板。该模板为监控前端应用程序提供了一个现成的起点，涵盖了大多数团队首先关注的领域：Core Web Vitals、页面加载性能、前端错误、流量细分以及用户体验指标。

该仪表板包括 p75 Core Web Vitals 指标，如 LCP、INP 和 CLS；页面加载百分位数；长任务计数；JavaScript 异常；API 故障；以及按 URL、浏览器、国家和设备尺寸等维度细分的流量。与其他 ClickStack 模板一样，它包含仪表板级别的过滤器和下钻工作流，允许团队无需修改单个图块，即可从应用程序运行状况的宏观视图深入到特定页面、环境、版本或用户细分。

该模板要求传入的 Span 具有 rum.sessionId 资源属性。使用 HyperDX Browser SDK 进行检测的应用程序会自动发出此属性。

Y 轴自适应数据范围

默认情况下，折线图会将 Y 轴固定在零点。这在比较绝对值时通常是正确的选择，但当指标在一个狭窄范围内波动时，它会使细微的变化难以察觉。延迟、CPU 利用率、缓存命中率以及类似的信号，尽管随着时间推移存在显著变化，最终仍可能看起来几乎是平坦的。

新的 Y 轴自适应数据范围 显示选项允许折线图将 Y 轴缩放到数据的可见范围。这使得趋势、回归以及短期波动更容易被发现，同时不改变底层查询和数据。

跟踪视图的改进

跟踪视图 (Trace View) 仍然是 ClickStack 中使用最频繁的部分之一。我们收到了大量用户反馈，尤其是那些从 Jaeger 迁移过来的用户，对于他们而言，导航和理解 Trace (跟踪) 是核心的可观测性 (Observability) 工作流。因此，过去一个月我们投入了大量精力优化跟踪体验，重点是加快调查速度，并减少处理大型跟踪时所需的导航操作。

最显著的变化是重新设计的布局。此前，选择一个 span 会在瀑布视图下方显示其详细信息，这常常导致重要信息超出可视区域。现在，追踪视图 (trace view) 采用了分窗格布局，左侧显示瀑布图，右侧则同步显示 span 详细信息。这使得用户在检查 span 的同时，也能保持完整的追踪结构可见。

我们还为追踪视图增加了全屏模式，让用户有更多空间探索包含数百甚至数千个 span 的复杂追踪。Span 详细信息现在划分为“概览 (Overview)”、“列值 (Column Values)”和“基础设施 (Infrastructure)”专用选项卡，并可在数据可用时自动展示 Kubernetes 基础设施相关信息。除了布局调整，我们还重构了时间线渲染功能，以确保在不同缩放级别下，轴标签和间距保持一致，无论追踪规模如何，都能使追踪导航更为顺畅。

服务地图改进

自去年推出服务地图 (service map) 以来，我们投入了大量时间收集用户反馈，深入理解服务地图如何融入实际的故障排查流程。真正的挑战从未在于如何绘制一张图，而是如何让这张图足够实用，成为工程师在故障发生时着手调查的起点，同时，还要确保它在 ClickHouse 规模下仍能保持高效计算能力。

本月，我们大幅扩充了服务地图中可用的信息。除了请求计数和错误率之外，服务现在还可显示吞吐量，以及 P50、P95 和 P99 延迟，这使得用户可以直接从拓扑视图中，更轻松地识别出过载或性能下降的服务。

我们还引入了过滤和聚焦 (Focus) 控件，以使服务地图在大型环境中更具实用性。用户可以通过服务选择器或 Lucene/SQL 过滤表达式筛选服务，从而减少冗余信息，将视图聚焦到他们关注的系统。新增的“聚焦 (Focus)”操作允许用户将任意服务设为地图中心，仅展示该服务及其直接依赖项。对于拥有数十乃至数百个服务的组织而言，这些新增功能显著简化了从宏观架构概览到目标性排查的过渡。

MCP 服务器工具投资

自 Open House 活动发布 ClickStack MCP 服务器以来，我们持续扩展其可观测性能力的广度和深度。尽管通用 SQL 接口功能强大，但我们发现，当 AI 智能体能够访问更高层次的可观测性原语，而不是被迫从原始查询中重构复杂的调查工作流时，它们的表现会显著提升。ClickStack MCP 服务器直接暴露这些工作流，允许智能体使用专为可观测性设计的工具，对 traces（追踪）、patterns（模式）、anomalies（异常）、dashboards（仪表盘）和 operational artifacts（运维工件）进行推理。

本月，我们新增了用于追踪分析、事件比较、源发现和仪表盘管理的新工具。现在，智能体可以直接通过 MCP 接口检索追踪瀑布图和分解详情，比较不同时间窗口的事件分布，检查源 schema 和样本数据，并创建或修改仪表盘。我们还为搜索工作流引入了降噪选项，通过抑制原本会主导调查的重复高频事件，帮助智能体专注于有意义的信号。

我们还投入开发了一个内部评估框架，该框架对调查质量、工具使用情况和响应准确性进行基准测试，帮助我们识别智能体遇到困难的环节，并衡量随时间推移的改进。

直接读取优化，加速属性搜索

我们在四月引入的一项重要性能改进是 OpenTelemetry 属性搜索的直接读取优化。OpenTelemetry 将其大部分元数据存储在灵活的属性映射中，这虽然非常有利于 schema 的灵活性，但传统上高效搜索的成本较高。这项优化允许 ClickStack 将属性过滤器重写为直接与 ClickHouse 文本索引对齐的形式，从而显著减少了搜索操作期间需要读取的数据量。在我们的基准测试中，受影响的查询根据工作负载的不同，运行速度提升了 1.4 倍到 10 倍。

该功能首次推出时采用按需启用（opt-in）模式，因为它依赖于配套的 materialized columns，这会增加存储开销。随着 ClickHouse 改进后允许相同的方法与 ALIAS columns（无存储开销）协同工作，此限制现已取消，该优化功能默认对日志（logs）和追踪（traces）数据源启用。大多数部署无需进行任何配置。如需更深入了解此优化功能的运作原理、其背后的基准测试以及所涉及的 ClickHouse 索引技术，请参阅我们的四月更新。

作用域限定的仪表盘过滤器

仪表盘层级的过滤器是实现仪表盘交互性的强大功能，但它们最初是为单一数据源仪表盘设计的。随着越来越多的用户开始将日志（logs）、追踪（traces）、指标（metrics）和自定义数据源组合到一个视图中，一个常见问题浮现：对某个数据源有意义的过滤器，对其他数据源往往毫无意义。例如，针对 SpanName 的过滤器可能对追踪图表很有用，却可能导致日志图表返回空值或意外结果。

仪表盘过滤器现在可以限定作用域到特定数据源。当一个过滤器配置了数据源作用域时，只有使用这些数据源的图块（tiles）才会应用该过滤器。所有其他图块将完全忽略它。这极大地简化了多数据源仪表盘的构建过程，确保每个过滤器只作用于其预期的图表，避免在其他地方引入令人困惑的交互。现有的仪表盘将继续保持原有行为，未限定作用域的过滤器仍将全局应用于所有图块。

实用小改进

随着 ClickStack 部署规模的增长，数据源列表可能会变得难以管理。现在可以将数据源分配到分区（sections），从而使相关数据源能够更便捷地分组和搜索。无论是按照环境、团队还是应用程序进行区分，现在都能更轻松地找到所需的数据源。

搜索过滤器现在可以直接就地编辑。用户无需先移除现有过滤器再从头创建，只需点击过滤器标签（filter pill），即可打开一个内联编辑器，从而在调查过程中更快速地细化搜索条件。

在映射时间戳、日志级别和消息体等字段时，源配置现在会从已连接的源中智能推荐匹配的列。这使得新源的设置过程更快，并能有效减少配置错误。

仪表盘导出功能现在会保留当前激活的仪表盘级别过滤器，确保导出的仪表盘能够捕获视图的完整状态，而不仅仅是底层图块。此外，导入时也增加了验证机制。

大型仪表盘现在配备了右侧目录，清晰展示所有部分，从而极大地简化了导航。此外，各部分还支持批量展开或折叠操作。

当用户将某个图块切换到不同的数据源时，ClickStack 会保留对新数据源依然有效的过滤器，而仅删除那些引用了不可用列的过滤器。

/END/

关于我们

ClickHouse（clickhouse.com) 是面向 AI 时代打造的高性能实时分析数据库，能够以极致性能处理海量数据分析任务。凭借高并发、低延迟和云原生架构，ClickHouse 广泛应用于可观测性、数据仓库、实时分析及 AI 数据基础设施等场景。我们致力于帮助企业在公有云平台上构建安全、弹性且高性价比的实时分析与 AI 数据平台，加速释放数据价值，推动智能化创新与数字化转型。目前，Trip.com、DiDi、Meta、Sony、Netflix、Deutsche Bank、Sierra、Cloudflare 等全球领先企业均在使用 ClickHouse 支撑其关键业务和数据分析平台。