HOOOS

Prometheus告警优化实战：Recording Rules与Alerting Rules精讲，告别误报漏报！

0 76 容器老司机阿强 Prometheus告警监控
Apple

大家好，我是你们的“容器老司机”阿强！今天咱们来聊聊Prometheus告警优化这个话题。相信不少小伙伴在使用Prometheus进行监控告警时，都遇到过“告警风暴”、“关键告警被淹没”、“误报漏报”等问题。别担心，阿强今天就带你深入了解Prometheus的Recording Rules和Alerting Rules，教你如何通过它们来优化告警，让你的监控系统更精准、更可靠！

为什么我们需要优化告警？

在正式讲解Recording Rules和Alerting Rules之前，咱们先来聊聊为什么需要优化告警。想象一下，如果你的监控系统每天都给你发送成百上千条告警，你还能从中快速找到真正关键的告警吗？恐怕早就“告警疲劳”了吧！

一个好的告警系统，应该具备以下特点：

  • 及时性： 在问题发生时，能够及时发出告警。
  • 准确性： 告警信息准确反映问题的本质，避免误报和漏报。
  • 可读性： 告警信息清晰易懂，方便快速定位问题。
  • 可操作性： 告警信息能够指导你采取相应的行动。

而Prometheus的Recording Rules和Alerting Rules，正是帮助我们实现这些目标的关键。

Recording Rules：预计算，提效率

Recording Rules，顾名思义，就是“记录规则”。它的作用是将一些常用的、复杂的PromQL查询表达式预先计算并保存为一个新的时间序列。这样做的好处有：

  • 提高查询效率： 当我们需要多次使用同一个复杂的PromQL查询时，Recording Rules可以避免重复计算，大大提高查询效率。
  • 降低Prometheus负载： 预计算可以减少Prometheus的计算压力，尤其是在高负载情况下。
  • 简化Alerting Rules： 预计算后的时间序列可以在Alerting Rules中直接使用，简化告警规则的配置。

Recording Rules实战

假设我们需要监控每个Job的请求失败率，并且这个失败率需要在多个告警规则中使用。我们可以创建一个Recording Rule来预先计算这个失败率。

# recording_rules.yml

groups:
  - name: example
    rules:
    - record: job:request_failure_rate:ratio
      expr: sum(rate(http_requests_total{status=~"5.."}[5m])) by (job) / sum(rate(http_requests_total[5m])) by (job)

在这个例子中，我们创建了一个名为job:request_failure_rate:ratio的Recording Rule。它的expr字段定义了一个PromQL表达式，用于计算每个Job的请求失败率。这个表达式的含义是：

  1. rate(http_requests_total{status=~"5.."}[5m]): 计算过去5分钟内，状态码为5xx的HTTP请求的速率。
  2. sum(...) by (job): 按照Job进行分组，计算每个Job的5xx请求速率。
  3. rate(http_requests_total[5m]): 计算过去5分钟内所有HTTP请求的速率。
  4. sum(...) by (job): 按照Job进行分组，计算每个Job的总请求速率。
  5. /: 将5xx请求速率除以总请求速率，得到每个Job的请求失败率。

将这个Recording Rule文件添加到Prometheus的配置文件中，并重新加载Prometheus，就可以在Prometheus的Web UI中看到这个新的时间序列了。

Alerting Rules：告警触发，通知到位

Alerting Rules，即“告警规则”。它的作用是根据PromQL表达式的计算结果，判断是否触发告警，并通过Alertmanager发送告警通知。

Alerting Rules实战

有了上面预计算的job:request_failure_rate:ratio时间序列，我们就可以创建一个Alerting Rule来监控每个Job的请求失败率。

# alerting_rules.yml

groups:
  - name: example
    rules:
    - alert: HighRequestFailureRate
      expr: job:request_failure_rate:ratio > 0.05
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "High request failure rate for job {{ $labels.job }}"
        description: "Job {{ $labels.job }} has a request failure rate of {{ $value | printf \"%.2f\" }}% for the last 5 minutes."

在这个例子中，我们创建了一个名为HighRequestFailureRate的Alerting Rule。它的expr字段定义了一个PromQL表达式，用于判断是否触发告警。这个表达式的含义是：

  • job:request_failure_rate:ratio > 0.05: 如果job:request_failure_rate:ratio的值大于0.05（即5%），则触发告警。

for字段指定了告警的持续时间。在这个例子中，只有当job:request_failure_rate:ratio持续5分钟大于0.05时，才会触发告警。这样可以避免一些短暂的波动导致的误报。

labels字段用于给告警添加标签。在这个例子中，我们添加了一个severity标签，值为critical，表示这是一个严重告警。

annotations字段用于给告警添加注释。summary字段是告警的摘要信息，description字段是告警的详细描述。在annotations中，我们可以使用模板变量来引用PromQL表达式中的标签和值。例如，{{ $labels.job }}表示引用job标签的值，{{ $value }}表示引用PromQL表达式的计算结果。

将这个Alerting Rule文件添加到Prometheus的配置文件中，并重新加载Prometheus，就可以在Alertmanager中配置告警通知方式（例如邮件、Slack、Webhook等）。

告警优化技巧

除了上面介绍的基本用法，还有一些告警优化技巧可以帮助你减少误报和漏报：

  1. 合理设置阈值： 告警阈值的设置需要根据实际情况进行调整。如果阈值设置过低，容易导致误报；如果阈值设置过高，可能会导致漏报。可以通过观察历史数据，分析业务特点，逐步调整阈值，找到一个合适的平衡点。

  2. 使用for关键字： for关键字可以避免一些短暂的波动导致的误报。只有当PromQL表达式的计算结果持续一段时间都满足告警条件时，才会触发告警。

  3. 使用聚合函数： 聚合函数（例如sum、avg、max、min等）可以对多个时间序列进行聚合，减少告警数量。例如，我们可以使用sum by (job)来计算每个Job的总请求数，而不是对每个实例的请求数都发出告警。

  4. 使用标签进行分组： 标签可以帮助我们对告警进行分组和过滤。例如，我们可以使用severity标签来区分不同严重程度的告警，使用environment标签来区分不同环境的告警。

  5. 抑制告警： Alertmanager提供了抑制告警的功能。当一个告警触发后，可以抑制其他相关的告警，避免“告警风暴”。例如，当一个服务的多个实例都出现故障时，我们可以只发送一个告警，而不是对每个实例都发送一个告警。

  6. 静默告警: 某些情况下, 我们可能希望某些告警在特定时间内不发出通知, 例如在计划内的维护期间. Alertmanager 提供了静默告警的功能, 可以临时静默某些告警。

  7. 告警升级: 对于一些重要的告警, 如果在一定时间内没有得到处理, 可以考虑升级告警级别, 例如从 warning 升级到 critical, 或者通知更高级别的负责人。

  8. 定期审查告警规则： 告警规则不是一成不变的，需要根据实际情况进行调整。定期审查告警规则，删除不再需要的告警规则，修改不合理的告警规则，可以保持告警系统的有效性。

总结

Prometheus的Recording Rules和Alerting Rules是强大的工具，可以帮助我们构建一个高效、可靠的告警系统。通过预计算、合理设置阈值、使用聚合函数、使用标签进行分组等技巧，我们可以减少误报和漏报，提高告警的准确性和可操作性。希望今天的分享能帮助你更好地使用Prometheus，让你的监控系统更上一层楼！

如果你还有其他关于Prometheus告警优化的问题，欢迎在评论区留言，阿强会尽力为你解答！

附录：PromQL常用函数

  • rate(): 计算每秒平均速率。
  • sum(): 求和。
  • avg(): 求平均值。
  • max(): 求最大值。
  • min(): 求最小值。
  • count(): 计数。
  • topk(): 返回前K个最大的值。
  • bottomk(): 返回前K个最小的值。
  • quantile(): 计算分位数。

附录：Alertmanager配置示例 (抑制告警)

route:
  receiver: 'team-x-mails'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
  group_by: [cluster, alertname]
  routes:
  - match:
      severity: 'critical'
    receiver: 'team-x-pager'
    continue: true

inhibit_rules:
- source_match:
    severity: 'critical'
  target_match:
    severity: 'warning'
  equal: ['cluster', 'alertname']

这个配置表示，如果一个severity为critical的告警触发了，那么所有severity为warning，并且cluster和alertname标签相同的告警都会被抑制。

附录：Alertmanager配置示例 (静默告警)

在 Alertmanager 的 Web UI 中，可以手动创建静默规则。也可以通过 API 创建。

{
  "matchers": [
    {
      "name": "alertname",
      "value": "HighRequestFailureRate",
      "isRegex": false
    },
      {
        "name": "job",
        "value": "api-server",
        "isRegex": false
      }
  ],
  "startsAt": "2023-10-27T10:00:00Z",
  "endsAt": "2023-10-27T12:00:00Z",
  "createdBy": "admin",
  "comment": "Scheduled maintenance"
}

这个静默规则表示, 从2023年10月27日10:00到12:00, alertname 为 HighRequestFailureRate 并且 job 为 api-server 的告警将被静默。

希望这些示例能帮助你更好地理解和使用 Alertmanager。

点评评价

captcha
健康