Prometheus监控告警体系搭建实战：从采集到告警分发的完整链路

Prometheus监控告警体系从搭建到生产化

SRE稳定性工程的核心能力是”看见”——在用户感知故障之前发现问题。Prometheus作为云原生监控的事实标准，配合Grafana和Alertmanager，构成从指标采集、可视化到告警分发的完整链路。DevOps实践中，这套体系的搭建质量直接决定故障平均发现时间(MTTD)。

架构设计与组件选型

生产级Prometheus监控体系架构分三层：

• 采集层：Prometheus Server + Node Exporter + 应用Exporter + Pushgateway
• 存储层：Prometheus本地TSDB + 远程存储(Thanos/VictoriaMetrics/Cortex)
• 展示与告警层：Grafana + Alertmanager + 告警路由

关键决策点：单机Prometheus可支撑百万级活跃时间序列，超过该规模需引入联邦集群或远程读写。VictoriaMetrics在写入吞吐和存储压缩率上优于Thanos，推荐作为远程存储首选。

Prometheus Server部署与调优

生产环境Prometheus Server配置：

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s
  external_labels:
    cluster: 'production'
    replica: 'prom-01'

rule_files:
  - /etc/prometheus/rules/*.yml

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

scrape_configs:
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['10.0.1.1:9100', '10.0.1.2:9100', '10.0.1.3:9100']
    relabel_configs:
      - source_labels: [__address__]
        target_label: instance

  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true

启动参数调优：

prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/data/prometheus \
  --storage.tsdb.retention.time=30d \
  --storage.tsdb.retention.size=500GB \
  --query.max-samples=50000000 \
  --query.timeout=120s \
  --web.max-connections=512 \
  --web.read-timeout=5m

内存占用预估：活跃时间序列数×12字节 + 样本缓存。200万活跃时间序列约需8GB内存，建议预留50%余量，分配16GB。

关键指标采集与Exporter部署

不同层级需要采集的指标集差异显著，以下是生产环境必采指标：

基础设施层（Node Exporter）：

# CPU利用率(扣除idle)
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_avail_bytes{fstype=~"ext4|xfs"} / node_filesystem_size_bytes) * 100

# 磁盘IO等待
rate(node_disk_io_time_seconds_total[5m])

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

容器层（cAdvisor + kube-state-metrics）：

# 容器CPU使用率
sum(rate(container_cpu_usage_seconds_total{container!=""}[5m])) by (pod, namespace)
/ sum(container_spec_cpu_quota / container_spec_cpu_period) by (pod, namespace) * 100

# 容器内存使用率(OOM风险)
container_memory_working_set_bytes / container_spec_memory_limit_bytes * 100

# Pod重启次数
increase(kube_pod_container_status_restarts_total[1h])

# Pending Pod数量
kube_pod_status_phase{phase="Pending"}

应用层需业务自行暴露指标，推荐使用Prometheus客户端库的默认指标+自定义业务指标。

告警规则设计与分级策略

告警设计遵循两个原则：可操作性（收到告警后知道该做什么）和分级响应（不同级别触发不同响应流程）。

# /etc/prometheus/rules/infrastructure.yml
groups:
  - name: infrastructure-critical
    rules:
      - alert: NodeDown
        expr: up{job="node-exporter"} == 0
        for: 2m
        labels:
          severity: P1
          team: sre-infra
        annotations:
          summary: "节点 {{ $labels.instance }} 不可达"
          runbook: "https://wiki/runbook/node-down"

      - alert: DiskSpaceCritical
        expr: (1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 > 90
        for: 5m
        labels:
          severity: P1
          team: sre-infra
        annotations:
          summary: "{{ $labels.instance }} 磁盘 {{ $labels.mountpoint }} 使用率超过90%"

  - name: infrastructure-warning
    rules:
      - alert: HighCPUUsage
        expr: 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 10m
        labels:
          severity: P2
          team: sre-infra
        annotations:
          summary: "{{ $labels.instance }} CPU使用率持续超过80%"

      - alert: HighMemoryUsage
        expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 > 85
        for: 10m
        labels:
          severity: P2
          team: sre-infra

告警分级标准：

Alertmanager告警路由与抑制

Alertmanager的告警路由决定了告警的分发路径，配置不当会导致告警风暴或关键告警丢失。

# alertmanager.yml
route:
  receiver: 'default'
  group_by: ['alertname', 'cluster', 'namespace']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - match:
        severity: P1
      receiver: 'p1-oncall'
      group_wait: 10s
      repeat_interval: 15m
    - match:
        severity: P2
      receiver: 'p2-team'
      group_wait: 1m
      repeat_interval: 1h

inhibit_rules:
  # 节点Down时抑制该节点上的所有告警
  - source_match:
      alertname: NodeDown
    target_match_re:
      alertname: .+
    equal: ['instance']
  # API错误率告警抑制延迟告警
  - source_match:
      alertname: APIErrorRateHigh
    target_match:
      alertname: APILatencyHigh
    equal: ['service']

receivers:
  - name: 'p1-oncall'
    webhook_configs:
      - url: 'http://oncall-webhook/p1'
        send_resolved: true
  - name: 'p2-team'
    webhook_configs:
      - url: 'http://oncall-webhook/p2'

抑制规则是告警治理的核心。上游故障（如节点Down）触发后，下游告警（如该节点上的服务不可用）应被自动抑制，避免同一故障产生大量冗余告警。

Grafana仪表盘设计实战

仪表盘设计的核心原则：信息密度高但不杂乱，故障定位路径清晰。

推荐仪表盘结构：

1. 全局视图：服务健康度矩阵(SLO达成率)、错误率热力图、流量趋势
2. 服务视图：QPS/延迟P50-P99/错误率三线图、资源使用率、依赖关系
3. 基础设施视图：CPU/内存/磁盘/网络四象限、进程资源排行
4. 告警视图：活跃告警列表、告警趋势、MTTR/MTTD统计

仪表盘模板变量设计：

# 变量定义
datasource: Prometheus
变量cluster: label_values(kube_node_info, cluster)
变量namespace: label_values(kube_pod_info{cluster="$cluster"}, namespace)
变量service: label_values(kube_pod_info{cluster="$cluster",namespace="$namespace"}, service)

# 在面板中使用变量
# 请求速率面板
sum(rate(http_requests_total{cluster="$cluster",namespace="$namespace",service="$service"}[5m])) by (status_code)

变量联动使得一个仪表盘可覆盖多集群多服务，避免为每个服务创建独立仪表盘的维护噩梦。

混沌工程验证监控有效性

监控体系搭建完成后，需要通过混沌工程验证其有效性——确保故障发生时告警确实能及时触发。

使用Chaos Mesh验证监控覆盖率：

# 注入网络延迟验证告警触发
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: test-latency-alert
  namespace: chaos-testing
spec:
  action: delay
  mode: one
  selector:
    namespaces: ["production"]
    labelSelectors:
      app: "order-service"
  delay:
    latency: "2000ms"
    jitter: "500ms"
  duration: "10m"

注入后观察：Alertmanager是否在预期时间内触发P2告警？告警信息是否准确指明了故障服务？Grafana仪表盘是否展示了异常指标？如果任何一环缺失，需要回补告警规则或调整仪表盘。

定期执行混沌实验（建议每月一次），持续验证监控体系的有效性，确保生产故障的MTTD稳定在5分钟以内。