Grafana Mixed 数据源时间范围切换时的过时数据问题修复

概述

在 Grafana 的可观测性仪表板中，Mixed 数据源 是一项强大的功能，它允许单个面板从多个不同的数据源查询数据并混合展示。然而，在特定条件下，这一功能会触发一个关键缺陷：当用户更改仪表板的时间范围时，面板可能无法及时刷新，而是持续显示上一个时间范围的“过时”数据。这直接损害了监控数据的实时性和准确性，可能导致 SRE 基于错误信息做出判断，延误故障响应。本次修复通过精修异步数据流的状态管理，确保了 Mixed 数据源面板在时间范围变更后能正确获取并渲染最新数据，维护了监控系统的可靠性。

核心概念

• Mixed 数据源: Grafana 的一种数据源类型，其核心作用是作为代理或“编排器”，将用户的查询请求转发给面板内定义的多个下游数据源，并将结果合并后返回。它本身不存储数据。
• ReplaySubject(1): RxJS 中的一种 Observable（可观察对象），它会“重播”其最新发出的一个值给新的订阅者。在 Grafana 的 SceneQueryRunner 中，它被用来缓存和分发查询结果。其特性是：即使查询已完成（Done），新订阅者也会立即收到该 Done 状态，而不是从头开始执行查询。
• first(Done || Error) 操作符: 在 Mixed 数据源的处理流程中使用，目的是等待某个子查询的第一次完成（或错误）信号后，就认为该子查询的“第一份数据”已加载，并关闭该子查询的后续监听。这个设计原本是为了优化渲染性能。
• 竞态条件 (Race Condition): 本问题的根本原因。当时间范围变更时，上游数据源的“过时”完成状态（Done）与下游面板期望的“新”查询状态在时间上发生了竞争。过早收到的旧 Done 状态错误地触发了 first 操作符，导致整个子流过早关闭，后续真正的、针对新时间范围的数据因此被忽略。

修复方案与实践

该 PR 修复的核心思路是，在触发 first(Done || Error) 这个“终止性”操作之前，增加一道过滤，丢弃那些时间范围不匹配的 Done 或 Error 信号。具体实现如下：

1. 定位问题路径：修复被严格限定在 Mixed 数据源的子查询路径内（通过 requestId.includes(MIXED_REQUEST_PREFIX) 判断）。这是因为在非 Mixed 的常规 Dashboard 数据源查询中，数据流是开放的，即使收到旧的 Done，后续新的数据到来仍会触发更新。但在 Mixed 路径中，first 操作符会“短路”数据流，导致永久性问题。

2. 实施过滤逻辑：

   • 在现有的 emitFirstLoadedDataIfMixedDS 操作符之前，插入一个新的过滤步骤。
   • 该步骤会检查每一个 Done 或 Error 信号的 request.range 是否与当前链式面板（chain panel）的 options.range 相同。
   • 不同，则丢弃。在时间范围变更场景下，上游 ReplaySubject 带来的是旧时间范围的 Done，而面板期望的是新时间范围的数据，因此这个旧信号会被成功过滤掉。
   • 相同，则放行。这确保了针对当前时间范围的正常完成信号能被正确处理。

3. 保护特殊场景：此过滤不会影响支持 PanelTimeRange 覆盖的面板。因为该过滤仅适用于 Mixed 路径，而拥有时间覆盖的面板其查询本身就不属于 Mixed 路径，它们可以自由地观察与上游不同的时间范围，并正常接收终止信号。

流程对比:

• 修复前: 上游(旧Done) -> MixDS操作符(first匹配并关闭) -> forkJoin得到旧数据 -> 面板显示旧数据。新数据到来时无订阅者接收。
• 修复后: 上游(旧Done) -> 过滤器(范围不匹配，丢弃) -> 上游(Loading) -> 上游(新Done) -> 过滤器(范围匹配，放行) -> MixDS操作符(正常匹配并关闭) -> forkJoin得到新数据 -> 面板更新新数据。

SRE 要点

与可靠性的关联

此缺陷直接影响 Grafana 监控仪表板这一核心可观测性工具的可靠性。当 SRE 或开发人员依赖仪表板进行故障排查、容量规划或性能分析时，看到过时的数据可能导致误判。例如，在一次时间范围拉大以查看长期趋势时，面板可能只显示了旧的、不完整的信息，掩盖了真正的问题模式。修复此问题保障了仪表板作为“单一事实来源”的可信度。

最佳实践与反模式

• 最佳实践：

  1. 关注异步状态管理：在处理像 RxJS 这样的响应式编程框架时，必须清晰理解 Subject（尤其是 ReplaySubject）的行为、订阅时机以及各类操作符（如 first, take, switchMap）对数据流的终结性影响。
  2. 为操作符添加上下文：修复中将过滤器作用域限定在 MIXED_REQUEST_PREFIX，是一个很好的实践。它避免了过度修复，影响其他合法场景（如时间覆盖），体现了对系统不同路径深入理解后的精准干预。
  3. 回归测试与场景覆盖：PR 中包含的测试计划非常全面，不仅验证了修复本身，还锁定了修复的适用范围，并确保了现有功能不受影响。SRE 在引入监控工具或插件时，应关注其是否有完善的回归测试。

• 常见反模式：

  1. 忽略初始值：使用 ReplaySubject 时，无条件地处理其重放的值，而未验证该值是否对应当前的有效上下文（如正确的时间范围）。
  2. 过度使用短路操作符：如 first() 或 take(1)，在可能持续更新的数据流中，如果不慎使用，会永久关闭对后续更新的监听，造成数据“冻结”。

相关指标 (SLI/SLO/SLA)

此修复本身不直接定义 SLI/SLO，但它维护了用于衡量这些指标的数据基础。

• SLI (服务级别指标)：例如，“面板查询数据新鲜度”可以作为一个 SLI，衡量从数据源产生数据到面板渲染完成之间的延迟。
• 潜在影响：此 Bug 会导致该 SLI 的测量值出现异常（数据完全停滞），从而可能错误地触发针对监控系统本身的告警，或掩盖了被监控服务的真实 SLI 恶化。
• SLO (服务级别目标)：对于提供 Grafana 服务的团队，一个合理的 SLO 可以是“核心仪表板数据在时间范围变更后 10 秒内更新”。此 Bug 会直接导致 SLO 违约。

关联事件响应

在事件响应（Incident Response）过程中，SRE 高度依赖仪表板进行快速诊断。如果仪表板因已知 Bug 而失效，会严重干扰“观测”环节。因此，SRE 需要：

1. 知晓此类已知缺陷：将其记录在内部知识库（如本页面），以便在排查监控系统自身问题时快速识别。
2. 制定应急措施：对于此特定问题，“硬刷新”页面可以临时解决，因为它会重新实例化整个场景树，清空 ReplaySubject。SRE 可将此作为临时规避步骤纳入 Runbook。
3. 推动版本升级：及时将包含此修复的 Grafana 版本纳入升级计划，从根本上消除隐患。