七、alertmanager介绍及部署

目录

一、alertmanager

1、简述：

2、使用步骤：

3、工作机制

4、设置警报和通知的主要步骤是：

5、AlertManager的4个概念

（1）分组（Grouping）

（2）抑制（Inhibition）

（3）静默（Silences ）

（4）路由（route）

6、Alert 的三种状态：

7、prometheus触发一条告警的过程：

二、安装部署

三、集成邮件告警 配置文件详解

1、配置文件详解

2、创建邮件模板 

3、配置systemd服务

4、修改prometheus 配置，加入alertmanager 

5、重新加载配置

6、测试

---

一、alertmanager

1、简述：

        Alertmanager是一个独立的告警模块，接收Prometheus等客户端发来的警报，之后通过分组、删除重复等处理，并将它们通过路由发送给正确的接收器。Prometheus的警报分为两个部分。Prometheus服务器中的警报规则将警报发送到Alertmanager。该Alertmanager 然后管理这些警报，包括沉默，抑制，聚集和通过的方法，如电子邮件发出通知，对呼叫通知系统，以及即时通讯平台。

2、使用步骤：

        1. 部署Alertmanager

        2. 配置告警接收人

        3. 配置Prometheus与Alertmanager通信

        4. 在Prometheus中创建告警规则

3、工作机制

        Prometheus发出告警时分为两个部分。Prometheus服务器按告警规则（rule_files配置块）将警报发送到Alertmanager（即告警规则是在Prometheus上定义的）。然后，由Alertmanager 来管理这些警报，包括去重（Deduplicating）、分组（Grouping）、沉默（silencing），抑制（inhibition），聚合（aggregation），最终通过电子邮件发出通知，对呼叫通知系统，以及即时通讯平台，将告警通知路由（route）给对应的联系人。

4、设置警报和通知的主要步骤是：

• 设置和配置 Alertmanager
• 配置Prometheus与Alertmanager对话
• 在Prometheus中创建警报规则

5、AlertManager的4个概念

（1）分组（Grouping）

        Grouping 是 Alertmanager 把同类型的警报进行分组，合并多条警报到一个通知中。在生产环境中，特别是云环境下的业务之间密集耦合时，若出现多台 Instance 故障，可能会导致成千上百条警报触发。在这种情况下使用分组机制，可以把这些被触发的警报合并为一个警报进行通知，从而避免瞬间突发性的接受大量警报通知，使得管理员无法对问题进行快速定位。

（2）抑制（Inhibition）

        Inhibition 是 当某条警报已经发送，停止重复发送由此警报引发的其他异常或故障的警报机制。

　　在生产环境中，IDC托管机柜中，若每一个机柜接入层仅仅是单台交换机，那么该机柜接入交换机故障会造成机柜中服务器非 up 状态警报。再有服务器上部署的应用服务不可访问也会触发警报。

　　这时候，可以通过在 Alertmanager 配置忽略由于交换机故障而造成的此机柜中的所有服务器及其应用不可达而产生的警报。

在我们的灾备体系中，当原有集群故障宕机业务彻底无法访问的时候，会把用户流量切换到备份集群中，这样为故障集群及其提供的各个微服务状态发送警报机会失去了意义，此时， Alertmanager 的抑制特性就可以在一定程度上避免管理员收到过多无用的警报通知。

（3）静默（Silences ）

        Silences 提供了一个简单的机制，根据标签快速对警报进行静默处理；对传进来的警报进行匹配检查，如果接受到警报符合静默的配置，Alertmanager 则不会发送警报通知。

        以上除了分组、抑制是在 Alertmanager 配置文件中配置，静默是需要在 WEB UI 界面中设置临时屏蔽指定的警报通知。

（4）路由（route）

        用于配置 Alertmanager 如何处理传入的特定类型的告警通知，其基本逻辑是根据路由匹配规则的匹配结果来确定处理当前报警通知的路径和行为

        以上的概念需要好好理解，这样才可以轻松的在监控系统设计的时候针对警报设计的一些场景自行调整。

6、Alert 的三种状态：

pending：警报被激活，但是低于配置的持续时间。这里的持续时间即rule里的FOR字段设置的时间。改状态下不发送报警。

firing：警报已被激活，而且超出设置的持续时间。该状态下发送报警。

inactive：既不是pending也不是firing的时候状态变为inactive

7、prometheus触发一条告警的过程：

prometheus—>触发阈值—>超出持续时间—>alertmanager—>分组|抑制|静默—>媒体类型—>邮件|钉钉|微信等。

二、安装部署

下载地址： Download | Prometheus

[root@rabbitmq_2 system]# wget https://github.com/prometheus/alertmanager/releases/download/v0.26.0/alertmanager-0.26.0.linux-amd64.tar.gz
[root@rabbitmq_2 prometheus]# tar -xvf alertmanager-0.26.0.linux-amd64.tar.gz 
[root@rabbitmq_2 prometheus]# mv alertmanager-0.26.0.linux-amd64 /opt/prometheus/alertmanager
[root@rabbitmq_2 prometheus]# chown -R prometheus:prometheus /opt/prometheus
[root@localhost prometheus]# mkdir -p ./alertmanager/{bin,conf,logs,data,templates}

三、集成邮件告警 配置文件详解

1、配置文件详解

# global：全局配置，主要配置告警方式，如邮件、webhook等。
global:

  resolve_timeout: 5m  # resolve_timeout：解析超时时间

  smtp_smarthost: 'smtp.139.com:25' # 这里为 139 邮箱 SMTP 服务地址,同时要设置开启 POP3/SMTP 服务。

  smtp_from: '*****@139.com'   # smtp_from：邮件发送者的邮箱地址

  smtp_auth_username: '*****@139.com'（发邮箱）   # 发邮件的邮箱用户名

  smtp_auth_password: '*****'（IMAP的授权码）  # smtp_auth_password：SMTP服务的密码 为授权码。非邮箱密码

  smtp_require_tls: false   # smtp_require_tls：是否启用tls

# 模板 (非必须，默认即可)
templates:
- '/opt/prometheus/alertmanager/templates/email.tmpl'

# route：用来设置报警的分发策略。Prometheus的告警先是到达alertmanager的根路由(route)，alertmanager的根路由不能包含任何匹配项，因为根路由是所有告警的入口点。
# 另外，根路由需要配置一个接收器(receiver)，用来处理那些没有匹配到任何子路由的告警（如果没有配置子路由，则全部由根路由发送告警）
# 接收器。告警进入到根route后开始遍历子route节点，如果匹配到，则将告警发送到该子route定义的receiver中，然后就停止匹配了。因为在route中 continue默认为false，如果continue为true，则告警会继续进行后续子route匹配。如果当前告警仍匹配不到任何的子route，则该告警将从其上一级(匹配)route或者根route发出（按最后匹配到的规则发出邮件）

route:  
  group_by: ['alertname']  # group_by：采用哪个标签作为分组的依据
  group_wait: 30s          # group_wait：分组等待的时间
  group_interval: 5m       # group_interval：上下两组发送告警的间隔时间
  repeat_interval: 1h      # repeat_interval：# 告警通知成功发送后，若问题一直未恢复，需再次重复发送的间隔。默认1h
  receiver: 'email'     #  配置告警消息接收者，与下面配置的对应。例如常用的 email、wechat
  
-------
  routes:    # 子路由
  - receiver: 'wechat'
    match:    # 通过标签去匹配这次告警是否符合这个路由节点；也可以使用  match_re 进行正则匹配
      severity: Disaster    # 标签severity为Disaster时满足条件，使用wechat警报
----------

receivers:  # 配置报警信息接收者信息。
- name: 'email'  # 警报接收者名称
  email_configs:
  - to: '*****@139.com'（收邮箱）# 接收警报的email
    html: '{{ template "email.html" .}}' # 发送邮件的内容（调用模板文件中的）
    headers:  # 邮件标题，不设定使用默认的即可
      Subject: '告警信息'
    send_resolved: true        # 故障恢复后通知
    
- name: 'wechat'
  wechat_configs:
  - corp_id: xxxxx        # 企业信息("我的企业"--->"CorpID"[在底部])
    to_user: '@all'        # 发送给企业微信用户的ID，这里是所有人
    agent_id: xxxxx    # 企业微信("企业应用"-->"自定应用"[Prometheus]--> "AgentId") 
    api_secret: DY9IlG0Bdwawb_ku0NblxKFrrmMwbLIZ7YxMa5rCg8g        # 企业微信("企业应用"-->"自定应用"[Prometheus]--> "Secret") 
    send_resolved: true         # 故障恢复后通知

 
# 抑制规则，用于定义哪些告警在触发时不应再触发其他告警。   
inhibit_rules: 
  - source_match:   # 定义了触发抑制规则的源告警的条件。只有当源告警满足这些条件时，抑制规则才会被触发。
      # 这里定义了源告警的severity 标签值必须为'critical'。换句话说，只有当告警的严重程度为 "critical" 时，才考虑应用抑制规则。
      severity: 'critical'
    # target_match 定义了被抑制的目标告警的条件。当源告警触发时，任何满足这些条件的目标告警都将被抑制，即不会被发送。        
    target_match:
      # 这里定义了目标告警的severity 标签值必须为 'warning'。因此，当有一个 "critical" 告警触发时，所有同时触发的 "warning" 告警将被抑制。
      severity: 'warning'
    # 字段定义了一组标签，源告警和目标告警在这些标签上的值必须相同，抑制规则才会被应用。        
    equal: ['alertname', 'dev', 'instance']


----------
举个例子，假设有以下两个告警：
一个 "critical" 级别的告警，标签为 alertname: server-down, dev: server1, instance: ip-192.168.1.1。
一个 "warning" 级别的告警，标签也为 alertname: server-down, dev: server1, instance: ip-192.168.1.1。
由于这两个告警在 alertname、dev 和 instance 标签上的值相同，并且源告警的 severity 是 "critical"，目标告警的 severity 是 "warning"，因此 "warning" 级别的告警将被抑制，不会被发送。


-----------
# 修改好配置文件后，可以使用amtool工具检查配置
[root@localhost conf]# ../bin/amtool check-config alertmanager.yml
Checking 'alertmanager.yml'  SUCCESS
Found:
 - global config
 - route
 - 1 inhibit rules
 - 1 receivers
 - 0 templates

#重载下alert manager配置
[root@rabbitmq_2 prometheus]# curl -X POST http://localhost:9093/-/reload

这里都能看到配置信息

 

2、创建邮件模板 

[root@rabbitmq_2 prometheus]# cd /opt/prometheus/alertmanager
[root@rabbitmq_2 prometheus]# vim alert.tmp

{{ define "email.html" }}
{{- if gt (len .Alerts.Firing) 0 -}}{{ range .Alerts }}
<h2>@告警通知</h2>
告警程序: prometheus_alert <br>
告警级别: {{ .Labels.severity }} 级 <br>
告警类型: {{ .Labels.alertname }} <br>
故障主机: {{ .Labels.instance }} <br>
告警主题: {{ .Annotations.summary }} <br>
告警详情: {{ .Annotations.description }} <br>
触发时间: {{ .StartsAt.Local.Format "2006-01-02 15:04:05" }} <br>
{{ end }}{{ end -}}

{{- if gt (len .Alerts.Resolved) 0 -}}{{ range .Alerts }}
<h2>@告警恢复</h2>
告警程序: prometheus_alert <br>
故障主机: {{ .Labels.instance }}<br>
故障主题: {{ .Annotations.summary }}<br>
告警详情: {{ .Annotations.description }}<br>
告警时间: {{ .StartsAt.Local.Format "2006-01-02 15:04:05" }}<br>
恢复时间: {{ .EndsAt.Local.Format "2006-01-02 15:04:05" }}<br>
{{ end }}{{ end -}}
{{- end }}

3、配置systemd服务

用systemctl来管理alertmanager

vim  /usr/lib/systemd/system/alertmanager.service
[Unit]
Description=Alert Manager
wants=network-online.target
After=network-online.target
 
[Service]
Type=simple
User=prometheus
Group=prometheus
Restart=always
ExecStart=/opt/prometheus/alertmanager/alertmanager \
--config.file=/opt/prometheus/alertmanager/alertmanager.yml \
--storage.path=/opt/prometheus/alertmanager/data/ 

[Install]
WantedBy=multi-user.target


启动
[root@rabbitmq_2 system]# systemctl start alertmanager.service 
[root@rabbitmq_2 system]# 
[root@rabbitmq_2 system]# systemctl status alertmanager.service 
● alertmanager.service - Alert Manager
   Loaded: loaded (/usr/lib/systemd/system/alertmanager.service; disabled; vendor preset: disabled)
   Active: active (running) since 三 2023-11-22 16:58:09 CST; 6s ago


web 界面 端口是9093
http://192.168.134.133:9093

因为安装了alertmanager 需要把它添加到prometheus里边

4、修改prometheus 配置，加入alertmanager 

[root@rabbitmq_2 prometheus]# vim prometheus.yml
alerting:
  alertmanagers:
    - static_configs:
        - targets:
          - localhost:9093
#告警规则配置文件位置：
rule_files:
  - "alert.yml"
  
# 抓取配置列表
scrape_configs:
  - job_name: 'alertmanager'
    static_configs:
      - targets: ['192.168.153.128:9093']

#创建告警规则的文件
[root@rabbitmq_2 prometheus]# vim alert.yml
# groups：组告警
groups:
# name：组名。报警规则组名称
- name: Prometheus alert
  # rules：定义角色
  rules:
  # 对任何实例超过30s无法联系的情况就发出警报
  - alert: 服务告警
    expr: up == 0
    for: 30s #评估等待时间
    labels: #自定义标签
      severity: critical
      opsalertname: 服务器宕机告警
    annotations:
      instance: "{{ $labels.instance }}"
      description: "{{ $labels.job }} 服务已关闭"
      
  - alert: 磁盘空间使用率告警
    expr: 100
      - (node_filesystem_avail_bytes{fstype=~"xfs|ext4",job="node_exporter"}
      / node_filesystem_size_bytes{fstype=~"xfs|ext4",job="node_exporter"}) * 100
      > 80
    for: 10m
    labels:
      severity: critical
      opsalertname: 磁盘空间使用率告警
    annotations:
      summary: '磁盘使用率告警'
      description: |
        磁盘使用: {{ $labels.mountpoint }}分区磁盘使用率{{ $value | humanize }} %, 大于告警阈值90%
  - alert: 磁盘inode使用率告警
    expr: 100 - (node_filesystem_files_free{job="node_exporter",fstype=~"ext4|xfs"} / node_filesystem_files{job="node_exporter",fstype=~"ext4|xfs"}) * 100  > 80
    for: 15m
    labels:
      severity: critical
      opsalertname: 磁盘inode使用率告警
    annotations:
      summary: "磁盘Inode告警"
      description: |
        Inode使用: {{ $value | humanize }} %, 大于告警阈值80%
                                         
  - alert: 内存使用率告警
    expr: 100 - ( node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes ) * 100 > 10 # 正常值为90，为了测试告警信息
    for: 10s #正常值为5m
    labels:
      severity: critical
      opsalertname: 内存使用率告警
    annotations:
      summary: '内存使用率告警'
      description: |
        内存使用率告警 {{ $value | humanize }} %, 大于告警阈值90%

检查配置文件

[root@rabbitmq_2 prometheus]# ./promtool check config prometheus.yml 
Checking prometheus.yml
  SUCCESS: 1 rule files found
 SUCCESS: prometheus.yml is valid prometheus config file syntax

Checking alert.yml
  SUCCESS: 1 rules found

5、重新加载配置

#重启
[root@rabbitmq_2 prometheus]# systemctl restart prometheus.service
或者重载
curl -X POST http://192.168.134.133:9090/-/reload

6、测试

1、检查Prometheus控制台，应用全部正常

 

2、停止node_exporter，当停止之后，根据规则配置，告警会触发 == 0 ，出发之后会发送告警信息给alertmanager，alert manager收到告警信息之后，会检查配置，然后发送邮件给相应负责人。

[root@localhost prometheus]# systemctl stop node_exporter.service

 当停止之后，有三种状态 ，详见第6步。因为for 设置的是30秒，所以30秒之后，服务状态变为Firing

 

 

当服务状态变为Firing，alert manager也会收到相应的告警，并发送邮件

 

 

当服务恢复之后，也会收到相应的故障恢复邮件。