Grafana Dashboard 数据合并时的空数据帧处理问题

概述

在构建可观测性平台时，Grafana 仪表盘是 SRE 团队实时监控系统健康状态、验证 SLO 达成情况和快速响应事件的核心工具。仪表盘的准确性和鲁棒性直接影响团队对系统可靠性的判断。一个已知的缺陷（Issue #102039）表明，当面板配置了多个查询数据源，并使用 merge（合并）变换时，如果其中一个查询返回空数据帧（例如无匹配结果的查询），会导致整个面板可视化失效，显示“无数据”。这违背了 SRE 实践中对可观测性数据完整性和系统状态准确呈现的基本要求，可能掩盖部分关键指标的变化，误导故障排查方向。

核心概念

要理解此问题，需要明确以下几个关键技术概念：

空数据帧（Empty Data Frame）：在 Grafana 的内部数据模型中，一个查询的结果可能返回一个结构存在但不含任何数据行（Records）的数据帧。这不同于查询失败或数据源连接错误，它表示查询成功执行但未命中任何数据。
数据合并（Merge）：这是一种常用的数据变换，旨在将来自多个查询（或多个数据帧）的字段进行逻辑合并，通常基于共同的键值（如时间戳或特定维度），以创建一个统一的、便于交叉对比的数据视图。
Merge 变换的实现逻辑：根据问题描述，当前的 merge 变换实现可能类似于 JavaScript 数组的 concat 操作，它直接拼接数据帧。当其中一个输入数据帧为空（[]）时，该操作可能未能正确处理，导致最终输出结果也被视为空，从而阻断了其他有效数据帧的可视化。

实践

问题复现步骤

根据提供的最小化复现用例，可以按以下步骤重现该问题：

创建包含多查询的面板：在 Grafana 中创建一个新仪表盘，并添加一个表格（Table）类型面板。
配置多个数据源查询：
- 查询 A（refId: “A”）：使用 grafana-testdata-datasource 的 csv_content 场景，提供一些示例数据。
- 查询 B（refId: “B”）：同样使用 csv_content 提供不同的示例数据。
- 查询 C（refId: “C”）：使用 raw_frame 场景，但将 rawFrameContent 设置为 “[]”，模拟一个返回空数据帧的查询。
应用 Merge 变换：在面板的“转换”（Transformations）选项卡中，添加一个“合并”（Merge）变换。
观察结果：预览或保存仪表盘后，面板应显示“无数据”（No data），尽管查询 A 和 B 均有有效数据。

当前行为与预期行为

当前行为：当合并的数据源中存在一个空数据帧时，整个可视化输出为空。
预期行为：可视化应显示所有非空查询的合并数据，忽略或跳过空数据帧。空数据帧不应阻塞整个数据流。

可能的临时规避方案

在官方修复此问题前，SRE 团队可以考虑以下临时方案以保证监控连续性：

数据源层面过滤：确保所有发送到 Grafana 的查询理论上都会返回至少一行数据，避免设计产生空结果的查询。但这可能不现实。
使用其他变换：尝试替代的合并策略。例如，先使用“添加字段从计算”（Add field from calculation）或“分组”（Group by）等变换对每个查询结果进行预处理，确保输出非空，然后再进行合并。但此方法复杂且可能无法完全模拟所需的合并逻辑。
简化查询逻辑：重新设计仪表盘，尽量减少在一个面板内混合使用可能返回空结果的异构查询。

SRE 要点

与可靠性的关联

此问题直接影响监控系统的可靠性。仪表盘作为事件响应和 On-Call 过程中的第一手信息来源，其数据不完整或误报会：

误导故障排查：掩盖了部分系统指标，导致 SRE 团队无法获得全面的系统状态视图，延长 MTTD（平均检测时间）和 MTTR（平均恢复时间）。
影响 SLO 计算与决策：如果用于计算关键 SLI 的面板因部分数据缺失而失效，可能错误触发 Error Budget 消耗警报，或反过来，未能及时触发必要的可靠性动作。
降低可观测性信任度：反复出现的“无数据”或数据缺失会降低团队对监控系统的信任，可能导致重要的告警被忽略。

最佳实践与反模式

最佳实践：
1. 设计健壮的仪表盘：避免依赖可能产生空结果的查询，或通过数据变换（如 Filter by name）显式处理空帧。
2. 使用数据验证（Data Alert）：为关键面板配置数据条件告警，当可视化意外变为空或数据量骤减时，能主动通知。
3. 仪表盘即代码：将仪表盘 JSON 定义纳入版本控制，并在 CI/CD 中进行基本的语法和逻辑检查，及早发现此类配置问题。
4. 监控配置健康度：定期审查仪表盘的查询成功率、面板错误率等元数据，主动发现类似问题。
常见反模式：
1. 忽视部分数据失败：认为“只要数据源能连接，仪表盘就应该工作”，忽视了查询结果内容（如空帧）对可视化的关键影响。
2. 过度复杂的面板：在一个面板内塞入过多、过于复杂的查询和变换，增加了出现类似未预料行为的风险。
3. 缺乏仪表盘测试：没有对关键监控仪表盘进行定期的“冒烟测试”（例如，验证关键面板是否一直有数据），导致问题潜伏。