Alertmanager告警配置

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事件就不再告警了，大大减少了告警风暴的效果。

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

如若内容造成侵权/违法违规/事实不符，请联系我们进行投诉反馈qq邮箱809451989@qq.com，一经查实，立即删除！

相关文章

java项目如何配置不同环境变量 以及 原理

java项目如何配置不同环境变量 以及 原理

如何配置不同的profile 首先&#xff0c;一个java项目&#xff0c;需要有不同的环境配置&#xff0c;打包时&#xff0c;自动使用对应的配置。那么&#xff0c;如何实现呢&#xff1f; 在你的Spring Boot项目的src/main/resources目录下创建或添加一个application.yml文件。这…
阅读更多...
2024前端面试题之Vue3

2024前端面试题之Vue3

2024前端面试题之Vue3 在面试具有五年经验的前端工程师时&#xff0c;对于 Vue 3 的掌握程度是一个重要的考核点。本文将提供一系列针对这一级别工程师的 Vue 3 面试题&#xff0c;并附上详细的解析&#xff0c;帮助面试官全面评估候选人的技术实力和项目经验。 一、Vue 3 基础…
阅读更多...
科普文：微服务之服务网格Service Mesh

科普文：微服务之服务网格Service Mesh

一、ServiceMesh概念 背景 随着业务的发展&#xff0c;传统单体应用的问题越来越严重&#xff1a; 单体应用代码库庞大&#xff0c;不易于理解和修改持续部署困难&#xff0c;由于单体应用各组件间依赖性强&#xff0c;只要其中任何一个组件发生更改&#xff0c;将重新部署整…
阅读更多...
shell脚本之if/case语句

shell脚本之if/case语句

一、条件测试 1、1 返回码 $? $? :返回码&#xff0c;用来判断命令或者脚本是否执行成功。 0 &#xff1a;表示true &#xff0c;成功&#xff1b;非0 则表示flase &#xff0c;失败。 1、2 test命令 可以进行条件测试&#xff0c;然后根据返回值来判断条件是否成立 -e…
阅读更多...
第2关 Python 基础知识

第2关 Python 基础知识

第2关 Python 基础知识 前言Python实现wordcountSSH远程连接开发机Bug记录 前言 本文是由上海人工智能实验室主办的第三期书生大模型实战营的笔记&#xff0c;仅供个人和助教批改作业参考&#xff0c;教程原文链接。 报名请在微信搜索“第三期书生大模型实战营”。 本笔记是在…
阅读更多...
BatchNorm LayerNorm

BatchNorm LayerNorm

0. Abstract 很早以前就遇到了 BatchNorm 和 LayerNorm, 当时只是粗略地知道它们是对数据进行了标准化: x x − μ σ \bm{x} \frac{\bm{x} - \bm{\mu}}{\bm{\sigma}} xσx−μ​ 这当然很简单, 但实际的数据是比较复杂的. 对于 CV 任务的数据 image 而言, 一个 batch 的数…
阅读更多...
linux系统操作/基本命令/vim/权限修改/用户建立

linux系统操作/基本命令/vim/权限修改/用户建立

Linux的目录结构&#xff1a; 一&#xff1a;在Linux系统中&#xff0c;路径之间的层级关系&#xff0c;使用:/来表示 注意:1、开头的/表示根目录 2、后面的/表示层级关系 二&#xff1a;在windows系统中&#xff0c;路径之间的层级关系&#xff0c;使用:\来表示 注意:1、D:表示…
阅读更多...
【技术追踪】HiDiff：医学图像分割的混合扩散框架（TMI-2024）

【技术追踪】HiDiff：医学图像分割的混合扩散框架（TMI-2024）

传统分割方法与扩散分割方法结合&#xff0c;做大做强~ HiDiff&#xff1a;一种用于医学图像分割的新型混合扩散框架&#xff0c;它可以协同现有判别分割模型和新型生成扩散模型的优势&#xff0c;在腹部器官、脑肿瘤、息肉和视网膜血管分割数据集上性能表现 SOTA &#xff01;…
阅读更多...
【eNSP模拟实验】三层交换机实现VLAN通信

【eNSP模拟实验】三层交换机实现VLAN通信

实验需求 让PC1和PC2能够互相通讯&#xff0c;其中PC1在vlan10中&#xff0c;PC2在vlan20中。 实验操作 首先把PC1和PC2都配置好ip&#xff0c;配置好之后&#xff0c;点击右下角的应用 然后&#xff0c;在S2交换机&#xff08;S3700&#xff09;上做如下配置 #进入系统 <…
阅读更多...
Java基础-组件及事件处理（下）

Java基础-组件及事件处理（下）

(创作不易&#xff0c;感谢有你&#xff0c;你的支持&#xff0c;就是我前行的最大动力&#xff0c;如果看完对你有帮助&#xff0c;请留下您的足迹&#xff09; 目录 面板组件 说明 常见组件 JScrollPane常用构造方法 JScrollPane设置面板滚动策略的方法 JScrollPane滚…
阅读更多...
进程调度篇

进程调度篇

在操作系统的广阔领域中&#xff0c;进程调度是其中一个至关重要的环节。它如同操作系统的“交通警察”&#xff0c;负责在多个等待CPU执行的进程间进行高效、公平的分配。本文将带您了解进程调度的基本概念、重要性、常用算法…… 1. 进程调度的基本概念 1.1 进程调度的定义 …
阅读更多...
HTAP 数据库在国有大行反洗钱场景的应用

HTAP 数据库在国有大行反洗钱场景的应用

导读 在金融领域&#xff0c;随着数字化服务的深入和监管要求的提高&#xff0c;反洗钱工作变得尤为关键。洗钱活动不仅威胁金融安全&#xff0c;也对社会秩序构成挑战。本文深入探讨了国产 HTAP 分布式数据库 TiDB 在某国有大行反洗钱系统中的应用实践。 依托 TiDB 构建的新…
阅读更多...
c＋＋初阶知识——类和对象（1）

c＋＋初阶知识——类和对象（1）

目录 1.类和对象 1.1 类的定义 1.2 访问限定符 1.3 类域 2.实例化 2.1 实例化概念 2.2 对象大小 内存对齐规则 3.this指针 1.类和对象 1.1 类的定义 &#xff08;1&#xff09;class为定义类的关键字&#xff0c;Stack为类的名字&#xff0c;{}中为类的主体&#xf…
阅读更多...
python怎么调用cmd命令

python怎么调用cmd命令

关于python调用cmd命令&#xff1a; 1、python的OS模块 OS模块调用CMD命令有两种方式&#xff1a;os.popen()、os.system()都是用当前进程来调用。 OS.system是无法获取返回值的。当运行结束后接着往下面执行程序。用法如&#xff1a;OS.system("ipconfig"). OS.…
阅读更多...
前台线程和后台线程（了解篇）

前台线程和后台线程（了解篇）

在多线程编程中&#xff0c;理解线程的不同类型对于编写高效、稳定的程序至关重要。特别地&#xff0c;前台线程&#xff08;Foreground Threads&#xff09;与后台线程&#xff08;Background Threads&#xff09;在行为上有着根本的区别&#xff0c;这些区别直接影响到程序的…
阅读更多...
【Linux 线程】线程的基本概念、LWP的理解

【Linux 线程】线程的基本概念、LWP的理解

文章目录 一、ps -L 指令&#x1f34e;二、线程控制 一、ps -L 指令&#x1f34e; &#x1f427; 使用 ps -L 命令查看轻量级进程信息&#xff1b;&#x1f427; pthread_self() 用于获取用户态线程的 tid&#xff0c;而并非轻量级进程ID&#xff1b;&#x1f427; getpid() 用…
阅读更多...
(CVPR-2024)SwiftBrush：具有变分分数蒸馏的单步文本到图像扩散模型

(CVPR-2024)SwiftBrush：具有变分分数蒸馏的单步文本到图像扩散模型

SwiftBrush&#xff1a;具有变分分数蒸馏的单步文本到图像扩散模型 Paper Title&#xff1a;SwiftBrush: One-Step Text-to-Image Diffusion Model with Variational Score Distillation Paper 是 VinAI Research 发表在 CVPR 24 的工作 Paper地址 Code:地址 Abstract 尽管文本…
阅读更多...
前端工程化（01）：10款自动化构建工具初识。

前端工程化（01）：10款自动化构建工具初识。

前端工程化自动化构建工具是用于简化前端开发流程、提高开发效率和优化项目质量的工具。市面上的工具多种多样&#xff0c;贝格前端工场先介绍一下什么是前端工程化&#xff0c;为什么要前端工程化&#xff0c;以及常用工具&#xff0c;后面会对各种工具逐一介绍。 一、什么是…
阅读更多...
【数据结构】一文了解七大排序算法

【数据结构】一文了解七大排序算法

文章目录 前言一.直接插入排序插入排序思想插入排序代码实现插入排序总结 二.希尔排序希尔排序思想希尔排序代码实现希尔排序总结 三.选择排序选择排序思想选择排序代码实现选择排序总结 四.堆排序堆排序思想堆排序代码实现堆排序总结 五、冒泡排序冒泡排序思想冒泡排序代码实现…
阅读更多...
深化信创存储 ，XEDP 与 飞腾腾云 S5000C 完成兼容性认证

深化信创存储 ，XEDP 与 飞腾腾云 S5000C 完成兼容性认证

近日&#xff0c;XSKY星辰天合的统一数据平台 XEDP 与飞腾信息技术有限公司的高性能服务器 CPU 飞腾腾云 S5000C 完成兼容性互认证。 经过严格的测试与评估&#xff0c;双方产品在技术上兼容良好&#xff0c;运行稳定且性能优异&#xff0c;融合双方优势构筑的软件定义存储系统…
阅读更多...
最新文章

Copyright @ 2022~2023