Prometheus监控告警规则设计实战：指标选型与分级告警配置

Prometheus告警规则设计的质量直接决定故障响应速度。告警太多会造成疲劳，真正的故障被淹没在噪音里；告警太少又会漏掉关键异常。设计监控告警体系的原则：覆盖服务可用性的核心指标，按影响面分级，每条告警都有明确的处置手册。本文给出从指标选型、规则编写到分级配置的完整方案，配置可直接复用。

监控指标选型：四类黄金指标如何采集

Google SRE提出的四个黄金信号是告警规则的基础：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。以HTTP服务为例，四个指标的PromQL查询：

# 延迟P99（按5分钟窗口）
histogram_quantile(0.99,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

# 流量：每秒请求数
sum(rate(http_request_duration_seconds_count[5m]))

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

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

采集端推荐cAdvisor（容器）、node_exporter（主机）、blackbox_exporter（拨测）的组合，应用侧通过/client库暴露RED指标。指标标签保持精简，只保留service、instance、endpoint三个维度，标签基数超过1万的指标要重新设计，否则存储与查询都会劣化。

Prometheus告警规则编写：语法与分组实战

规则文件的核心是表达式、持续时间（for）与标签三个字段。以下为Web服务的完整规则示例：

groups:
- name: web-service
  rules:
  - alert: HighErrorRate
    expr: |
      sum(rate(http_request_duration_seconds_count{status=~"5.."}[5m]))
      / sum(rate(http_request_duration_seconds_count[5m])) > 0.05
    for: 3m
    labels:
      severity: critical
      team: backend
    annotations:
      summary: "{{ $labels.service }} 5xx错误率超过5%"
      description: "当前错误率 {{ $value | humanizePercentage }}，持续3分钟"
      runbook_url: "https://wiki.example.com/runbook/high-error-rate"

  - alert: LatencyP99High
    expr: |
      histogram_quantile(0.99,
        sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
      > 1.5
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "P99延迟超过1.5秒"

for字段的作用是过滤瞬时抖动，核心服务取2-3分钟，边缘服务取10-15分钟。聚合维度按业务影响面确定，服务级聚合比实例级告警噪音少一个量级——单实例异常大概率被负载均衡消化，不必打扰值班人员。

分级告警策略：severity标签与通知路由配置

告警分三级处理。critical（影响核心功能）打电话并拉群，5分钟响应；warning（潜在风险）发IM消息，当天处理；info（趋势提示）只进看板，周报回顾。Alertmanager的路由配置：

route:
  group_by: ['service', 'severity']
  group_wait: 30s        # 同组告警合并等待时间
  group_interval: 5m     # 同组新告警的通知间隔
  repeat_interval: 4h    # 未恢复告警的重复通知
  routes:
  - match:
      severity: critical
    receiver: phone-call
    repeat_interval: 30m
  - match:
      severity: warning
    receiver: im-bot
  - match:
      severity: info
    receiver: archive

抑制规则（inhibit_rules）用于告警风暴治理：critical触发时自动屏蔽同服务的warning，主机down时屏蔽其上所有实例告警：

inhibit_rules:
- source_match:
    severity: critical
  target_match:
    severity: warning
  equal: ['service']

告警规则治理：降噪与有效性验证

告警上线后需要持续治理。每周统计三个数据：告警总量、误报率（值班人员确认为噪音的占比）、MTTR（平均响应时间）。单条规则周触发超过10次说明阈值或聚合维度设计有问题。验证新规则有效性的做法是先以severity: info观察两周，确认触发模式符合预期后再提级。规则文件纳入Git管理，改动词必须附带触发样例，避免”拍脑袋调阈值”。最后给每条critical告警配runbook链接，值班人员按步骤处置，这是缩短MTTR最有效的手段。