4. Prometheus + Grafana 监控栈搭建：Prometheus架构、Exporter部署、Grafana仪表盘设计
说实话，监控这块我踩过不少坑。早期做RMC性能调优时，我习惯用top、htop这些命令行工具，盯着屏幕看CPU和内存的波动。但项目一复杂，节点一多，这种「人肉监控」的方式就彻底崩了。后来我下定决心，把Prometheus和Grafana这套组合拳打起来，才真正体会到什么叫「监控自由」。
今天咱们就聊聊，怎么把Prometheus + Grafana这套监控栈，稳稳地架在RMC环境上。
4.1 Prometheus架构：拉模式才是王道
Prometheus的设计理念，说白了就是「你去问，而不是等它报」。它采用拉（Pull）模式，定期从各个目标节点抓取指标数据。这和传统的推（Push）模式完全不同——你想想看，如果每个服务都主动往监控系统推数据，一旦网络拥堵或监控系统挂了，数据就全丢了。而Prometheus这种拉模式，天然就带重试和健康检查机制。
核心架构组件：
- Prometheus Server：负责拉取数据、存储、告警规则评估
- Exporter：部署在被监控节点上，暴露指标接口
- Alertmanager：处理告警通知（邮件、钉钉等）
- Grafana：可视化仪表盘，展示数据
下面这张图，是我自己画的一个简化版架构。你看一眼就能明白数据是怎么流动的：
4.2 Exporter部署：把RMC的「心跳」暴露出来
Exporter是Prometheus的「眼睛」。没有它，Prometheus就是个瞎子。我个人习惯把Exporter分为两类：系统级和应用级。
4.2.1 系统级Exporter：Node Exporter
Node Exporter是必装的。它监控CPU、内存、磁盘、网络这些基础指标。部署方式很简单：
# 下载并解压
wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz
tar -xzf node_exporter-1.6.0.linux-amd64.tar.gz
# 启动（默认端口9100）
cd node_exporter-1.6.0.linux-amd64
./node_exporter &
# 验证
curl http://localhost:9100/metrics | head -20小技巧： 我在生产环境会用systemd管理Node Exporter，确保它开机自启。另外，记得在防火墙放行9100端口，不然Prometheus拉不到数据。
4.2.2 应用级Exporter：RMC自定义指标
RMC本身有一些关键指标，比如任务队列长度、内存池使用率、GC暂停时间。这些指标Node Exporter是拿不到的，需要我们自己写一个Exporter。
嗯，这里要注意：RMC的指标暴露接口，我建议用/metrics路径，格式遵循Prometheus的规范。举个例子：
# HELP rmc_task_queue_length 当前任务队列长度
# TYPE rmc_task_queue_length gauge
rmc_task_queue_length{queue="high"} 12
rmc_task_queue_length{queue="low"} 45
# HELP rmc_memory_pool_usage_bytes 内存池使用量
# TYPE rmc_memory_pool_usage_bytes gauge
rmc_memory_pool_usage_bytes{pool="young"} 104857600
rmc_memory_pool_usage_bytes{pool="old"} 314572800我曾经遇到过一个坑：RMC的GC暂停时间指标，一开始我用的Counter类型，结果发现每次重启后数据归零，导致告警误报。后来改成Gauge类型，记录最近一次GC暂停的毫秒数，问题就解决了。
4.3 Prometheus配置：告诉它去哪「拉」数据
Prometheus的配置文件是prometheus.yml。核心就是scrape_configs部分，告诉Prometheus从哪些目标拉数据。
global:
scrape_interval: 15s # 每15秒拉一次
evaluation_interval: 15s # 每15秒评估告警规则
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['192.168.1.10:9100', '192.168.1.11:9100']
- job_name: 'rmc'
static_configs:
- targets: ['192.168.1.10:8080']
- job_name: 'mysql'
static_configs:
- targets: ['192.168.1.10:9104']避坑指南： 我曾经把scrape_interval设成5秒，结果Prometheus服务器CPU直接飙到80%。对于RMC这种指标变化不剧烈的系统，15秒完全够用。别太贪心。
4.4 Grafana仪表盘设计：让数据「说话」
数据拉回来了，怎么展示？Grafana就是干这个的。我个人习惯把仪表盘分成三层：
- 概览层：一眼看出系统整体健康状态
- 分析层：深入排查具体问题
- 告警层：异常时触发通知
4.4.1 关键面板设计
| 面板名称 | 指标 | 查询语句（PromQL） | 图表类型 |
|---|---|---|---|
| CPU使用率 | node_cpu_seconds_total | 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) | Gauge / 时间序列 |
| 内存使用率 | node_memory_MemTotal_bytes / node_memory_MemAvailable_bytes | (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 | Gauge |
| RMC任务队列 | rmc_task_queue_length | sum by(queue)(rmc_task_queue_length) | 柱状图 / 时间序列 |
| GC暂停时间 | rmc_gc_pause_ms | avg_over_time(rmc_gc_pause_ms[5m]) | 时间序列 |
你想想看，如果RMC的任务队列长度持续增长，说明消费速度跟不上生产速度。这时候就该检查消费者线程是不是卡住了，或者数据库写入太慢。
4.4.2 变量与模板化
Grafana支持模板变量，这个功能我特别喜欢。比如你有一个RMC集群，里面有10个节点。你可以定义一个变量$instance，然后面板的查询语句写成：
sum by(queue)(rmc_task_queue_length{instance="$instance"})这样，你只需要在仪表盘顶部下拉选择节点，所有面板自动切换数据源。省去了重复创建面板的麻烦。
我的经验： 模板变量用label_values函数自动填充，比如label_values(rmc_task_queue_length, instance)。这样新增节点时，下拉列表自动更新，不用手动维护。
4.5 告警配置：别等用户投诉才发现问题
Prometheus的告警规则写在rules.yml里。我一般会配置几个核心告警：
groups:
- name: rmc_alerts
rules:
- alert: RMCQueueTooLong
expr: sum(rmc_task_queue_length) > 100
for: 5m
annotations:
summary: "RMC任务队列超过100"
description: "当前队列长度 {{ $value }}，请检查消费者"
- alert: RMCGCPauseTooLong
expr: rmc_gc_pause_ms > 500
for: 1m
annotations:
summary: "RMC GC暂停超过500ms"
description: "最近一次GC暂停 {{ $value }}ms"告警规则里，for字段很关键。它表示「持续多久才触发告警」。我曾经设成0秒，结果网络抖动一下，告警就炸了，半夜被电话吵醒。后来改成5分钟，稳定多了。
4.6 实战验证：从部署到看到数据
最后，咱们走一遍完整流程。假设你有一台服务器192.168.1.10：
- 部署Node Exporter和RMC Exporter
- 配置
prometheus.yml，添加两个job - 启动Prometheus：
./prometheus --config.file=prometheus.yml - 打开Grafana，添加Prometheus数据源（URL:
http://192.168.1.10:9090） - 导入或创建仪表盘，添加面板
我第一次搭完这套栈时，看着Grafana面板上跳动的曲线，心里特别踏实。以前靠猜的问题，现在数据一清二楚。说白了，监控不是为了好看，是为了在故障发生前，你就能看到苗头。
嗯，这套栈搭好之后，下一步就是基于这些数据做调优了。不过那是后面章节的事，咱们先把监控跑起来。