Prometheus监控告警体系搭建实战：指标采集、告警规则与分级响应

监控告警体系的目标不是”出图”，而是让故障在影响扩大前被发现、让值班人员第一时间知道该处理什么。只装了Prometheus和Grafana却没有告警分级和响应流程，故障时要么漏报要么告警风暴。搭建一套可用的体系，按指标分层、采集部署、告警规则、通知路由、响应机制五步走。

监控指标分层：从系统资源到业务指标

指标按四个层次组织，每一层回答不同的问题：

• 系统层：CPU、内存、磁盘、网络，用node_exporter采集，回答”机器是否正常”。
• 中间件层：MySQL、Redis、RabbitMQ等，用对应exporter采集，回答”依赖是否正常”。
• 应用层：QPS、延迟分位数、错误率，服务自己暴露/metrics，按RED方法（Rate、Errors、Duration）组织，回答”服务是否健康”。
• 业务层：下单量、支付成功率、登录量，回答”业务是否正常”，是判断故障影响面的最终依据。

Prometheus部署与采集配置

prometheus.yml核心配置：

global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "rules/*.yml"

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

scrape_configs:
  - job_name: node
    static_configs:
      - targets: ["10.0.1.11:9100", "10.0.1.12:9100"]
  - job_name: app
    static_configs:
      - targets: ["10.0.2.11:8080", "10.0.2.12:8080"]

15秒采集间隔对大多数场景够用，告警评估间隔与采集间隔保持一致，避免告警延迟叠加。

告警规则编写：阈值、持续时长与告警风暴预防

告警规则示例：

groups:
  - name: host-alerts
    rules:
      - alert: HostHighCPU
        expr: 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "CPU持续高负载 {{ $labels.instance }}"
      - alert: HostDiskWillFillIn24h
        expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 24*3600) < 0
        for: 30m
        labels:
          severity: critical

三个关键点：阈值别照抄别人的经验值，按自身业务的历史基线设定；for持续时间用来过滤瞬时抖动，CPU、内存类给10分钟，磁盘预测这类不可逆趋势给更长观察期；每条告警的summary必须带实例信息，让值班不需要先查这条告警是什么意思。

Alertmanager路由：分级通知与告警抑制

route:
  receiver: default-webhook
  group_by: [alertname, instance]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - match:
        severity: critical
      receiver: oncall-phone
    - match:
        severity: warning
      receiver: team-wechat

inhibit_rules:
  - source_match:
      severity: critical
    target_match:
      severity: warning
    equal: [instance]

critical走电话或短信触达值班人，warning进群通知。inhibit规则让同一实例触发critical时抑制其warning，避免同一问题重复打扰。group_by把同一主机的多条告警合并成一条通知。

告警分级响应机制：P0到P3的处置约定

• P0：核心业务不可用或存在数据风险，电话叫醒，5分钟内响应。
• P1：核心功能降级，15分钟内响应，给出处理或降级方案。
• P2：非核心异常，工作时间处理。
• P3：容量与趋势类提醒，纳入周会讨论。

每次P0、P1告警处理完做简短复盘：告警是否准确、响应是否及时、规则是否需要调整。告警体系的维护成本主要在规则调优，定期清理两周内没有触发过任何行动的告警项，让每条告警都有存在的理由。