第4章：集群监控体系：核心监控指标与 Prometheus + Grafana 搭建

监控这事儿，说白了就是给集群装个“仪表盘”。

我刚开始带集群那会儿，总觉得机器跑得挺欢，结果某天半夜三点，一台节点的磁盘 IO 直接打满，整个业务线全挂了。从那以后，我养成了一个习惯——没有监控，不上线。

这一章，咱们就聊聊集群监控到底该盯哪些指标，以及怎么用 Prometheus + Grafana 把这套体系搭起来。

4.1 核心监控指标：CPU / 内存 / IO / 网络

你想想看，集群里成百上千台机器，不可能每台都盯着。关键是要抓住那几个“命门”指标。

4.1.1 CPU 指标

• CPU 使用率：别只看总使用率，要看 user、system、iowait 的分布。我遇到过好几次，iowait 飙到 30% 以上，结果发现是磁盘坏了。
• 负载（Load Average）：这个值超过 CPU 核数两倍，基本就说明系统在“排队”了。
• 上下文切换：每秒几十万次切换，大概率是线程开太多了。

4.1.2 内存指标

• 内存使用率：注意区分“已用”和“缓存/缓冲区”。Linux 会把空闲内存拿来做缓存，这不代表内存不够。
• Swap 使用量：一旦开始用 Swap，性能就会断崖式下跌。我曾经有个 Java 应用，堆内存设太大，结果 Swap 用了 2GB，GC 停顿直接飙到 10 秒。
• OOM Killer 事件：这个必须监控。进程被系统杀掉，往往是因为内存泄漏。

4.1.3 磁盘 IO 指标

• IOPS：每秒读写次数。数据库类应用特别敏感。
• 吞吐量（Throughput）：每秒读写的数据量。视频、日志类服务更关注这个。
• IO 等待时间（await）：超过 100ms 就算异常了。我见过最夸张的一次，await 到了 2000ms，查了半天发现是 RAID 卡坏了。

4.1.4 网络指标

• 带宽使用率：别只看入口流量，出口流量也很重要。有一次业务反馈慢，结果发现出口带宽被打满了。
• 丢包率：超过 0.1% 就要警惕了。网络抖动往往从这里开始。
• TCP 连接数：特别是 TIME_WAIT 状态的数量。如果几万个 TIME_WAIT 堆积，端口资源会耗尽。

4.2 Prometheus + Grafana 搭建

好了，指标知道了，接下来就是怎么采集和展示。我个人习惯用 Prometheus 做数据采集，Grafana 做可视化。这套组合拳，业界用得最多。

4.2.1 架构概览

先看一张图，帮你理解整体流程：

4.2.2 安装 Prometheus

嗯，这里要注意，Prometheus 本身不采集数据，它只负责“拉取”。你需要先在每台机器上装一个 Exporter。

# 1. 下载 Prometheus
wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz
tar -xzf prometheus-2.45.0.linux-amd64.tar.gz
cd prometheus-2.45.0.linux-amd64

# 2. 配置 prometheus.yml
# 在 scrape_configs 里添加目标节点
scrape_configs:
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['192.168.1.10:9100', '192.168.1.11:9100']

# 3. 启动
./prometheus --config.file=prometheus.yml

4.2.3 安装 Grafana

# 1. 安装 Grafana
sudo apt-get install -y software-properties-common
sudo add-apt-repository "deb https://packages.grafana.com/oss/deb stable main"
sudo apt-get update
sudo apt-get install grafana

# 2. 启动
sudo systemctl start grafana-server
sudo systemctl enable grafana-server

# 3. 访问 http://localhost:3000，默认账号密码 admin/admin

登录后，第一步就是添加数据源。选择 Prometheus，填上地址（比如 http://localhost:9090），点保存。搞定。

4.2.4 导入仪表盘

Grafana 社区有很多现成的仪表盘模板。我个人推荐用 Node Exporter Full（ID: 1860），它把 CPU、内存、磁盘、网络都展示在一个面板上，非常直观。

# 在 Grafana 中导入：
# 1. 点击左侧 "+" → Import
# 2. 输入 1860 → Load
# 3. 选择 Prometheus 数据源 → Import

4.3 告警规则设计

监控不是为了看数据，而是为了在出事之前收到通知。告警规则设计得好，能帮你省下不少半夜爬起来排查的时间。

4.3.1 告警规则示例

在 Prometheus 里，告警规则写在 rules.yml 文件中：

groups:
  - name: node_alerts
    rules:
      - alert: 节点宕机
        expr: up == 0
        for: 1m
        annotations:
          summary: "节点 {{ $labels.instance }} 已宕机"

      - alert: CPU 使用率过高
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        annotations:
          summary: "节点 {{ $labels.instance }} CPU 使用率超过 80%"

      - alert: 磁盘空间不足
        expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 10
        for: 2m
        annotations:
          summary: "节点 {{ $labels.instance }} 根分区剩余空间不足 10%"

4.3.2 告警分级

4.3.3 告警通知配置

Alertmanager 支持多种通知渠道。我常用的是钉钉机器人：

# alertmanager.yml
route:
  receiver: 'dingtalk'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h

receivers:
  - name: 'dingtalk'
    webhook_configs:
      - url: 'https://oapi.dingtalk.com/robot/send?access_token=你的token'
        send_resolved: true

好了，这一章的内容就到这儿。监控体系搭起来之后，你会发现集群的“黑盒”慢慢变成了“白盒”。下一章咱们聊聊日志管理，那又是另一片天地。