4. Prometheus告警规则基础

Prometheus 告警规则是监控体系的核心执行单元，它定义了“什么条件下触发告警”。在 Argo CD 同步工程中，告警规则被标准化为模板，随应用部署自动同步。本章深入剖析告警规则的语法结构、分组策略、抑制与静默机制，为后续模板化工程奠定基础。

4.1 告警规则语法结构

每条 Prometheus 告警规则由 名称、表达式、持续时间 和 标签/注解 四部分组成。规则文件采用 YAML 格式，通常放置在 rules/ 目录下。

groups:
  - name: example-group
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          /
          sum(rate(http_requests_total[5m]))
          > 0.05
        for: 2m
        labels:
          severity: critical
          team: platform
        annotations:
          summary: "HTTP 5xx 错误率超过 5%"
          description: "当前错误率 {{ $value | humanizePercentage }}，已持续 2 分钟"
字段 必填 说明 典型值
alert 是 告警名称，必须唯一 HighErrorRate
expr 是 PromQL 表达式，返回非零值即触发 rate(...) > 0.05
for 否 持续时间，防止抖动误报 2m、5m
labels 否 附加标签，用于路由和分组 severity: critical
annotations 否 描述信息，支持模板变量 summary、description
模板变量提示： 注解中可使用 {{ $value }}、{{ $labels.instance }} 等变量动态填充当前值。在 Argo CD 模板中，这些变量会被保留，由 Prometheus 在运行时解析。

4.2 告警分组机制

分组（Grouping）将相似告警合并为一条通知，避免告警风暴。分组在 alertmanager.yml 中配置，核心参数如下：

参数 默认值 作用
group_by ['...'] 按哪些标签分组，如 ['severity', 'team']
group_wait 30s 首次告警等待时间，收集同组告警
group_interval 5m 同组新告警的发送间隔
repeat_interval 4h 已解决告警的重复通知间隔
工程实践： 在 Argo CD 模板中，group_by 通常固定为 ['alertname', 'severity', 'namespace']，确保同一命名空间下的同类告警合并为一条通知，减少运维噪音。

4.3 抑制机制

抑制（Inhibition）用于在高级别告警已触发时，自动屏蔽低级别关联告警。例如：节点宕机时，抑制该节点上所有 Pod 的不可达告警。

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

抑制规则三要素：

  • source_match：源告警匹配条件（高级别）
  • target_match：目标告警匹配条件（被抑制）
  • equal：必须相等的标签列表，确保抑制范围精确
注意： 抑制规则不要过度泛化。避免使用 equal: ['...'] 通配，否则可能误屏蔽真正需要关注的告警。建议至少包含 namespace 或 instance 作为限定标签。

4.4 静默机制

静默（Silence）是运维人员主动设置的告警屏蔽，常用于计划内维护窗口。静默通过 Alertmanager API 或 Web UI 创建，支持定时过期。

属性 说明 示例
匹配器 标签匹配表达式 severity =~ "warning|critical"
开始/结束时间 静默生效窗口 2025-04-10 02:00 至 2025-04-10 06:00
创建者 操作人标识 ops-team
注释 静默原因说明 数据库升级维护
模板化静默： 在 Argo CD 工程中，可将静默配置作为 Application 的额外资源，通过 Silence CRD 或 Alertmanager API 自动创建，实现维护窗口的声明式管理。

4.5 告警生命周期与状态流转

告警从产生到关闭经历多个状态，理解状态流转有助于排查告警丢失或重复问题。

告警状态流转图 Pending Firing Resolved Silenced for 期满 表达式恢复 静默匹配 静默过期 Pending → Firing 需经过 for 持续时间；Silenced 状态不发送通知

4.6 规则分组与路由关系

告警规则分组（groups）与 Alertmanager 路由分组（group_by）是两个不同层级的概念，容易混淆。下表明确区分：

层级 配置位置 作用 示例
规则分组 rules/*.yml 将多条告警规则组织在一起，共享评估间隔 groups: - name: kubernetes-apps
路由分组 alertmanager.yml 将已触发的告警按标签合并为通知 group_by: ['alertname', 'namespace']
模板化建议： 在 Argo CD 模板中，规则分组按 namespace 或 application 划分，每个分组独立评估。路由分组则统一在 Alertmanager 配置中定义，不随应用模板变化。

4.7 常见告警规则模式

以下列出同步工程中高频使用的告警规则模式，可直接作为模板参考：

  • 错误率突增： sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05
  • 延迟过高： histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 2.0
  • Pod 重启频繁： increase(kube_pod_container_status_restarts_total[10m]) > 3
  • 磁盘空间不足： node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} < 0.1
  • 证书即将过期： certmanager_certificate_expiration_seconds < 604800
避坑指南： 避免在 expr 中使用 absent() 函数检测指标缺失，因为 absent() 在指标恢复时不会自动清除告警。推荐使用 up == 0 或 rate(...) == 0 替代。

4.8 本章小结

Prometheus 告警规则是监控告警的基石。掌握语法结构、分组、抑制与静默机制，能够有效控制告警数量、提升运维效率。在 Argo CD 模板化工程中，规则分组按应用维度组织，抑制与静默通过声明式配置统一管理，确保告警策略随代码同步、可追溯。

← 上一章 📖 返回目录 下一章 →