Prometheus 报警规则配置#

Prometheus 的报警规则是整个报警系统的核心。一条好的报警规则不仅能够在正确的时机触发，还需要提供足够的上下文让接收者快速响应。报警规则配置的质量直接决定了告警的有效性。

#PromQL 表达式基础

报警条件的核心是 PromQL 表达式。常见的报警模式包括：

阈值报警：最简单的报警类型，当指标超过或低于某个阈值时触发。

# CPU 使用率超过 80% 持续 5 分钟
avg by (instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) < 0.2

比率变化报警：用于检测变化率异常，适合业务指标监控。

# HTTP 5xx 错误率超过 1%
sum by (service)(rate(http_requests_total{status=~"5.."}[5m]))
/
sum by (service)(rate(http_requests_total[5m])) > 0.01

连续 N 次报警：避免抖动导致的误报，通常使用 for 子句实现。

# 内存使用率超过 90% 持续 3 分钟才触发
(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.1
  and on(instance)
  (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.1
  offset 3m

#Labels 设计

Labels 决定了报警如何路由和分组。良好的 Labels 设计应当包含：

Labels 不应该包含动态变化的数值（如具体的错误数或延迟值），这些信息应该放在 Annotations 中。

#Annotations 设计

Annotations 存放报警的详细描述信息，这些信息不会用于路由，但会在报警通知中展示。典型的 Annotations 包括：

summary：简短的告警描述，一句话说明发生了什么。

summary: "订单服务 CPU 使用率过高"

description：详细的告警说明，包含具体数值和单位。

description: "订单服务的 CPU 使用率已达 {{ $value }}%，超过阈值 80%"

runbook_url：关联的故障处理手册，让不熟悉的工程师也能快速上手。

dashboard：指向相关仪表盘的链接，便于快速定位问题。

#最佳实践

避免报警风暴：使用 group_by 控制报警分组数量，避免同一故障产生大量重复告警。

添加超时时间：for 子句的设置需要权衡。太短会导致抖动误报，太长则延迟发现问题的时机。

定期评估有效性：每季度审视一次报警规则，删除不再有效的规则，补充遗漏的监控场景。