二、 Prometheus告警：特性、配置、绑定Alertmanager（1）

告警能力在Prometheus的架构中被划分为两个部分，在Prometheus Server中定义告警规则以及产生告警，Alertmanager组件则用于处理这些由Prometheus产生的告警。Alertmanager即Prometheus体系中告警的统一处理中心。

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

Alertmanager作为一个独立的组件，负责接收并处理来自Prometheus Server(也可以是其它的客户端程序)的告警信息。Alertmanager可以对这些告警信息进行进一步的处理，比如当接收到大量重复告警时能够消除重复的告警信息，同时对告警信息进行分组并且路由到正确的通知方，Prometheus内置了对邮件，Slack等多种通知方式的支持，同时还支持与Webhook的集成，以支持更多定制化的场景。例如，目前Alertmanager还不支持钉钉，那用户完全可以通过Webhook与钉钉机器人进行集成，从而通过钉钉接收告警信息。同时AlertManager还提供了静默和告警抑制机制来对告警通知行为进行优化。

Prometheus告警简介

警报一直是整个监控系统中的重要组成部分，Prometheus监控系统中，采集与警报是分离的。警报规则在 Prometheus 定义，警报规则触发以后，才会将信息转发到给独立的组件 Alertmanager ，经过 Alertmanager r对警报的信息处理后，最终通过接收器发送给指定用户，另外在 Alertmanager 中没有通知组的概念，只能自己对软件重新Coding，或者使用第三方插件来实现。注意，这个通知组不是Alertmanager中的group概念。

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

Prometheus告警处理

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

告警名称：为告警规则命名。
告警规则：告警规则实际上主要由PromQL进行定义，其实际意义是当表达式（PromQL）查询结果持续多长时间（During）后出发告警

Alertmanager特性

Alertmanager除了提供基本的告警通知能力以外，还主要提供了如：分组、抑制以及静默等告警特性：

Alertmanager特性

分组

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

例如，当集群中有数百个正在运行的服务实例，并且为每一个实例设置了告警规则。假如此时发生了网络故障，可能导致大量的服务实例无法连接到数据库，结果就会有数百个告警被发送到Alertmanager。

而作为用户，可能只希望能够在一个通知中中就能查看哪些服务实例收到影响。这时可以按照服务所在集群或者告警名称对告警进行分组，而将这些告警内聚在一起成为一个通知。

告警分组，告警时间，以及告警的接受方式可以通过Alertmanager的配置文件进行配置。

在分配报警通知之前，alertmanager是最后一个环节，当切换到firing或者是inactive的时候，alertmanager会发送告警通知（pending状态不会通知alertmanager）

抑制

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

例如，当集群不可访问时触发了一次告警，通过配置Alertmanager可以忽略与该集群有关的其它所有告警。这样可以避免接收到大量与实际问题无关的告警通知。

抑制机制同样通过Alertmanager的配置文件进行设置。

静默

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

静默设置需要在Alertmanager的Werb页面上进行设置。

部署Alertmanager

通过alertmanager实现告警通知。

alertmanager和Prometheus Server一样均采用Golang实现，并且没有第三方依赖。一般来说可以通过以下几种方式来部署Alertmanager：二进制包、容器以及源码方式安装。

Alertmanager最新版本的下载地址可以从Prometheus官方网站Download | Prometheus获取

或

https://download.csdn.net/download/zhouruifu2015/87579035

创建Alertmanager配置文件

Alertmanager解压后会包含一个默认的alertmanager.yml配置文件，内容如下所示：

global:
  # resolve_timeout：解析超时时间
  resolve_timeout: 5m
  # smtp_smarthost: 使用email打开服务配置
  smtp_smarthost: smtp.126.com:25
  # smtp_from：指定通知报警的邮箱
  smtp_from: rocket_2014@126.com
  # smtp_auth_username：邮箱用户名
  smtp_auth_username: rocket_2014@126.com
 
  smtp_auth_identity: rocket_2014@126.com
  # smtp_auth_password：授权密码
  smtp_auth_password: ****************


# route标记：告警如何发送分配
route:
  # group_by：采用哪个标签作为分组的依据
  group_by: ['alertname']
  # group_wait：分组等待的时间
  group_wait: 30s
  # group_interval：上下两组发送告警的间隔时间
  group_interval: 5m
  # repeat_interval：重复发送告警时间。默认1h
  repeat_interval: 1h
  # receiver 定义谁来通知报警
  # receiver: 'web.hook'
  receiver: 'default-receiver'
  # error use 
  # receiver: ['web.hook','default-receiver']


# receiver标记：告警接受者
receivers:
  # - name: 'web.hook'
  #   webhook_configs:
  #     - url: 'http://127.0.0.1:5001/web_hook'  # python webhook server
  
  # name：报警来源自定义名称
  - name: 'default-receiver'
    # email_configs：通过邮箱发送报警
    email_configs: # error use ['rocket_2014@126.com', 'gc_zhouruifu@ieggtc.com']
      # to：指定接收端email
      - to: 'rocket_2014@126.com' # error use ['rocket_2014@126.com', 'gc_zhouruifu@ieggtc.com']
        send_resolved: true
    webhook_configs:
      #- url: 'http://127.0.0.1:5001/'
      - url: 'http://127.0.0.1:5001/web_hook'  # python webhook server
        #send_resolved: true

# inhibit_rules标记：降低告警收敛，减少报警，发送关键报警
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
equal: ['alertname', 'dev', 'instance']

Alertmanager的配置主要包含两个部分：路由(route)以及接收器(receivers)。所有的告警信息都会从配置中的顶级路由(route)进入路由树，根据路由规则将告警信息发送给相应的接收器。

在Alertmanager中可以定义一组接收器，比如可以按照角色(比如系统运维，数据库管理员)来划分多个接收器。接收器可以关联邮件，Slack以及其它方式接收告警信息。

当前配置文件中定义了一个默认的接收者default-receiver由于这里没有设置接收方式，目前只相当于一个占位符。关于接收器的详细介绍会在后续章节介绍。

在配置文件中使用route定义了顶级的路由，路由是一个基于标签匹配规则的树状结构。所有的告警信息从顶级路由开始，根据标签匹配规则进入到不同的子路由，并且根据子路由设置的接收器发送告警。目前配置文件中只设置了一个顶级路由route并且定义的接收器为default-receiver。因此，所有的告警都会发送给default-receiver。关于路由的详细内容会在后续进行详细介绍。

检查alertmanager配置文件

./amtool.exe check-config alertmanager.yml

配置alertmanager

webhook_config配置插件对应的URL

route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
  receiver: 'web.hook'
receivers:
  - name: 'web.hook'
    webhook_configs:
      - url: 'http://10.0.1.59:10220/event/prometheus_alert_event/'
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

绑定Prometheus与Alertmanager

在Prometheus的架构中被划分成两个独立的部分。Prometheus负责产生告警，而Alertmanager负责告警产生后的后续处理。因此Alertmanager部署完成后，需要在Prometheus中设置Alertmanager相关的信息。

编辑Prometheus配置文件prometheus.yml,并添加以下内容

重启Prometheus服务，成功后，可以从http://192.168.33.10:9090/config查看alerting配置是否生效。

等待Prometheus触发告警，并在Prometheus界面看到已成功触发告警规则

查看Alertmanager UI此时可以看到Alertmanager接收到的告警信息。

启动Alertmanager

Alermanager会将数据保存到本地中，默认的存储路径为data/。因此，在启动Alertmanager之前需要创建相应的目录，windows会自动在当前目录下创建data目录

--config.file用于指定alertmanager配置文件路径，--storage.path用于指定数据存储路径。

Linux启动Alertmanager

后台启动

nohup ./alertmanager --config.file=alertmanager.yml &

加入开机启动

cat > /etc/systemd/system/alertmanager.service << "EOF"

[Unit]

Description=alertmanager

After=local-fs.target network-online.target network.target

Wants=local-fs.target network-online.target network.target



[Service]

ExecStart=/usr/local/alertmanager/alertmanager --config.file=/usr/local/alertmanager/alertmanager.yml

Restart=on-failure

[Install]

WantedBy=multi-user.target

EOF

服务管理命令：

systemctl daemon-reload

systemctl enable alertmanager

systemctl start alertmanager

systemctl status alertmanager

查看运行状态

Alertmanager启动后可以通过9093端口访问，http://127.0.0.1:9093

Alert菜单下可以查看Alertmanager接收到的告警内容。Silences菜单下则可以通过UI创建静默规则，进入Status菜单，可以看到当前系统的运行状态以及配置信息。

查看告警状态

用户可以通过Prometheus WEB界面中的Alerts菜单查看当前Prometheus下的所有告警规则，以及其当前所处的活动状态。

配置告警规则文件后的状态

告警活动状态

同时对于已经pending或者firing的告警，Prometheus也会将它们存储到时间序列ALERTS{}中。

可以通过表达式，查询告警实例：

ALERTS{alertname="<alert name>", alertstate="pending|firing", <additional alert labels>}

样本值为1表示当前告警处于活动状态（pending或者firing），当告警从活动状态转换为非活动状态时，样本值则为0。

Alert的三种状态（active为多有告警）：

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

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

3) inactive：既不是pending也不是firing的时候状态变为inactive，警报未激活；

注意：

Prometheus告警不存在默认的告警名称。
推送的日志也没有唯一标识。
可以通过http://localhost:9093/api/v2/alerts获取告警日志
1. 此接口没分页参数。
2. 如果有上万条告警日志，通过此接口则会全部响应。

Alertmanager配置概述

在Alertmanager中通过路由(Route)来定义告警的处理方式。路由是一个基于标签匹配的树状匹配结构。根据接收到告警的标签匹配相应的处理方式。

Alertmanager配置中一般会包含以下几个主要部分：

全局配置（global）：用于定义一些全局的公共参数，如全局的SMTP配置，Slack配置等内容；
模板（templates）：用于定义告警通知时的模板，如HTML模板，邮件模板等；
告警路由（route）：根据标签匹配，确定当前告警应该如何处理；
接收人（receivers）：接收人是一个抽象的概念，它可以是一个邮箱也可以是微信，Slack或者Webhook等，接收人一般配合告警路由使用；
抑制规则（inhibit_rules）：合理设置抑制规则可以减少垃圾告警的产生

完整配置格式如下：

global:
  [ resolve_timeout: <duration> | default = 5m ]
  [ smtp_from: <tmpl_string> ] 
  [ smtp_smarthost: <string> ] 
  [ smtp_hello: <string> | default = "localhost" ]
  [ smtp_auth_username: <string> ]
  [ smtp_auth_password: <secret> ]
  [ smtp_auth_identity: <string> ]
  [ smtp_auth_secret: <secret> ]
  [ smtp_require_tls: <bool> | default = true ]
  [ slack_api_url: <secret> ]
  [ victorops_api_key: <secret> ]
  [ victorops_api_url: <string> | default = "https://alert.victorops.com/integrations/generic/20131114/alert/" ]
  [ pagerduty_url: <string> | default = "https://events.pagerduty.com/v2/enqueue" ]
  [ opsgenie_api_key: <secret> ]
  [ opsgenie_api_url: <string> | default = "https://api.opsgenie.com/" ]
  [ hipchat_api_url: <string> | default = "https://api.hipchat.com/" ]
  [ hipchat_auth_token: <secret> ]
  [ wechat_api_url: <string> | default = "https://qyapi.weixin.qq.com/cgi-bin/" ]
  [ wechat_api_secret: <secret> ]
  [ wechat_api_corp_id: <string> ]
  [ http_config: <http_config> ]

templates:
  [ - <filepath> ... ]

route: <route>

receivers:
  - <receiver> ...

inhibit_rules:
  [ - <inhibit_rule> ... ]

在全局配置中需要注意的是resolve_timeout，该参数定义了当Alertmanager持续多长时间未接收到告警后标记告警状态为resolved（已解决）。该参数的定义可能会影响到告警恢复通知的接收时间，可根据自己的实际场景进行定义，其默认值为5分钟。

实例：定义主机监控告警

修改Prometheus配置文件prometheus.yml,添加以下配置：

重启Prometheus后访问Prometheus UIhttp://127.0.0.1:9090/rules可以查看当前以加载的规则文件。

访问ttp://localhost:9090/alerts查看当前已加载的alert

groups:
- name: hostStatsAlert
  rules:
  - alert: hostCpuUsageAlert
    expr: sum(avg without (cpu)(irate(node_cpu_seconds_total{mode!='idle'}[5m]))) by (instance) > 0.85
    for: 1m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} CPU usgae high"
      description: "{{ $labels.instance }} CPU usage above 85% (current value: {{ $value }})"
  - alert: hostMemUsageAlert
    expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes)/node_memory_MemTotal_bytes > 0.85
    for: 1m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} MEM usgae high"
      description: "{{ $labels.instance }} MEM usage above 85% (current value: {{ $value }})"