Prometheus之Alertmanager告警

news2024/10/6 22:33:12

告警流程

Prometheus主要是提供了数据的采集和存储，Alertmanager组件主要实现告警功能。Alertmanager 主要用于接收 Prometheus 发送的告警信息，它支持丰富的告警通知渠道，而且很容易做到告警信息进行去重，降噪，分组等，是一款前卫的告警通知系统。

Prometheus告警流程：
prometheus–>触发阈值–>超出持续时间–>alertmanager–>分组|抑制|静默–>媒体类型–>邮件|钉钉|微信等发送通知
在这里插入图片描述
Prometheus根据rule规则判断指标是否超过阈值，如果超出阈值且持续一段时间未恢复就发送告警到Alertmanager。Alertmanager根据配置中定义的规则对告警进行分组/抑制/静默处理，最后以不同的形式发送给接收人

部署Alertmanager

下载安装包

tar xf alertmanager-0.25.0.linux-amd64.tar.gz -C /usr/local/
ln -sv /usr/local/alertmanager-0.25.0.linux-amd64 /usr/local/alertmanager
/usr/local/alertmanager/alertmanager -h	#查看帮助信息

准备service文件

root@prometheus-server-01:~# cat /lib/systemd/system/alertmanager.service
[Unit]
Description=Prometheus Alertmanager
After=network.target

[Service]
ExecStart=/usr/local/alertmanager/alertmanager --config.file="/usr/local/alertmanager/alertmanager.yml"

[Install]
WantedBy=multi-user.target

启动alertmanager服务

systemctl daemon-reload
systemctl start alertmanager.service
systemctl status alertmanager.service
systemctl enable alertmanager.service

访问alertmanager界面
在这里插入图片描述

Alertmanager配置介绍

Alertmanager的配置介绍可以参考官方文档：https://prometheus.io/docs/alerting/latest/configuration

一般情况下Altermanager的配置文件会包含以下几个部分：

  • global（全局配置）：用来定义一些全局的公共参数，比如Smtp邮件服务器配置、企业微信配置等
  • template（告警模板）：用于定义告警通知时的模板，比如邮件模板、微信模板等
  • router（告警路由规则）：用于定义告警的分发策略
  • receivers（接收者）：用于定义告警接收人，可以是邮箱、微信等。一般配和告警路由规则来使用，实现不同的告警发给不同的接收人
  • inhibit_rules（告警抑制规则）：用于定义告警抑制规则，避免垃圾告警产生

完整格式如下：

global:
  [ smtp_from: <tmpl_string> ]
  [ smtp_smarthost: <string> ]
  [ smtp_hello: <string> | default = "localhost" ]
  [ smtp_auth_username: <string> ]
  [ smtp_auth_password: <secret> ]
  [ smtp_auth_password_file: <string> ]
  [ smtp_auth_identity: <string> ]
  [ smtp_auth_secret: <secret> ]
  [ smtp_require_tls: <bool> | default = true ]

  [ slack_api_url: <secret> ]
  [ slack_api_url_file: <filepath> ]
  [ victorops_api_key: <secret> ]
  [ victorops_api_key_file: <filepath> ]
  [ 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_key_file: <filepath> ]
  [ opsgenie_api_url: <string> | default = "https://api.opsgenie.com/" ]
  [ wechat_api_url: <string> | default = "https://qyapi.weixin.qq.com/cgi-bin/" ]
  [ wechat_api_secret: <secret> ]
  [ wechat_api_corp_id: <string> ]
  [ telegram_api_url: <string> | default = "https://api.telegram.org" ]
  [ webex_api_url: <string> | default = "https://webexapis.com/v1/messages" ]
  [ http_config: <http_config> ]
  [ resolve_timeout: <duration> | default = 5m ]

templates:
  [ - <filepath> ... ]

route: <route>

receivers:
  - <receiver> ...

inhibit_rules:
  [ - <inhibit_rule> ... ]

time_intervals:
  [ - <time_interval> ... ]

下面是一个示例配置文件：

global:
  #在5m内收到Prometheus发来相同告警情况下认为告警已经恢复
  resolve_timeout: 5m
  #SMTP邮件服务器配置
  smtp_smarthost: 'localhost:25'
  smtp_from: 'alertmanager@example.org'
  smtp_auth_username: 'alertmanager'
  smtp_auth_password: 'password'

#告警模板文件
templates:
  - '/etc/alertmanager/template/*.tmpl'

#告警路由规则，所有告警信息进入后的根路由
route:
  #告警分组规则，例如，这里表示具有相同alertname值的告警会被分为一组。这个值是可以修改的，并不一定是alertname
  group_by: ['alertname']
  # 在一个新的告警分组被创建后，需要等待group_wait指定的时间来初始化通知，这种方式可以确保有足够的时间为同一分组获取多条告警，
  # 然后一起发送这些告警到接收人
  group_wait: 30s 
  # 同一组告警发送时间间隔，如果一个组第一次告警已经发送，则等待group_interval时间再来发送组内新的告警
  group_interval: 5m
  #重复告警间隔时间，如果一条告警已经发送成功，则需要等待repeat_interval时间才能重新发送
  repeat_interval: 3h
  #默认接收人
  receiver: team-X-mails
 #子路由配置，上面的所有属性都会被子路由，并且可以在每个子路由上覆盖
  routes:
	# 子路由规则1
    - matchers:
        - service=~"foo1|foo2|baz"
      receiver: team-X-mails
	 #子路由下还可以继续配置子路由
      routes:
        - matchers:
            - severity="critical"
          receiver: team-X-pager
    #子路由规则2
    - matchers:
        - service="files"
      receiver: team-Y-mails
      routes:
        - matchers:
            - severity="critical"
          receiver: team-Y-pager
	#子路由规则3
    - matchers:
        - service="database"
      receiver: team-DB-pager
      group_by: [alertname, cluster, database]
      routes:
        - matchers:
            - owner="team-X"
          receiver: team-X-pager
          continue: true
        - matchers:
            - owner="team-Y"
          receiver: team-Y-pager


#告警抑制规则配置
inhibit_rules:
  #此配置表示如果发生多个告警时，它们的alertname和node标签值相同，那么产生critical级别的告警就不产生warning级别的告警。告警级别可以在Prometheus的rules中定义
  - source_matchers: [severity="critical"]
    target_matchers: [severity="warning"]
    equal: [alertname, node]

#告警接收人定义
receivers:
  - name: 'team-X-mails'
    email_configs:
      - to: 'team-X+alerts@example.org'

  - name: 'team-X-pager'
    email_configs:
      - to: 'team-X+alerts-critical@example.org'
    pagerduty_configs:
      - service_key: <team-X-key>

  - name: 'team-Y-mails'
    email_configs:
      - to: 'team-Y+alerts@example.org'

  - name: 'team-Y-pager'
    pagerduty_configs:
      - service_key: <team-Y-key>

  - name: 'team-DB-pager'
    pagerduty_configs:
      - service_key: <team-DB-key>

关于告警的分组、抑制和静默解释：

  • 分组：将同类型的警告进行分组，并将同组的多个告警合并为一个通知发送，避免短时间内收到大量告警通知，被告警通知淹没
  • 抑制：当某条告警已经发送，停止重复发送由此告警引起的其它告警。例如当一个节点down后，其上部署的服务也会触发不可用的告警，这时候就可以配置忽略由于节点down而造成的服务不可用告警
  • 静默：一个简单的定时静音机制，例如服务器需要升级维护时，可以设置这个时间段内告警静默，不再发送告警通知

在AlertManager中通过路由（route）来定义告警的处理方式。路由是一个基于标签匹配的树状怕匹配结构，根据接收到告警的标签匹配相应的处理方式。路由树状结构大致如下图所示：

在这里插入图片描述

默认情况下，Alertmanager接收到的每个告警都会先到根路由（配置文件中的route字段），然后遍历匹配所有的子路由（配置中的route.routes字段），再往下遍历匹配子路由的子路由（配置中的route.routes.routes字段），以此类推，直到找到最深的匹配的路由，并将告警通知发送到此路由定义的接收者。但如果路由中设置了continue的值为false，那么告警在匹配到第一个子节点之后就会停止，不再继续往下匹配。如果不能匹配任何一个子路由，那么告警会基于当前路由节点定义规则进行处理。

其中告警的匹配使用matchers字段定义，标签和标签值可以使用等值匹配或者正则表达式匹配，具体可以参考官方文档：https://prometheus.io/docs/alerting/latest/configuration/#matcher

需要注意：根路由必须匹配所有的告警，即不能设置matchers

关于路由设置中的几个时间配置，也需要详细解释一下：

  • group_wait：当Altertmanager收到一条新告警时，会先根据group_by指定的标签为其确定一个组，然后等待group_wait指定时间，在此时间段内如果收到同一个group的其它告警，则这些告警会被合并为一条通知发送给接收人，可以认为Alertmanager发送通知的单位是组
  • group_interval：在一个组的告警被第一次发送后，该组会进入睡眠/唤醒周期，睡眠时长为group_interval指定时间，在睡眠期间该group不会进行任何发送告警的操作（但会插入/更新group中的内容），睡眠结束后进入唤醒状态，然后检查是否需要发送新的告警通知或者重复已发送的告警（resolved类型的告警在发送完成后会从group中剔除）。这就是group_interval的作用
  • repeat_interval：如果一条告警已经发送成功，则需要等待repeat_interval时间才能重复发送。但是repeat_interval并不能真正代表告警的实际重复间隔，假如一条告警达到了repeat_interval时间，但它所属的组此时还处于睡眠状态，此时是无法发送重复告警的。所以实际的重复告警间隔应该大于repeat_interval，但小于repeat_interval+group_interval

Prometheus rule文件配置

Prometheus的rule文件是用来定义告警触发规则，主要是使用PromQL语句来查询指标，然后进行判断。可以参考官方文档介绍：https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/

下面是一个示例rule文件：

groups:
  - name: alertmanager_pod.rules	#告警规则组名，注意这和Altermanager中的组不是一个概念
    rules:
    - alert: Pod_all_cpu_usage	#告警名称，对应标签alertname
      expr: (sum by(name)(rate(container_cpu_usage_seconds_total{image!=""}[5m]))*100) > 10	#告警表达式
      for: 2m	#持续时长，表示上面的表达式满足且超过两分钟才会触发告警
      labels:	#对告警附加的标签
        severity: critical
        service: pods
        project: myserver
      annotations:	#告警通知中的注释内容，可用于描述告警具体信息
        description: 容器 {{ $labels.name }} CPU 资源利用率大于 10% , (current value is {{ $value }})
        summary: Dev CPU 负载告警

    - alert: Pod_all_memory_usage  
      #expr: sort_desc(avg by(name)(irate(container_memory_usage_bytes{name!=""}[5m]))*100) > 10  #内存大于10%
      expr: sort_desc(avg by(name)(irate(node_memory_MemFree_bytes {name!=""}[5m]))) > 2*1024*1024*1024   #内存大于2G
      for: 2m
      labels:
        severity: critical
        project: myserver
      annotations:
        description: 容器 {{ $labels.name }} Memory 资源利用率大于 2G , (current value is {{ $value }})
        summary: Dev Memory 负载告警

    - alert: Pod_all_network_receive_usage
      #expr: sum by (name)(irate(container_network_receive_bytes_total{container_name="POD"}[1m])) > 50*1024*1024
      expr: sum by (name)(irate(container_network_receive_bytes_total{container_name="POD"}[1m])) > 0
      for: 2m
      labels:
        #severity: critical
        project: myserver
      annotations:
        description: 容器 {{ $labels.name }} network_receive 资源利用率大于 50M , (current value is {{ $value }})

    - alert: node内存可用大小 
      expr: node_memory_MemFree_bytes < 524288000 #内存小于500兆
      for: 30s
      labels:
        project: node
      annotations:
        description: node节点可用内存小于500M

修改Prometheus配置，加载此rule文件

global:
  scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.

alerting:
  alertmanagers:
    - static_configs:
        - targets:	#指定alertmanager地址，可以指定多个，Prometheus会将告警发到这些指定的Alertmanager
          - 192.168.122.21:9093	

rule_files:	#指定要加载的rule文件
  - "/usr/local/prometheus/rules/test-rules.yml"

配置修改之后重启Prometheus

systemctl restart prometheus

在Prometheus界面查看是否已经加载对应的rule
在这里插入图片描述

邮件告警

开启邮箱授权

以QQ邮箱为例，开启邮箱的POP3/SMTP服务
在这里插入图片描述
开启之后会得到一个授权码，妥善保存

配置Alertmanager

修改Alertmanager配置，添加邮件服务器配置、告警路由规则配置和告警接收者配置

global:
  resolve_timeout: 5m
  #添加邮件服务器配置
  smtp_from: "xxxx@qq.com"	#指定发件人地址
  smtp_smarthost: "smtp.qq.com:465"	#smtp服务器地址
  smtp_auth_username: "1348937808@qq.com"	#邮箱服务器认证用户名
  smtp_auth_password: "xxxxx"	#邮箱服务器认证密码。QQ邮箱是之前获取的授权码
  smtp_require_tls: true	#访问smtp服务器是否需要tls
  smtp_hello: "qq.com"	#向SMTP服务器发送测试消息的内容
#添加告警路由规则，目前只有根路由，所以所有的告警都会发给默认接收者email-receiver
route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 2m
  repeat_interval: 1h
  receiver: 'email-receiver'	#指定告警消息接收者
receivers:
  #添加email-receiver接收者
  - name: email-receiver
    email_configs:	#邮件配置
    - send_resolved: true	#是否发送告警恢复消息
      to: wang@outlook.com	#收件人
  - 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

systemctl restart alertmanager

验证

在Prometheus界面查看Alerts，如下图所示，可以看到在node_memory_alert这个规则下有六条告警处于Pending状态

在这里插入图片描述

等待一段时间刷新再看，发现这六条告警已经变为Firing状态，如下图，这表示已经将告警发送至Alertmanager

在这里插入图片描述

Prometheus中的告警存在3中状态：

  1. inactive：表示无事件发生，没有告警
  2. pending：已经触发阈值但为满足告警持续时间（即rule中的for字段）
  3. firing：已经触发阈值且满足持续时间，并且已经将告警发送至Alertmanager

在Alertmanager界面查看数据，确实收到了这六条告警，如下图：

在这里插入图片描述

在目标邮箱中查看，也收到了关于这六条告警的通知，如下图：
在这里插入图片描述

钉钉告警

Alertmanager目前还不支持直接向钉钉发送通知，需要借助一个代理程序webhook-dingtalk实现，其流程大概如下图所示：
在这里插入图片描述

钉钉创建群组和群组机器人

在钉钉群聊的群设置中选择机器人管理，然后点击添加机器人
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
最后会得到一个webhook地址，包含access-token，请妥善保存，避免泄露之后别人利用此地址发送垃圾信息

部署webhook-dingtalk

webhook-dingtalk项目地址：https://github.com/timonwong/prometheus-webhook-dingtalk

下载安装包

wget https://github.com/timonwong/prometheus-webhook-dingtalk/releases/download/v2.1.0/prometheus-webhook-dingtalk-2.1.0.linux-amd64.tar.gz
tar xf prometheus-webhook-dingtalk-2.1.0.linux-amd64.tar.gz -C /usr/local/
ln -sv /usr/local/prometheus-webhook-dingtalk-2.1.0.linux-amd64 /usr/local/prometheus-webhook-dingtalk
 /usr/local/prometheus-webhook-dingtalk/prometheus-webhook-dingtalk -h	#查看帮助信息

准备service文件

root@prometheus-node-01:~# cat /lib/systemd/system/prometheus-webhook-dingtalk.service
[Unit]
Description=Prometheus Webhook Dingtalk
After=network.target


[Service]
Type=simple
User=root
Group=root
ExecStart=/usr/local/prometheus-webhook-dingtalk/prometheus-webhook-dingtalk --web.listen-address=":8060" --web.enable-ui --web.enable-lifecycle --config.file=/usr/local/prometheus-webhook-dingtalk/config.yml

Restart=on-failure

[Install]
WantedBy=multi-user.target

修改webhook-dingtalk配置文件

webhook-dingtalk安装包中默认提供了一个示例配置文件，根据此示例文件进行修改即可

 cd /usr/local/prometheus-webhook-dingtalk
 cp config.example.yml config.yml

配置文件内容如下，只定义了一个名为webhook1的钉钉接收人配置

targets:
  #url是前面创建群组机器人得到的webhook地址
  webhook1:
    url: https://oapi.dingtalk.com/robot/send?access_token=xxxxxxxxxxxxxxxxxxx

配置修改后，启动webhook-dingtalk

systemctl daemon-reload
systemctl start prometheus-webhook-dingtalk.service
systemctl status prometheus-webhook-dingtalk.service
systemctl enable prometheus-webhook-dingtalk.service

确保服务处于正常启动状态，无报错
在这里插入图片描述

配置Alertmanager

修改Alertmanager配置，添加一个告警接收者

global:
  resolve_timeout: 5m
  smtp_from: "1348937808@qq.com"
  smtp_smarthost: "smtp.qq.com:465"
  smtp_auth_username: "1348937808@qq.com"
  smtp_auth_password: "gzykyatpfkaifhbb"
  smtp_require_tls: false
  smtp_hello: "qq.com"

route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 2m
  repeat_interval: 1h
  receiver: 'dingtalk-webhook'	#将默认接收者也修改为dingtalk-webhook
receivers:
  - name: email-receiver
    email_configs:
    - send_resolved: true
      to: wangxian776@outlook.com
  # 添加dingtalk-webhook接收者
  - name: 'dingtalk-webhook'
    webhook_configs:
      #url中webhook1对应上边webhook-dingtalk配置中定义的webhook1
      - url: 'http://192.168.122.22:8060/dingtalk/webhook1/send'
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

修改完成后，重启Alertmanager

systemctl restart alertmanager

验证

重启Prometheus，让其重新构建node内存告警发送到Alertmanager，用来验证钉钉告警通知配置是否生效
在这里插入图片描述

Alertmanager界面上查看
在这里插入图片描述

钉钉群组也收到了对应的告警通知
在这里插入图片描述

企业微信告警

企业微信配置

在企业微信管理后台中选择应用管理–>创建应用
在这里插入图片描述
在这里插入图片描述
创建完成后，在应用详情界面可以获得一个AgentId和Secret（Secret点击查看会发送到企业微信），请妥善保存
在这里插入图片描述

配置Alertmanager

修改Alertmanager配置，添加企业微信接收者

global:
  resolve_timeout: 5m
  smtp_from: "xxxxx@qq.com"
  smtp_smarthost: "smtp.qq.com:465"
  smtp_auth_username: "xxxxx@qq.com"
  smtp_auth_password: "gzykyatpfkaifhbb"
  smtp_require_tls: false
  smtp_hello: "qq.com"

route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 2m
  repeat_interval: 1h
  receiver: 'wechat'	#默认接收者修改为wechat
receivers:
  - name: email-receiver
    email_configs:
    - send_resolved: true
      to: xxxxx@outlook.com
  - name: 'dingtalk-webhook'
    webhook_configs:
      - url: 'http://192.168.122.22:8060/dingtalk/webhook1/send'
  #添加微信接受者
  - name: "wechat"
    wechat_configs:
    - send_resolved: true
      api_secret: xxxxxxxxxxxxxxxxxxxxxxxxxxx	#上面在企业微信创建应用之后获取的Secret
      corp_id: ww4cc53bff288sdbff	#企业微信公司id，可以在企业微信管理后台获得
      agent_id: 1000002		#上面在企业微信创建应用之后获取的AgentId
      # to_user: '@all'		#如果需要发送给指定用户可以使用to_user，@all表示所有人
      to_party: 2	#发送给指定的部门，2代表部门ID，部门ID可以在企业微信管理后台获得
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

配置修改完成后重启Alertmanager

systemctl restart alertmanager

验证

重启Prometheus让其重新构建node内存告警发送到Alertmanager，用来验证企业微信告警通知配置是否生效
在这里插入图片描述

Alertmanager界面上查看

在这里插入图片描述

由于企业微信增加了对IP的限制，我所使用的IP不在可信IP之内，所以这里没有在企业微信收到告警信息。Alertmanager报错信息如下：
在这里插入图片描述

可以在之前创建的企业微信应用详情界面下选择添加可信IP解决此问题。但是由于我没有公司对应的域名进行校验，所以此处不在演示。
在这里插入图片描述

告警分类发送

告警分类发送就是利用Alertmanager配置文件中定义的告警路由规则匹配不同的告警然后发送给不同的接收者

groups:
  - name: alertmanager_pod.rules
    rules:
    - alert: Pod_all_cpu_usage
      expr: (sum by(name)(rate(container_cpu_usage_seconds_total{image!=""}[5m]))*100) > 10
      for: 2m
      labels:
        severity: critical
        type: pods
      annotations:
        description: 容器 {{ $labels.name }} CPU 资源利用率大于 10% , (current value is {{ $value }})
        summary: Dev CPU 负载告警

    - alert: Pod_all_memory_usage
      #expr: sort_desc(avg by(name)(irate(container_memory_usage_bytes{name!=""}[5m]))*100) > 10  #内存大于10%
      expr: sort_desc(avg by(name)(irate(node_memory_MemFree_bytes {name!=""}[5m]))) > 2*1024*1024*1024   #内存大于2G
      for: 2m
      labels:
        severity: critical
        type: pods
      annotations:
        description: 容器 {{ $labels.name }} Memory 资源利用率大于 2G , (current value is {{ $value }})
        summary: Dev Memory 负载告警

    - alert: Pod_all_network_receive_usage
      #expr: sum by (name)(irate(container_network_receive_bytes_total{container_name="POD"}[1m])) > 50*1024*1024
      expr: sum by (name)(irate(container_network_receive_bytes_total{namespace="default"}[1m])) > 300	#这里是为了便于触发告警才设置为大于300字节
      for: 1m
      labels:
        severity: critical
        type: pods
      annotations:
        description: 容器 {{ $labels.name }} network_receive 资源利用率大于 50M , (current value is {{ $value }})

    - alert: node_memory_alert
      expr: node_memory_MemFree_bytes < 524288000 #内存小于500兆
      for: 1m
      labels:
        component: memory
        type: nodes
      annotations:
        description: node节点可用内存小于500M

以上面的Prometheus rule文件为例，假如要实现将节点告警发送到钉钉，Pod告警发送至邮件。可以修改Alertmanager规则，添加如下告警路由规则实现：

global:
  resolve_timeout: 5m
  smtp_from: "xxxxxxx@qq.com"
  smtp_smarthost: "smtp.qq.com:465"
  smtp_auth_username: "xxxxxxx@qq.com"
  smtp_auth_password: "gzykyatpfkaifhbb"
  smtp_require_tls: false
  smtp_hello: "qq.com"

route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 2m
  repeat_interval: 1h
  receiver: 'wechat'
  #添加子路由规则设置
  routes:
  #子路由规则1，匹配告警中type标签，如果标签值为pods，将告警通知发送至dingtalk-webhook接收者	
  - matchers:
    - type = pods
    receiver: 'dingtalk-webhook'
  #子路由规则2，匹配告警中type标签，如果标签值为nodes，将告警通知发送至email-receiver接收者	
  - matchers:
    - type = nodes
    receiver: 'email-receiver'
receivers:

  - name: 'email-receiver'
    email_configs:
    - send_resolved: true
      to: xxxxxx@outlook.com
  - name: 'dingtalk-webhook'
    webhook_configs:
      - url: 'http://192.168.122.22:8060/dingtalk/webhook1/send'
  - name: "wechat"
    wechat_configs:
    - send_resolved: true
      api_secret: xxxxxxxxxx
      corp_id: xxxxxxxxxx
      agent_id: 1000002
      #to_user: '@all'
      to_party: 2
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

将Prometheus rule文件应用到Prometheus，再修改Alertmanager配置，然后重启Prometheus和Alertmanager进行验证

在Prometheus上查看告警
在这里插入图片描述

Alertmanager上查看
在这里插入图片描述

钉钉收到关于容器的告警
在这里插入图片描述

邮件收到关于节点的告警
在这里插入图片描述

自定义消息模板

默认通知消息比较杂乱，可以定义模板，对其进行格式化，便于阅读

消息模板的官方文档：https://prometheus.io/docs/alerting/latest/notifications/ https://prometheus.io/docs/alerting/latest/notification_examples/

模板使用的是go text/template语法

以企业微信为例，消息模板文件可以定义为如下所示：

#定义一个名为wechat.user_defined.message的块
{{ define wechat.user_defined.message }}
{{ range $i, $alert :=.Alerts }}
===alertmanager监控报警===
告警状态: {{ .Status }}
告警级别: {{ $alert.Labels.severity }}
告警类型: {{ $alert.Labels.alertname }}
告警应用: {{ $alert.Annotations.summary }}
故障主机: {{ $alert.Labels.instance }}
告警主题: {{ $alert.Annotations.summary }}
触发阀值: {{ $alert.Annotations.value }}
告警详情: {{ $alert.Annotations.description }}
触发时间: {{ $alert.StartsAt.Format "2006-01-02 15:04:05" }}
===========end============
{{ end }}
{{ end }}

修改Alertmanager配置，加载改模板文件，并引用wechat.user_defined.message

global:
  resolve_timeout: 5m
  smtp_from: "xxxxx@qq.com"
  smtp_smarthost: "smtp.qq.com:465"
  smtp_auth_username: "xxxxx@qq.com"
  smtp_auth_password: "gzykyatpfkaifhbb"
  smtp_require_tls: false
  smtp_hello: "qq.com"

#配置加载指定的模板文件
templates:
  - "/usr/local/alertmanager/templates/wechat-messsage-template.templ"

route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 2m
  repeat_interval: 1h
  receiver: 'wechat'
  routes:
  - matchers:
    - type = pods
    receiver: 'dingtalk-webhook'
  - matchers:
    - type = nodes
    receiver: 'wechat'
receivers:
  - name: 'email-receiver'
    email_configs:
    - send_resolved: true
      to: xxxxxx@outlook.com
  - name: 'dingtalk-webhook'
    webhook_configs:
      - url: 'http://192.168.122.22:8060/dingtalk/webhook1/send'
  - name: "wechat"
    wechat_configs:
    - send_resolved: true
      api_secret: xxxxxxxxxxxxxx
      corp_id: ww4cc53bff288asbff
      agent_id: 1000002
      #to_user: '@all'
      to_party: 2
      message: '{{ template "wechat.user_defined.message" . }}'		#指定发送消息时引用的模板
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

最后收到的消息大概如下图所示：
在这里插入图片描述

告警抑制

在Prometheus的rule文件中添加下面两条规则用于验证告警抑制：

    #磁盘分区使用率超过%60告警规则
    - alert: node_disk_alert
      expr: 100 - node_filesystem_avail_bytes{fstype=~"xfs|ext4"} / node_filesystem_size_bytes{fstype=~"ext4|xfs"} * 100 > 60
      for: 30s
      labels:
        type: nodes
        component: disk
        severity: critical
      annotations:
        summary: "{{ $labels.mountpoint }} 磁盘分区使用率过高！"
        description: "{{ $labels.mountpoint }} 磁盘分区使用大于 60%(目前使用:{{ $value }}%)"
	 #磁盘分区使用率超过%60告警规则
    - alert: node_disk_alert
      expr: 100 - node_filesystem_avail_bytes{fstype=~"xfs|ext4"} / node_filesystem_size_bytes{fstype=~"ext4|xfs"} * 100 > 40
      for: 30s
      labels:
        type: nodes
        component: disk
        severity: warning
      annotations:
        summary: "{{ $labels.mountpoint }} 磁盘分区使用率过高！"
        description: "{{ $labels.mountpoint }} 磁盘分区使用大于 40%(目前使用:{{ $value }}%)"

重启Prometheus，应用rule文件

systemctl restart prometheus

然后修改Alertmanager配置，添加抑制规则

global:
.......
#告警抑制规则配置
inhibit_rules:
  - source_match:	#如果两条告警标签alertname、instance、mountpoint值相等的，只发送critical级别的告警，不发送warning级别的
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'instance', 'mountpoint']

修改完成后，重启Alertmanager

systemctl restart alertmanager

在一个节点上使用dd写一个大文件，让根分区使用率超过%60
在这里插入图片描述

等待一段时间验证告警，
在这里插入图片描述
在这里插入图片描述

最后在邮箱中查看，可以看到只收到一条磁盘使用率超过%60的告警通知，没有%40的通知
在这里插入图片描述

告警静默

针对于在Alertmanager上已存在的告警，可以直接选择静默
在这里插入图片描述

在这里插入图片描述

静默之后可以在Alertmanager界面查到对应的记录，如果需要提前结束静默可以可以点击Expire结束
在这里插入图片描述

如果是针对还未触发过的告警进行静默，可以直接创建一个新的Silence记录，但需要手动添加标签来匹配告警
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/366183.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

Elasticsearch 基础（三）之相关术语概念及原理

Elasticsearch 基础（三）之相关术语概念及原理

目录前言一、集群1、相关术语概念1.1、集群&#xff08;Cluster&#xff09;1.2、节点&#xff08;Node&#xff09;1.3、角色&#xff08;Roles&#xff09;1.4、分片&#xff08;Shard&#xff09;2、集群场景及原理2.1、集群健康2.2、空节点2.3、单节点2.4、集群追加节点2.5…
阅读更多...
【GeoDjango框架解析——读取矢量数据写入postgis数据库】

【GeoDjango框架解析——读取矢量数据写入postgis数据库】

系列文章目录 提示&#xff1a;这里可以添加系列文章的所有文章的目录&#xff0c;目录需要自己手动添加 geodjango框架解析之读取矢量数据shp文件写入postgis数据库 提示&#xff1a;写完文章后&#xff0c;目录可以自动生成&#xff0c;如何生成可参考右边的帮助文档 文章目录…
阅读更多...
我记不住的那些maven内容

我记不住的那些maven内容

背景&#xff1a; 之前使用maven都是基于IDE并且对maven本身也很少究其过程和原理&#xff0c;当出现问题也不知道如何解决&#xff0c;后续想使用命令行来进行操作&#xff0c;并通过文档记录一下学习的内容加深理解以防止忘记。 一、简要介绍 maven是通过插件来增强功能&am…
阅读更多...
项目经理该怎样做好项目质量管理工作？

项目经理该怎样做好项目质量管理工作？

项目经理做好项目质量管理工作&#xff0c;重点需要关注以下几个方面&#xff1a; 1、质量产生于过程 需要成熟稳定的软件过程 软件项目质量产生于开发过程&#xff0c;要想真正提高软件质量&#xff0c;必须有一个成熟而稳定的软件过程。如因特殊原因造成的过程性能不稳定&…
阅读更多...
自动化测试框架pytest教程(一)pytest用例编写和pytest前后置方法

自动化测试框架pytest教程(一)pytest用例编写和pytest前后置方法

自动化测试框架pytest教程(一)pytest用例编写和pytest前后置方法 目录&#xff1a;导读 一、入门使用 1、环境安装 2、用例编写 3、执行测试 二、前后置方法和fixture机制 1、xunit风格的前后置方法 函数用例的前后置方法 测试类中用例的前后置方法 模块级别的前后置…
阅读更多...
Tekton实战案例--S2I

Tekton实战案例--S2I

案例环境说明 示例项目&#xff1a; 代码仓库&#xff1a;https://gitee.com/mageedu/spring-boot-helloWorld.git 构建工具maven pipeline各Task git-clone&#xff1a;克隆项目的源代码 build-to-package: 代码测试&#xff0c;构建和打包 generate-build-id&#xff1a;生…
阅读更多...
valgrind 移植到arm64 平台上总结

valgrind 移植到arm64 平台上总结

valgrind 介绍valgrind是查找内存泄漏的神器&#xff0c;你可以自动的检测许多内存管理和线程的bug&#xff0c;避免花费太多的时间在bug寻找上&#xff0c;使得你的程序更加稳固。 下载地址&#xff1a;https://valgrind.org/downloads/ 本人下载的是valgrind-3.19.0valgrind编…
阅读更多...
【Java基础 下】 026 -- 集合进阶（不可变集合、Stream流、方法引用）

【Java基础 下】 026 -- 集合进阶（不可变集合、Stream流、方法引用）

目录 一、不可变集合 1、创建不可变集合的应用场景 2、创建不可变集合的书写格式 ①、不可变的List集合 ②、不可变的Set集合 ③、不可变的Map集合 3、小结 二、Stream流 1、体验Stream流的作用 2、Stream流的思想 3、Stream流的使用步骤 ①、单列集合获取Stream流 ②、双列集合…
阅读更多...
面试 | 递归乘法【细节决定成败】

面试 | 递归乘法【细节决定成败】

不用[ * ]如何使两数相乘❓一、题目明细二、思路罗列 & 代码解析1、野蛮A * B【不符合题意】2、sizeof【可借鉴】解析3、简易递归【推荐】① 解析&#xff08;递归展开图&#xff09;② 时间复杂度分析4、移位<<运算【有挑战性&#x1f4aa;】① 思路顺理② 算法图解…
阅读更多...
消息队列的介绍

消息队列的介绍

1.什么时候会用到消息队列&#xff1f; 公司本身业务小&#xff0c;可以做单体的&#xff0c;但是后面业务体量不断扩大&#xff0c;采用微服务的设计思想&#xff0c;分布式的部署方式&#xff0c;所以拆分了很多的服务&#xff0c;随着体量的增加以及业务场景越来越复杂了&a…
阅读更多...
SCG failure information

SCG failure information

我们知道5G网络有独立组网和非独立组网&#xff0c;独立组网中不论是核心网还是接入网都是5G&#xff0c;但是部署成本高&#xff1b;非独立组网也就是双连接(MRDC)也是目前比较流行的一种方式&#xff0c;其中的ENDC&#xff0c;即E-UTRA-NRDual Connectivity&#xff0c;是将…
阅读更多...
Apifox-比postman更优秀的接口自动化测试平台

Apifox-比postman更优秀的接口自动化测试平台

一、Apifox介绍 Apifox 是 API 文档、API 调试、API Mock、API 自动化测试一体化协作平台&#xff0c;定位 Postman Swagger Mock JMeter。通过一套系统、一份数据&#xff0c;解决多个系统之间的数据同步问题。只要定义好 API 文档&#xff0c;API 调试、API 数据 Mock、A…
阅读更多...
如何将Linux的NIC 名称更改为 eth0 而不是 enps33 或 enp0s25，只要几秒钟

如何将Linux的NIC 名称更改为 eth0 而不是 enps33 或 enp0s25，只要几秒钟

概述 我们使用Linux系统&#xff0c;网卡名称通常都是eth0&#xff0c;但是有一些新的linux发行版&#xff0c;网卡名字 enps33 或 enp0s25。 pengubuntu:~$ ifconfig ens33 Link encap:Ethernet HWaddr 00:0c:29:fd:4d:3a inet addr:192.168.0.113 Bcast:192.168.0.…
阅读更多...
[NOIP2002 普及组] 过河卒

[NOIP2002 普及组] 过河卒

题目描述&#xff1a; 棋盘上 A 点有一个过河卒&#xff0c;需要走到目标 B 点。卒行走的规则&#xff1a;可以向下、或者向右。同时在棋盘上 C 点有一个对方的马&#xff0c;该马所在的点和所有跳跃一步可达的点称为对方马的控制点。因此称之为“马拦过河卒”。 棋盘用坐标表…
阅读更多...
上海亚商投顾：沪指窄幅震荡 ChatGPT概念股全线下挫

上海亚商投顾：沪指窄幅震荡 ChatGPT概念股全线下挫

上海亚商投顾前言&#xff1a;无惧大盘涨跌&#xff0c;解密龙虎榜资金&#xff0c;跟踪一线游资和机构资金动向&#xff0c;识别短期热点和强势个股。市场情绪三大指数早盘小幅冲高&#xff0c;随后又震荡走低&#xff0c;午后一度集体翻绿&#xff0c;临近尾盘有所回升。Chat…
阅读更多...
kettle使用--1.mysql多表关联导入mongoDB

kettle使用--1.mysql多表关联导入mongoDB

文章目录1. 初步体验&#xff1a;csv 转为excelKettle概念配置mysql链接mysql 一对多关联查询结果保存到mongodb中1. 初步体验&#xff1a;csv 转为excel Windows环境下安装pdi-ce-8.0.0.0-28.zip &#xff0c;解压后执行lib下的Spoon.bat 将csv输入拖入 双击拖进去的csv&…
阅读更多...
无聊小知识02.Junit4Junit5对比

无聊小知识02.Junit4Junit5对比

Junit是Java编程语言的单元测试框架&#xff0c;用来编写单元测试代码。随着Junit5的盛行&#xff0c;与Junit4有何差异。JDK支持Junit4需要Java5版本Junit5需要Java8版本Maven依赖Junit4不区分模块&#xff0c;只有一个jar&#xff1a;<dependency><groupId>junit…
阅读更多...
【Linux】工具（1）——yum

【Linux】工具（1）——yum

好久不见&#xff0c;让大家久等啦~最近开学被一系列琐事所耽误了&#xff0c;接下来会进入稳定更新状态~话不多说&#xff0c;在我们了解Linux基本内容之后&#xff0c;我们的目的是要在Linux环境下进行软硬件开发&#xff0c;在这个过程中我们会用到一系列工具&#xff0c;例…
阅读更多...
知识蒸馏论文阅读：LD算法笔记

知识蒸馏论文阅读：LD算法笔记

标题&#xff1a;Localization Distillation for Dense Object Detection 会议&#xff1a;CVPR2022 论文地址&#xff1a;https://ieeexplore.ieee.org/document/9878414/ 官方代码&#xff1a;https://github.com/HikariTJU/LD 作者单位&#xff1a;南开大学、天津大学、哈尔…
阅读更多...
uniapp本地存储

uniapp本地存储

uniapp本地存储 vue的本地存储方式, 小程序在浏览器测试时也可以实现, 但是在真机运行时不能实现 一. 存储 1.uni.setStorage(OBJECT) 将数据存储在本地缓存中指定的key中, 会覆盖掉原来该key对应的内容, 这是一个异步接口 OBJECT参数示例 uni.setStorage({key:"token&qu…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023