指数直方图指标
现已初步支持查询 OpenTelemetry 指数直方图指标。此前，您可以在 source 上注册此类指标，但无法对其进行查询。现在可通过查询构建器使用计数和分位数。
指数直方图与显式桶直方图类似，但其桶边界根据 2 的幂计算，而不是为每个桶单独存储。标度决定使用哪个 2 的幂。标度越高，桶越小；偏移量则会将边界移向更高或更低的倍数。每个桶计数记录落在该范围内的观测值数量。
最大值、最小值、总和及平均值仍不受支持，这与现有的显式直方图实现一致。这些字段在 OpenTelemetry 数据模型中是可选的，因此我们不依赖它们存在。
如演示所示，生成的 SQL 很长，也不太美观。它的性能尚可且不会耗尽内存，但目前仅提供初步的功能支持。下一步将着重优化性能；更新后的 schema 已在开发中，预计可显著加快这些查询。
目前，只有时间序列显示类型能够正确渲染。这与现有的直方图指标类型一致。
相关 PR：#2687 feat：在指标名称下拉菜单中显示指数直方图指标，#2697 feat：为指数直方图指标实现分位数和总和，#2705 feat：在 MCP 中支持指数直方图，#2707 fix：支持按非 Attribute 列对直方图分位数聚合进行分组
原始 SQL 图表验证
现在，如果缺少预期的宏，原始 SQL 图表会发出警告。这项改动源于一个支持请求：有用户在创建大量原始 SQL 图表时，反复遇到令人困惑的结果。
仪表盘查询应包含过滤器和源表宏。时间序列图表还应包含时间范围和时间间隔宏。此前，这些检查仅在卡片关联 alert 后才会执行。现在，这些检查会对每个原始 SQL 图表执行，因此移除宏时，编辑器会显示警告，而不会在之后生成令人费解的图表。
验证还会考虑每个宏的依赖项。源表和过滤器宏需要选择 source，尽管原始 SQL 图表本身并不需要 source。因此，未选择 source 就使用任一宏会产生 error，而非警告。
这是一项小改动，但应该能让原始 SQL 问题更容易发现，无需通过支持团队排查。
相关 PR：#2742 feat：在 SQL Editor 中针对缺失的 params/macros 发出警告
通过名称而非 ID 链接到 source
LogHouse 团队希望采用更稳定的方式链接到 source。他们负责运行 ClickHouse Cloud 的日志环境，并通过基础设施即代码以编程方式配置 source。重新创建 source 时，其 ID 会发生变化，且在开发、暂存和生产环境中各不相同，因此任何基于 ID 的链接都不够可靠。由于他们会从告警系统和 Grafana 链接到 ClickStack，为每个环境维护一套独立的 source ID 并不现实。
source URL 参数现在除了接受 ID 外，也接受 source 名称。source 在配置时即可确定名称，因此同一链接可在所有环境中使用。该支持最初仅添加到搜索页面，后续 PR 将其扩展到所有包含 source 参数的页面，包括 Chart Explorer、服务地图、会话、服务仪表盘和 Kubernetes dashboard。
后续讨论主要围绕可发现性展开。这实际上是一个 URL API，用户不太可能偶然发现它。一种方案是默认使用名称而非 ID，但名称冲突会带来风险。其他建议包括通过共享按钮提供链接、让智能体通过 MCP 生成链接，以及完善 URL API 文档。相对时间范围也将受益于同样的文档说明。
基于名称的引用还可以扩展到仪表盘。这样，基础设施即代码工作流便可配置 source、导入仪表盘并自动完成所有关联。通过 UI 导入仪表盘时已会按名称匹配 source，因此剩余缺口主要在于编程式工作流。
相关 PR： #2746 feat：URL 参数中除 ID 外也接受 source 名称，#2758 feat：在其他页面中支持 source 名称深链接
图表显示设置重新设计
关于图表显示设置应放在哪里的工作仍在推进。最初的改动将其以内联形式移至卡片编辑器右侧，而非在单独的抽屉面板中打开。此前，卡片编辑器采用模态框形式，Display Settings 会在其上方的抽屉面板中打开。按一次 Escape 会同时关闭两者，而在模态框上方再叠加抽屉面板始终不太合理。
当系列设置也需要在上方叠加时，该 PR 变得更加复杂，因此我们退后一步，开始从更全面的角度审视页面。这项工作仍处于线框图阶段。当前设计将设置放入停靠面板，并自动应用更改，让你无需按 Apply 按钮即可实时查看结果。
计划是在将重新设计方案重新纳入现有 PR 前完成它。目前的实现被视为原型，尤其是因为新设计还会更改仪表盘页面的部分内容。
相关 PR： #2721 feat(dashboards)：将卡片编辑器移至带停靠设置面板的抽屉中
全新的 Explore 页面
这是对统一 Explore 页面的早期探索，未来可能通过单一入口取代搜索、已保存的搜索和 Chart Explorer。
此次滚动发布借鉴了我们从重新设计 trace 查看器中获得的经验。新页面不会一次性改变所有人的使用体验，而是会先通过功能标志向一小部分用户推出。我们会利用这段时间发现并修复问题，再逐步扩大发布范围。如果这个想法不可行，它就会停留在实验阶段，不会正式发布。这同样是完全合理的结果。
页面首先选择信号类型。选择链路追踪、日志或指标后，其余体验会相应调整。例如，选择日志后，你将看到目前 Chart Explorer 中提供的列表视图、事件模式、时间序列和其他可视化。
调查应能在不切换页面的情况下持续进行。你可以先从列表开始，转到数值或分组表，将结果添加到仪表盘；如果需要更精细的控制，再编写自定义查询。
其中还包含了一些较小的改进，大多来自用户反馈。查询编辑器的工作方式将更接近 SQL Editor，消除当前自动补全行为上的差异。错误和警告会在编辑时显示，而无需等到查询运行后才出现。
列将提供专用选择器。至少有一位用户没有意识到，更改
SELECT 子句可以控制表中显示哪些列。使用选择器后，单击字段即可更新 SQL，并可按该字段排序。SELECT 子句仍会为高级用户保留。
已保存的视图也将放在该页面中，因此你可以先探索而不保存，然后直接保存当前视图。生成的 SQL 将以内联形式显示。
目前仍缺少不少内容，包括当前 Chart Explorer 中提供的一些可视化。随着这些部分的加入，设计还会继续变化。
**相关 PR：**暂无；这是一项探索，并非已发布的功能
仪表盘过滤器联动
仪表盘过滤器联动功能已合并。数月前我们曾以草稿形式首次演示该功能，随后在评估性能影响期间暂停了开发。联动会改变仪表盘查询的形态，且不一定能充分利用 materialized views，因此将以可选 toggle 的形式提供，而非默认启用。
启用联动后，在一个过滤器中选择某个值会缩小其他过滤器的可选值范围。选择某个 service 后，仅保留该 service 中存在的严重性值。选择某个 trace ID 后，仅保留相关的 parent trace ID。这可避免用户选择不会返回任何数据的组合。
后续 PR 让联动具备 source 感知能力。过滤器会按 source 分组，能够相互缩小范围的相邻过滤器之间会显示链状图标。在包含两个日志过滤器和两个 trace 过滤器的仪表盘中，应能清楚看出哪些过滤器会相互联动。
最初的用例是 Kubernetes dashboard。选择一个 pod (容器组) 后，应仅保留包含该 pod (容器组) 的 deployments 和节点。缩小范围后的值会在打开下拉列表时按需拉取，从而控制额外 lookup 的开销。
讨论中留下了两个待解决的问题。该设置目前按用户存储在浏览器存储中。会议中预计，用户最终会希望将其保存到仪表盘级别。如果确实如此，按用户保存的偏好最好仅作为临时设置，以免日后与仪表盘级行为冲突。
另一个问题是，依赖过滤器在加载其值时应如何表现。当前选择某个值后，会在依赖下拉列表中显示加载状态，而不会阻止操作；不过第二个依赖过滤器的行为仍需验证。倾向于在缩小范围的过程中保持过滤器可用，并提示列表尚未完成更新。已知所需值的用户不应为了等待 metadata 而受阻。
相关 PR： #2423 feat(dashboards)：级联 (分面) 过滤器值，#2760 feat(dashboards)：持久化过滤器联动 toggle，并明确 source 内联动
记住上次使用的侧边面板选项卡
本周最小的 PR 也很好地说明了一个值得修复的小问题。
行侧边面板始终在 Overview 选项卡中打开，该选项卡是围绕 OpenTelemetry 日志字段设计的。对于不具备 OTel 形态的日志，该选项卡几乎不显示有用信息。每次打开一行时，都得切换到列值选项卡。
现在，面板会记住你上次使用的选项卡，并在下次打开时自动恢复。无需任何配置。非 OTel 用户切换到列值选项卡后会一直停留在那里，而使用 Overview 的用户则保持原有行为。
相关 PR：#2752 feat(app)：跨多次打开记住上次使用的侧边面板选项卡