Alertmanager告警配置

已于 2024-07-11 17:02:24 修改
阅读量1.4k 收藏 28
点赞数 18
分类专栏： Prometheus 文章标签： linux 运维 prometheus
于 2024-07-11 16:58:30 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/arrogantb/article/details/140356598
版权

1、告警概述及说明

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

当Alertmanager接收到 Prometheus 端发送过来的 Alerts 时，Alertmanager 会对 Alerts 进行去重复，分组，按标签内容发送不同报警组，包括：邮件，微信，Webhook。AlertManager还提供了静默和告警抑制机制来对告警通知行为进行优化。

2、Alertmanager告警特性

  • 去重
    • 将多个相同的告警,去掉重复的告警,只保留不同的告警
  • 分组
    • 分组机制可以将详细的告警信息合并成一个通知。在某些情况下，比如由于系统宕机导致大量的告警被同时触发，在这种情况下分组机制可以将这些被触发的告警合并为一个告警通知，避免一次性接受大量的告警通知，而无法对问题进行快速定位。
    • 告警分组，告警时间，以及告警的接受方式可以通过Alertmanager的配置文件进行配置。
  • 路由
    • 将不同的告警定制策略路由发送至不同的目标
  • 抑制
    • 抑制可以避免当某种问题告警产生之后用户接收到大量由此问题导致的一系列的其它告警通知，同样通过Alertmanager的配置文件进行设置。
  • 静默
    • 静默提供了一个简单的机制可以快速根据标签对告警进行静默处理。如果接收到的告警符合静默的
  • 配置，Alertmanager则不会发送告警通知。
    • 静默设置需要在Alertmanager的Web页面上进行设置。

3、安装配置

3.1、部署alertmanager

测试结果测试结果#获取软件
wget
https://github.com/prometheus/alertmanager/releases/download/v0.23.0/alertmanage
r-0.23.0.linux-amd64.tar.gz

#解压软件
tar xf alertmanager-0.23.0.linux-amd64.tar.gz -C /usr/local/
ln -s /usr/local/alertmanager-0.23.0.linux-amd64 /usr/local/alertmanager

#准备工作
cd /usr/local/alertmanager

### 进行配置文件修改
vim alertmanager.yml

# 全局配置
global:
  resolve_timeout: 5m #处理超时时间，默认为5分钟
  smtp_smarthost: 'smtp.qq.com:465' # smtp_smarthost: 使用email打开服务配置
  smtp_from: '1724720581@qq.com'    # smtp_from：指定通知报警的邮箱
  smtp_auth_username: '1724720581@qq.com'   # smtp_auth_username：邮箱用户名
  smtp_auth_password: 'vjvcszllefanbcjd' # 这里是邮箱的授权密码，不是登录密码
  smtp_require_tls: false
templates:   # 定义模板
  - '/usr/local/alertmanager/template/*.tmpl'
# 路由配置
route:
  group_by: ['alertname', 'cluster', 'service']   # 传入报警分组在一起的标签
  group_wait: 10s    # 这个参数设置了在发送第一批警报之后，Alertmanager 等待新警报加入现有组的时间。此处 group_wait 被设置为 10 秒。如果在 10 秒内没有新的警报加入组，那么这个组的警报将被发送出去。
  group_interval: 10s    # 发送组警报的时间间隔
  repeat_interval: 30m   # 对同一个警报组的重复通知之间的时间间隔 对于email配置中，此项不可以设置过低，否则将会由于邮件发送太多频繁，被smtp服务器拒绝
  receiver: default-receiver  # 发送警报的接收者的名称
# 收信人员
receivers:
- name: 'email'
  email_configs:
  - to: '1724720581@qq.com'
    send_resolved: true   #问题解决后也会发送告警
    html: '{{ template "default.html" . }}'   #添加此行,调用模板显示邮件正文
    headers: { Subject: "[WARN] 报警邮件" }   #添加此行,定制邮件标题
# 抑制规则
inhibit_rules:
- source_match:
    severity: 'critical'
  target_match:
    severity: 'warning'
  equal: ['alertname', 'dev', 'instance']


#属性解析：repeat_inerval配置项，用于降低告警收敛，减少报警，发送关键报警，对于email来说，此
项不可以设置过低，否则将会由于邮件发送太多频繁，被smtp服务器拒绝

{{}} 属性用于加载其它信息，所以应该使用单引号括住
{} 不需要使用单引号，否则服务启动不成功
AlertManager配置介绍
1、配置文件概述

在上面的部分中已经简单介绍过，在Alertmanager中通过路由(Route)来定义告警的处理方式。路由是一个基于标签匹配的树状匹配结构。根据接收到告警的标签匹配相应的处理方式。这里将详细介绍路由相关的内容。

Alertmanager主要负责对Prometheus产生的告警进行统一处理，因此在Alertmanager配置中一般会 包含以下几个主要部分:

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

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

2、route 告警路由与告警分组

        对于不同级别的告警，我们可能有不同的处理方式，因此在route中，我们还可以在routes中定义更多的子route（不同的match和receiver等信息）。

route的完整配置如下：

route:
  receiver: <string>     # 根路由，默认的告警接收器，对应receiver配置中的name
  group_by: [' <labelname>, ... ']  # 可通过prometheus告警规则中的标签名称将告警进行分组（alertmanager将同组告警合并一起发送，例如一封邮件通知包含2个告警信息）；group_by:['…'] 禁用分组聚合
  group_wait: <duration> | default = 30s  # 30s内接收到的同组的告警，会合并成一个通知向receiver发送
  group_interval: <duration> | default = 5m  # 相同的组之间发送告警通知的时间间隔（同组告警的发送间隔）
  repeat_interval: <duration> | default = 4h  # 未恢复的告警重复发送的时间间隔（告警升级）
  
####################
  routes:  # 下面配置所有子路由（根路由的配置，若子路由未定义，则会使用根路由配置；子路由有的配置，以子路由为准）
  - receiver: '<string>' # 指定告警接收器，对应receiver配置中的name
    group_by: [' <labelname>, ... ']
    match: # 匹配器
      [ <labelname>: <labelvalue>, ... ]  # 匹配prometheus告警规则中的label
    match_re: # 正则匹配器
      [ <labelname>: <regex>, ... ]  # 使用正则表达式匹配prometheus告警规则中的label
    matchers: # 一个匹配器列表，必须满足该列表所有匹配规则
      [ - <matcher> ... ]
    [ continue: <boolean> | default = false ]  # 是否继续匹配后续的子route规则，true/false
    mute_time_intervals:  # 路由被静音的次数。这些必须与mute_time_interval部分中定义的静音时间间隔的名称相匹配。根节点不能设置静音时间。当路由被静音时，它将不发送任何通知，但其他方面正常运行(包括如果未设置“continue”选项，则结束路由匹配过程)。
      [ - <string> ...]
    active_time_intervals:  # 路由激活的次数。这些必须与time_interval部分中定义的时间间隔名称相匹配。空值表示该路由始终处于活动状态。此外，根节点不能有任何活动时间。路由只有在激活时才会发送通知，否则会正常运行(包括在未设置“continue”选项时结束路由匹配过程)。
      [ - <string> ...]

路由匹配规则：

        每一个告警都会从配置文件中顶级的route进入路由树，需要注意的是顶级的route必须匹配所有告警 (即不能有任何的匹配设置match和match_re)，每一个路由都可以定义自己的接收人以及匹配规则。默认情况下，告警进入到顶级route后会遍历所有的子节点，直到找到最深的匹配route，并将告警发送到 该route定义的receiver中。但如果route中设置continue的值为false，那么告警在匹配到第一个子节点之后就直接停止。如果continue为true，报警则会继续进行后续子节点的匹配。如果当前告警匹配不到任何的子节点，那该告警将会基于当前路由节点的接收器配置方式进行处理。

        对Prometheus告警规则的匹配有两种方式可以选择。一种方式基于字符串验证，通过设置match规则判断当前告警 中是否存在标签labelname并且其值等于labelvalue。第二种方式则基于正则表达式，通过设置 match_re验证当前告警标签的值是否满足正则表达式的内容。

        如果警报已经成功发送通知, 如果想设置重复发送告警通知之前的等待时间，则可以通过repeat_interval 参数进行设置。（告警升级）

        注意根路由的配置，若子路由未定义，则子路由会带上该根路由的配置

        Alertmanager可以对告警通知进行分组，将多条告警合并为一个通知。使用group_by来定义分组规则，基于prometheus告警规则中的标签名称。

配置案例：

route:
  receiver: 'default-receiver'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  group_by: [cluster, alertname]
 
  routes:
  - receiver: 'database-pager'
    #group_by: [alertname]
    group_wait: 10s
    matchers:
    - service=~"mysql|cassandra"
 
  - receiver: 'frontend-pager'
    group_by: [product, environment]
    matchers:
    - team="frontend"
 
  - receiver: 'dev-pager'
    matchers:
      - service="inhouse-service"
    mute_time_intervals:
      - offhours
      - holidays
    continue: true
 
  - receiver: 'on-call-pager'
    matchers:
      - service="inhouse-service"
    active_time_intervals:
      - offhours
      - holidays

3.2、配置快速启动文件

cat > /usr/lib/systemd/system/alertmanager.service << EOF
 
[Unit]
Description=alertmanager server daemon
Documentation=https://prometheus.io/docs/introduction/overview/
After=network.target
 
[Service]
ExecStart=/usr/local/alertmanager/alertmanager --config.file=/usr/local/alertmanager/alertmanager.yml --storage.path=/usr/local/alertmanager/data
ExecReload=/bin/kill -HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
 
[Install]
WantedBy=multi-user.target

EOF

#######
# 重新加载配置
systemctl daemon-reload
systemctl start alertmanager.service
systemctl status alertmanager.service

3.3、进行Prometheus配置

mkdir /usr/local/prometheus/rules/


#修改配置文件，加载alertmanager配置属性
vim /usr/local/prometheus/prometheus.yml
#######    
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - localhost:9093
    
rule_files:
   - /usr/local/prometheus/rules/*.rules # 规则配置文件   

#注意：alertmanager服务启动时候的监控开放主机地址必须保证正确，否则服务启动不起来
   
#重启prometheus
systemctl restart prometheus.service

3.4、配置告警规则

告警规则可以参考：https://samber.github.io/awesome-prometheus-alerts/rules，并根据自己的需要进行修改

vim /usr/local/prometheus/rules/hoststats-alert.rules1

groups:  # 告警组 对一组相关的告警进行统一定义，下面可定义多个告警规则
- name: flask_web
  rules:
    - alert: diskFree # 告警规则的名称
      expr:  (1-(node_filesystem_free_bytes{fstype=~"ext4|xfs"} / node_filesystem_size_bytes{fstype=~"ext4|xfs"}) ) * 100 > 5 # 告警的判定条件，参考PromQL高级查询来设定
      for: 1m # 满足告警条件持续时间多久后，才会发送告警
      labels: #标签项，定义告警级别
        severity: page
      annotations: # 解析项，详细解释告警信息;在告警产生时会一同作为参数发送到alertmanager
        summary: "Instance {{ $labels.instance }} down"  #摘要
        description:  "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."  #描述
        value: "{{$value}}"   

#属性解析：
{{ $labels.<labelname> }} 要插入触发元素的标签值
{{ $value }} 要插入触发元素的数值表达式值，会从prometheus的默认信息中获取阈值
这里的$name 都是来源于模板文件中的定制内容，如果不需要定制的变动信息，可以直接写普通的字符串
#annotations这部分内容不再显示邮件中,而按模板形式显示

#### 配置完成后重启服务
systemctl restart prometheus.service

一般来说，在告警规则文件的annotations中使用summary描述告警的概要信息， description用于描述告警的详细信息。同时Alertmanager的UI也会根据这两个标签值，显示告警信息。为了让告警信息 具有更好的可读性，Prometheus支持模板化label和annotations的中标签的值。

通过变量 $labels.<labelname> 可以访问当前告警实例中指定标签的值。$value则可以获取当前 PromQL表达式计算的样本值。

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

  • 告警名称：用户需要为告警规则命名，当然对于命名而言，需要能够直接表达出该告警的主要内容
  • 告警规则：告警规则实际上主要由PromQL进行定义，其实际意义是当表达式（PromQL）查询结果持续多长时间（During）后出发告警

3.5、 验证结果

可以在浏览器查看rules的页面，http://192.168.255.120:9090/rule

可以在浏览器查看告警界面效果，http://192.168.255.120:9090/alert

告警状态

  • Inactive：正常效果
  • Pending：已触发阈值，但未满足告警持续时间（即rule中的for字段）
  • Firing：已触发阈值且满足告警持续时间。

3.6、定制模板

#建立邮件模板文件
cd /usr/local/alertmanager/template
vim default.tmpl


{{ define "default.html" }}
{{- if gt (len .Alerts.Firing) 0 -}}
[{{ .Status | toUpper }}:{{ .Alerts.Firing | len }}]
{{ range $i, $alert := .Alerts }}
<pre>
告警主机：{{ index $alert.Annotations "summary" }}
告警区域: 非生产环境
告警服务：{{ index $alert.Labels "alertname" }}
报警详情：{{ index $alert.Annotations "description" }}
开始时间：{{ $alert.StartsAt }}
</pre>
{{ end }}
{{ end }}
{{- if gt (len .Alerts.Resolved) 0 -}}
[{{ .Status | toUpper }}:{{ .Alerts.Resolved | len }}]
{{ range $i, $alert := .Alerts }}
<pre>
恢复主机：{{ index $alert.Annotations "summary" }}
恢复区域：非生产环境
恢复服务：{{ index $alert.Labels "alertname" }}
状    态：{{ index $alert.Status }} {{ index $alert.Annotations "resolved" }}
开始时间：{{ $alert.StartsAt }}
恢复时间：{{ $alert.EndsAt }}
</pre>
{{ end }}
{{ end }}
{{- end }}

#属性解析
{{ define "default.html" }} 表示定义了一个 default.html 模板文件，通过该名称在配置文件中应用。
$alert.xxx 其实是从默认的告警信息中提取出来的重要信息

3.7、查看邮箱

#重启服务

systemctl restart alertmanager.service

4、templates 告警通知模板详解

默认的告警信息界面有些简单，可以借助于告警的模板信息，对告警信息进行丰富。需要借助于alertmanager的模板功能来实现。

使用流程：

  • 分析关键信息
  • 定制模板内容
  • alertmanager 加载模板文件
  • 告警信息使用模板内容属性

范例1：

vim  /usr/local/alertmanager/template/email.tmpl
#基于jin2的模板内容
cat email.tmpl
{{ define "email.html" }}
<table border="1">
       <tr>
               <th>报警项</th>
               <th>实例</th>
               <th>报警阀值</th>
               <th>开始时间</th>
       </tr>
       {{ range $i, $alert := .Alerts }}
               <tr>
                       <td>{{ index $alert.Labels "alertname" }}</td>
                       <td>{{ index $alert.Labels "instance" }}</td>
                       <td>{{ index $alert.Annotations "value" }}</td>
                       <td>{{ $alert.StartsAt }}</td>
               </tr>
       {{ end }}
</table>
{{ end }}
#属性解析
{{ define "test.html" }} 表示定义了一个 test.html 模板文件，通过该名称在配置文件中应用
上边模板文件就是使用了大量的jinja2模板语言。
$alert.xxx 其实是从默认的告警信息中提取出来的重要信息

应用模版：

vim /usr/local/alertmanager/conf/alertmanager.yml

html: '{{ template "email.html" . }}'   #添加此行,调用模板显示邮件正文
   
#重启服务
# systemctl restart alertmanager.service

测试：

范例2：

vim  /usr/local/alertmanager/template/test.tmpl

{{ define "test.html" }}
{{- if gt (len .Alerts.Firing) 0 -}}
[{{ .Status | toUpper }}:{{ .Alerts.Firing | len }}]
{{ range $i, $alert := .Alerts }}
<pre>
告警名称: {{ index $alert.Labels "alertname" }}
实例名: {{ index $alert.Labels "instance" }}
摘要:  {{ index $alert.Annotations "summary" }}
详情:  {{ index $alert.Annotations "description" }}
开始时间:  {{ $alert.StartsAt }}
</pre>
{{ end }}
{{ end }}
{{- if gt (len .Alerts.Resolved) 0 -}}
[{{ .Status | toUpper }}:{{ .Alerts.Resolved | len }}]
{{ range $i, $alert := .Alerts }}
<pre>
Resolved-告警恢复了
告警名称: {{ index $alert.Labels "alertname" }}
摘要:  {{ index $alert.Annotations "summary" }}
详情:  {{ index $alert.Annotations "description" }}
开始时间:  {{ $alert.StartsAt }}
恢复时间:  {{ $alert.EndsAt }}
</pre>
{{ end }}
{{ end }}
{{- end }}

应用模版：

vim /usr/local/alertmanager/conf/alertmanager.yml

html: '{{ template "test.html" . }}'   #添加此行,调用模板显示邮件正文
   
#重启服务
# systemctl restart alertmanager.service

测试：

5、inhibit_rules 抑制规则详解

Alertmanager提供了方式可以帮助用户控制告警抑制通知的行为，包括预先定义的抑制机制和临时定义的静默规则。

对于一种业务场景，有相互依赖的两种服务：A服务和B服务，一旦A服务异常，依赖A服务的B服务也会异常,从而导致本来没有问题的B服务也不断的发出告警。

Alertmanager的抑制机制可以避免当某种问题告警产生之后用户接收到大量由此问题导致的一系列的其它告警通知。例如当集群不可用时，用户可能只希望接收到一条告警，告知用户这时候集群出现了问题，而不是大量的如集群中的应用异常、中间件服务异常的告警通知。当已经发送的告警通知匹配到target_match和target_match_re规则，当有新的告警规则如果满足source_match或者定义的匹配规则，并且已发送的告警与新产生的告警中equal定义的标签完全相同，则启动抑制机制，新的告警不会发送。

在Alertmanager配置文件中，使用inhibit_rules定义一组告警的抑制规则:

inhibit_rules:

[ - <inhibit_rule> ... ]

每一条抑制规则的具体配置如下：

source_match:  # 源告警匹配器
  [ <labelname>: <labelvalue>, ... ]
 
source_match_re: # 源告警正则匹配器
  [ <labelname>: <regex>, ... ]
 
source_matchers: # 源告警匹配器列表，需要全满足
  [ - <matcher> ... ]
 
target_match: # 目标告警匹配器
  [ <labelname>: <labelvalue>, ... ]
 
target_match_re: # 目标告警正则匹配器
  [ <labelname>: <regex>, ... ]
 
target_matchers: # 目标告警匹配器列表，需要全满足
  [ - <matcher> ... ]
 
[ equal: '[' <labelname>, ... ']' ] # 在源和目标告警中必须具有相等值的标签

以下3个条件同时满足，则启动抑制机制，新的告警不会发送。

  • 当已经发送的告警通知匹配 source_match 规则
  • 有新的告警满足 target_match 匹配规则
  • 并且已发送的告警与新产生的告警中，equal定义的标签完全相同

注意：

1、在语义上，缺失的标签和空值的标签是相同的意思。因此，如果在源警报和目标警报中， equal 中列出的所有标签名称都不存在，也会启动抑制规则。

2、为了防止警报抑制自身，建议 target_match 和 source_match 一般不要设置的一样。

配置案例：

例如：
集群中的A主机节点异常导致NodeDown告警被触发，该告警会触发一个severity=critical的告警级别。
由于A主机异常导致该主机上相关的服务，会因为不可用而触发关联告警。
根据抑制规则的定义：
如果有新的告警级别为severity=critical，且告警中标签的node值与NodeDown告警的相同
则说明新的告警是由NodeDown导致的，则启动抑制机制停止向接收器发送通知。


inhibit_rules: # 抑制规则
- source_match:     # 源标签警报触发时抑制含有目标标签的警报
   alertname: NodeDown # 可以针对某一个特定的告警动作规则
   severity: critical # 限定源告警规则的等级
 target_match:      # 定制要抑制的告警规则的所处位置
   severity: normal # 触发告警目标标签值的正则匹配规则，可以是正则表达式如: 
".*MySQL.*"
 equal: # 因为源告警和触发告警必须处于同一业务环境下，确保他们在同一个业务中
    - instance # 也就是说，源告警和触发告警存在相同的 instance值时，触发告警才会
被抑制。
   # 样式二 equal: ['alertname','operations', 'instance']
#表达式
 up{node="node01.wang.org",...} == 0
 severity: critical
#触发告警
 ALERT{node="node01.wang.org",...,severity=critical}

告警抑制案例

#准备告警规则
# cat /usr/local/prometheus/rules/prometheus_alert_inhibit.yml
groups:
- name: flask_web
 rules:
  - alert: InstanceDown
   expr: up{instance="10.0.0.101:8000",job="my_metric"} == 0
    for: 1m
   labels:
     severity: critical
   annotations:
     summary: "Instance {{ $labels.instance }} 停止工作"
     description: "{{ $labels.instance }} job {{ $labels.job }} 已经停止1分钟以
上"
     value: "{{$value}}"
- name: flask_QPS
 rules:
  - alert: InstanceQPSIsHight
   expr: 
sum(increase(request_count_total{instance="10.0.0.101:8000",job="my_metric"}
[1m])) > 500
    for: 1m
   labels:
     severity: warning
   annotations:
   summary: "Instance {{ $labels.instance }} QPS 持续过高"
     description: "{{ $labels.instance }} job {{ $labels.job }} QPS 持续过高"
     value: "{{$value}}"
  - alert: InstanceQPSIsLow
   expr: up{instance="10.0.0.101:8000",job="my_metric"} == 0
    for: 1m
   labels:
     severity: warning
   annotations:
     summary: "Instance {{ $labels.instance }} QPS 异常为零"
     description: "{{ $labels.instance }} job {{ $labels.job }} QPS 异常为0"
     value: "{{$value}}"
#定制告警对象
cat /usr/local/alertmanager/conf/alertmanager.yml
# 全局配置
global:
 resolve_timeout: 5m
 smtp_smarthost: 'smtp.qq.com:25'
 smtp_from: '29308620@qq.com'
 smtp_auth_username: '29308620@qq.com'
 smtp_auth_password: 'dgezyimkdswwbhe'
 smtp_hello: 'qq.com'
 smtp_require_tls: false
# 模板配置
templates:
  - '../tmpl/*.tmpl'
# 路由配置
route:
 group_by: ['instance', 'cluster']
 group_wait: 10s
 group_interval: 10s
 repeat_interval: 10s
 receiver: 'email'
 routes:
  - match:
     severity: critical
   receiver: 'admin-team'
  - match_re:
     severity: ^(warning)$
   receiver: 'supper-team'
# 收信人员
receivers:
- name: 'email'
 email_configs:
  - to: '29308620@qq.com'
   send_resolved: true
   html: '{{ template "test.html" . }}'
   headers: { Subject: "[WARN] 报警邮件"}
- name: 'admin-team'
 email_configs:
  - to: '29308620@qq.com'
   html: '{{ template "test.html" . }}'
   headers: { Subject: "[CRITICAL] 应用服务报警邮件"}
   send_resolved: true
- name: 'supper-team'
 email_configs:
  - to: '29308620@qq.com'
   html: '{{ template "test.html" . }}'
   headers: { Subject: "[WARNNING] QPS负载报警邮件"}
   send_resolved: true
#重启服务
systemctl restart prometheus.service alertmanager.service
#关停flask服务后，查看效果,显示有多个重复告警

启动抑制机制

#定制抑制
cat /usr/local/alertmanager/conf/alertmanager.yml
# 全局配置
global:
 resolve_timeout: 5m
 smtp_smarthost: 'smtp.qq.com:25'
 smtp_from: '29308620@qq.com'
 smtp_auth_username: '29308620@qq.com'
 smtp_auth_password: 'dgezyimkdswwbhe'
 smtp_hello: 'qq.com'
 smtp_require_tls: false
# 模板配置
templates:
  - '../tmpl/*.tmpl'
# 路由配置
route:
 group_by: ['instance', 'cluster']
 group_wait: 10s
 group_interval: 10s
 repeat_interval: 10s
 receiver: 'email'
 routes:
  - match:
     severity: critical
   receiver: 'admin-team'
  - match_re:
     severity: ^(warning)$
   receiver: 'supper-team'
# 收信人员
receivers:
- name: 'email'
 email_configs:
  - to: '29308620@qq.com'
   send_resolved: true
   html: '{{ template "test.html" . }}'
   headers: { Subject: "[WARN] 报警邮件"}
- name: 'admin-team'
 email_configs:
  - to: '29308620@qq.com'
   html: '{{ template "test.html" . }}'
   headers: { Subject: "[CRITICAL] 应用服务报警邮件"}
   send_resolved: true
- name: 'supper-team'
 email_configs:
  - to: '29308620@qq.com'
   html: '{{ template "test.html" . }}'
   headers: { Subject: "[WARNNING] QPS负载报警邮件"}
   send_resolved: true
# 抑制措施                           #添加下面告警抑制配置
inhibit_rules: 
- source_match: 
   severity: critical
 target_match:             
   severity: warning
 equal:
    - instance
    
#重启alertmanager服务
systemctl restart alertmanager.service

结果显示：开启告警抑制之后，因为 critical导致的warning事件就不再告警了，大大减少了告警风暴的效果。

运维小斌
关注
专栏目录
promeuth+alertmanager配置
09-22
开源全方位监控工具 promeuth +alertmanager 报警配置
AlertManager解析：构建高效告警系统
kfashfasf的博客
06-14 1124
接收器是AlertManager中用于定义告警通知方式的组件。它支持多种通讯渠道，如Email、Slack、Webhook等。用户可以根据需要配置一个或多个接收器，以确保告警能够及时准确地送达到目标受众。告警生成是整个流程的起点，通常由外部监控系统（如Prometheus）负责。监控系统根据预设的规则实时评估收集到的指标数据，一旦满足告警条件，即生成告警并发送给AlertManager。告警规则是在Prometheus配置文件中定义的，每个规则包含一个PromQL表达式和相应的告警条件。
Alertmanager 路由匹配
最新发布
小楼一夜听春雨，深巷明朝卖杏花
09-26 1505
2、第二种方式则基于正则表达式，通过设置match_re验证当前告警标签的值是否满足正则表达式的内容。当前告警中是否存在标签labelname并且其值等于labelvalue。1、一种方式基于字符串验证，通过设置。告警的匹配有两种方式可以选择。
AlertManager配置
summer_fish的专栏
06-02 430
如果在`group_interval`时间内有新的告警触发，并且它们属于同一分组，它们将被合并到之前的通知中。通过使用`group_wait`和`group_interval`，您可以在发送通知之前合并相关的告警，并控制告警通知的频率。通过调整`group_wait`和`group_interval`的值，可以根据实际需求平衡告警通知的及时性和准确性。当配置Alertmanager的路由规则时，`group_wait`和`group_interval`是两个重要的参数，用于控制告警通知的行为。
Prometheus实战篇:Alertmanager配置概述及告警规则
helloworld工程师的博客
01-11 2136
全局配置(global) : 用于定义一些全局的公共参数,如全局的SMTP配置,Slack配置等内容;模板(templates) : 用于定义告警通知时的模板,如HTML模板,邮件模板等;告警路由(route) : 根据标签匹配,确定当前告警应该如何处理;接收人(receivers) : 接收人是一个抽象的概念,它可以是一个邮箱也可以是微信,Slack或者Webhook等,接收人一般告警路由使用;抑制规则(inhibit_rules) : 合理设置抑制规则可以减少垃圾告警的产生。
Alertmanager 告警详解
热门推荐
小楼一夜听春雨，深巷明朝卖杏花
02-03 1万+
然后，你可以定义子路由或子节点，它们是树的分支，对某些特定的警报感兴趣，或者会采取某些特定的操作。Prometheus scrape_interval: 15s：采集的时间间隔是15s，也就是默认每隔15s采集一次指标，也就是有一个实例宕掉了，正好前一秒刚好采集完，那么还要等15s才能采集到这个指标，普罗米修斯才能感知到。分组的概念rules.yml .groups.name：将类似的指标分组，比如说监控linux服务器会监控其负载，资源负载就是一个分组，这个分组下面会有cpu的指标，内存的指标。
Prometheus（三）：Alertmanager配置，并实现飞书告警
dl_11的博客
03-20 5173
使用 Prometheus 发出警报分为两部分。Prometheus 服务器的告警规则会将告警发送给Alertmanager。然后，Alertmanager 管理这些警报，包括静音、抑制、聚合和 通过电子邮件、随叫随到的通知系统和聊天平台等方法发送通知。设置和配置 Alertmanager配置 Prometheus 与 Alertmanager 通信在 Prometheus 中创建报警规则alertmanager 是告警处理模块，但是告警消息的发送方法并不丰富。
Prometheus配置alertmanager告警
weixin_44147924的博客
07-24 833
由于上面配了job_name为jumpserver，登陆此job所属的机器，停掉上面的docker，测试能否告警。可以看到默认提供的 UI 页面，不过现在是没有任何告警信息的，因为我们还没有配置报警规则来触发报警。3、Prometheus添加alertmanager告警规则。将此密码填入上述alertmanager配置文件中。2、配置alertmanager告警。
k8s1.28.8版本配置Alertmanager报警方式（邮件，企业微信）
mingqing的博客
03-31 1870
部署Alertmanager配置Prometheus与Alertmanager通信配置告警prometheus指定rules目录 ，创建告警yamlconfigmap存储告警规则configmap挂载到容器rules目录增加alertmanager告警配置，有俩种方式下面注意下这里是定义谁发送这个告警信息的，谁接收这个邮件Prometheus Operator 为 alertmanager 抽象了两个 CRD资源:可以理解为俩中方式更新alertmanager，
学习笔记三：配置alertmanager-发送报警
weixin_43258559的博客
07-18 819
配置alertmanager
Alertmanager常用配置详解
小太阳DENGJIE的博客
04-23 7337
Alertmanager的抑制规则配置
Prometheus Alertmanager 告警配置详解
悦分享
01-12 386
在Prometheus的报警系统中，是分为2个部分的， 规则是配置是在prometheus中的， prometheus组件完成报警推送给alertmanager的， alertmanager然后管理这些报警信息，包括静默、抑制、聚合和通过电子邮件、on-call通知系统和聊天平台等方法发送通知。
【云原生】Prometheus整合Alertmanager告警规则使用详解
congge
07-14 6825
Prometheus整合Alertmanager配置告警规则使用详解
Alertmanager告警数据持久化到MySQL详细配置
L
05-19 1648
Integrations | Prometheus
Alertmanager 模板配置：自定义告警通知内容
TechEnthusiast的博客
08-27 192
提高可读性：默认模板可能缺乏结构，难以快速理解告警的关键信息。增加上下文：自定义模板可以包含更多相关的系统信息，帮助快速定位问题。标准化格式：统一的格式有助于团队更快地解析和响应告警。添加有用链接：可以直接在告警中添加相关文档或仪表板的链接。品牌化：可以根据组织的需求添加特定的品牌元素。
Alertmanager 告警通知系统的安装与配置
lovely_nn的博客
02-15 3248
Alertmanager简介 Alertmanager是什么? Alertmanager 是 Prometheus 的一个报警模块，主要用于接收 Prometheus 发送的告警信息，它支持丰富的告警通知渠道，而且能够做到对告警信息进行去重，降噪，分组，是一款前卫的告警通知系统。 Alertmanager工作机制 在Prometheus生态架构里，警报是由独立的俩部分组成，Prometheus和Alertmanager是两个独立的组件，Prometheus用于采集监控指标数据，定义告警规则，并.
部署Alertmanager发送告警
zx52306的博客
08-29 482
【代码】部署Alertmanager发送告警。
【Alertmanager发送告警邮件配置】
小怪兽的博客
03-10 4883
Prometheus将数据采集和报警分成了两个模块。报警规则配置在Prometheus Servers上，然后发送报警信息到AlertManger，然后我们的AlertManager就来管理这些报警信息，聚合报警信息过后通过email、PagerDuty、HipChat、Slack 等方式发送消息提示。本文演示通过email发送告警信息。 如下为在prometheus已经部署好的情况下，配置Alertmanager邮件发送。 一、安装Altermanager软件 下载地址为https://pr.
alertmanager告警配置
oneslide
06-11 1013
alertmanager告警配置
alertmanager短信告警配置
09-29
alertmanager短信告警配置相对比较简单，你可以使用支持电话、短信、邮件、微信多种报警的OpsAlert。你只需要使用WebHook进行配置即可。具体的配置步骤如下： 1. 首先，确保你已经安装了OpsAlert组件，并配置好了短信报警的相关信息。 2. 打开Alertmanager的配置文件，一般为alertmanager.yml。 3. 在配置文件中，找到receivers部分，这是用来定义告警接收者的地方。 4. 添加一个新的receiver，设置它的name为"sms"，并指定它的webhook_configs属性。 5. 在webhook_configs属性中，设置url为OpsAlert的WebHook地址。 6. 保存配置文件，并重启Alertmanager服务使配置生效。 配置完成后，当Alertmanager触发告警时，它会将告警信息通过WebHook发送到OpsAlert，然后OpsAlert会根据你的配置发送短信告警。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

运维小斌

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值