Prometheus+Alertmanager监控告警体系搭建：从指标采集到分级告警的完整方案

监控告警体系为什么是SRE的第一优先级

没有监控的系统等于黑盒。线上故障时靠用户反馈发现问题，MTTR（平均恢复时间）至少翻10倍。Prometheus+Alertmanager是云原生生态中事实上的监控标准，这套方案覆盖指标采集、规则配置、分级告警、路由分发四个环节，适用于50-500节点规模的生产环境。

Prometheus部署与基础配置

Prometheus的部署没有复杂依赖，一个二进制文件加配置文件即可运行。核心配置逻辑在prometheus.yml：

# prometheus.yml
global:
  scrape_interval: 15s          # 全局采集间隔
  evaluation_interval: 15s      # 规则评估间隔
  external_labels:
    cluster: 'production'
    env: 'prod'

scrape_configs:
  # Prometheus自监控
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  # Node Exporter - 主机指标
  - job_name: 'node'
    file_sd_configs:
      - files:
        - '/etc/prometheus/targets/node/*.yml'
        refresh_interval: 30s

  # 应用指标 - Kubernetes服务发现
  - job_name: 'k8s-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
        target_label: __metrics_path__
        regex: (.+)
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port]
        target_label: __address__
        regex: (.+)
        replacement: ${1}:9112

文件服务发现（file_sd_configs）是动态管理采集目标的最简方案。Ansible或Terraform部署新节点时，把目标文件丢进对应目录即可，Prometheus会自动加载，无需重启。

关键指标采集：四个黄金信号

Google SRE提出的四个黄金信号是监控体系的骨架：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。对应到Prometheus的核心指标：

# 延迟 - P50/P90/P99分位数
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

# 流量 - QPS
rate(http_requests_total[5m])

# 错误率 - 5xx占比
rate(http_requests_total{status=~"5.."}[5m]) 
/ rate(http_requests_total[5m])

# 饱和度 - CPU/内存/连接池使用率
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes

不监控所有指标，只监控决策需要的指标。每条告警规则必须对应一个明确的处理动作。如果一条告警触发后你不知道该做什么，这条告警就是噪音。

告警规则设计：分级与抑制

告警分级的本质是告诉值班人员”该在多长时间内响应”。三级模型：

# 告警规则文件: /etc/prometheus/rules/infrastructure.yml
groups:
  - name: infrastructure
    rules:
      # P0 - 立即响应（30分钟内）
      - alert: ServiceDown
        expr: up == 0
        for: 2m
        labels:
          severity: critical
          team: sre
        annotations:
          summary: "服务 {{ $labels.job }} 实例 {{ $labels.instance }} 已宕机"
          runbook: "https://wiki.internal/runbooks/service-down"

      # P1 - 4小时内响应
      - alert: HighErrorRate
        expr: |
          rate(http_requests_total{status=~"5.."}[5m]) 
          / rate(http_requests_total[5m]) > 0.05
        for: 5m
        labels:
          severity: warning
          team: sre
        annotations:
          summary: "服务 {{ $labels.job }} 错误率超过5%"

      # P2 - 工作时间内处理
      - alert: HighMemoryUsage
        expr: |
          (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) > 0.85
        for: 15m
        labels:
          severity: info
          team: sre
        annotations:
          summary: "实例 {{ $labels.instance }} 内存使用率超过85%"

for字段是告警的忍耐期。ServiceDown只等2分钟就告警，因为服务挂了是紧急问题。HighMemoryUsage等15分钟，因为可能是正常的突发流量，等它自然回落。

抑制规则：同一条链路上的告警只发最高级别那条，避免告警风暴：

# alertmanager.yml 抑制配置
inhibit_rules:
  # 如果服务宕机，抑制该实例的所有其他告警
  - source_match:
      severity: 'critical'
      alertname: 'ServiceDown'
    target_match:
      severity: 'warning'
    equal: ['instance']

  # 如果节点宕机，抑制该节点上的所有应用告警
  - source_match:
      alertname: 'NodeDown'
    target_match:
      alertname: 'ServiceDown'
    equal: ['instance']

Alertmanager配置：路由与分派

Alertmanager的核心能力是路由分发——不同级别告警走不同通道，不同团队告警互不干扰：

# alertmanager.yml
route:
  receiver: 'default'
  group_by: ['alertname', 'cluster']
  group_wait: 30s        # 同组告警等待30s再发送（合并）
  group_interval: 5m     # 同组新告警间隔5m
  repeat_interval: 4h    # 未恢复告警4h重复一次

  routes:
    # P0告警 - 电话+钉钉
    - match:
        severity: critical
      receiver: 'critical-alert'
      repeat_interval: 30m

    # P1告警 - 钉钉
    - match:
        severity: warning
      receiver: 'warning-alert'
      repeat_interval: 2h

    # P2告警 - 邮件
    - match:
        severity: info
      receiver: 'info-alert'
      repeat_interval: 24h

receivers:
  - name: 'default'
    webhook_configs:
      - url: 'http://alertmanager-webhook:8080/notify'

  - name: 'critical-alert'
    webhook_configs:
      - url: 'http://alertmanager-webhook:8080/critical'
    # 电话通知通过webhook后端调用短信/语音网关

  - name: 'warning-alert'
    webhook_configs:
      - url: 'http://alertmanager-webhook:8080/warning'

  - name: 'info-alert'
    email_configs:
      - to: 'sre-team@example.com'
        send_resolved: true

告警质量治理：消灭告警噪音

告警泛滥是监控体系最大的敌人。治理三原则：

原则1：每条告警必须有runbook。没有runbook的告警 = 没有处理方案的告警 = 值班人员只能凭感觉操作。runbook地址写在annotations里，点开就看到。

原则2：按比例删减告警。统计过去30天的告警触发次数，按频次排序，top 20%的告警占了80%的噪音。逐条review：触发后是否真的需要人工介入？不需要的改成日志，需要的调阈值或加抑制。

原则3：定期红蓝对抗。模拟故障场景，检验告警是否及时触发、路由是否正确、值班是否响应。每季度一次，发现监控盲区立即补规则。

# 告警质量统计查询（PromQL）
# 过去7天触发的告警数量排行
topk(20, count_over_time(ALERTS[7d]))

# 告警恢复时间统计
avg_over_time(ALERTS{alertstate="firing"}[7d]) - avg_over_time(ALERTS{alertstate="resolved"}[7d])

监控告警体系的终极目标不是告警越少越好，而是每条告警都有价值、每个告警都有明确的处理路径。从采集到规则到路由到治理，四步走完，才是一个可运维的监控体系。