4. Prometheus 告警规则设计：证书过期、轮换失败与资源不足告警

告警规则是证书轮换调度器的“神经末梢”。本章聚焦三类核心告警：证书过期预警、轮换失败告警以及资源不足告警。每类告警均需精确的 PromQL 表达式、合理的阈值以及清晰的告警分级。

4.1 证书过期告警：从“被动宕机”到“主动预警”

证书过期是最常见的故障原因之一。告警规则应基于证书的 NotAfter 时间戳与当前时间的差值，按剩余天数分级触发。

核心 PromQL 表达式：

# 证书剩余天数（假设指标 x509_cert_not_after 为 Unix 时间戳）
(
  x509_cert_not_after - time()
) / 86400

# Warning: 剩余天数 < 30
(
  x509_cert_not_after - time()
) / 86400 < 30

# Critical: 剩余天数 < 7
(
  x509_cert_not_after - time()
) / 86400 < 7

# Emergency: 剩余天数 < 1
(
  x509_cert_not_after - time()
) / 86400 < 1

4.2 轮换失败告警：捕获“静默失败”

轮换失败可能由多种原因导致：证书签名超时、Secret 更新冲突、Webhook 调用异常等。告警规则应监控轮换操作的 状态指标 和 错误计数。

关键指标设计：

• cert_rotation_total：轮换总次数（Counter）
• cert_rotation_failed_total：轮换失败次数（Counter）
• cert_rotation_duration_seconds：轮换耗时（Histogram）

PromQL 告警规则：

# 轮换失败率 > 5%（最近 5 分钟）
rate(cert_rotation_failed_total[5m])
/
rate(cert_rotation_total[5m]) > 0.05

# 轮换耗时超过 P99 阈值（假设 P99 为 30 秒）
histogram_quantile(0.99, rate(cert_rotation_duration_seconds_bucket[5m])) > 30

# 连续 3 次轮换失败（无成功记录）
increase(cert_rotation_failed_total[15m]) >= 3
and
increase(cert_rotation_total[15m]) == increase(cert_rotation_failed_total[15m])

4.3 资源不足告警：防止“饿死”调度器

证书轮换调度器在执行轮换时需要消耗 CPU、内存以及 API Server 的 QPS 配额。资源不足会导致轮换积压，进而引发证书过期。告警规则需覆盖 系统资源 和 调度器内部资源 两个维度。

PromQL 表达式：

# CPU 使用率告警
sum(rate(container_cpu_usage_seconds_total{container="cert-rotator"}[5m]))
/
sum(kube_pod_container_resource_limits{resource="cpu", container="cert-rotator"})
> 0.8

# 轮换队列深度告警
cert_rotation_queue_depth > 100

# API Server 请求错误率 > 1%
sum(rate(rest_client_requests_total{code=~"5.."}[5m]))
/
sum(rate(rest_client_requests_total[5m]))
> 0.01

4.4 告警规则聚合与路由策略

为减少告警风暴，建议使用 Prometheus Alertmanager 对告警进行分组和抑制。以下是一个典型的路由配置示例：

groups:
- name: cert-rotation-alerts
  rules:
  - alert: CertExpiryWarning
    expr: (x509_cert_not_after - time()) / 86400 < 30
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "证书 {{ $labels.cert_name }} 将在 30 天内过期"

  - alert: CertRotationFailed
    expr: rate(cert_rotation_failed_total[5m]) / rate(cert_rotation_total[5m]) > 0.05
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "证书 {{ $labels.cert_name }} 轮换失败率超过 5%"

  - alert: CertRotatorResourcePressure
    expr: cert_rotation_queue_depth > 100
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "轮换队列深度 {{ $value }}，可能存在资源瓶颈"

4.5 告警规则验证与测试

在将告警规则部署到生产环境前，建议使用 promtool 进行语法和逻辑验证：

# 检查规则语法
promtool check rules cert-rotation-rules.yml

# 单元测试规则（需准备测试数据）
promtool test rules cert-rotation-test.yml

测试用例示例：

rule_files:
  - cert-rotation-rules.yml

evaluation_interval: 1m

tests:
  - interval: 1m
    input_series:
      - series: 'x509_cert_not_after{namespace="default", cert_name="ingress-tls"}'
        values: '1700000000 1700000000 1700000000'
    alert_rule_test:
      - eval_time: 5m
        alertname: CertExpiryWarning
        exp_alerts:
          - exp_labels:
              severity: warning
              namespace: default
              cert_name: ingress-tls
            exp_annotations:
              summary: "证书 ingress-tls 将在 30 天内过期"

4.6 告警生命周期与自愈闭环

告警不应只是“通知”，而应驱动自动化修复。以下 SVG 展示了从告警触发到证书轮换完成的闭环流程：

4.7 告警规则性能优化

高基数标签（如 cert_name 包含大量唯一值）会导致 Prometheus 内存飙升。优化建议：

• 减少不必要的标签：只保留 namespace、cert_name、severity 等关键标签。
• 使用记录规则预聚合：对于频繁查询的复杂表达式，创建记录规则。
• 设置合理的评估间隔：Warning 级别告警可设为 5 分钟评估一次，Critical 级别设为 1 分钟。

# 记录规则示例：预计算证书剩余天数
groups:
  - name: cert_recording_rules
    interval: 5m
    rules:
      - record: cert:days_remaining
        expr: (x509_cert_not_after - time()) / 86400

# 告警规则引用记录规则
  - alert: CertExpiryWarning
    expr: cert:days_remaining < 30
    for: 10m