4、数据采集与监控：用 Prometheus 搭起资源使用的“眼睛”

做资源回收，第一步是什么？

不是写脚本，不是定策略。是先把“谁在用、用了多少”看清楚。

我见过太多团队，一上来就搞自动化回收，结果误杀了线上任务。说白了，你连数据都没有，怎么敢动手？

这一章，我们就来搭一套最经典的监控组合：Prometheus + Node Exporter + Grafana。这套组合在业界用了快十年了，稳定、轻量、社区活跃。我个人习惯，所有新集群落地第一天，先把这套监控架起来。

4.1 整体架构：三个组件各司其职

先看一张图，把整体逻辑理清楚。

Prometheus + Node Exporter + Grafana 架构图 数据采集与监控架构 被监控节点 1 被监控节点 2 被监控节点 N Node Exporter (9100) Prometheus Server 拉取 /metrics 数据 Grafana 可视化 & 告警 运维人员 说明： Node Exporter 部署在每个节点上，暴露 /metrics 接口。 Prometheus 定期拉取数据，Grafana 从 Prometheus 读取并展示。

流程很简单：

  • 每个机器上跑一个 Node Exporter，暴露 /metrics 接口。
  • Prometheus Server 定期去拉这些数据。
  • Grafana 连上 Prometheus，画图、做看板、设告警。

你想想看，这套架构最妙的地方在哪？

每个组件只干一件事。Exporter 只负责采集，Prometheus 只负责存储和查询，Grafana 只负责展示。出了问题，排查范围非常小。

4.2 部署 Node Exporter：每个节点都要装

Node Exporter 是 Prometheus 生态里最基础的采集器。它把 CPU、内存、磁盘、网络这些系统指标全部暴露出来。

部署方式很简单，我一般用二进制包直接跑。

# 下载最新版本（以 1.7.0 为例）
wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz

# 解压
tar xvf node_exporter-1.7.0.linux-amd64.tar.gz
cd node_exporter-1.7.0.linux-amd64

# 直接启动（默认监听 9100 端口）
./node_exporter

启动后，用 curl 验证一下：

curl http://localhost:9100/metrics | head -20

你会看到一堆指标，像这样：

# HELP node_cpu_seconds_total Seconds the cpus spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu="0",mode="idle"} 123456.78
node_cpu_seconds_total{cpu="0",mode="system"} 2345.67
# HELP node_memory_MemTotal_bytes Memory information field MemTotal_bytes.
# TYPE node_memory_MemTotal_bytes gauge
node_memory_MemTotal_bytes 1.6777216e+10
小提示： 生产环境建议用 systemd 管理，设置开机自启。我曾经遇到过机器重启后 Exporter 没起来，监控断了大半天才发现。 
# /etc/systemd/system/node_exporter.service
[Unit]
Description=Node Exporter
After=network.target

[Service]
ExecStart=/usr/local/bin/node_exporter
Restart=always

[Install]
WantedBy=multi-user.target

4.3 部署 Prometheus Server：数据汇聚中心

Prometheus 负责拉取所有 Exporter 的数据，存到本地时序数据库里。

同样用二进制部署：

# 下载
wget https://github.com/prometheus/prometheus/releases/download/v2.52.0/prometheus-2.52.0.linux-amd64.tar.gz

# 解压
tar xvf prometheus-2.52.0.linux-amd64.tar.gz
cd prometheus-2.52.0.linux-amd64

核心是配置文件 prometheus.yml。这里要告诉 Prometheus 去哪拉数据。

# prometheus.yml
global:
  scrape_interval: 15s      # 每15秒拉一次
  evaluation_interval: 15s  # 每15秒评估一次告警规则

scrape_configs:
  - job_name: 'node_exporter'
    static_configs:
      - targets:
        - '192.168.1.10:9100'   # 节点1
        - '192.168.1.11:9100'   # 节点2
        - '192.168.1.12:9100'   # 节点3
注意： scrape_interval 不要设太短。我见过有人设成 1 秒，结果 Prometheus 自己先撑不住了。15 秒对于资源监控完全够用。

启动 Prometheus：

./prometheus --config.file=prometheus.yml

访问 http://<你的IP>:9090，能看到 Prometheus 自带的 Web UI。在查询框里输入 node_cpu_seconds_total，点 Execute，就能看到数据了。

4.4 部署 Grafana：把数据变成图表

Prometheus 自带的 UI 太简陋了，只能查原始数据。真正好看好用的，还得是 Grafana。

# 用 Docker 部署最省事
docker run -d \
  --name=grafana \
  -p 3000:3000 \
  grafana/grafana:latest

访问 http://<你的IP>:3000，默认账号密码都是 admin。

进去之后第一步：添加数据源。

  1. 点击左侧齿轮图标 → Data Sources → Add data source。
  2. 选择 Prometheus。
  3. URL 填 http://<Prometheus IP>:9090。
  4. 点击 Save & Test，看到绿色提示就成功了。

然后导入一个现成的看板。我个人习惯用 Node Exporter Full（ID: 1860），社区维护了好几年，指标很全。

  1. 左侧 + 号 → Import。
  2. 输入 1860，点 Load。
  3. 选择刚才配好的 Prometheus 数据源，点 Import。

几秒钟后，你就能看到每个节点的 CPU、内存、磁盘、网络流量了。

4.5 关键指标解读：哪些数据对资源回收有用

看板有了，但这么多指标，哪些才是我们做资源回收真正关心的？

我列一个对照表，方便你快速定位。

指标名称 含义 资源回收用途
node_cpu_seconds_total CPU 累计使用时间（按模式分） 计算 CPU 使用率，判断节点是否空闲
node_memory_MemTotal_bytes 总内存大小 与 MemAvailable 对比，计算内存利用率
node_memory_MemAvailable_bytes 可用内存大小 判断内存是否充足，决定是否回收
node_filesystem_size_bytes 文件系统总大小 与 free 对比，计算磁盘使用率
node_filesystem_free_bytes 文件系统剩余空间 判断磁盘是否快满，是否需要清理
node_network_receive_bytes_total 网络接收字节数（累计） 计算网络流量，判断节点是否活跃
node_load1 / node_load5 / node_load15 系统负载（1/5/15分钟平均） 综合判断节点繁忙程度
核心思路： 资源回收不是看瞬时值，而是看一段时间的趋势。比如一个节点过去 7 天 CPU 使用率一直低于 10%，内存用了不到 20%，那它大概率是闲置的。

4.6 实战：用 PromQL 查闲置节点

PromQL 是 Prometheus 的查询语言。写几个常用的查询，帮你快速定位闲置资源。

查询 CPU 使用率（过去 5 分钟平均）：

100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

查询内存使用率：

(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

查询磁盘使用率（排除临时文件系统）：

(1 - node_filesystem_free_bytes{fstype!="tmpfs"} / node_filesystem_size_bytes{fstype!="tmpfs"}) * 100

把这些查询放到 Grafana 的看板里，或者写成告警规则。一旦某个节点的 CPU 和内存使用率连续 24 小时低于阈值，就自动标记为“疑似闲置”。

我的经验： 阈值不要拍脑袋定。先跑一周数据，看看正常节点的使用范围，再往下调 20%-30% 作为闲置判定线。我曾经直接设了 10%，结果发现有些批处理任务凌晨跑完就闲置了，白天又起来，误报率很高。

4.7 告警配置：让系统主动通知你

光有看板还不够，你不可能 24 小时盯着屏幕。告警才是监控的闭环。

在 Prometheus 里配置告警规则：

# alert_rules.yml
groups:
  - name: resource_recovery
    rules:
      - alert: NodeIdle
        expr: |
          (100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) < 5
          and
          (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 < 20
        for: 24h
        labels:
          severity: warning
        annotations:
          summary: "节点 {{ $labels.instance }} 疑似闲置"
          description: "CPU 使用率低于 5%，内存使用率低于 20%，持续超过 24 小时。"

然后在 prometheus.yml 里引用这个文件：

rule_files:
  - "alert_rules.yml"

告警触发后，Prometheus 会把消息推给 Alertmanager，再由 Alertmanager 发到钉钉、邮件、Slack 等。这部分我们后面章节会细讲。

4.8 避坑指南：我踩过的几个坑

最后分享几个实战中容易翻车的地方。

  • 时间不同步： Prometheus 对时间很敏感。节点时间差太多，数据会乱掉。所有机器务必配好 NTP。
  • 端口被占： Node Exporter 默认 9100，Prometheus 默认 9090，Grafana 默认 3000。如果和现有服务冲突，记得改端口。
  • 数据保留时间： Prometheus 默认只保留 15 天数据。做资源趋势分析，至少需要 30 天。启动时加参数 --storage.tsdb.retention.time=30d。
  • Exporter 版本： 不同版本的 Node Exporter 指标名可能略有差异。升级前先在测试环境验证，别直接上生产。

嗯，这一章的内容就到这里。监控搭好了，数据有了，下一步就是怎么用这些数据去识别和回收闲置资源。别急，后面会一步步展开。

← 上一章 📖 返回目录 下一章 →