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: 30s
group_interval: 5m
repeat_interval: 12h
receivers:
- name: 'default-receiver'
email_configs:
- to: 'ops@example.com'
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'
关键说明
- 分组（Grouping）：通过
group_by标签组合告警，减少通知数量；group_wait和group_interval控制合并策略。 - 抑制（Inhibition）：通过父子告警关系屏蔽次要信息，需确保
source_match和target_match的标签关联。 - 静默（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: InstanceDown
expr: up == 0
for: 1m
labels:
serverity: page
annotations:
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_alerts
rules:
- alert: HighCPUUsage
expr: sum(rate(container_cpu_usage_seconds_total{image!=""}[1m])) / sum(machine_cpu_cores) > 0.9
labels:
severity: critical
annotations:
description: "The container {{ $labels.container_name }} is using more than 90% of CPU for over 1 minute."
- **规则内容**：
- **解释**：通过计算容器的CPU使用率，当容器的CPU使用率超过90%并持续1分钟时，触发 `HighCPUUsage` 告警。
- 内存使用率过高告警
- alert: MemoryUsageHigh
expr: ((node_memory_MemTotal_bytes - (node_memory_MemFree_bytes + node_memory_Buffers_bytes + node_memory_Cached_bytes)) / node_memory_MemTotal_bytes) * 100 > 80
labels:
severity: warning
annotations:
summary: "Memory usage is high"
description: "Memory usage on {{ $labels.instance }} is above 80%."
- **规则内容**：
- **解释**：计算主机的内存使用率，当内存使用率超过80%时触发告警。
- 接口请求异常告警
- alert: InterfaceRequestException
expr: http_server_requests_seconds_count{exception!="", job="<app_name>", method="<method>", uri="<uri>"} > 0
for: 5m
labels:
severity: error
annotations:
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组件，能够帮助用户及时发现系统中的问题，并有效地管理和处理告警信息，从而保障系统的稳定运行。