一、概述

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