Prometheus 监控搭建与告警规则实战：从零到生产可用的 3 个关键坑

结论先行： 花 2 小时就能搭起 Prometheus 监控，但真正让它稳定告警、不误报、不丢数据，你得避开我在下面踩过的 3 个坑。这篇文章直接给命令、给配置、给踩坑实录。

一、裸机搭建：别被官方文档绕晕

我最初照着官方文档 prometheus.yml 配了一小时，发现根本跑不起来。核心原因：默认配置只监控自己，不监控任何目标。

1. 快速启动 Prometheus Server

# 下载最新版（2024年稳定版 2.53.0）
wget https://github.com/prometheus/prometheus/releases/download/v2.53.0/prometheus-2.53.0.linux-amd64.tar.gz
tar -xzf prometheus-2.53.0.linux-amd64.tar.gz
cd prometheus-2.53.0.linux-amd64



![Prometheus 监控架构与数据流动](imgs/Prometheus 架构.png)

# 创建最小配置 prometheus.yml
cat > prometheus.yml <<EOF
global:
  scrape_interval: 15s
  evaluation_interval: 15s

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

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

坑 1：默认端口 9090 容易被防火墙拦截。检查 firewall-cmd --list-ports，没开放的话直接 firewall-cmd --add-port=9090/tcp --permanent && firewall-cmd --reload。

2. 监控 Linux 节点：node_exporter

不要手动编译，直接下载二进制：

wget https://github.com/prometheus/node_exporter/releases/download/v1.8.1/node_exporter-1.8.1.linux-amd64.tar.gz
tar -xzf node_exporter-1.8.1.linux-amd64.tar.gz
cd node_exporter-1.8.1.linux-amd64
./node_exporter --web.listen-address=:9100

然后在 prometheus.yml 里加：

  - job_name: 'node'
    static_configs:
      - targets: ['192.168.1.100:9100', '192.168.1.101:9100']

坑 2：node_exporter 默认暴露所有指标，CPU、内存、磁盘、网络全都有，但 磁盘 I/O 指标默认不采集。需要加参数 --collector.diskstats 才能拿到 node_disk_io_time_seconds_total。

二、告警规则：别让误报毁掉你的周末

我第一版告警规则配了 20 条，结果上线第一晚就收到 300 条告警。核心教训：阈值要带缓冲，表达式要防抖动。

1. 基础告警规则（直接可用）

创建 alerts.yml：

groups:
  - name: node_alerts
    rules:
      - alert: NodeDown
        expr: up{job="node"} == 0
        for: 5m
        annotations:
          summary: "节点 {{ $labels.instance }} 已宕机 5 分钟"

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

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

在 prometheus.yml 中引用：

rule_files:
  - "alerts.yml"

2. 踩坑实录：三个致命错误

错误 1：up 指标不加 for 字段。
结果：网络抖动导致节点 30 秒断连，立即触发告警，实际 1 分钟后就恢复了。加了 for: 5m 后，误报减少 90%。

错误 2：CPU 告警用 avg(node_cpu_seconds_total{mode="idle"})。
结果：这是累积计数器，不是瞬时值。正确写法是用 rate() 函数算每秒变化率：rate(node_cpu_seconds_total{mode="idle"}[5m])。

错误 3：磁盘告警没过滤 tmpfs。
结果：/run、/sys/fs/cgroup 等虚拟文件系统也被监控，告警一直触发。必须加 fstype!="tmpfs" 过滤。

三、告警通知：Alertmanager 配置实战

Prometheus 本身不发告警，它只负责评估规则。真正发邮件、钉钉、企业微信的是 Alertmanager。

1. 快速部署 Alertmanager

wget https://github.com/prometheus/alertmanager/releases/download/v0.27.0/alertmanager-0.27.0.linux-amd64.tar.gz
tar -xzf alertmanager-0.27.0.linux-amd64.tar.gz
cd alertmanager-0.27.0.linux-amd64

# 最小配置 alertmanager.yml
cat > alertmanager.yml <<EOF
route:
  receiver: 'default'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h

receivers:
  - name: 'default'
    webhook_configs:
      - url: 'http://localhost:5000/alert'
EOF

./alertmanager --config.file=alertmanager.yml

2. 集成企业微信机器人（最实用）

我最终选的是企业微信机器人，因为它免费、稳定、支持 Markdown。

receivers:
  - name: 'wechat'
    webhook_configs:
      - url: 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的key'
        send_resolved: true

坑 3：企业微信机器人有频率限制——每分钟最多 20 条。如果告警风暴来了，后面的消息会被丢弃。解决方案是设置 group_wait: 30s 和 group_interval: 5m，把多条告警合并成一条。

四、生产环境必须做的 3 件事

1. 数据持久化：Prometheus 默认数据存在内存，重启即丢。加参数 --storage.tsdb.retention.time=30d --storage.tsdb.path=/data/prometheus。

2. 监控 Prometheus 自身：在 prometheus.yml 里加 - job_name: 'prometheus'，然后告警规则里写 up{job="prometheus"} == 0。

3. 配置健康检查：用 curl http://localhost:9090/-/ready 来检测 Prometheus 是否就绪，配合 systemd 实现自动重启。

延伸思考

• 如果你有 50+ 台机器，Prometheus 单机扛不住，得学 Thanos 或 VictoriaMetrics 做集群。
• 告警规则不是配完就完事，每季度要 review 一次：哪些告警从没触发过？哪些误报率太高？删掉或调整。
• 别把所有指标都拉到 Prometheus 里，只监控你需要关心的，否则存储爆炸、查询变慢。

最后一句实话：Prometheus 入门容易，精通难。 我踩过的这三个坑，你大概率也会遇到。现在你已经知道怎么避开了，动手试试吧。