Grafana 是当下最流行的开源监控可视化与告警平台。很多人刚接触可观测性时会有疑问：Prometheus 本身也能画图，为什么还要再引入一层 Grafana？答案在于分工——Prometheus 擅长采集与存储时序指标，但原生界面查询笨重、看板协作弱；Grafana 则把”把数据变成一眼看懂的图表”做到了极致。它不绑定数据源，既能连 Prometheus，也能连 Loki、MySQL、Elasticsearch、InfluxDB 等几十种后端，是真正中立的可视化层。对运维和开发者来说，一套 Grafana 就能把分散在各系统的指标、日志、链路统一到同一个大屏，这是它成为事实标准的原因。
更现实一点：没有统一可视化，故障来临时你要在十几个后台之间来回切换，等拼出全貌，止损窗口早就过了。Grafana 的价值不只是”好看”，而是把”发现问题—定位问题”的链路压缩到一块屏幕上，让 oncall 的人少熬夜、让管理者随时能看见业务健康度。对创业团队尤其划算——它开源免费，一台 2C4G 的机器就能撑起几十个服务的监控。
快速起步：用 Docker 拉起 Grafana
最小可用环境只需要一条命令。生产环境建议用 docker-compose 管理，把数据持久化到卷，避免容器重建后仪表盘丢失。
docker run -d --name grafana \
-p 3000:3000 \
-v grafana-storage:/var/lib/grafana \
grafana/grafana-oss:11.3.0默认账号 admin/admin，首次登录会强制改密码。更稳妥的做法是用 compose 文件统一管理配置与数据卷，方便随 Docker 一起迁移。
services:
grafana:
image: grafana/grafana-oss:11.3.0
container_name: grafana
ports:
- "3000:3000"
volumes:
- ./grafana-data:/var/lib/grafana
- ./grafana.ini:/etc/grafana/grafana.ini
restart: unless-stopped接入数据源：以 Prometheus 为例
Grafana 通过”数据源（Data Source）”连接后端，最常见的是 Prometheus。在界面依次点击 Connections → Data sources → Add new → Prometheus，填写 URL（如 http://prometheus:9090）即可。更推荐用配置文件声明，便于随容器注入、版本化管理。
apiVersion: 1
datasources:
- name: Prometheus
type: prometheus
access: proxy
url: http://prometheus:9090
isDefault: true把该文件挂到 /etc/grafana/provisioning/datasources/ 目录，Grafana 启动即自动加载，无需手动点界面，也方便在 CI/CD 里把监控配置一并纳管。
第一张面板：用 PromQL 画出图表
面板（Panel）是 Grafana 的最小可视化单元。新建 Dashboard → Add panel，选 Prometheus 数据源，在查询框写 PromQL。例如查看节点 CPU 使用率：
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)再比如统计每秒 HTTP 请求量，按服务拆分：
sum(rate(http_requests_total[1m])) by (service)图表类型可在右侧切换：Time series（时序折线）、Bar gauge（柱状）、Stat（单值大数字）、Heatmap（热力图）等。记住一个原则：一张面板只表达一个核心问题，别把十几个指标硬塞进同一张图。
仪表盘组织：行、模板变量与复用
当面板变多，要用”行（Row）”分组，比如把 CPU、内存、磁盘归到”主机资源”行。更进阶的是模板变量（Template Variables），让同一个面板按实例、集群动态切换，避免为每个环境复制粘贴。
{
"name": "instance",
"type": "query",
"datasource": "Prometheus",
"query": "label_values(node_cpu_seconds_total, instance)",
"refresh": 2
}面板里用 $instance 引用变量，切换下拉框时所有图表联动刷新，一套模板就能服务整个集群。
| 面板类型 | 适用场景 | 关键设置 |
| Time series | 趋势曲线、资源水位 | 单位、图例、阈值线 |
| Bar gauge | 横向对比多实例 | 最大值、方向 |
| Stat | 单值核心指标 | 阈值着色、Sparkline |
| Heatmap | 延迟/分布密度 | 分桶、配色 |
| Table | 明细列表、Top N | 列排序、颜色 |
告警：从规则到通知渠道
可观测的最后一公里是把”异常”主动推给人。Grafana 9 之后统一了告警引擎（Unified Alerting），规则、通知渠道、静默集中管理。在 Alerting → Alert rules 里写一条规则，例如 CPU 持续 5 分钟高于 85% 就触发。更深层的系统级异常，还能结合 eBPF 内核观测 做根因定位。
apiVersion: 1
groups:
- name: host-alerts
rules:
- alert: HighCpuUsage
expr: 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m]))*100) > 85
for: 5m
labels:
severity: warning
annotations:
summary: "CPU 使用率超过 85%（{{ $labels.instance }}）"通知渠道（Contact point）可接钉钉、飞书、Slack、Webhook、邮件。把告警和值班群打通，故障响应就从”有人发现”变成”系统叫你”。
权限与团队协作：Folder、Team 与 RBAC
团队大了，不能人人都是 admin。Grafana 用 Folder 组织仪表盘，用 Team 把人和 Folder 绑定，再配合 RBAC 控制谁能看、谁能改。建议按业务线建 Folder（如”交易””支付””基础设施”），每个 Team 只看到自己那块，既安全又清爽。Viewer 给老板和运营看大屏，Editor 给 SRE 改面板，Admin 留给平台组。
| 角色 | 能看 | 能改面板 | 能改数据源/告警 |
| Viewer | ✓ | ✗ | ✗ |
| Editor | ✓ | ✓ | 视 RBAC |
| Admin | ✓ | ✓ | ✓ |
生产避坑：性能、鉴权与备份
跑起来容易，跑稳要靠经验。几个高频坑：① 仪表盘太多、查询太重会把 Grafana 和后端数据库一起拖垮，定期清理废弃面板、给 PromQL 加 recording rule 减负；② 别用默认 admin 弱密码，前面加一层反向代理做 HTTPS 与登录保护；③ Grafana 自身的 sqlite/MySQL 也要备份，否则仪表盘配置一夜回到解放前。可同时用 Uptime Kuma 监控 Grafana 自身存活，Docker 部署记得挂持久卷。
| 现象 | 原因 | 对策 |
| 面板加载慢 | 查询时间范围过大 | 缩短区间、加 recording rule |
| 登录被爆破 | 弱密码+公网暴露 | 反向代理+强密码+限流 |
| 重启后面板没了 | 没持久化数据目录 | 挂卷/外置数据库 |
| 告警不触发 | expr 写错/for 太短 | 先在 Explore 验证 PromQL |
Dashboard as Code：把面板纳入版本管理
手动在界面上点出来的仪表盘有个隐患：没法 review、没法回滚、换个人就接不上手。更工程化的做法是 Dashboard as Code——把面板定义成 JSON 或 Terraform 资源，提交到 Git，通过 CI/CD 自动同步到 Grafana。这样谁改了哪条曲线、为什么改，都有 commit 记录可查；新环境一条命令就能复刻整套监控，避免”只有小李知道面板怎么配”的单点风险。
最轻量的落地是用 Grafana 的 HTTP API 把导出的 dashboard JSON 推上去，或者直接用官方 provisioning 目录挂载。下面是用 API 创建或更新面板的最小示例：
curl -X POST https://grafana.example.com/api/dashboards/db \
-H "Authorization: Bearer $GRAFANA_TOKEN" \
-H "Content-Type: application/json" \
-d @dashboard.json更进一步，用 Terraform 的 grafana provider 把数据源、文件夹、告警规则全部声明化，监控基础设施和后端服务一样进入”改一行、审一次、自动生效”的闭环。团队规模上来后，这一步几乎省不掉，也是从”能用”走向”可控”的分水岭。
小结
Grafana 把”分散的数据”变成”可决策的视图”，是搭建可观测体系的必选项。从 Docker 拉起、接入 Prometheus、画第一张面板，到配置模板变量、统一告警与权限，这套路径足以支撑从中型团队到生产的监控需求。把它和 Prometheus、eBPF、日志系统打通，你就拥有了一块真正能”看见系统呼吸”的大屏。
