Grafana Mixed数据源面板时间范围更新问题修复

概述

在 Grafana 的仪表板中，Mixed 数据源（Mixed datasource）面板允许在一个可视化中组合来自不同数据源的查询。本修复（backport 自 PR #124665）解决了一个关键的前端数据流竞争问题：当用户更改仪表板时间范围时，使用了“— Dashboard —”数据源的 Mixed 面板可能无法重新渲染新时间范围内的数据，而是卡在旧数据上。该问题源于 RxJS 数据流中对“完成（Done）”事件的过早处理，是一个典型的异步数据流同步时序错误。修复对于保证监控数据的实时性和准确性至关重要，直接影响用户对仪表板数据的信任度。

核心概念

要理解此问题，需了解以下关键概念：

  1. Mixed 数据源（Mixed Datasource）：一种特殊的Grafana数据源类型，它充当“路由器”，将用户定义的多个子查询分发到不同的后端数据源，并将结果“链式（Chain）”组合。
  2. SceneQueryRunner 与 ReplaySubject(1)：SceneQueryRunner 是负责执行查询的场景对象。它使用 RxJS 的 ReplaySubject(1) 来暴露查询结果，该主题会缓冲最近一次发射的值（包括状态）。当新的订阅者（如仪表板数据源适配器）订阅时，会立即收到该缓冲的、可能是陈旧的完成状态。
  3. 竞争条件（Race Condition）：问题的核心在于，当用户更改时间范围时，以下顺序发生了错误的交叉：
    • 仪表板数据源向 SceneQueryRunner 发起新查询。
    • 仪表板数据源同时订阅其结果流。
    • 订阅动作立即触发了 ReplaySubject(1) 中缓冲的、上一次查询的完成状态（Done）。
    • 系统内部的 emitFirstLoadedDataIfMixedDS 操作符匹配到这个“完成”信号，并认为数据已加载完毕，从而关闭了本次数据流的订阅（complete）。
    • 此时，新的查询可能还在上游缓慢执行中，其真正的“完成”事件稍后到达，但数据流已关闭，无法被处理。
  4. emitFirstLoadedDataIfMixedDS 操作符：这是一个自定义的 RxJS 操作符，设计用于在 Mixed 数据源链中，一旦收到第一个“成功（Done）”或“错误（Error）”事件，就终止（complete）该子流，以确保 Mixed 链能快速组合数据。错误的实现导致了上述竞争。

实践

此修复在 datasource.ts 文件中引入了一个关键的过滤步骤，具体实现如下：

  1. 引入范围校验辅助函数：添加了一个名为 isSameRange 的辅助函数，用于比较两个时间范围对象是否相同。
  2. 在 Mixed 数据源路径添加过滤：在 emitFirstLoadedDataIfMixedDS 操作符之前，添加了一个 filter(...) 操作符。该过滤器会丢弃（filter 出去）那些“终止状态（Done/Error）”的事件，但仅当这些事件对应的上游请求时间范围与当前 Mixed 链发出的请求时间范围不一致时。
  3. 作用域限定：此过滤器仅应用于 Mixed 数据源的查询路径。代码通过检查 requestId 是否包含 MIXED_REQUEST_PREFIX 来实现此限定。非 Mixed 数据源路径不受影响，因为：
    • 非 Mixed 路径自然依赖于新数据的到来来重新发射。
    • 带有 PanelTimeRange 覆盖（如 timeFrom， timeShift）的面板，其观察的时间范围本来就可能与上游不同，如果在此处应用过滤会导致其永久处于“加载中”状态。
  4. 验证与测试：修复通过了所有现有测试，并新增了 3 个回归测试用例来专门验证此竞争条件。所有 lint、类型检查和本地测试均通过。

SRE 要点

与可靠性的关联

  • 数据准确性：此 Bug 直接导致仪表板面板显示过时的数据，这是可观测性系统中的严重可靠性缺陷。SRE 可能基于错误的数据做出判断或告警。
  • 用户体验：面板无响应或显示陈旧数据会破坏用户对监控平台的信任，增加排查时间，影响事件响应效率。

最佳实践与反模式

  • 最佳实践：
    • 对于涉及异步数据流和复杂订阅的前端代码，必须进行严格的时间范围/状态一致性测试。
    • 当使用缓冲数据流（如 ReplaySubject）时，必须考虑其缓存的旧数据是否会在新上下文中造成干扰。
    • 修复应尽可能隔离影响范围（如此处仅限于 Mixed 路径），避免引入新的副作用。
  • 常见反模式：
    • 过早终止数据流：基于陈旧信号关闭数据管道是导致此类问题的典型反模式。
    • 忽略请求上下文：在处理异步响应时，不检查该响应是否对应当前活动的请求，是引发竞争条件的主要原因。

相关指标（SLI/SLO/SLA）

  • SLI（服务级别指标）：可关联到“仪表板数据新鲜度”或“查询时间范围覆盖准确率”。此 Bug 会导致指标值瞬间下跌。
  • SLO（服务级别目标）：对于实时监控系统，SLO 可能要求“面板数据在时间范围变更后 2 秒内刷新”。此修复旨在满足此类目标。
  • 根本原因：问题根因在于 RxJS 数据流中的状态管理不当，属于前端实现层面的可靠性债务。

> 相关页面参考：grafana、rxjs、observability-frontend。