Grafana 监控大盘搭建与告警配置——让数据「看见」问题 • 七万号·数据平台实战手记

明朗北街七万号·数研工坊｜扎根雄安新区中关村科技园，专注受限环境下软件搭建与数据平台落地

适用场景#

如果你属于以下任一种情况，这篇对你有用：

指标数据已经存到 VictoriaMetrics，但还停留在「命令行查」的阶段

想一眼看清整个平台的健康状态（而不是一个个指标 curl）

需要把监控数据可视化展示给团队或领导

想让系统出问题时自动通知你（而不是你发现时已经炸了）

应用范围： 监控体系的展示与告警层。架构里的最后一环：Categraf（采集）→ VictoriaMetrics（存储）→ Grafana（展示+告警）。本篇完成后，一套完整的 Metrics 可观测链路就通了。

架构定位（完整链路）#

  Categraf ──► VictoriaMetrics ──► Grafana ──► 人
  (第9篇采集)   (第10篇存储)        (本篇展示)
                                     │
                                     ▼
                                   告警通知
                              (飞书/钉钉/邮件)

plaintext

到这里，监控体系的三件套就齐了。

一、问题#

数据在 VictoriaMetrics 里存着，你可以用 curl 查：

curl 'http://127.0.0.1:8428/api/v1/query?query=cpu_usage_active'

plaintext

但这不叫监控——这叫考古。你需要的是：

可视化：把指标画成图，一眼看出趋势
大盘：一台机器一个面板，所有关键指标一屏看全
告警：CPU 超了、磁盘满了、服务挂了——自动通知你

这就是 Grafana 的工作。

二、约束#

无公网，需离线部署
数据源是 VictoriaMetrics（不是 Prometheus 本体）
告警通知要能发到飞书/钉钉（内网环境常见 IM）
资源受限，Grafana 本身要轻量运行

三、部署 Grafana#

3.1 方式一：Docker 部署（第 6 篇的 Docker 用起来）#

如果已经搭好了第 6 篇的 Docker 环境：

# 从内部 Registry 拉取（或先在外网 pull 再 load）
docker run -d --name grafana \
    -p 3000:3000 \
    -v /data/grafana:/var/lib/grafana \
    --restart always \
    192.168.1.100:5000/grafana/grafana:latest

plaintext

3.2 方式二：二进制部署（无 Docker 场景）#

# 外网下载
wget https://dl.grafana.com/oss/release/grafana-11.1.0.linux-amd64.tar.gz

# 内网解压
tar xzf grafana-11.1.0.linux-amd64.tar.gz
mv grafana-v11.1.0 /usr/local/grafana

# 启动
nohup /usr/local/grafana/bin/grafana server \
    --homepath=/usr/local/grafana \
    > /var/log/grafana.log 2>&1 &

plaintext

3.3 验证#

浏览器访问 http://<服务器IP>:3000，默认账号密码 admin/admin，首次登录会要求改密码。

四、接入 VictoriaMetrics 数据源#

4.1 添加数据源#

登录 Grafana → 左侧菜单「Connections → Data sources」
点击「Add data source」
搜索选择 Prometheus（VictoriaMetrics 兼容 Prometheus 协议，用 Prometheus 类型接入）
URL 填：http://<VM的IP>:8428
点击「Save & test」，提示成功即接通

为什么用 Prometheus 类型接 VM？因为 VM 完全兼容 Prometheus 的查询协议（PromQL），Grafana 用 Prometheus 数据源类型就能直接查 VM 的数据。

五、搭建监控大盘#

5.1 新建 Dashboard#

左侧菜单「Dashboards → New → New Dashboard」
添加 Panel，选择数据源 Prometheus
在查询框输入 PromQL

5.2 常用 PromQL（直接抄）#

CPU 使用率：

100 - (avg by (instance) (rate(cpu_usage_total{...}[5m])))

plaintext

内存使用率：

mem_used_percent

plaintext

磁盘使用率：

disk_used_percent

plaintext

服务存活（up）：

up

plaintext

5.3 推荐的大盘结构#

区块	指标	说明
概览	up、CPU、内存、磁盘	一眼看全
每台机器	细分 CPU/内存/磁盘/网络	机器级排障
中间件	MySQL 连接数、Redis 命中率	组件健康
应用	QPS、延迟、错误率	服务维度

也可以直接导入官方 Dashboard 模板（Grafana 官网 Dashboards 页面下载 JSON，导入时选 VictoriaMetrics 数据源），省去手写 PromQL 的功夫。

六、告警配置（重点）#

监控的最终目的是告警——问题发生时第一时间知道。

6.1 创建告警规则#

进入某个 Panel →「Edit」→「Alert」
配置规则：
- 条件：如 cpu_usage_active > 90 持续 5 分钟
- 评估间隔：每 1 分钟评估一次
- 通知策略：选择通知渠道

6.2 配置飞书/钉钉通知（内网场景）#

方式：Webhook 通知。

飞书群机器人 Webhook：

1. 在飞书群添加「自定义机器人」
2. 获取 Webhook URL（形如 https://open.feishu.cn/open-apis/bot/v2/hook/xxx）

plaintext

Grafana 配置：

# 在 Grafana 的 Contact points 里添加：
# 类型：Webhook
# URL：飞书机器人地址
# 消息体：自定义 JSON（飞书机器人要求特定格式）

plaintext

告警内容模板示例（飞书消息）：

{
  "msg_type": "text",
  "content": {
    "text": "⚠️ 告警：{{ .CommonLabels.alertname }}\n实例：{{ .CommonLabels.instance }}\n描述：{{ .CommonAnnotations.summary }}"
  }
}

json

6.3 告警分级#

级别	示例	通知方式
警告	CPU > 80% 持续 10 分钟	飞书普通通知
严重	服务 down / 磁盘 > 95%	飞书 @人
紧急	数据库挂掉 / 主节点失联	飞书 + 电话（如可行）

七、常见坑#

坑	症状	解决
数据源连不上	Save & test 失败	VM 的 8428 端口是否被防火墙挡（第 2 篇）
图是空的	Panel 无数据	时间范围选对没？PromQL 写法对不对？
告警不触发	规则已建无通知	检查评估间隔、通知策略是否绑定
飞书收不到	Webhook 配置了没消息	确认机器人没被飞书风控、消息格式对不对
磁盘暴涨	Grafana 数据库变大	Grafana 自身数据在 /var/lib/grafana，定期备份清理

八、总结——监控体系收官#

到这里，三篇监控文章完成了。回顾整条链路：

采集（Categraf）→ 存储（VictoriaMetrics）→ 展示告警（Grafana）

plaintext

层	组件	端口	资源占用
采集	Categraf	无（主动推送）	~30MB
存储	VictoriaMetrics	8428	受 allowedPercent 限制
展示	Grafana	3000	~200MB

一套 3 个组件，总内存占用控制在 1G 以内，就得到了完整的监控能力——这就是受限环境下「够用就好」的典范。

从此你的平台不再是黑盒：机器负载、服务状态、中间件健康——一屏看全，出事自动通知。

本文首发于掘金 · 作者：七万号扎根雄安新区中关村科技园，专注受限环境下软件搭建与数据平台落地

下一篇预告：进入数据平台核心——Flink 集群部署