📚 课程目录第2章监控体系搭建

2. 监控体系搭建

监控体系，说白了就是系统的眼睛。没有它，你就像蒙着眼开车——出了故障只能靠猜。我在一线干了这么多年，见过太多团队因为监控缺失，半夜被叫起来处理事故，结果连问题出在哪都不知道。

这一章，咱们就搭一套真正能用的监控体系。选 Prometheus + Grafana 这个组合，不是因为它们时髦，而是因为这套架构在实时系统里确实扛得住。

2.1 整体架构：谁负责什么

先看一张图，把整个体系的结构理清楚。

这套架构的核心思路很简单：Exporter 负责暴露数据，Prometheus 负责拉取和存储，Grafana 负责展示。各司其职，互不干扰。

2.2 部署 Prometheus Server

我个人习惯用 Docker 部署，干净利落。生产环境建议用二进制包或者 Kubernetes Operator，但咱们先跑起来再说。

# 拉取镜像
docker pull prom/prometheus:v2.45.0

# 准备配置文件 prometheus.yml
cat <<EOF > /etc/prometheus/prometheus.yml
global:
  scrape_interval: 15s      # 采集间隔
  evaluation_interval: 15s  # 告警规则评估间隔

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node_exporter'
    static_configs:
      - targets: ['192.168.1.10:9100']
EOF

# 启动容器
docker run -d \
  --name prometheus \
  -p 9090:9090 \
  -v /etc/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \
  prom/prometheus:v2.45.0

小提示：scrape_interval 设 15s 是折中方案。实时性要求高的场景可以压到 5s，但磁盘 I/O 和网络开销会明显上升。我在项目中遇到过把间隔设成 1s 的，结果 Prometheus 自己先撑不住了。

2.3 核心指标采集：node_exporter

node_exporter 是采集 Linux 系统指标的标配工具。CPU、内存、磁盘、网络，全都能搞定。

# 部署 node_exporter
docker run -d \
  --name node_exporter \
  --net="host" \
  --pid="host" \
  -v "/:/host:ro,rslave" \
  quay.io/prometheus/node-exporter:latest \
  --path.rootfs=/host

启动后访问 http://<IP>:9100/metrics，就能看到海量指标。别慌，咱们只关注最核心的几个。

2.3.1 CPU 指标

指标名	含义	常用 PromQL
`node_cpu_seconds_total`	CPU 各模式累计时间（user/system/idle/iowait）	`100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)`
`node_load1 / node_load5 / node_load15`	系统平均负载	`node_load1 / count by(instance) (node_cpu_seconds_total{mode="idle"})`

CPU 使用率我一般看 5 分钟滑动平均，能过滤掉瞬时毛刺。load average 要结合 CPU 核心数看，超过核心数 * 0.7 就要警惕了。

2.3.2 内存指标

指标名	含义	常用 PromQL
`node_memory_MemTotal_bytes`	总内存	`(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100`
`node_memory_MemAvailable_bytes`	可用内存（含缓存）
`node_memory_MemFree_bytes`	空闲内存（不含缓存）

注意：千万别只看 MemFree！Linux 会把空闲内存用作缓存，MemAvailable 才是真正可用的内存。我曾经见过一个运维只看 MemFree，发现只剩 200MB 就报警，实际上 MemAvailable 还有 8GB，虚惊一场。

2.3.3 磁盘指标

指标名	含义	常用 PromQL
`node_filesystem_size_bytes`	分区总大小	`(1 - (node_filesystem_avail_bytes / node_filesystem_size_bytes)) * 100`
`node_filesystem_avail_bytes`	分区可用空间
`node_disk_io_time_seconds_total`	磁盘 I/O 时间累计	`rate(node_disk_io_time_seconds_total[5m])`

磁盘空间告警阈值我一般设 80% 警告、90% 严重。I/O 利用率超过 60% 就要开始排查了，超过 80% 基本就是瓶颈。

2.3.4 网络指标

指标名	含义	常用 PromQL
`node_network_receive_bytes_total`	网卡接收字节数	`rate(node_network_receive_bytes_total[5m])`
`node_network_transmit_bytes_total`	网卡发送字节数	`rate(node_network_transmit_bytes_total[5m])`
`node_network_receive_drop_total`	接收丢包数	`rate(node_network_receive_drop_total[5m])`

网络指标要注意过滤掉 lo（回环接口），只看物理网卡。丢包率超过 0.1% 就要查链路质量了。

2.4 配置 Grafana 仪表盘

Grafana 的部署同样简单：

docker run -d \
  --name grafana \
  -p 3000:3000 \
  -e GF_SECURITY_ADMIN_PASSWORD=admin123 \
  grafana/grafana:10.0.0

登录后添加 Prometheus 数据源，URL 填 http://<Prometheus_IP>:9090。然后导入现成的仪表盘模板，比如 Node Exporter Full (ID: 1860)，几分钟就能看到完整的系统监控面板。

核心原则：仪表盘不是越花哨越好。我一般只放 6-8 个关键图表：CPU 使用率、内存使用率、磁盘空间、磁盘 I/O、网络流量、系统负载。多了反而干扰判断。

2.5 避坑指南

时间同步问题：Prometheus 对时间敏感，所有节点必须用 NTP 同步。时间偏差超过 5 分钟，数据就会乱掉。我曾经因为一台虚拟机时间跑偏，查了整整两天才发现是时间问题。
存储容量规划：Prometheus 默认本地存储，每个样本大约 1-2 字节。1000 个指标、15s 间隔，一天大约 5-8GB。生产环境建议保留 15-30 天数据，提前规划磁盘。
Exporter 安全：/metrics 端点不要暴露到公网。可以用防火墙限制，或者加一层 nginx 反向代理做认证。
采集压力：别把所有目标都塞到一个 Prometheus 实例里。超过 10000 个时间序列，建议拆分或者用联邦集群。

好了，监控体系的基础架构就搭完了。你现在应该能看到 CPU、内存、磁盘、网络的实时数据在 Grafana 上跳动。这套东西虽然基础，但它是后续所有性能分析的基石——没有数据，调优就是空谈。