AI 可能出错，请核对原文 在独立页面打开
问文档
目录

Grafana 操作手册

7 分钟
本页目录

把数据源、查询、面板和告警分开定位，并先找到对象的配置来源。能在 UI 编辑不代表变更会回写 provisioning 文件；直接操作内部数据库表也不是受支持的对象管理方式。

当前任务入口
面板没有数据从查询结果到展示
配置更新被覆盖配置所有权
告警没通知评估与通知链
备份 / 升级受支持的恢复边界

先证明查询有结果，再检查面板

服务与数据库健康

# 查看实际进程与启动结果
systemctl status grafana-server.service --no-pager

unit 名按安装方式替换；容器部署使用对应容器日志，不在宿主机查一个无关服务。

# 读取本次启动的最近错误
journalctl -u grafana-server.service -b -n 100 --no-pager

# 检查健康响应和版本
curl -fsS http://127.0.0.1:3000/api/health | jq .

核对 database 状态。HTTP 成功不能代替数据源查询成功；连接被拒先查监听/入口，401/403 先查代理认证规则。

确认数据源 UID，再复现面板查询

# 在当前 shell 输入有读取权限的服务账户令牌
read -r -s GRAFANA_TOKEN

输入不会回显，完成后按 Enter。账户必须属于目标组织；下列 API 使用该变量，不把令牌硬编码进手册或 URL。

# 列出当前组织可见的数据源
curl -fsS -H "Authorization: Bearer ${GRAFANA_TOKEN:?Load a read-scoped token}" \
  http://127.0.0.1:3000/api/datasources | jq ".[] | {uid,name,type,url}"

将面板配置中的 UID 与结果匹配。空列表可能是组织/权限错误，不能直接认定数据源被删除。

# 对已确认 UID 请求插件健康检查
curl -fsS -H "Authorization: Bearer ${GRAFANA_TOKEN:?Load a read-scoped token}" \
  http://127.0.0.1:3000/api/datasources/uid/prometheus-main/health | jq .

替换 prometheus-main；插件需支持该检查。404 要区分 UID 错误与插件/API 支持问题。健康通过后仍用 Explore 复现原始表达式、时间范围和变量值。

# 完成 API 检查后清除当前 shell 的令牌变量
unset GRAFANA_TOKEN

服务名、端口按实际部署替换；health 只证明 Grafana 自身相应检查，不证明每个数据源可用。使用组织与权限正确的 service account。数据源请求通常由 Grafana 服务端发出，浏览器能访问某 URL 不证明服务器网络或容器 DNS 可访问它。

位置检查证据下一步
数据源UID, URL, auth, TLSTest/Save 或相应健康检查；检查服务器到目标路径
查询Explore / Query inspector核对原始响应、时区、时间范围、变量展开与 step
面板Transformations / field config原始数据存在后检查转换、字段类型、单位和可见性

UID 是引用身份，文件是配置来源

apiVersion: 1
datasources:
  - name: Prometheus
    uid: prometheus-main
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    editable: false

放到实际 provisioning/datasources 目录；prometheus 主机名需在 Grafana 所在网络可解析。面板用稳定 UID 引用，改显示名不应随意重建 UID。启动时加载 datasource provisioning；不是所有 provisioning 都按 dashboard 的扫描周期热加载。对运行实例使用对应受支持的 Admin API reload 或有计划地重启，不假设 systemctl reload 一定有实现。

provisioning 的单向同步 版本库中的文件 Provisioning 同步 Grafana 对象 / UID 面板引用数据源

dashboard provider 的 allowUiUpdates=true 可以允许 UI 保存，但不会写回文件；下一次源文件更新仍可覆盖 UI 状态。将 UI 导出的修改审阅后写回源文件才算持久变更。删除同样回到配置来源，注意 disableDeletion、prune 等各类型选项的范围；不删除数据库内部 resource 表来“清缓存”。

发布 provisioning 后验证实际对象

# 确认启动参数、服务身份和配置来源
systemctl cat grafana-server.service

定位 --config、GF_PATHS_PROVISIONING 与挂载目录，保留旧文件后编辑 YAML。不要仅凭发行版默认路径决定写入位置。

# 在已安排的维护窗口重新加载启动期配置
sudo systemctl restart grafana-server.service

这会中断当前实例，可能影响规则评估；多实例先按部署策略滚动处理。仅适用于本页 systemd 部署，不能与 Admin API reload 当成连续步骤。

# 检查 provisioning 的加载错误
journalctl -u grafana-server.service --since "5 minutes ago" --no-pager

重新执行 health 和数据源 UID 查询，并打开真实面板。若失败，恢复源文件再按同一流程加载；UI 临时改动不能替代源文件回退。

Firing 与发出通知之间还有策略

环节检查
查询与表达式规则使用的数据源 UID、时间窗口、reduce/math 输出；与面板变量语义分开
评估状态Normal/Pending/Alerting，持续条件、评估间隔与 No Data/Error 处理
通知路由标签是否匹配 policy、group_wait/group_interval、静默与 mute timings
投递contact point、模板渲染、出网权限和发送日志

静默通常抑制通知，不让规则停止评估；No Data/Error 的配置可能生成不同告警实例，不能都解释为“指标为 0”。用 UI 预览与日志先确认内容和路由，联系点测试会真的发送消息，安排给预期接收人。文件管理的告警通过对应 provisioning 流程更新，不靠改数据库。

把评估失败与发送失败分开看

# 按告警发生时间读取评估和通知日志
journalctl -u grafana-server.service --since "30 minutes ago" --no-pager

按 rule UID、组织和错误时间关联 UI 状态；日志没有某条发送记录也可能只是日志级别不足，不能据此证明从未发送。

备份真实存储后端与配置

先从实际配置确认 SQLite、PostgreSQL 或 MySQL；Grafana 版本号不能替代存储布局确认。备份数据库、grafana.ini/环境配置、provisioning、插件及用于解密敏感字段的 secret_key，独立恢复后核对数据源、仪表盘 UID 和告警。SQLite 在线复制使用正确备份方式，见 数据库。升级前保存兼容版本与恢复方案，降级二进制不能保证已迁移数据库可读。

Grafana provisioning · Query inspector · Alerting · Backup

链接预览

新窗口打开