Grafana仪表板外部共享时的“数据源缺失”故障分析与处理

概述

在 Grafana 中，将仪表板或面板共享给外部（非登录）用户时，依赖于正确的数据源访问权限和配置。本文档基于一个实际报告的问题，分析了当仪表板面板内部的查询目标（Query Target）数据源引用丢失或不一致时，如何导致外部用户看到“Unsupported data sources”警告及“No Data”错误。理解此问题有助于 SRE 团队维护仪表板配置的完整性和可靠性，确保监控视图在各种访问场景下的有效性。

核心概念

要理解此问题，需要明确以下几个 Grafana 架构中的关键概念：

仪表板（Dashboard）：由多个面板（Panel）组成的可视化视图，是展示监控数据的主要载体。
面板（Panel）：仪表板的基本单元，用于展示特定图表或数据。每个面板通过查询（Query）从数据源获取数据。
查询目标（Query Target）：面板查询配置中的一个具体数据查询条目。一个面板可以包含多个查询目标（例如，同时查询 CPU 使用率和内存使用率）。每个查询目标需要独立指定其使用的数据源（Datasource）。
数据源（Datasource）：Grafana 连接并从中获取数据的后端服务（如 Prometheus、InfluxDB 等）。数据源的配置可以在仪表板级别、面板级别或查询目标级别进行覆盖。
外部共享（Share Externally）：通过生成公开链接，将仪表板或面板分享给没有 Grafana 账户的外部用户。外部访问依赖于数据源自身的匿名访问权限或公开 API。

问题的核心在于，尽管面板级别可能指定了一个有效的数据源，但其内部某个查询目标的数据源引用可能为空或指向了一个不存在的 ID。在内部（已登录）用户访问时，这可能被上游的默认数据源覆盖而正常工作；但在外部共享时，由于缺少上下文或权限，Grafana 无法自动处理这种不一致，从而引发错误。

实践

问题现象复现与诊断

根据报告，该问题可在以下环境中复现：

Grafana 版本：11.6.0
部署方式：Docker
数据源类型：Prometheus

创建仪表板：创建一个包含一个或多个面板的仪表板，每个面板配置多个查询目标。
配置查询：在某个面板的查询编辑器中，可能通过手动编辑 JSON Model 或多次编辑，导致其中某个查询目标的 datasource 字段丢失或设置为 null/无效值。
尝试外部共享：点击仪表板或面板的“分享”按钮，选择“外部链接”选项并生成链接。
观察结果：外部用户打开链接，会看到面板顶部出现黄色警告条“Unsupported data sources”，且图表区域显示“No Data”。

根因分析

问题的直接原因是面板模型（Panel Model）中，某个查询目标的 datasource 属性未能正确关联到有效的数据源 UID。这通常源于：

手动编辑 JSON：在仪表板的 JSON Model 中直接修改了查询配置，但未确保 datasource 字段的正确性。
插件或导入问题：从其他环境导入仪表板 JSON 时，数据源 UID 不匹配。
UI 编辑器的边缘情况：在 Grafana UI 中快速切换或编辑数据源时，可能因状态未正确同步导致目标级别的引用丢失。

由于 Grafana UI 通常在面板或数据源级别提供配置界面，查询目标级别的数据源配置有时被折叠或不易察觉，这增加了此类错误的隐蔽性。

解决方案

定位问题面板：在仪表板编辑模式下，逐一检查每个面板的查询编辑器。重点关注那些在面板顶部数据源选择器中已选定了数据源，但警告或错误依然存在的面板。
检查查询目标：展开每个查询编辑器，仔细查看每个查询目标的设置。虽然 UI 可能不直接显示每个目标的单独数据源选择器，但可以：
- 检查 JSON 模型：在面板的“JSON 模型”选项卡中，检查 targets 数组下的每个对象，确认其 datasource 字段。正确的值应为一个对象，包含 type 和 uid 字段（例如 {"type": "prometheus", "uid": "abc123"}）。如果该字段为 null、空字符串 "" 或 {"type": "prometheus"} 而缺少 uid，则需要修复。
- 重新选择：最简单的方法是重新配置该查询。在查询编辑器中，删除该问题目标，然后从数据源下拉列表中重新选择并创建新查询。这将确保 datasource 字段被正确填充。
验证外部访问：修复后，重新生成外部共享链接并检查问题是否解决。同时，确保被引用的数据源本身允许匿名访问（如果外部用户无账户），或已配置了适当的 API 密钥/令牌。

SRE 要点

与可靠性、可观测性的关联

仪表板作为关键基础设施：监控仪表板是团队了解系统状态、响应事件的首要界面。其配置错误（如本例）会直接破坏可观测性，导致关键用户（包括外部合作伙伴或客户）无法获取正确的监控视图。
“失效但不告警”的故障模式：此类问题通常不会触发 Grafana 自身的告警，而是静默地导致共享视图损坏。SRE 需要通过定期的仪表板审计或自动化验证测试来主动发现此类配置漂移。

最佳实践与常见反模式

最佳实践：

使用仪表板代码库：将仪表板 JSON 作为代码存储在版本控制系统中（如 Git），并使用 grafana-dashboard-exporter 等工具管理，避免通过 UI 进行可能导致配置不一致的直接修改。
强制数据源配置：在团队规范中，要求每个查询目标必须显式指定数据源，避免依赖面板或全局默认值。
实施共享前检查：在文档或流程中规定，任何仪表板在配置为外部共享前，应在无登录会话的“无痕窗口”中预览测试。

常见反模式：

信任 UI 的默认行为：认为在面板顶部选择数据源后，其所有查询目标都会自动继承该配置。实际上，每个目标的数据源配置是独立的。
忽视 JSON 模型：仅通过 UI 操作仪表板，而不检查底层 JSON 模型的完整性和一致性。
未测试外部视图：仅以管理员或内部用户身份测试仪表板功能，忽略了外部用户所见的最终效果。