ClickStack 更新：深度洞察，可观测性分析再升级！

欢迎阅读 ClickStack 三月更新一览。

每月，我们都会分享 ClickStack 的最新进展，涵盖从平台增强到旨在提升可观测性（observability）速度、简化操作并增强其能力的新功能。三月，我们带来了一系列广泛的改进：通过常驻的 Event Deltas 和更智能的属性评分，实现更深入的事件分析；全面扩展 SQL 图表类型，并支持 Grafana 风格的模板宏（template macros）以及导入/导出功能；对采样 Trace 数据 (trace data) 进行准确聚合；为在本地模式 (local mode) 下运行的用户提供持久化仪表盘 (persistent dashboards)；以及一系列仪表盘组织优化。

非常感谢我们的开源贡献者，以及所有用户，正是你们的反馈帮助塑造了这些功能，让 ClickStack 变得更好，惠及所有人。

新贡献者

一如既往，我们非常感谢所有开源贡献者，特别是本月首次加入，助力 ClickStack 惠及所有人的新成员。

[ZeynelKoca](https://github.com/ZeynelKoca)

[sanjams2](https://github.com/sanjams2)

[vinzee](https://github.com/vinzee)

[vinzee](https://github.com/vinzee)

[sanjams2](https://github.com/sanjams2) 

[ZeynelKoca](https://github.com/ZeynelKoca)

[matsilva](https://github.com/matsilva)

如果代码贡献并非您的兴趣所在，我们也非常欢迎您通过 [repository](https://github.com/hyperdxio/hyperdx) 提交文档改进、创意、功能建议、错误报告和一般性反馈。每一份贡献，无论大小，都将助力整个社区改进这个技术栈。

AI Notebooks (AI 笔记本)

本月早些时候，我们发布了 AI Notebooks (AI 笔记本)，这是一种创新方式，可将 AI 直接嵌入到结构化、Notebook 风格的工作区中，用于调查日志、指标和 Trace。这标志着我们向 ClickStack 内部的原生 Agentic 体验 (agentic experience) 迈出了第一步，AI 将在 SRE 工作流中充当协作者而非独立的界面。调查过程将逐步展开，结合自然语言 (natural language)、生成的查询和人工分析，同时确保工程师始终掌握主动权。

Managed ClickStack 的 AI Notebooks 目前正处于私有预览阶段，我们正与早期用户密切合作，以持续优化产品体验。欢迎大家提供宝贵反馈，助力我们不断完善此功能。如需了解更多信息，请查阅[公告文章](https://clickhouse.com/blog/clickstack-ai-notebooks)；如需申请访问权限，请通过[候补名单](https://clickhouse.com/cloud/ai-notebooks-in-clickstack-waitlist)提交申请。

Event Deltas 的改进

Event Deltas 是 ClickStack 中用于根本原因分析（root cause analysis）最强大的工具之一。它能够根据慢速或错误跨度（span）热图，识别并突出显示在选定区域中相对于整体背景异常突出的属性值。这对于 SRE (Site Reliability Engineer) 和开发人员调查生产问题至关重要，使他们能够快速定位导致性能下降或错误的属性及其关联的跨度特征。Event Deltas 无需手动切分数据或构建复杂查询，而是直接揭示关键信号，从而加速从发现症状到定位根本原因的过程。如需深入了解该功能的工作原理，请参阅我们的[专用博客文章](https://clickhouse.com/blog/faster-root-cause-for-slow-traces-with-clickstack-event-deltas)。

本月，我们针对该功能的使用体验进行了四项显著改进。

欲亲自体验这些改进，我们建议您访问我们的[演示环境](https://play-clickstack.clickhouse.com/search?source=3b743139&where=&select=&whereLanguage=lucene&filters=%255B%255D&orderBy=&mode=delta&isLive=false&from=1775654690000&to=1775741090000&xMin=1775666834.0190363&xMax=1775719838.3538175&yMin=1.7378845061203285&yMax=913.6388954631163)，您可以在其中使用 [OpenTelemetry 演示数据集](https://clickhouse.com/docs/use-cases/observability/clickstack/getting-started/remote-demo-data) 自行体验 Event Deltas。

此前，属性分布图只会在用户在热图上选择一个区域，并将其与背景跨度进行比较后才会生成。现在，视图会立即显示当前时间窗口内所有跨度（由蓝色的“所有跨度”柱表示）的属性及其值分布。这使得用户无需事先进行选择，即可立即发现整个数据集中的主要行为模式——即便热图保持稳定，没有明显变化时也同样适用。

当用户选择某个区域时，图表会切换到比较模式，通过红绿条来对比所选组与整体分布。这项功能对于日常数据探索以及调查特定假设（例如，关注具有特定状态码的 spans，或仅查看对 SQL 的客户端调用）都极具价值。

尽管表面上看只是一个小改动，但此功能却有潜力开启全新的工作流程。我们将后续发布一篇专门的博客文章，深入探讨我们对此功能的愿景，以及我们认为它将如何简化 ClickStack 中的调查工作流程。

当您点击并拖动选择一个区域时，图表会切换到比较模式，并显示红绿条，将所选组与背景进行对比。

根据诊断有用性对属性进行排名，实际上比看起来更具挑战性。之前的实现是根据最大原始增量进行排序的，当异常组和正常组的样本量不同时，这会产生误导性的排名结果。即使某个属性在两组中的分布完全相同，但如果其原始计数不同，它仍然可能排名很高。

举例来说，假设 `service.name = checkout` 在背景数据中出现了 1,000 次，而在所选区域中出现了 100 次；同时，`service.name = payments` 在背景中出现了 10 次，在所选区域中出现了 8 次。尽管这两个属性的比例分布非常相似，但 `checkout` 的原始增量要大得多，这导致其排名更高，即使它并非更能指示实际问题。在实践中，这意味着那些绝对计数较高的属性，往往会优先于那些与异常真正具有更强相关性的属性。

为此，我们现在采用了比例比较评分（proportional comparison scoring）方法，它会在计算增量之前，将每个组的百分比归一化至总和为 100%。如此一来，无论原始计数差异如何，只要属性具有相同的比例分布，其得分都将为零，这使得在组大小不相等的情况下，排名结果更为可靠。

Event Deltas 的真正价值不仅在于识别异常值，更在于解释它们为何与正常行为不同。通过将选定的 span 子集（即前景或异常值）与基线分布（即背景或正常值）进行比较，它能揭示哪些属性值与性能下降存在过度关联。这消除了手动进行筛选、分组以及跨列目视比较分布的迭代工作流的必要。

然而，过去一旦用户识别出可疑属性，后续步骤仍略显繁琐。将这种洞察转化为具体的查询、进行验证并继续深入调查，需要一系列手动操作。

为解决此问题，现在点击属性比较图表中的任意条形图，都会弹出一个操作浮窗，提供三个选项：包含该值、排除该值或将其复制到剪贴板。

这使用户能够立即根据 Event Deltas 的发现采取行动。例如，上方示例中的慢速 span 子集显示，93% 的异常值涉及 `card_type = Visa`，而背景中则以其他卡类型为主，这强烈表明存在与 Visa 相关的问题。包含该值允许用户隔离并检查这些有问题的 span，以确认假设。排除该值有助于验证性能在排除该因素后是否恢复正常，或揭示此前被掩盖的次级异常值。

Event Deltas 在构建热图时会对 span 进行抽样。此前，该过程使用 ORDER BY rand()，这意味着在两次渲染中，用户将鼠标悬停在同一区域时，可能会高亮显示不同的单元格，导致界面体验不稳定。现在，抽样改用 ORDER BY cityHash64(SpanId)，因此相同的查询总是会选择相同的 span 子集，从而使热图在不同交互中保持一致——这对于确保分析的可重复性至关重要。

带有 Grafana 风格宏的 SQL 图表 (SQL charts with Grafana-style macros)

查询构建器非常适合新手入门并满足常见需求，但它们本质上带有某种预设偏好。当查询变得日益复杂，涉及跨数据集连接、应用自定义聚合或表达细微的逻辑时，用户通常需要直接访问 SQL，以充分发挥 ClickHouse 的底层能力。平衡简单性与灵活性，一直是 ClickStack 关注的重点。

在过去几个月里，我们一直在稳步扩展对所有可视化类型中的 Raw SQL 图表支持。本月，我们完成了最后两种图表类型，并显著增强了为直接编写 SQL 的用户提供的功能集。

Raw SQL 现在已支持数字指标卡、饼图、折线图、表格图和堆叠柱状图——这是在上个月表格支持的基础上进一步扩展。用户现在可以通过自定义查询，充分利用 ClickHouse 强大的表达能力来驱动任何可视化类型，而不再局限于查询构建器 (query builder) 所支持的范围。

SQL 图表带来了极高的灵活性，使用户能够表达超出查询构建器 (query builder) 限制的复杂查询。与此同时，它们仍需与整个仪表板体验无缝集成，尤其要兼容全局过滤器 (global filters) 和时间范围 (time ranges)。若无法实现这一点，SQL 图表将很快与周围的上下文脱节。

为解决此问题，我们引入了一组在查询时展开的模板宏 (template macros)，其约定与 Grafana 用户所熟悉的一致。这些宏允许用户编写富有表现力的 SQL，同时自动继承仪表板当前的时间范围和活跃过滤器 (active filters)，从而确保所有可视化之间的数据一致性。

$__timeFilter(column) 会展开为指定列上的秒级精度范围谓词 (range predicate)。$__timeFilter_ms(column) 则以毫秒精度执行相同的操作。$__timeInterval(column) 会生成一个用于 GROUP BY 的 toStartOfInterval 表达式，该表达式会自动对齐到所选时间窗口的粒度。

$__filters 在查询时会被活跃的仪表板过滤器 (dashboard filter) 条件所替换。当没有过滤器处于活跃状态时，它会展开为 1=1，从而确保查询在没有任何条件逻辑的情况下依然有效。为了使过滤器自省 (filter introspection) 功能生效，图表上必须选择一个数据源。

使用这些宏的典型 Raw SQL 图表示例如下：

SELECT  toStartOfInterval(Timestamp, INTERVAL {intervalSeconds:Int64} second) AS ts, -- (Timestamp column)  ServiceName,                                                                     avg(Duration)                                                                        FROM $__sourceTableWHERE Timestamp >= fromUnixTimestamp64Milli ({startDateMilliseconds:Int64})  AND Timestamp < fromUnixTimestamp64Milli ({endDateMilliseconds:Int64})  AND $__filtersGROUP BY ServiceName, ts

宏 $__sourceTable 在查询时会解析为所选数据源的完全限定表名 (fully qualified table name)。这对于导入和导出工作流 (import and export workflows) 尤为实用。当一个包含 Raw SQL 图表的仪表板被导出并导入到不同的环境时，导入过程中应用的源映射会自动代入此宏，从而无需在导入后手动更新表引用。

该宏还支持一个指标类型参数：$__sourceTable(sum) 会解析为针对求和类型聚合的相应指标表。这在查询按聚合类型分区的 OpenTelemetry 指标表时非常重要。

外部 API 现在也全面支持原生 SQL 图表的所有五种显示类型：折线图、数字图、饼图、表格图和堆叠柱状图。团队现在可以通过 API 以编程方式管理仪表盘，并使用与基于构建器的图表相同的端点，创建和更新由 SQL 驱动的图块。

采样追踪数据的聚合

随着可观测性数据集的不断增长，许多高吞吐量系统会采用采样（Sampling）来控制存储和数据摄入成本。头部采样（Head-based sampling）和尾部采样（Tail-based sampling）都遵循相同的原则：只保留一部分 Span，而丢弃其余部分。头部采样通常在早期阶段，通过概率或简单规则做出决策；而尾部采样则在评估完整追踪后再决定保留哪些数据。尽管这两种方法在执行方式上有所不同，但它们都导致一个共同的结果：存储的数据集不再是完整的。

在 ClickHouse 中，由于其高压缩率和强大的大规模查询性能，对于许多工作负载而言，采样通常是不必要的。然而，在面对极大数据量时，仍有部分用户选择进行采样。但这带来了一个挑战：一旦数据经过采样，标准的聚合结果就会变得不准确。例如，计数会低估真实的数据量，平均值会偏向于被保留的 Span，而百分位数也无法再反映完整的数据分布。简而言之，除非在查询执行过程中将采样机制纳入考量，否则将无法保证统计结果的准确性。

为解决此问题，ClickStack 在数据源层面引入了采样感知聚合。由于采样是数据集固有的一个属性，我们允许用户直接在追踪数据源配置中定义如何解释采样数据。这通过一个 sampleRateExpression 来实现，该表达式会计算出每个 Span 的采样率，这个采样率通常会与每个 Span 一同存储，例如 SpanAttributes['SampleRate']。这种机制使得采样率可以在不同 Span 之间有所差异，同时仍能得到一致且准确的处理。

ClickStack 配置完成后，会自动重写聚合操作以纳入采样考量。例如，一个 count() 函数会被改写为 sum(weight)，其中 weight 代表采样率的倒数。平均值则通过空安全除法计算为加权平均值，总和会相应地进行缩放，百分位计算则利用 quantileTDigestWeighted 函数来保持分布的准确性。而 weight 值本身通过 greatest(toUInt64OrZero(toString(expr)), 1) 计算得出，这确保了缺失或无效的采样率能够安全地默认为一个有效值。

此修正会透明地应用于仪表板、警报、外部 API 以及 AI 驱动的摘要功能。通过在数据源层面一次性定义采样规则，用户可以一如既往地构建图表和执行查询，ClickStack 会确保结果在统计学上是准确无误的。

对采样数据集的简单计数操作被映射为采样率之和 - sum(greatest(toUInt64OrZero(toString(SpanAttributes['SampleRate'])), 1))

Dashboard template gallery and listing pages

随着 ClickStack 使用量的不断增长，团队创建的仪表板数量也日益增多。此前，仪表板主要通过侧边栏进行展示，这种方式在小规模部署中运行良好，但随着规模的扩大，导航变得愈发困难。用户经常难以发现已有的资源、高效组织仪表板，或者在不从头构建所有内容的情况下快速上手。

为解决这一问题，我们为仪表板和已保存的搜索引入了专门的列表页面。这些页面提供了所有资源的清晰且可搜索的视图，从而取代了之前扁平化的侧边栏模式。用户可以在这些页面上按名称进行筛选。

仪表板和已保存搜索的交互模式保持一致，侧边栏现在直接链接到这些视图页面，为用户提供了更具扩展性的方式来管理和浏览其可观测性资产。

在此基础上，我们引入了模板库 (template gallery)，帮助用户更快上手。该库提供了一系列精选的预置且可导入的仪表盘，适用于常见的运行时环境。首批模板涵盖了 OpenTelemetry 针对 JVM、.NET、Go 和 Node.js 的运行时指标。这些模板提供了一个即时的起点，使用户无需从头构建仪表盘即可立即可视化关键指标。每个模板都可用于任何通过 OpenTelemetry SDK 进行插桩的服务，在导入时仅需选择一个数据源。模板按标签分组，方便用户浏览和查找。

仪表盘和已保存搜索的收藏功能

在新的列表页基础上，我们还让用户能够更轻松地优先处理和快速访问最重要的仪表盘和已保存搜索。

仪表盘和已保存搜索现在可以被标记为收藏。收藏项会置顶显示在各自列表页的顶部，并固定在侧边栏中，方便即时访问。收藏功能基于用户独立存储，因此每位团队成员都可以独立维护自己的收藏列表。

仪表盘过滤器的改进

去年，我们引入了 [仪表盘过滤器](https://clickhouse.com/blog/whats-new-in-clickstack-october-2025#dashboard-filtering)，提供了一种简单的方式，可在仪表盘中的所有图表上应用全局过滤。这消除了在各个查询中重复过滤逻辑的需求，并显著简化了仪表盘的配置和重用。

本月，我们对过滤器进行了两项有针对性的改进，以使其更加灵活和高效。

过滤器现在可以包含一个可选的 WHERE 条件，该条件用于限制在填充可用过滤值时扫描的行数。这对于高基数 (high-cardinality) 字段或存在于大型数据集中的列特别有用。通过将查询范围限制在相关子集，即使在大规模使用场景下，过滤器下拉菜单也能保持快速响应。此改进适用于用户定义和预设的过滤器。

过滤器现在支持多值选择。这些值以 IN 子句（IN clause）的形式应用，例如 toString(environment) IN ('production', 'staging')。此前，过滤器仅限于单个值，导致在同一个仪表板（dashboard）中比较不同环境（environment）、区域（region）或服务（service）时非常不便。此次改进显著提升了仪表板在并排分析（side-by-side analysis）方面的灵活性。

本地模式下仪表板和已保存搜索的 localStorage 持久化

ClickStack 可以在本地模式（local mode）下运行，在此模式下，用户界面（UI）直接从浏览器连接到 ClickHouse，无需后端应用程序编程接口（API）。该模式支持 ClickHouse 二进制文件内部的嵌入式部署（此功能已于[上月](https://clickhouse.com/blog/clickstack-embedded-clickhouse)公布），也适用于希望获得最简易自托管配置的开发者。

在此之前，本地模式无法实现在页面重新加载时持久化仪表板（dashboard）或已保存的搜索（saved searches）。现在，我们新增了一个 createEntityStore 抽象层（abstraction），当本地模式（local mode）激活时，它会利用浏览器 localStorage 为所有仪表板和已保存的搜索操作提供支持。这意味着用户现在可以创建、编辑和保存可在会话间保持持久化的仪表板和搜索，而无需任何服务器或数据库。上文提及的新收藏夹功能也采用了相同机制。

更多图表显示单位

图表现在支持更广泛的显示单位种类，从而更清晰地展示各项指标（metrics），而无需依赖标题或别名来提供上下文信息。

本次发布显著扩展了数据大小、数据速率和吞吐量（throughput）的单位支持范围。它全面支持国际电工委员会（IEC）和国际单位制（SI）的字节（bytes）和位（bits）标准，支持从千字节（kilobytes）到拍字节（petabytes）的各种量级，以及对应的每秒等效单位。此外，吞吐量单位也已扩展，涵盖了常见的运营指标，如请求（requests）、操作（operations）、读取（reads）、写入（writes）和每秒输入/输出操作数（IOPS），并提供每秒（per-second）和每分钟（per-minute）两种形式。

现有格式，如数字、货币、百分比和时间，仍可在统一的“基础”（Basic）分组下使用，其中时间单位可继续支持精确到微秒（microseconds）和纳秒（nanoseconds）等细粒度单位。

/END/

试用阿里云 ClickHouse企业版

轻松节省30%云资源成本？阿里云数据库ClickHouse 云原生架构全新升级，首次购买ClickHouse企业版计算和存储资源组合，首月消费不超过99.58元（包含最大16CCU+450G OSS用量）了解详情：https://t.aliyun.com/Kz5Z0q9G