【监控】Prometheus中的告警机制介绍

prometheus实战之三：告警规则_验证prometheus告警规则-CSDN博客

Prometheus是一款开源的系统监控和告警工具，其告警功能是保障系统稳定运行的重要部分。以下将从告警的整体架构、核心概念、规则配置以及具体的通知流程等方面对Prometheus中的告警进行介绍。

告警架构

Prometheus的告警管理分为两部分。首先，在Prometheus服务端设置告警规则，Prometheus服务器端会基于这些规则对采集到的监控数据进行评估，当满足告警条件时，就会向Alertmanager发送告警。然后，由Alertmanager负责管理这些告警，包括静默、抑制、聚合以及通过电子邮件、PagerDuty和HipChat等方法发送通知。

核心概念

• 分组（Grouping）：分组是将类似性质的告警分类为单个通知的机制。在大型中断期间，例如网络分区导致许多服务实例无法访问数据库，Prometheus中针对每个服务实例的告警规则会被触发，数百个告警发送到Alertmanager。此时，可将Alertmanager配置为按群集和alertname对警报进行分组，这样用户就能收到单个紧凑通知，同时确切了解哪些服务实例受到影响。通知的接收器通过配置文件中的路由树来配置告警分组，并定时进行分组通知。
• 抑制（Inhibition）：如果某些特定的告警已经触发，那么可以配置Alertmanager抑制其他相关告警。例如，当某个告警触发表示无法访问整个集群时，可让Alertmanager在该特定告警触发时，将与该集群有关的所有其他告警静音，防止收到数百或数千个与实际问题无关的告警通知。
• 静默（Silences）：静默是在给定时间内简单地静音告警的方法。基于匹配器配置静默，就像路由树一样。检查告警是否匹配或者正则表达式匹配静默，如果匹配，则不会发送该告警的通知。可以在Alertmanager的Web界面中配置静默。

global:resolve_timeout: 5m  # 告警解决后等待5分钟标记为已解决route:receiver: 'default-receiver'group_by: ['alertname']group_wait: 30sgroup_interval: 5mrepeat_interval: 12hreceivers:
- name: 'default-receiver'email_configs:- to: '[e-mail]'inhibit_rules:
- source_match:alertname: 'ClusterCritical'target_match:cluster: '{{ .labels.cluster }}'equal: ['cluster']# 预定义静默（可选，通常通过Web界面动态管理）
silences:
- matchers:- name: 'env'value: 'staging'startsAt: '2023-10-05T09:00:00Z'endsAt: '2023-10-05T18:00:00Z'comment: 'Staging environment maintenance'

关键说明

1. 分组（Grouping）：通过 group_by 标签组合告警，减少通知数量；group_wait 和 group_interval 控制合并策略。
2. 抑制（Inhibition）：通过父子告警关系屏蔽次要信息，需确保 source_match 和 target_match 的标签关联。
3. 静默（Silences）：临时屏蔽告警，支持动态配置（Web 界面）和静态配置（文件），适合计划内维护或临时故障屏蔽。

告警规则配置

一条告警规则主要由以下几部分组成：

• alert：告警规则的名称，用于唯一标识该告警规则。
• expr：用于进行报警规则的PromQL查询语句，通过该语句定义告警触发的条件。例如，设定CPU利用率、内存使用量等性能指标的阈值，当指标在某个时间段内多次触发该阈值时，视为满足告警条件。
• for：评估等待时间（Pending Duration），表示只有当触发条件持续一段时间后才发送告警，在等待期间新产生的告警状态为pending。
• labels：自定义标签，允许用户指定额外的标签列表，把它们附加在告警上，用于对告警进行分类和标识。
• annotations：指定了另一组标签，它们不被当做告警实例的身份标识，通常用于存储一些额外的信息，如告警的描述、解决方法等，用于报警信息的展示。

告警通知流程

Prometheus以scrape_interval（默认为1m）的规则周期从监控目标上收集信息，并将监控信息持久存储在其本地存储上。然后以evaluation_interval（默认为1m）的规则周期对告警规则做定期计算。当表达式为真时，告警状态切换到pending，若在下个计算周期表达式仍为真，且符合for持续时间，告警状态变更为active，并将告警从Prometheus发送给Alertmanager。Alertmanager接收告警后，根据配置的路由规则、抑制规则和静默规则等对告警进行处理，最终将告警通过配置好的通知方式发送给相关人员。

例子

以下是一些Prometheus告警规则的例子：

• 实例宕机告警

- alert: InstanceDownexpr: up == 0for: 1mlabels:serverity: pageannotations:summary: "Instance {{ $labels.instance }} down"description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minute."

- **规则内容**：
- **解释**：用于检测job的状态，当持续1分钟获取不到指标数据（即 `up == 0`）时，触发告警，将告警发送给Alertmanager。

• CPU使用率过高告警

- name: docker_alertsrules:- alert: HighCPUUsageexpr: sum(rate(container_cpu_usage_seconds_total{image!=""}[1m])) / sum(machine_cpu_cores) > 0.9labels:severity: criticalannotations:description: "The container {{ $labels.container_name }} is using more than 90% of CPU for over 1 minute."

- **规则内容**：
- **解释**：通过计算容器的CPU使用率，当容器的CPU使用率超过90%并持续1分钟时，触发 `HighCPUUsage` 告警。

• 内存使用率过高告警

- alert: MemoryUsageHighexpr: ((node_memory_MemTotal_bytes - (node_memory_MemFree_bytes + node_memory_Buffers_bytes + node_memory_Cached_bytes)) / node_memory_MemTotal_bytes) * 100 > 80labels:severity: warningannotations:summary: "Memory usage is high"description: "Memory usage on {{ $labels.instance }} is above 80%."

- **规则内容**：
- **解释**：计算主机的内存使用率，当内存使用率超过80%时触发告警。

• 接口请求异常告警

- alert: InterfaceRequestExceptionexpr: http_server_requests_seconds_count{exception!="", job="<app_name>", method="<method>", uri="<uri>"} > 0for: 5mlabels:severity: errorannotations:summary: "Interface request exception"description: "There is an exception in the interface request of job {{ $labels.job }}, method {{ $labels.method }}, uri {{ $labels.uri }}."

- **规则内容**：
- **解释**：当指定应用（`<app_name>`）、指定方法（`<method>`）和指定接口地址（`<uri>`）的请求出现异常，且异常持续5分钟时触发告警。

总结

Prometheus中的告警机制通过灵活的规则配置和强大的Alertmanager组件，能够帮助用户及时发现系统中的问题，并有效地管理和处理告警信息，从而保障系统的稳定运行。