服务卡片 · 监控
把 Grafana 当作机架的那块玻璃
Grafana 本身什么都不做——它只是一个需要数据源的绘图引擎。它值那 260MB 的理由，是能把 Prometheus、node exporter 和容器指标放在同一屏上，并且有足够长的历史来回答唯一重要的问题：这东西是不是在变差？
| 容器镜像 | grafana/grafana:11.4.0 |
|---|---|
| 宿主端口 | :3000/tcp |
| 数据目录 | /srv/homelab/grafana/data |
| 内存预留 | 260 MB |
| CPU 上限 | 0.30 vCPU (cpus: "0.30") |
| 更新节奏 | quarterly, pinned tag. Dashboards are versioned in the database, so an upgrade that changes a panel type can be seen and reverted |
| ARM 兼容 | arm64 native; the image has no compiled plugins in this configuration, which keeps it small |
| 宿主 | 容器 | proto | 暴露 | 用途 |
|---|---|---|---|---|
| :3000 | 3000 | tcp | 仅局域网 | dashboards over the metrics the Prometheus node collects |
部署步骤
建数据目录并生成管理员密码
把密码生成进 env 文件，而不是在登录表单里手打——因为镜像只会在面板已经可达之后才提示你修改它。
run sudo mkdir -p /srv/homelab/grafana/data sudo chown -R 472:472 /srv/homelab/grafana echo "GRAFANA_PASSWORD=$(openssl rand -base64 24 | tr -d '/+=')" >> /srv/homelab/.env用文件配置数据源，而不是在界面里点
点出来的数据源会随数据卷一起消失。文件让重建变成一件小事，也让那个 URL 可以被 git 复核。
run mkdir -p /srv/homelab/grafana/provisioning/datasources # 按上文写入 prom.yml，然后： cd /srv/homelab/grafana && docker compose up -d导入三块仪表盘，并立刻导出回去
在界面里搭好，然后同一次会话里导出成 JSON。一块从没被导出过的仪表盘，距离「靠记忆重建」只差一次数据卷故障。
run # Dashboard -> Share -> Export -> 保存到文件 mkdir -p /srv/homelab/grafana/dashboards && cp ~/Downloads/*.json /srv/homelab/grafana/dashboards/ cd /srv/git/rack-config && git add dashboards && git commit -m 'grafana dashboards'
三块仪表盘，不多不少
用 Grafana 最典型的诱惑是建十二块仪表盘，然后一块都不看。能在一个家庭里活下来的数量是三块：一块给宿主机（每核 CPU、内存、磁盘、温度、降频标志），一块给容器（每个容器的内存和 CPU、重启次数，以及那些每小时悄悄重启一次的），一块给网络与存储（网口吞吐、固态盘的 SMART 属性、备份任务结果）。
温度那一块是每天都在证明自己价值的。被动散热、放在温暖房间里的树莓派会在 80 度开始降频，而第一个症状是 Jellyfin 掉帧——人们往往会顺着完全错误的方向去查这个症状。
用配置，而不是点出来
点出来的仪表盘会随着数据卷一起消失，而六个月后没人记得某块面板当初是干什么的。Grafana 启动时会从文件读取数据源和仪表盘，所以它们可以和其它东西一起放进 git。
数据源文件就九行，而它让这个容器的重建变成一件无足轻重的小事。
# /srv/homelab/grafana/provisioning/datasources/prom.yml
apiVersion: 1
datasources:
- name: prometheus
type: prometheus
access: proxy
url: http://prometheus:9090
isDefault: true
editable: false在这里 Grafana 不是用来干这个的
本机架上 Grafana 不承担报警职责。通断由 Uptime Kuma 负责，慢性的劣化由 Prometheus 告警规则负责；Grafana 是你已经知道出问题之后去看的地方。家里没有人会因为有通知就打开一块仪表盘——那是状态页的职责。
compose 文件
整份文件放在 /srv/homelab/grafana/compose.yaml。标签固定版本号，不用 latest——树莓派上回滚比升级麻烦得多。
services:
grafana:
image: grafana/grafana:11.4.0
container_name: grafana
restart: unless-stopped
ports:
- "3000:3000/tcp"
environment:
TZ: Asia/Shanghai
GF_SECURITY_ADMIN_PASSWORD: ${GRAFANA_PASSWORD}
GF_USERS_ALLOW_SIGN_UP: "false"
GF_AUTH_ANONYMOUS_ENABLED: "false"
GF_ANALYTICS_REPORTING_ENABLED: "false"
volumes:
- /srv/homelab/grafana/data:/var/lib/grafana
networks: [rack]
networks:
rack:
external: true加固清单
- 匿名访问关闭，管理员密码在首次启动时由环境变量提供
- 数据源使用只读的 Prometheus 账号，被攻陷的仪表盘也写不了指标
- 面板受代理层的仅局域网规则保护，从不做端口转发
- 关闭公开仪表盘功能，这里没有任何需要公开分享的东西
备份方案
数据卷里的 SQLite 数据库存着所有仪表盘、用户和数据源，每晚导出一次。仪表盘本身在每次改动后还会导出成 JSON 放进 git，因为一个没法 diff 的仪表盘，就是一个没人会复核的仪表盘。
上线后验证
- 在 Grafana 界面里测试 Prometheus 数据源能通过
- 某个容器重启后，一个抓取周期内重启次数面板上就能看到台阶
- 宿主机仪表盘上温度曲线和降频标志面板在同一行
- 用 compose 文件重建容器后，配置好的数据源无需任何点击就回来了
踩过的坑
- Grafana 默认管理员密码是 admin/admin，而且只在你登录时提示你改。在首次启动前通过 GF_SECURITY_ADMIN_PASSWORD 设好，能避免一段面板完全敞开的时间窗。
- 为了临时分享而打开的匿名访问设置，是家庭 Grafana 变成公开服务最常见的原因。演示之后要关掉，而不是演示之前才想起来。
- 只存在数据卷里的仪表盘，会在数据卷消失的那天一起消失——而那一天恰好就是你最需要它来回忆基线长什么样的日子。
硬件与选型问答
- 已经有 Uptime Kuma 了还需要 Grafana 吗？
- 它们回答的不是同一个问题。Uptime Kuma 告诉你服务挂了并给你发通知；Grafana 显示这个服务的内存三个月来每周涨 40MB，这才是它死掉的原因。如果只有四个服务，只用 Uptime Kuma 是诚实且够用的。超过十个，趋势视图就开始回本了。
- 整套监控在派上要多少内存？
- Grafana 260MB，保留十五天的 Prometheus 约 700MB，node exporter 30MB，Uptime Kuma 180MB，合计约 1.2GB。8GB 的板子负担得起，2GB 的负担不起。
- 能不能把 Grafana 挪到 NAS 上？
- 可以。如果你已经有一台支持容器的 NAS，指标系统本来就该放那儿——Grafana 和 Prometheus 是这份清单里对延迟最不敏感的服务，而 NAS 通常有磁盘做长期保留。本机架把它们留在派上，是因为 NAS 的角色是备份目标。