Grafana SQL表达式中的数据格式转换问题

概述

在构建基于 Grafana 的可观测性管道时，SQL 表达式是一个强大工具，允许用户对来自不同数据源或查询（通过 RefID 标识）的结果进行二次加工和分析。本页面探讨了一个具体的技术问题：当 SQL 表达式引用包含指标数据（如时间序列标签或多表结构）的查询时，由于底层数据格式转换的中间状态，导致在查询编辑器中无法直接查看被引用查询的原始结果。理解此问题对于构建可靠的告警规则和仪表盘至关重要，因为它是保证数据处理流程正确性的基础。

核心概念

  • RefID (Query Reference ID)：在 Grafana 查询编辑器中，每个独立的查询（例如一个 Prometheus 查询或 SQL 查询）都会被分配一个唯一的标识符，通常为 A、B、C 等。后续的查询（如 SQL 表达式）可以通过这些 ID 来引用前面查询的结果。
  • 指标数据 (Metric Data)：通常指 Prometheus、InfluxDB 等时间序列数据库返回的数据，其特点是包含标签（Labels）等丰富的元数据，且数据结构可能并非严格的行列表格。
  • 数据平面 (Dataplane)：Grafana 内部用于统一不同数据源返回数据的规范化层。其目标是定义一组标准的数据格式，以简化插件开发和数据处理。在本问题中，涉及的中间格式被称为 “Full long”，这是一种尚在定义中的长表格格式。
  • SQL 表达式 (SQL Expressions)：Grafana 提供的一种查询类型，允许用户使用 SQL 语法对其他查询的结果进行计算、过滤和转换。

实践

问题场景与表现

该问题出现在 Grafana 的查询编辑器（例如用于告警规则的评估）中。当用户配置一个 SQL 表达式查询，并在其 FROM 或 JOIN 子句中引用其他查询（如 query(A)）时，预期应在编辑器中直接看到被引用查询（如 RefID A 和 B）的原始结果预览。然而，实际情况是这些预览结果并未正确显示。

根据问题报告的分析，其根本原因在于数据流转过程中的一个内部步骤：

  1. 当 SQL 表达式被配置为引用一个 RefID 时，Grafana 会尝试将该引用查询的结果作为输入。
  2. 如果被引用的查询返回的是“指标数据”（包含标签或多表结构），系统会首先对其进行格式转换，以使其适配 SQL 表达式处理所需的表格结构。
  3. 这种转换的目标格式被称为 “Full long”。然而，这个中间格式尚未在 Grafana 数据平面（dataplane）项目中正式定义和文档化。
  4. 由于这个中间转换步骤的输入格式（被引用的原始结果）和输出格式（“Full long”）都处于不稳定或未完全兼容的状态，导致预览功能无法正确解析和展示原始查询结果。

影响范围

此问题主要影响 Grafana 的查询构建和调试体验。它使得用户在编写复杂的、基于 SQL 表达式的查询或告警规则时，难以验证前置查询的正确性，增加了调试难度。最终执行查询时，数据可能在后台被正确处理，但编辑过程中的不透明性降低了工作效率和配置信心。

SRE 要点

  • 与可靠性的关联：该问题直接关系到 可观测性系统的可靠性。SRE 团队依赖 Grafana 构建监控和告警。如果无法在配置时验证中间数据，可能会错误地设置告警规则，导致误报或漏报，影响事件响应（Incident Response）的及时性和准确性。
  • 最佳实践与反模式：
    • 最佳实践：在配置复杂的 SQL 表达式或告警规则时，应首先单独测试每个基础查询（RefID A、B 等），确保其返回预期数据。可以利用 Grafana 的“Explore”视图进行独立验证，再将其组合到表达式中。
    • 反模式：过度依赖在 SQL 表达式编辑器中同时构建和验证所有查询。当问题出现时，难以定位是基础查询错误还是表达式逻辑或格式转换问题。
  • 相关指标 (SLI/SLO)：虽然此问题不直接对应一个运行时指标，但它影响的是监控配置的准确性这一内部可靠性指标。一个相关的 SLI 可以是“告警规则配置的首次正确率”，而 SLO 可以是“核心业务监控规则在 95% 的情况下无需调试即可生效”。解决此问题有助于达成该 SLO。
  • 对 SRE 工具链的启示：SRE 在选型和依赖开源工具时，应关注其数据模型的成熟度。像 Grafana 数据平面这样仍在演进的核心组件，其不稳定性可能渗透到用户工作流中。在关键路径上（如核心业务告警），建议对工具链进行充分的压力测试和集成验证。

相关的内部术语和概念包括 data-plane、observability 和 alerting-pipeline。