Prometheus配置和使用Alertmanager发送告警至企业微信

news/2024/5/19 2:02:48 标签: prometheus, alertmanager, 企业微信

注:本文基于CentOS 7.4编写

1、准备工作

1.1 创建应用

注册企业微信,这个不细说。注册完成后,点击应用管理->应用->创建应用
在这里插入图片描述

1.2 获取应用ID和秘钥

按照要求创建应用后,点击创建的应用就能看到我们的应用id和秘钥,这两个信息很重要,后面在prometheus中会用到。
在这里插入图片描述

1.3 获取企业账号ID

我的企业->企业信息->企业ID
在这里插入图片描述

1.4 获取告警发送部门或组ID

获取需要接收告警的部门或组ID,注意ID为1,表示整个公司,慎用!
在这里插入图片描述

1.5 设置告警可见范围

我们添加的应用中需要设置告警可见范围,把需要接收告警的群组添加进去,不然告警一直无法接受到,我在这折腾了很久。
在这里插入图片描述

alertmanager_20">2、安装下载alertmanager

我们以官网最新版本为例,官网地址,https://prometheus.io/download/

wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz

如果觉得官网下载实在慢,可以通过以下链接下载,
alertmanager-0.21.0.linux-amd64.tar.gz

下载完压缩包后我们直接解压,并放到/usr/local/prometheus目录,便于管理,

[root@centos74 prometheus]# tar -xf alertmanager-0.21.0.linux-amd64.tar.gz 
[root@centos74 prometheus]# cp -r alertmanager-0.21.0.linux-amd64 /usr/local/prometheus/alertmanager
[root@centos74 prometheus]# cd /usr/local/prometheus/alertmanager/
[root@centos74 alertmanager]# ls
alertmanager  alertmanager.yml  amtool  LICENSE  NOTICE
[root@centos74 alertmanager]# ./alertmanager --version
alertmanager, version 0.21.0 (branch: HEAD, revision: 4c6c03ebfe21009c546e4d1e9b92c371d67c021d)
  build user:       root@dee35927357f
  build date:       20200617-08:54:02
  go version:       go1.14.4

alertmanager_45">3、配置alertmanager

[root@centos74 alertmanager]# cat alertmanager.yml 
global:
  resolve_timeout: 5m

route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'wechat'
receivers:
- name: 'wechat'
  wechat_configs:
  - corp_id: '123456'       
   	to_party: '123456'      
  	agent_id: '123456'     
   	api_secret: '123456'     
   	send_resolved: true    
inhibit_rules:
  - source_match:
      severity: 'major'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'instance']
templates:
  - '*.tmpl'

主要有五个字段,

  • global:全局配置
    resolve_timeout:告警恢复超时时间,当接收的告警没有EndsAt字段时,经过该时间就将该告警标志为已解决,prometheus上用不上,告警都会带EndsAt字段

  • route:告警分配配置
    group_by:设置分组标签,告警时出现的labels都可用于分组,如果需要对所有不同label都分组,可以使用’…’
    group_wait:告警发送等待时间,时间拉长便于告警聚合
    group_interval:前后两组告警发送间隔时间
    repeat_interval:重复告警发送间隔时间
    receiver:定义接收告警的对象

  • receivers:告警接收对象,这部分信息参考步骤1获取
    name:告警接收名称,与route中的receiver一一对应,这里我们配置的是企业微信
    corp_id: 企业微信唯一ID,我的企业 -> 企业信息
    to_party: 告警需要发送的组
    agent_id: 自己创建应用的ID,自己创建的应用详情页面查看
    api_secret: 自己创建应用的密钥,自己创建的应用详情页面查看
    send_resolved: 告警解决是否发送通知

  • inhibit_rules:告警抑制规则
    当新的告警匹配到target_match规则,而已发送告警满足source_match规则,并且新告警与已发送告警中equal定义的标签完全相同,则抑制这个新的告警。
    上述配置的结果就是同个instance的同个alertname告警,major会抑制warning告警,这很好理解,比如阈值告警,达到critical肯定也达到了warning,没必要发送两个告警。
    不过,从实际测试结果看,这个抑制规则只能在触发告警时使用,对于告警恢复没有,应该是个bug,也有可能我用的版本过低,有时间再去看下源码,查一查

  • templates:告警消息模板
    定义模板路径

4、告警消息模板

模板内容如下,关于模板语法及解释,参看另一篇文章——Prometheus Alertmanager告警模板

[root@centos74 home]# cat /usr/local/prometheus/alertmanager/wechat.tmpl
{{ define "wechat.default.message" }}
{{- if gt (len .Alerts.Firing) 0 -}}
{{- range $index, $alert := .Alerts -}}
======== 异常告警 ========
告警名称:{{ $alert.Labels.alertname }}
告警级别:{{ $alert.Labels.severity }}
告警机器:{{ $alert.Labels.instance }} {{ $alert.Labels.device }}
告警详情:{{ $alert.Annotations.summary }}
告警时间:{{ $alert.StartsAt.Format "2006-01-02 15:04:05" }}
========== END ==========
{{- end }}
{{- end }}
{{- if gt (len .Alerts.Resolved) 0 -}}
{{- range $index, $alert := .Alerts -}}
======== 告警恢复 ========
告警名称:{{ $alert.Labels.alertname }}
告警级别:{{ $alert.Labels.severity }}
告警机器:{{ $alert.Labels.instance }}
告警详情:{{ $alert.Annotations.summary }}
告警时间:{{ $alert.StartsAt.Format "2006-01-02 15:04:05" }}
恢复时间:{{ $alert.EndsAt.Format "2006-01-02 15:04:05" }}
========== END ==========
{{- end }}
{{- end }}
{{- end }}

当然,这个模板是基于告警规则定义的,本次测试使用的告警规则如下, 阈值都是为了测试而设置,切勿照搬~

[root@centos74 home]# cat /usr/local/prometheus/rules/node_health.yml 
groups:
- name: node_health
  rules:
  - alert: HighMemoryUsage
    expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.9
    for: 1m
    labels:
      severity: warning
    annotations:
      summary: High memory usage

  - alert: HighDiskUsage
    expr: node_filesystem_free_bytes{mountpoint='/'} / node_filesystem_size_bytes{mountpoint='/'} < 0.7
    for: 1m
    labels:
      severity: major
    annotations:
      summary: High Disk usage

  - alert: HighDiskUsage
    expr: node_filesystem_free_bytes{mountpoint='/'} / node_filesystem_size_bytes{mountpoint='/'} < 0.71
    for: 1m
    labels:
      severity: warning
    annotations:
      summary: High Disk usage

5、启动服务

鉴于安装是通过二进制文件安装,为了便于管理,我们增加一个对应的systemd服务,这样启动和开机启动就更方便了。

cat > /usr/lib/systemd/system/alertmanager.service <<EOF
[Unit]
Description=altermanager
After=network.target
 
[Service]
ExecStart=/usr/local/prometheus/alertmanager/alertmanager \
		  --config.file=/usr/local/prometheus/alertmanager/alertmanager.yml 
ExecReload=/bin/kill -s HUP \$MAINPID
Restart=on-failure
 
[Install]
WantedBy=multi-user.target
EOF

设置可执行文件路径以及配置文件路径

然后就可以通过systemctl命令设置开机启动,并启动服务了。

systemctl enable alertmanager&& systemctl start alertmanager

prometheusalertmanager_197">6、配置prometheus使用alertmanager

[root@centos74 ~]# grep -Ev "^#|^$" /usr/local/prometheus/prometheus.yml 
...
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - 127.0.0.1:9093
...

添加targets字段,指向alertmanager地址,这样告警就能发往alertmanager处理。
修改完配置记得reload下配置,

systemctl reload prometheus

7、触发告警

配置都OK后,就可以测试了,针对告警规则,手动触发告警,等待一小段时间,观察prometheus web上的告警和企业微信上的消息,

  • web
    在这里插入图片描述
  • 企业微信
    在这里插入图片描述
    然后针对disk告警,消除告警,可见,告警抑制在告警恢复时并不能正常工作。
    在这里插入图片描述

http://www.niftyadmin.cn/n/1035300.html

相关文章

通过BAPI方式展示长文本ADA_POPUP_WITH_TABLE

BAPI测试如下&#xff1a;结果DATA:BEGIN OF wa_info,info TYPE char72, END OF wa_info, it_info LIKE TABLE OF wa_info.CALL FUNCTION ADA_POPUP_WITH_TABLEEXPORTINGstartpos_col 1startpos_row 1titletext 长文本展示测试 * WORDWRAP_POSITION …

Prometheus Alertmanager告警模板

1、告警模板 关于Alertmanager的告警模板&#xff0c;我们以上篇《Prometheus配置和使用Alertmanager发送告警至企业微信》的模板为例&#xff0c;对其做个说明&#xff0c; [rootcentos74 home]# cat /usr/local/prometheus/alertmanager/wechat.tmpl {{ define "wecha…

LRU链表及LRU缓存

注&#xff1a;本文分析基于linux-4.18.0-193.14.2.el8_2内核版本&#xff0c;即CentOS 8.2 1、 关于LRU LRU即Least recently used&#xff0c;也就是最近最少使用&#xff0c;一般用作缓存淘汰上&#xff0c;它的核心思想是——如果一个数据在最近一段时间没有被访问到&…

kswapd进程工作原理(一)——初始化及触发

注&#xff1a;本文分析基于linux-4.18.0-193.14.2.el8_2内核版本&#xff0c;即CentOS 8.2 1、关于kswap进程 kswap用于在内存不足时进行内存回收&#xff0c;每个NUMA内存节点会有一个kswapd进程&#xff0c; [rootlocalhost ~]# numactl -H available: 2 nodes (0-1) nod…

kswapd进程工作原理(二)——回收内存上半部

注&#xff1a;本文分析基于linux-4.18.0-193.14.2.el8_2内核版本&#xff0c;即CentOS 8.2 在上篇文章——kswapd进程工作原理(一)中&#xff0c;我们分析了kswapd进程的初始化以及触发场景&#xff0c;那kswap到底是怎么回收内存&#xff0c;回收哪些内存呢&#xff0c;我们…

kswapd进程工作原理(三)——回收LRU链表

注&#xff1a;本文分析基于linux-4.18.0-193.14.2.el8_2内核版本&#xff0c;即CentOS 8.2 在上篇文章——kswapd进程工作原理(二)——回收内存上半部中&#xff0c;我们分析了kswapd进程的具体回收过程&#xff0c;今天我们再继续往下&#xff0c;看看kswapd是如何回收LRU链…

kswapd进程工作原理(四)——总结

注&#xff1a;本文分析基于linux-4.18.0-193.14.2.el8_2内核版本&#xff0c;即CentOS 8.2 kswapd进程工作原理(一)——初始化及触发 kswapd进程工作原理(二)——回收内存上半部 kswapd进程工作原理(三)——回收LRU链表 关于kswapd进程&#xff0c;我们通过之前这三篇文章分…

vm内核参数之swap分区使用控制swappiness

注&#xff1a;本文分析基于linux-4.18.0-193.14.2.el8_2内核版本&#xff0c;即CentOS 8.2 1 背景 swap分区在系统内存不足时&#xff0c;会使用swap来存放内存中暂不用的数据&#xff0c;这能一定程度缓解内存不足&#xff0c;但系统具体是通过什么方式使用swap分区呢&…