Prometheus + Grafana 监控告警体系搭建实战：从指标采集到智能告警

监控告警体系对 SRE 稳定性工程的价值

SRE 的核心工作之一是缩短故障发现到响应的时间窗口（MTTD）。没有监控的生产环境，等于蒙眼开车。Prometheus 作为时序数据采集和存储引擎，Grafana 作为可视化与告警前端，二者的组合是目前主流的监控方案。这套体系不只是看图表，关键是定义好指标、阈值和告警规则，让系统在出问题之前发出预警。

架构设计：组件与数据流

完整的 Prometheus + Grafana 监控体系包含四个组件：

Prometheus Server：核心采集和存储引擎，通过 HTTP 拉取目标暴露的 metrics 端点，数据存储在本地 TSDB。

Exporter：暴露 metrics 端点的采集代理。node_exporter 采集主机指标，mysqld_exporter 采集 MySQL 指标，blackbox_exporter 采集网络探测指标。应用自身也可以通过 Prometheus SDK 直接暴露 metrics。

Alertmanager：接收 Prometheus 触发的告警，负责去重、分组、路由、静默和通知。支持邮件、企业微信、钉钉、Slack 等通知渠道。

Grafana：数据可视化面板，通过 PromQL 查询 Prometheus 数据源，支持告警规则配置和通知。

Prometheus 部署与配置实战

生产环境推荐 Docker 部署：

docker run -d --name=prometheus \
  -p 9090:9090 \
  -v /data/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \
  -v /data/prometheus/data:/prometheus \
  prom/prometheus:latest

核心配置文件 prometheus.yml：

global:
  scrape_interval: 15s
  evaluation_interval: 15s

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager:9093']

rule_files:
  - 'rules/*.yml'

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets:
          - 'web-01:9100'
          - 'web-02:9100'
          - 'db-01:9100'
    relabel_configs:
      - source_labels: [__address__]
        target_label: instance

  - job_name: 'mysql'
    static_configs:
      - targets: ['db-01:9104']

  - job_name: 'blackbox-http'
    metrics_path: probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - https://api.example.com/health
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox-exporter:9115

scrape_interval 设 15 秒，粒度够细又不给系统造成太大负担。HTTP 探测通过 blackbox_exporter 间接采集，relabel 配置让 target 地址正确传递。

告警规则设计与分级

告警规则放在 rules/ 目录下，按严重级别分层：

# rules/infrastructure.yml
groups:
  - name: infrastructure
    rules:
      # P0 - 紧急：服务宕机
      - alert: NodeDown
        expr: up{job="node"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "节点 {{ $labels.instance }} 不可达"
          description: "已持续 1 分钟无法采集到 {{ $labels.instance }} 的指标"

      # P1 - 严重：磁盘即将满
      - alert: DiskSpaceWarning
        expr: |
          (node_filesystem_avail_bytes{fstype=~"ext4|xfs"}
          / node_filesystem_size_bytes{fstype=~"ext4|xfs"}) < 0.15
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }} 磁盘 {{ $labels.mountpoint }} 剩余空间不足 15%"

      # P2 - 提醒：CPU 使用率偏高
      - alert: HighCPU
        expr: |
          100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 10m
        labels:
          severity: info
        annotations:
          summary: "{{ $labels.instance }} CPU 使用率超过 80% 持续 10 分钟"

for 字段是关键：设置了持续时间窗口，避免瞬时抖动触发告警。P0 告警的 for 设 1 分钟，P2 设 10 分钟，区分紧急和缓急。

Alertmanager 告警路由与通知策略

Alertmanager 配置核心是路由树和静默规则：

global:
  resolve_timeout: 5m

route:
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default'
  routes:
    - match:
        severity: critical
      receiver: 'oncall-pager'
      repeat_interval: 15m
    - match:
        severity: warning
      receiver: 'team-chat'

receivers:
  - name: 'default'
    email_configs:
      - to: 'sre@company.com'
        from: 'alertmanager@company.com'
        smarthost: 'smtp.company.com:587'
  - name: 'oncall-pager'
    webhook_configs:
      - url: 'http://pagerduty-webhook/notify'
  - name: 'team-chat'
    webhook_configs:
      - url: 'http://dingtalk-webhook/notify'

group_by 控制告警合并维度——同一类告警聚在一起发一条通知。group_wait 是首次等待时间，group_interval 是同组新告警的间隔。repeat_interval 控制未恢复告警的重复通知频率，P0 级别 15 分钟提醒一次，P2 级别 4 小时提醒一次。

Grafana 仪表盘搭建

Grafana 添加 Prometheus 数据源后，关键仪表盘的指标配置：

节点总览面板：

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

# 内存使用率
(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100

# 磁盘 I/O 利用率
rate(node_disk_io_time_seconds_total[5m])

# 网络带宽
rate(node_network_receive_bytes_total{device=~"eth0|ens.*"}[5m])

服务健康面板：

# HTTP 探测成功率
probe_success{job="blackbox-http"}

# 请求延迟 P99
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

# 请求错误率
sum(rate(http_requests_total{code=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

Grafana 支持变量模板，用 $instance 变量做面板过滤，一套模板适配多台服务器。

混沌工程验证监控覆盖度

搭建完监控体系，必须验证告警是否真的能触发。用混沌工程手段主动注入故障：

# 模拟 CPU 满载
stress-ng --cpu 4 --timeout 600s

# 模拟磁盘写满
dd if=/dev/zero of=/tmp/fillfile bs=1M count=50000

# 模拟网络延迟
tc qdisc add dev eth0 root netem delay 500ms 100ms

注入故障后观察：告警是否在预期时间内触发？通知是否到达正确渠道？值班人员能否根据告警信息快速定位问题？这套验证流程建议每月执行一次，确保监控规则始终有效。

监控告警体系的目标不是面板数量，而是故障发生时能在 MTTD 内准确定位。Prometheus + Grafana 的组合提供了灵活的指标采集和告警定义能力，关键在于告警规则要和业务 SLI 挂钩，覆盖度要通过混沌工程持续验证。