告警规则的基本结构

一条完整的 Prometheus 告警规则包含 5 个要素：

groups:
  - name: example
    rules:
      - alert: HighCPUUsage          # 告警名称
        expr: cpu_usage > 0.8        # PromQL 表达式
        for: 5m                      # 持续时间阈值
        labels:
          severity: warning          # 标签
        annotations:
          summary: "CPU 使用率过高"   # 注解
          description: "实例 {{ $labels.instance }} CPU 使用率 {{ $value }}"

注意事项1：合理设置持续时间阈值（for）

  • 太短：产生大量误报（网络抖动、瞬时峰值）
  • 太长：真实故障发现延迟

建议：

  • 关键指标（服务不可用）：2-5 分钟
  • 资源指标（CPU、内存）：10-15 分钟
  • 趋势类指标（磁盘增长）：30 分钟以上

注意事项2：避免高基数标签

不要在告警规则中使用用户 ID、请求 ID 等高基数标签，会导致时间序列爆炸。

# 错误示例
expr: http_requests_total{user_id=~".+"} > 100

# 正确示例
expr: sum(rate(http_requests_total[5m])) by (service) > 100

注意事项3：善用标签和注解

标签用于路由和分组，注解用于提供上下文信息。

annotations:
  summary: "服务 {{ $labels.service }} 响应时间过高"
  description: "P99 延迟 {{ $value }}ms，超过阈值 500ms"
  runbook: "https://wiki.example.com/runbook/high-latency"

注意事项4：防止告警疲劳

按严重程度分层，只对需要立即人工介入的情况发送告警。

使用 Inhibition 规则：当严重告警触发时，自动抑制相关的警告级告警。

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

注意事项5：基于历史数据设置阈值

不要用通用标准，要基于实际观测的基线数据。同一个指标在不同业务场景下的正常范围差异很大。

注意事项6：测试和验证

# 语法检查
promtool check rules /etc/prometheus/rules/*.yml

# 单元测试
promtool test rules /etc/prometheus/tests/*.yml

在测试环境验证告警规则，确认触发条件和通知内容符合预期。

注意事项7：定期维护

  • 定期审查告警触发记录，清理长期不触发或频繁误报的规则
  • 用版本控制管理告警规则文件
  • 为每条规则添加注释，说明告警的业务含义和处理建议