Prometheus监控告警处理

告警能力在Prometheus的架构中被划分成两个独立的部分。如下所示，通过在Prometheus中定义AlertRule(告警规则)，Prometheus会周期性的对告警规则进行计算，如果满足告警触发条件就会向Alertmanager发送告警信息。

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

• 告警名称：用户需要为告警规则命名，当然对于命名而言，需要能够直接表达出该告警的主要内容;

• 告警规则：告警规则实际上主要由PromQL进行定义，其实际意义是当表达式(PromQL)查询结果持续多长时间(During)后出发告警;

在Prometheus中，还可以通过Group(告警组)对一组相关的告警进行统一定义。当然这些定义都是通过YAML文件来统一管理的。

Alertmanager作为一个独立的组件，负责接收并处理来自Prometheus Server(也可以是其它的客户端程序)的告警信息。Alertmanager可以对这些告警信息进行进一步的处理，比如当接收到大量重复告警时能够消除重复的告警信息，同时对告警信息进行分组并且路由到正确的通知方，Prometheus内置了对邮件，Slack等多种通知方式的支持，同时还支持与Webhook的集成，以支持更多定制化的场景。

例如，目前Alertmanager还不支持钉钉，那用户完全可以通过Webhook与钉钉机器人进行集成，从而通过钉钉接收告警信息。同时AlertManager还提供了静默和告警抑制机制来对告警通知行为进行优化。

告警处理核心流程

1)告警规则配置

在Prometheus配置文件中定义告警规则(alerting_rules.yml)

示例规则：

groups:
- name: example
  rules:
  - alert: HighCPUUsage
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "CPU usage above 80% for 2 minutes"

2)告警触发与发送

• Prometheus周期性评估告警规则，当表达式持续为真(超过for时间)时触发告警。

• 告警通过HTTP POST请求发送至Alertmanager的API端点。

3)Alertmanager处理

• 去重：基于告警标签(如alertname、instance)合并重复告警。

• 分组：将相似告警分组(如按severity或job)。

• 路由：根据路由规则将告警发送至指定接收器(如邮件、Slack、Webhook)。

4)告警通知

• 支持多种通知方式，如邮件、短信、钉钉、企业微信等。

• 示例Alertmanager配置

route:
  receiver: 'email-alert'
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
receivers:
- name: 'email-alert'
  email_configs:
  - to: 'admin@example.com'
    send_resolved: true

Alertmanager特性

分组

分组机制可以将详细的告警信息合并成一个通知。在某些情况下，比如由于系统宕机导致大量的告警被同时触发，在这种情况下分组机制可以将这些被触发的告警合并为一个告警通知，避免一次性接受大量的告警通知，而无法对问题进行快速定位。

抑制

抑制是指当某一告警发出后，可以停止重复发送由此告警引发的其它告警的机制。

静默

静默提供了一个简单的机制可以快速根据标签对告警进行静默处理。如果接收到的告警符合静默的配置，Alertmanager则不会发送告警通知。

问题与解决方案

1)告警延迟

原因：Prometheus评估间隔过长或Alertmanager队列堵塞。

解决：缩短Prometheus评估间隔(evaluation_interval)，优化Alertmanager性能。

2)告警丢失

原因：网络中断或Alertmanager配置错误。

解决：检查Prometheus与Alertmanager的连通性，验证接收器配置。

3)告警风暴

原因：大量相似告警同时触发。

解决：优化分组策略，增加去重规则，调整告警表达式。