一、概述

Prometheus 包括一个报警模块，便是咱们的 AlertManager，Alertmanager 主要用于接纳 Prometheus 发送的告警信息，它支撑丰富的告警告诉途径，而且很简单做到告警信息进行去重，降噪，分组等，是一款前卫的告警告诉体系。

  • GitHub地址：github.com/prometheus/…
  • 官方文档：prometheus.io/docs/alerti…
  • 关于Prometheus全体介绍，能够参考我这篇文章：Prometheus原理详解
  • Prometheus和Pushgetway的安装，能够参考我这篇文章：【云原生】Prometheus Pushgetway解说与实战操作

【云原生】Prometheus AlertManager讲解与实战操作

二、AlertManager 架构

【云原生】Prometheus AlertManager讲解与实战操作
【云原生】Prometheus AlertManager讲解与实战操作

Alertmanager由以下6部分组成：

  • API组件——用于接纳Prometheus Server的http恳求，主要是告警相关的内容。
  • Alert Provider组件——API层将来自Prometheus Server的告警信息存储到Alert Provider上。
  • Dispatcher组件——不断的经过订阅的方法从Alert Provider获取新的告警，并依据yaml装备的routing tree将告警经过label路由到不同的分组中，以完成告警信息的分组处理。
  • Notification Pipeline组件——这是一个职责链模式的组件，它经过一系列的逻辑（按捺、静默、去重）来优化告警质量。
  • Silence Provider组件——API层将来自prometheus server的告警信息存储到silence provider上，然后由这个组件完成去重逻辑处理。
  • Notify Provider组件——是Silence Provider组件的下流，会在本地记录日志，并经过peers的方法将日志播送给集群中的其他节点，判别当时节点本身或许集群中其他节点是否现已发送过了，防止告警信息在集群中重复呈现。

三、AlertManager 布置

下载地址：prometheus.io/download/

1）下载

wget https://github.com/prometheus/alertmanager/releases/download/v0.24.0/alertmanager-0.24.0.linux-amd64.tar.gz
tar -xf alertmanager-0.24.0.linux-amd64.tar.gz

2）装备

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

Alertmanager装备中一般会包括以下几个主要部分：

  • 大局装备（global）：用于界说一些大局的公共参数，如大局的SMTP装备，Slack装备等内容。
  • 模板（templates）：用于界说告警告诉时的模板，如HTML模板，邮件模板等。
  • 告警路由（route）：依据标签匹配，确定当时告警应该如何处理。
  • 接纳人（receivers）：接纳人是一个抽象的概念，它能够是一个邮箱也能够是微信，Slack或许Webhook等，接纳人一般配合告警路由运用。
  • 按捺规矩（inhibit_rules）：合理设置按捺规矩能够削减废物告警的发生。

详细字段解释：

  • global 这个是大局设置
  • resolve_timeout 当告警的状态有firing变为resolve的以后还要呆多长时间，才宣布告警免除。这个主要是解决某些监控方针在阀值边际上动摇，一会儿好一会儿欠好。
  • route 是个要点，告警内容从这儿进入，寻觅自己应该用那种策略发送出去。
  • receiver 一级的receiver，也便是默许的receiver，当告警进来后没有找到任何子节点和自己匹配，就用这个receiver。
  • group_by 告警应该依据那些标签进行分组。
  • group_wait 同一组的告警宣布前要等候多少秒，这个是为了把更多的告警一个批次宣布去。
  • group_interval 同一组的多批次告警间隔多少秒后，才干宣布。
  • repeat_interval 重复的告警要等候多久后才干再次宣布去。
  • routes 也便是子节点了，装备项和上面一样。告警会一层层的找，假如匹配到一层，而且这层的continue选项为true，那么他会再往下找，假如基层节点不能匹配那么他就用区配的这一层的装备发送告警。假如匹配到一层，而且这层的continue选项为false，那么他会直接用这一层的装备发送告警，就不往下找了。
  • match_re 用于匹配label。此处列出的所有label都匹配到才算匹配。
  • inhibit_rules这个叫做按捺项，经过匹配源告警来按捺意图告警。比如说当咱们的主机挂了，或许引起主机上的服务，数据库，中间件等一些告警，假如说后续的这些告警相对来说没有意义，咱们能够用按捺项这个功能，让Prometheus只宣布主机挂了的告警。
  • source_match 依据label匹配源告警。
  • target_match 依据label匹配意图告警。
  • equal 此处的调集的label，在源和意图里的值有必要相等。假如该调集的内的值再源和意图里都没有，那么意图告警也会被按捺。

3）发动服务

# 查看帮助
./alertmanager -h
# 能够直接发动，可是不发起，最好装备alertmanager.service
./alertmanager

装备alertmanager.service发动脚本

# 默许端口9093
cat >/usr/lib/systemd/system/alertmanager.service<<EOF
[Unit]
Description=alertmanager
[Service]
WorkingDirectory=/opt/prometheus/alertmanager/alertmanager-0.24.0.linux-amd64
ExecStart=/opt/prometheus/alertmanager/alertmanager-0.24.0.linux-amd64/alertmanager --config.file=/opt/prometheus/alertmanager/alertmanager-0.24.0.linux-amd64/alertmanager.yml --storage.path=/opt/prometheus/alertmanager/alertmanager-0.24.0.linux-amd64/data --web.listen-address=:9093 --data.retention=120h
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF

发动服务

# 履行 systemctl daemon-reload 指令重新加载systemd
systemctl daemon-reload
# 发动
systemctl start alertmanager
# 查看
systemctl status alertmanager
netstat -tnlp|grep :9093
ps -ef|grep alertmanager

【云原生】Prometheus AlertManager讲解与实战操作
web拜访：http://ip:9093
【云原生】Prometheus AlertManager讲解与实战操作

4）与Prometheus集成

修改Prometheus的装备文件，修改装备如下：

【云原生】Prometheus AlertManager讲解与实战操作
重启Prometheus

systemctl restart prometheus

四、在Prometheus中设置告警规矩

在Prometheus 装备中增加报警规矩装备，装备文件中 rule_files 便是用来指定报警规矩文件的，如下装备即指定寄存报警规矩的目录为/etc/prometheus，规矩文件为rules.yml：

rule_files:
- /etc/prometheus/rules.yml

设置报警规矩：

警报规矩允许依据 Prometheus 表达式语言的表达式来界说报警报条件的，并在触发警报时发送告诉给外部的接纳者（Alertmanager），一条警报规矩主要由以下几部分组成：

  • alert——告警规矩的称号。
  • expr——是用于进行报警规矩 PromQL 查询句子。
  • for——评价告警的等候时间（Pending Duration）。
  • labels——自界说标签，允许用户指定额外的标签列表，把它们附加在告警上。
  • annotations——用于存储一些额外的信息，用于报警信息的展示之类的。

rules.yml如下所示：

groups:
- name: example
  rules:
  - alert: high_memory
    # 当内存占有率超越10%，继续1min,则触发告警
    expr: 100 - ((node_memory_MemAvailable_bytes{instance="192.168.182.110:9100",job="node_exporter"} * 100) / node_memory_MemTotal_bytes{instance="192.168.182.110:9100",job="node_exporter"}) > 90
    for: 1m
    labels:
      severity: page
    annotations:
      summary: spike memeory

五、AlertManager 告警通道装备

## Alertmanager 装备文件
global:
  resolve_timeout: 5m
  # smtp装备
  smtp_from: "xxx@qq.com"
  smtp_smarthost: 'smtp.qq.com:465'
  smtp_auth_username: "xxx@qq.com"
  smtp_auth_password: "auth_pass"
  smtp_require_tls: true
# email、企业微信的模板装备寄存位置，钉钉的模板会独自讲假如装备。
templates:
  - '/data/alertmanager/templates/*.tmpl'
# 路由分组
route:
  receiver: ops
  group_wait: 30s # 在组内等候所装备的时间，假如同组内，30秒内呈现相同报警，在一个组内呈现。
  group_interval: 5m # 假如组内内容不改变，合并为一条警报信息，5m后发送。
  repeat_interval: 24h # 发送报警间隔，假如指定时间内没有修复，则重新发送报警。
  group_by: [alertname]  # 报警分组
  routes:
      - match:
          team: operations
        group_by: [env,dc]
        receiver: 'ops'
      - match_re:
          service: nginx|apache
        receiver: 'web'
      - match_re:
          service: hbase|spark
        receiver: 'hadoop'
      - match_re:
          service: mysql|mongodb
        receiver: 'db'
# 接纳器
# 按捺测验装备
      - receiver: ops
        group_wait: 10s
        match:
          status: 'High'
# ops
      - receiver: ops # 路由和标签，依据match来指定发送方针，假如 rule的lable 包括 alertname， 运用 ops 来发送
        group_wait: 10s
        match:
          team: operations
# web
      - receiver: db # 路由和标签，依据match来指定发送方针，假如 rule的lable 包括 alertname， 运用 db 来发送
        group_wait: 10s
        match:
          team: db
# 接纳器指定发送人以及发送途径
receivers:
# ops分组的界说
- name: ops
  email_configs:
  - to: '9935226@qq.com,10000@qq.com'
    send_resolved: true
    headers:
      subject: "[operations] 报警邮件"
      from: "警报中心"
      to: "小煜狼皇"
  # 钉钉装备
  webhook_configs:
  - url: http://localhost:8070/dingtalk/ops/send
    # 企业微信装备
  wechat_configs:
  - corp_id: 'ww5421dksajhdasjkhj'
    api_url: 'https://qyapi.weixin.qq.com/cgi-bin/'
    send_resolved: true
    to_party: '2'
    agent_id: '1000002'
    api_secret: 'Tm1kkEE3RGqVhv5hO-khdakjsdkjsahjkdksahjkdsahkj'
# web
- name: web
  email_configs:
  - to: '9935226@qq.com'
    send_resolved: true
    headers: { Subject: "[web] 报警邮件"} # 接纳邮件的标题
  webhook_configs:
  - url: http://localhost:8070/dingtalk/web/send
  - url: http://localhost:8070/dingtalk/ops/send
# db
- name: db
  email_configs:
  - to: '9935226@qq.com'
    send_resolved: true
    headers: { Subject: "[db] 报警邮件"} # 接纳邮件的标题
  webhook_configs:
  - url: http://localhost:8070/dingtalk/db/send
  - url: http://localhost:8070/dingtalk/ops/send
# hadoop
- name: hadoop
  email_configs:
  - to: '9935226@qq.com'
    send_resolved: true
    headers: { Subject: "[hadoop] 报警邮件"} # 接纳邮件的标题
  webhook_configs:
  - url: http://localhost:8070/dingtalk/hadoop/send
  - url: http://localhost:8070/dingtalk/ops/send
# 按捺器装备
inhibit_rules: # 按捺规矩
  - source_match: # 源标签警报触发时按捺含有方针标签的警报，在当时警报匹配 status: 'High'
      status: 'High'  # 此处的按捺匹配一定在最上面的route中装备不然，会提示找不key。
    target_match:
      status: 'Warning' # 方针标签值正则匹配，能够是正则表达式如: ".*MySQL.*"
    equal: ['alertname','operations', 'instance'] # 确保这个装备下的标签内容相同才会按捺，也便是说警报中有必要有这三个标签值才会被按捺。

一般企业钉钉、邮件、webhook告警通道比较常用，尤其是webhook，一般都会经过webhook对接公司内部的统一告警平台。

Prometheus AlertManager解说就先到这儿了，有任何疑问欢迎给我留言，后续会继续更新【云原生+大数据】相关的文章，请小伙伴耐性等候~