📚 课程目录第2章 Prometheus告警体系

2. Prometheus 告警体系：PromQL 基础、告警规则编写、Alertmanager 路由与抑制

在容量规划场景中，告警体系是发现资源瓶颈、触发自动扩缩容或通知运维人员的核心环节。本章从 PromQL 基础语法出发，逐步深入到告警规则编写与 Alertmanager 的路由抑制策略，为后续与 OPA 策略引擎联动打下坚实基础。

2.1 PromQL 基础：容量规划的核心查询语言

PromQL（Prometheus Query Language）是 Prometheus 内置的数据查询与聚合语言。在容量规划中，我们主要使用以下几类查询模式：

查询类型	语法示例	容量规划用途
瞬时向量	`node_cpu_seconds_total{mode="idle"}`	获取当前 CPU 空闲时间
范围向量	`node_memory_MemAvailable_bytes[5m]`	查看过去 5 分钟内存可用量趋势
速率/增量	`rate(node_network_receive_bytes_total[1m])`	计算网络接收速率，用于带宽容量评估
聚合运算	`avg by(instance) (node_cpu_seconds_total)`	按实例聚合 CPU 使用率，识别热点
预测函数	`predict_linear(node_filesystem_free_bytes[1h], 3600)`	预测 1 小时后磁盘剩余空间，用于容量预警

容量规划提示： 使用 predict_linear 函数时，建议结合 deriv 函数验证趋势的稳定性，避免因短期抖动导致误告警。

以下是一个典型的容量规划 PromQL 查询，用于计算 CPU 使用率并过滤空闲实例：

100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80

2.2 告警规则编写：从指标到告警事件

告警规则定义在 Prometheus 配置文件中，通常以 rules/*.yml 形式组织。每条规则包含：告警名称、表达式、持续时间、标签和注解。

容量规划场景下的告警规则模板：

groups:
  - name: capacity_alerts
    rules:
      - alert: HighCPUUsage
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
        for: 10m
        labels:
          severity: warning
          team: capacity
        annotations:
          summary: "Instance {{ $labels.instance }} CPU usage > 85%"
          description: "CPU usage has been above 85% for more than 10 minutes. Current value: {{ $value }}%"

常见陷阱： for 持续时间过短（如 1m）会导致告警抖动；过长（如 1h）则可能错过扩容窗口。容量规划建议设置为 5-15 分钟，具体取决于业务容忍度。

告警规则的生命周期状态包括：

Pending：表达式满足但未达到 for 持续时间。
Firing：表达式持续满足超过 for 时间，触发告警发送。
Resolved：表达式不再满足，告警自动恢复。

2.3 Alertmanager 路由与抑制：告警的智能分发

Alertmanager 负责接收 Prometheus 发送的告警，并根据路由树进行分组、抑制和通知。路由配置是容量规划告警体系的关键枢纽。

2.4 路由配置实战：基于容量规划标签的分发

以下是一个面向容量规划场景的 Alertmanager 路由配置示例：

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

receivers:
  - name: 'capacity-critical'
    webhook_configs:
      - url: 'http://opa-service:8181/v1/data/capacity/autoscale'
  - name: 'capacity-warning'
    email_configs:
      - to: 'capacity-team@company.com'

  关键参数说明：
  group_wait：首次告警发送前的等待时间，用于收集同一组内的其他告警。
group_interval：同一组告警的发送间隔，避免频繁通知。
repeat_interval：告警重复发送的间隔，容量规划中建议设为 2-4 小时。
group_by：按标签分组，容量规划中常用 alertname 和 instance。

2.5 抑制规则：避免告警风暴

抑制规则用于在某个告警触发时，自动屏蔽其他相关告警。在容量规划中，当节点宕机时，应抑制该节点上的所有资源告警。

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

上述规则表示：当 InstanceDown 告警触发时，所有与该实例相关的 warning 级别告警（如 CPU 高、磁盘满）都会被抑制，直到源告警恢复。

抑制场景	源告警	目标告警	匹配标签
节点宕机	InstanceDown	CPU/Memory/Disk 告警	instance
集群不可用	ClusterDown	节点级告警	cluster
网络分区	NetworkPartition	服务连通性告警	region

抑制规则陷阱： 过度使用抑制可能导致关键告警被隐藏。建议在容量规划中只对明确的主从关系（如节点宕机抑制其子资源）设置抑制，避免跨层级抑制。

2.6 告警体系与 OPA 联动的接口设计

Alertmanager 支持通过 Webhook 将告警转发给外部服务。在容量规划场景中，我们将告警发送给 OPA 策略引擎，由 OPA 根据预定义的容量策略决定是否触发自动扩缩容。

告警负载示例（发送给 OPA 的 Webhook）：

{
  "receiver": "capacity-critical",
  "status": "firing",
  "alerts": [
    {
      "status": "firing",
      "labels": {
        "alertname": "HighCPUUsage",
        "instance": "web-server-01",
        "severity": "critical",
        "team": "capacity"
      },
      "annotations": {
        "summary": "CPU usage > 85%",
        "current_value": "92.3"
      },
      "startsAt": "2025-01-15T10:30:00Z"
    }
  ]
}