使用 Prometheus 配置 SLO 监控和告警

最新推荐文章于 2024-05-19 20:05:04 发布
最新推荐文章于 2024-05-19 20:05:04 发布
阅读量501 收藏 1
点赞数
文章标签： kubernetes 云原生 可观察性 docker
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/east4ming/article/details/127826445
版权

概述

Prometheus 作为云原生和容器平台监控的事实标准，本期我们来看一下如何通过 Prometheus 配置 SLO 监控和告警.

SLO 告警

SLO 的告警, 根据 Google SRE 官方实践, 建议使用如下几个维度的告警:

  1. Burn Rate(消耗率)Alerts
  2. Error Budget (错误预算)Alerts

Error Budget

假设我们与用户的合同规定，在 7天内的可用性为 99.9%。这相当于10分钟的Error Budget。

Error Budget 的一种参考实现:

  1. 计算过去 7 天(或更长如30天, 或更短如3天)的error budget
  2. 告警级别:
    1. CRITICAL: error budget >= 90%(或100%)(即过去7天已经不可用9.03分钟; 即availability已达到99.91%, 马上接近99.9% 危险阈值)
    2. WARNING: error budget >= 75%

📝Notes:

Key Words:

  • SLO
  • 时间窗口
  • 阈值

Burn Rate

假设我们与用户的合同规定，在 30 天内的可用性为 99.9%。这相当于43分钟的Error Budget。如果我们以小增量的小故障来消耗这43分钟，我们的用户可能仍然很高兴和高效。但是，如果我们在关键业务时间发生 43 分钟的单次中断，该怎么办？可以肯定地说，我们的用户会对这种体验感到非常不满意！

为了解决这个问题，Google SRE引入Burn Rate。定义很简单：如果我们在示例中在 30 天内精确地消耗 43 分钟，则将其称为 1 的消耗速率。如果我们以两倍的速度将其消耗，例如，在15天内消耗殆尽，消耗速率为2，依此类推。如您所见，这使我们能够跟踪长期合规性，并就严重的短期问题发出警报。

下图说明了多种burn rate的概念。X 轴表示时间，Y 轴表示剩余error budget。

SLO Burn Rate

📝Notes:

本质上, Error Budget >= 100% 的告警, 其实就是 Burn Rate 为 1 的这种特殊情况.

Burn Rate 的一种参考实践:

  1. 计算过去1小时(或者更短的窗口5m, 或者更长的窗口3h-6h...)的time window 的 burn rate
  2. 告警级别:
    1. CRITICAL: burn rate >= 14.4(即按照这个速率, 2天内30天的availability error budget就会用尽)
    2. WARNING: burn rate >=7.2 (即按照这个速率, 4天内30天的availability error budget就会用尽)

使用 Prometheus 配置 SLO 监控和告警实战

这里以 2 个典型的 SLO 为例:

  1. HTTP 请求的错误率大于 99.9%(即 在30天的不可用时间为: 43min 11s)
  2. 99% 的 HTTP 请求延迟时间大于 100ms

HTTP 请求错误率

基本信息:

  1. 指标为: http_requests_total
  2. label 为: {job=busi}
  3. 错误的定义: http code 为 5xx, 即 code=~"5xx"

完整的 Prometheus Rule 如下:

groups:
- name: SLOs-http_requests_total
  rules:
  # 过去5m的http请求错误率
  - expr: |
      sum(rate(http_requests_total{job="busi",code=~"5.."}[5m]))
      /
      sum(rate(http_requests_total{job="busi"}[5m]))
    labels:
      job: busi
    record: http_requests_total:burnrate5m
  # 过去30m的
  - expr: |
      sum(rate(http_requests_total{job="busi",code=~"5.."}[30m]))
      /
      sum(rate(http_requests_total{job="busi"}[30m]))
    labels:
      job: busi
    record: http_requests_total:burnrate30m
  # 过去1h的
  - expr: |
      sum(rate(http_requests_total{job="busi",code=~"5.."}[1h]))
      /
      sum(rate(http_requests_total{job="busi"}[1h]))
    labels:
      job: busi
    record: http_requests_total:burnrate1h
  # 过去6h的
  - expr: |
      sum(rate(http_requests_total{job="busi",code=~"5.."}[6h]))
      /
      sum(rate(http_requests_total{job="busi"}[6h]))
    labels:
      job: busi
    record: http_requests_total:burnrate6h
  # 过去1d的        
  - expr: |
      sum(rate(http_requests_total{job="busi",code=~"5.."}[1d]))
      /
      sum(rate(http_requests_total{job="busi"}[1d]))
    labels:
      job: busi
    record: http_requests_total:burnrate1d
  # 过去3d的
  - expr: |
      sum(rate(http_requests_total{job="busi",code=~"5.."}[3d]))
      /
      sum(rate(http_requests_total{job="busi"}[3d]))
    labels:
      job: busi
    record: http_requests_total:burnrate3d
  # 🐾短期内快速燃尽
  # 过去5m和过去1h的燃尽率都大于 14.4
  - alert: ErrorBudgetBurn
    annotations:
      message: 'High error budget burn for job=busi (current value: {{ $value }})'
    expr: |
      sum(http_requests_total:burnrate5m{job="busi"}) > (14.40 * (1-0.99900))
      and
      sum(http_requests_total:burnrate1h{job="busi"}) > (14.40 * (1-0.99900))
    for: 2m
    labels:
      job: busi
      severity: critical
  # 🐾中期时间内燃尽过快
  # 过去30m和过去6h的燃尽率都大于7.2
  - alert: ErrorBudgetBurn
    annotations:
      message: 'High error budget burn for job=busi (current value: {{ $value }})'
    expr: |
      sum(http_requests_total:burnrate30m{job="busi"}) > (7.20 * (1-0.99900))
      and
      sum(http_requests_total:burnrate6h{job="busi"}) > (7.20 * (1-0.99900))
    for: 15m
    labels:
      job: busi
      severity: warning
  # 🐾长期内错误预算超出
  # 过去6h和过去3天的错误预算已燃尽
  - alert: ErrorBudgetAlert
    annotations:
      message: 'High error budget burn for job=busi (current value: {{ $value }})'
    expr: |
      sum(http_requests_total:burnrate6h{job="busi"}) > (1.00 * (1-0.99900))
      and
      sum(http_requests_total:burnrate3d{job="busi"}) > (1.00 * (1-0.99900))
    for: 3h
    labels:
      job: busi
      severity: warning

HTTP 请求延迟

基本信息:

  1. 指标为: http_request_duration_seconds
  2. label 为: {job=busi}
  3. 99% 的 HTTP 请求响应时间都应小于等于 100ms
  4. 只计算成功的请求(毕竟上面已经算过错误率了)

完整的 Prometheus Rule 如下:

groups:
- name: SLOs-http_request_duration_seconds
  rules:
  # 过去5m HTTP 请求响应时间大于100ms(0.1s)的百分比
  - expr: |
      1 - (
        sum(rate(http_request_duration_seconds_bucket{job="busi",le="0.1",code!~"5.."}[5m]))
        /
        sum(rate(http_request_duration_seconds_count{job="busi"}[5m]))
      )
    labels:
      job: busi
      latency: "0.1"
    record: latencytarget:http_request_duration_seconds:rate5m
  # 过去30m的
  - expr: |
      1 - (
        sum(rate(http_request_duration_seconds_bucket{job="busi",le="0.1",code!~"5.."}[30m]))
        /
        sum(rate(http_request_duration_seconds_count{job="busi"}[30m]))
      )
    labels:
      job: busi
      latency: "0.1"
    record: latencytarget:http_request_duration_seconds:rate30m
  # 过去1h的
  - expr: |
      1 - (
        sum(rate(http_request_duration_seconds_bucket{job="busi",le="0.1",code!~"5.."}[1h]))
        /
        sum(rate(http_request_duration_seconds_count{job="busi"}[1h]))
      )
    labels:
      job: busi
      latency: "0.1"
    record: latencytarget:http_request_duration_seconds:rate1h
  # 过去2h的
  - expr: |
      1 - (
        sum(rate(http_request_duration_seconds_bucket{job="busi",le="0.1",code!~"5.."}[2h]))
        /
        sum(rate(http_request_duration_seconds_count{job="busi"}[2h]))
      )
    labels:
      job: busi
      latency: "0.1"
    record: latencytarget:http_request_duration_seconds:rate2h
  # 过去6h的
  - expr: |
      1 - (
        sum(rate(http_request_duration_seconds_bucket{job="busi",le="0.1",code!~"5.."}[6h]))
        /
        sum(rate(http_request_duration_seconds_count{job="busi"}[6h]))
      )
    labels:
      job: busi
      latency: "0.1"
    record: latencytarget:http_request_duration_seconds:rate6h
  # 过去1d的
  - expr: |
      1 - (
        sum(rate(http_request_duration_seconds_bucket{job="busi",le="0.1",code!~"5.."}[1d]))
        /
        sum(rate(http_request_duration_seconds_count{job="busi"}[1d]))
      )
    labels:
      job: busi
      latency: "0.1"
    record: latencytarget:http_request_duration_seconds:rate1d
  # 过去3d的
  - expr: |
      1 - (
        sum(rate(http_request_duration_seconds_bucket{job="busi",le="0.1",code!~"5.."}[3d]))
        /
        sum(rate(http_request_duration_seconds_count{job="busi"}[3d]))
      )
    labels:
      job: busi
      latency: "0.1"
    record: latencytarget:http_request_duration_seconds:rate3d  
  # 🐾HTTP 相应时间SLO短中期内快速燃尽
  # - 过去5m和过去1h燃尽率大于14.4
  # - 或: 过去30m和过去6h燃尽率大于7.2
  - alert: LatencyBudgetBurn
    annotations:
      message: 'High requests latency budget burn for job=busi,latency=0.1 (current value: {{ $value }})'
    expr: |
      (
        latencytarget:http_request_duration_seconds:rate1h{job="busi",latency="0.1"} > (14.4*(1-0.99))
        and
        latencytarget:http_request_duration_seconds:rate5m{job="busi",latency="0.1"} > (14.4*(1-0.99))
      )
      or
      (
        latencytarget:http_request_duration_seconds:rate6h{job="busi",latency="0.1"} > (7.2*(1-0.99))
        and
        latencytarget:http_request_duration_seconds:rate30m{job="busi",latency="0.1"} > (7.2*(1-0.99))
      )
    labels:
      job: busi
      latency: "0.1"
      severity: critical
  - alert: LatencyBudgetBurn
    annotations:
      message: 'High requests latency budget burn for job=busi,latency=0.1 (current value: {{ $value }})'
    expr: |
      (
        latencytarget:http_request_duration_seconds:rate1d{job="busi",latency="0.1"} > (3*(1-0.99))
        and
        latencytarget:http_request_duration_seconds:rate2h{job="busi",latency="0.1"} > (3*(1-0.99))
      )
      or
      (
        latencytarget:http_request_duration_seconds:rate3d{job="busi",latency="0.1"} > ((1-0.99))
        and
        latencytarget:http_request_duration_seconds:rate6h{job="busi",latency="0.1"} > ((1-0.99))
      )
    labels:
      job: busi
      latency: "0.1"
      severity: warning

🎉🎉🎉

总结

Prometheus 作为云原生和容器平台监控的事实标准，本期我们来看一下如何通过 Prometheus 配置 SLO 监控和告警.

我们例举了 2 个典型的 SLO - HTTP 响应时间和错误率. 错误率的非常好理解, 响应时间的有点绕, 需要大家慢慢消化下.

😼😼😼

📚️参考文档

本文由博客一文多发平台 OpenWrite 发布！

东风微鸣
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
第五章 报警 SLO
焦振清
12-10 1214
本章介绍如何在发生重要事件将SLO转换为可操作的报警。我们的第一本SRE和本书都讨论了实施SLO。我们相信，拥有很好的SLO可以衡量你的平台可靠性，正如你的客户所经历的那样，可以为on-call人员该如何迅速做出响应提供最准确的提示。在这里，我们提供了有关如何将这些SLO转换为报警规则的具体指导，以便你在消耗过多的错误预算之前响应问题。 我们的示例展示了一系列报警指标和逻辑的复杂实现；讨论他们的...
prometheus和loki的告警配置
08-05
Prometheus 和 Loki 的告警配置 Prometheus 和 Loki 是两个 популяр的监控和日志管理工具，经常被用于大规模分布式系统的监控和告警。在这篇文章中，我们将讨论如何配置 Prometheus 和 Loki 的告警系统，...
使用Prometheus和Grafana实现SLO
cpongo011702
06-09 348
在线服务的目标应该是提供与业务需求匹配的可用服务。此流程的关键部分应该涉及组织中的不同团队，例如，从业务开发团队到工程团队。要验证一个服务如何符合这些目标，可以用这些目标可衡量的“成就”来定义“阈值”，例如，“服务必须在99.9%的时间内可用”，这应该与用户的期望和业务连续性相匹配。SLA, SLO, SLI已经有很多关于这些话题的文章，如果你不熟悉这些术语，我强烈建议你先阅读谷歌关于SLO(服务...
prometheus告警配置
最新发布
nujnus9221的博客
05-19 330
在你的 Prometheus 配置中定义告警规则，这与设置 Alertmanager 发送通知的方式相同。你需要在 Prometheus 的配置文件（通常是。
Prometheus 监控告警配置
IoTHub - 物联网开源技术社区
03-14 1051
Prometheus 监控告警配置，邮件通知、钉钉通知、自定义模版，常用软件报警规则配置，包括：linux、docker、nginx、postgresql、mysql、rabbitmq 等。
大数据监控告警系统（Prometheus）视频教程
07-08
这是一套集成了Prometheus+Grafana+睿象云的监控告警系统，融合了当下热门的监控系统Prometheus，使用了便捷的数据可视化工具Grafana，睿象云智能告警平台可接入各类告警信息，提供了丰富的告警形式。本套教程细致...
prometheus监控mysql和报警规则详细资料—超详细，超全面(带文档和相关软件包)
06-04
除了数据库监控，Prometheus还能监控Linux系统的资源使用情况，例如CPU、内存、磁盘I/O和网络流量，结合MySQL监控，可全面评估整体系统健康状况。 通过上述步骤，你可以实现Prometheus对MySQL的深度监控，并设置...
基于kube-prometheus-stack部署监控K8S告警系统资源合集
11-08
5. 配置 ServiceMonitor：在 K8S 中定义 ServiceMonitor 资源，告诉 Prometheus 如何发现和监控目标服务。 6. 观察和优化：通过 Grafana 仪表板查看监控数据，根据实际情况调整监控规则和告警阈值。 这个资源合集...
prometheus监控redis和报警规则详细资料—超级详细(带文档和软件包)
06-04
本资料包提供了Prometheus监控Redis的详细教程，包括部署文档和相关软件包，旨在帮助用户理解如何设置和使用Prometheus来监控Redis，并配置报警规则以及时发现并处理问题。 首先，你需要了解如何安装Prometheus。...
sloth::sloth: 简单易用的 Prometheus SLO（服务级别目标）生成器
08-03
树懒 介绍 了解为 Prometheus 生成的最简单方法。 Sloth 为任何类型的服务生成易于理解、统一且可靠的 Prometheus SLO。 使用导致多个指标和警报的简单 SLO 规范。 目前 Sloth 专注于 Prometheus，但根据需求和复杂性，我们可能会支持其他后端。 特征 简单、可维护且易于理解的 SLO 规范。 可靠的 SLO 指标和警报。 基于实现和警报框架。 在不同的时间窗口自动生成 Prometheus SLI 记录规则。 自动生成 Prometheus SLO 元数据规则。 自动生成 Prometheus SLO 警报规则（页面和警告）。 SLO 规范验证（包括用于 Gitops 和 CI 的validate命令）。 自定义标签，禁用不同类型的警报... 跨所有不同服务和团队创建 SLO 的单一方式（统一）。 自动可查看您的所有 SLO
Prometheus配置AlertManager告警
博客
06-14 1000
expr: (node_memory_MemTotal_bytes - (node_memory_MemFree_bytes+node_memory_Buffers_bytes+node_memory_Cached_bytes )) / node_memory_MemTotal_bytes * 100 > 75 # 告警阈值为当内存使用率大于75%告警进入到根route后开始遍历子route节点，如果匹配到，则将告警发送到该子route定义的receiver中，然后就停止匹配了。
【Prometheus】prometheus告警配置
qq_41466440的博客
02-09 8759
【Prometheus】prometheus告警配置
10--部署Prometheus服务并实现服务监控及告警
Wsjm666的博客
02-23 1534
10--部署Prometheus服务并实现服务监控及告警
【监控】prometheus传统环境监控告警常用配置
weixin_45385457的博客
03-26 1219
在生产环境使用 prometheus 监控时，要充分利用标签的功能，对不同的环境不同作用的机器制定不同的告警规则，避免出现告警过多导致的漏处理。要严格把控安全问题，防止信息的泄露。
【Prometheus】Prometheus的监控告警
koeda1的博客
02-01 1230
关于Prometheus的监控告警
容器云平台监控告警体系—— Prometheus发送告警机制
2301_77342543的博客
08-15 1421
在Prometheus的架构中告警被划分为两个部分，在Prometheus Server中定义告警规则以及产生告警，Alertmanager组件则用于处理这些由Prometheus产生的告警。本文主要讲解Prometheus发送告警机制也就是在Prometheus Server中定义告警规则和产生告警部分，不过多介绍Alertmanager组件。告警名称：用户需要为告警规则命名，当然对于命名而言，需要能够直接表达出该告警的主要内容。
二、 Prometheus告警：特性、配置、绑定Alertmanager（1）
SteveRocket's-Blog
03-16 2292
告警能力在Prometheus的架构中被划分为两个部分，在Prometheus Server中定义告警规则以及产生告警，Alertmanager组件则用于处理这些由Prometheus产生的告警。Alertmanager即Prometheus体系中告警的统一处理中心。 在Prometheus中，还可以通过Group（告警组）对一组相关的告警进行统一定义，都是通过YAML文件来统一管理。
Pod使用率用prometheus怎么监控告警
05-12
可以使用 Prometheus 监控 Pod 使用率，并设置告警规则进行告警。以下是具体步骤： 1. 在 Kubernetes 集群中安装 Prometheus Operator。 2. 在 Prometheus Operator 中创建一个 ServiceMonitor，用于监控 Pod 使用率。 3. 在 Prometheus 中配置相应的指标收集规则，例如： ``` - job_name: 'kubernetes-pods' kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_container_name] action: keep regex: my-container - source_labels: [__meta_kubernetes_pod_name] action: replace target_label: pod_name metric_relabel_configs: - source_labels: [__name__] action: replace target_label: metric regex: container_memory_usage_bytes - source_labels: [pod_name] action: replace target_label: pod regex: (.+) - source_labels: [__meta_kubernetes_namespace] action: replace target_label: namespace ``` 其中，`__meta_kubernetes_pod_container_name`和`__meta_kubernetes_pod_name`是 Kubernetes 的标准标签，可以用来选择要监控的 Pod 和容器。`container_memory_usage_bytes`是用来收集 Pod 内存使用率的指标。 4. 设置告警规则，例如： ``` groups: - name: pod-alerts rules: - alert: PodMemoryUsageHigh expr: sum(container_memory_usage_bytes{namespace="my-namespace", pod=~"my-pod.*", container="my-container"}) / sum(container_spec_memory_limit_bytes{namespace="my-namespace", pod=~"my-pod.*", container="my-container"}) > 0.8 for: 1m labels: severity: warning annotations: summary: "Memory usage is high in Pod {{ $labels.pod }}" description: "Memory usage is high ({{ printf "%.2f" $value }}%) in container {{ $labels.container }}" ``` 这个告警规则用于监控 Pod 内存使用率，当内存使用率超过 80% 时，触发告警，并在告警信息中包含 Pod 和容器的名称。 5. 在 Prometheus Operator 中配置 Alertmanager，用于接收和处理告警信息。 通过以上步骤，就可以使用 Prometheus 监控 Pod 使用率，并设置告警规则进行告警。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值