告警系统

部署及使用
AlterManager加入Prometheus
AlterManager告警
告警模版
告警路由
邮件模版
PythonHook
抑制
示例
静默

TOC

告警系统

    对于一个监控系统而言，告警是必不可少的组件之一，对于Prometheus而言指标的收集、存储同告警功能分属于Prometheus Server和AlterManager两个独立的组件，前者仅负责“告警规则”生成告警通知，具体的告警操作则由后者完成，“告警规则”和前面说的“记录规则”很相像，只不过“记录规则”是用来定义指标生成的新规则的，而“告警规则”通常是一个Bool表达式，要么为True要么为False；
    因为如果对应的“告警规则”返回值为True，就意味着它满足我们的条件，而满足这个条件，通常是用于表达有异常事件发生了，那么这个时候Prometheus就会借助于“告警规则”生成一个告警通知信息， 这个告警通知会通知给AlterManager，Prometheus Server是作为AlterManger的一个客户端，我们必须告诉Prometheus Server我们的AlterManager究竟在何处，也就意味着，我们可以认为，AlterManager提供了告警服务，Prometheus Server要调用这种服务，才能将告警功能得以完成；
    同样的，AlterManager既然是一个独立的服务，那么它也可以被Prometheus拿来作为一个监控Target组件之一，因而，我们完全可以基于Prometheus Server定制一些规则去发现AlterManager，发现了AlterManager之后，将其添加为自己的告警服务端和自己监控的Target；
    事实上AlterManager之所以独立于Prometheus之外，其实也有一个原因，就是将其作为一个单独的告警组件，它不仅能够接受Prometheus Server发送来的告警通知，还可以接受其他客户端的告警通知，所以，它的目的是为了作为一个更具通用性的告警服务器，我们写的应用程序，如果调用AlterManager的告警接口，也完全可以借助于AlterManager完成告警功能；
    所谓告警，无非就是把这个异常事件的事件本身，通知给对应事务的负责人，因此，通常情况下，无非就是通过某一种媒介来实现告警通知，同时AlterManager对告警通知也可以进行进行分组、去重，然后根据路由规则将其路由到不同的receiver，如Email、短信、PagerDuty、微信和叮叮等；
    比如某一个监控的Target发生故障，那么这个Target上的所有指标可能都会异常，再比如，我们某个交换机发生异常，那么链接到这个交换机的主机也都会异常，所以在这种情况下，我们也可以基于这种情况做分组，去重以及抑制等高级功能，避免发送大量的无用的告警信息给用户发送过去，这就意味着说，被监控对象之间可能有依赖关系，如果我们定义出这个依赖关系来，那么依赖的这个指标报警了，其他指标就不会报警了，就像交换机宕机了，我们只需要报告给管理员交换机宕机，不用把那些被影响的服务器也都报告一遍；
    因此它要抑制，要分组还要去重等等，而且还应该根据路由规则将对应的告警路由到不同的receiver上才是合理的，再比如，再公司内部，有MySQL等各种应用指标数据，当发生告警通知时，很显然，我们只需要发送给相关的运维技术人员即可，如果是网络设备出现故障，比如路由器，交换机，那么很显然，我们只需要发送给相关的网络运维工程师即可，也没必要通知给运维工程师；
    所以，AlterManager也可以根据服务或者标签来判断一下，究竟是哪一种组件发生故障了，然后路由到不同到receiver上去，数据库发生故障了，那么就应该发送给DBA，服务器发生故障了应该发送给Linux运维工程师，网络设备发生故障则送给网络运行工程师，当然，当故障长时间没能得到解决，我们也可以进行报警升级，直接送给相关部分的主管负责人；


    因此，正常情况下，我们要想使用报警功能，我们就需要将Prometheus配置成为AlterManager的告警客户端，返回来，AlterManager作为一个应用程序，也应该纳入到监控系统中来，而在配置逻辑上，我们需要在AlterManager上定义出合理的receiver而后，再去根据对应的告警机制通过路由规则将合理的信息路由给对应的receiver；
    如下流程图，首先在Prometheus上定义Alter rule，即触发规则，同时Prometheus也定义了谁是AlterManager，因此Alter rule触发的告警通知会达到AlterManager的route路由表的根路由，然后在每一个子路由上通过match来匹配这个通知信息的某一部分，或者某些特征，即标签，一旦匹配到了就交给匹配到receiver进行报警触发；
    因此每一个receiver应该有具体的定义，比如定义receiver的媒介是什么，邮件、叮叮还是微信，如果对应的告警信息已经匹配到了第一个receiver，至于要不要继续匹配第二个、第三个实现告警升级等高级功能，这完全是可以通过配置逻辑来实现的，比如刚开始触发时为waring，一段时间没解决就升级；
    有时候偶尔的一次状态转换不见得真正发生了严重事件，所以Alter rule在评估某一个异常发生的时候不应该第一时间就进行报警，因而，我们通常会给定一个持续的时间窗口，比如这个对应的告警规则表达式，采样的结果为True，这个True持续了2分钟还没有解决，那么就可以认为它可能真的出现问题了，所以要稍微等待一段时间，这是Prometheus上定义的，一旦第一次触发时，这个告警通知就会产生，但是这个告警通知不会立即交给AlterManager去发送，而是先在Prometheus上暂存一会儿，这个暂存的状态就上Pending，一旦超出了Pending的最长时长，这个告警就会交给AlterManager；


分组：我们也可以通过Group功能，将告警规则进行统一定义，将多个规则定义在一个组当中，以实现分组的功能，分组可以将多个告警信息合并成一个，在某些情况下，比如系统宕机导致大量的告警触发时，这个时候做分组就可以只触发一次告警即可；
抑制：我们也可以做抑制，当一个告警发送完以后，因为其他问题还要再发一次，也没必要，可以等一段时间再发送告警信息；
静默：也可以静默，比如每一周周三晚上凌晨1:00例行维护，为例避免例行维护期间会触发告警，我们可以定制静默期间触发的任何异常状态都不进行告警；
部署及使用
    AlterManager是一个独立的go二进制程序，需要独立部署维护，部署方式和Prometheus一样，官方提供的都是单一的二进制程序，也提供了配置文件，我们可以在配置文件里面定义好路由、分组、抑制、静默及媒介等信息，实现触发告警；

route：配置路由树；
receiver: 从接受组（与route同级别）中选择接受；
group_by：分组时使用的标签，默认情况下，所有告警都组织在一起，而一旦指定分组标签，则AlterManager将按这些标签进行分组；
continue：告警是否去继续路由子节点；
match：通过标签去匹配这次告警是否符合这个路由节点，必须全部匹配才可以告警，已弃用；
match_re：通过正则表达是匹配标签，意义同上，已弃用；
matchers：警报必须满足匹配节点的匹配器列表；
group_wait：组内等待时间，同一分组内收到第一个告警等待多久开始发送，目标是为了同组消息同时发送，不占用告警信息，默认30s
group_interval：当组内已经发送过一个告警，组内若有新增告警需要等待的时间，默认为5m,这条要确定组内信息是影响同一业务才能设置，若分组不合理，可能导致告警延迟，造成影响
repeat_interval：告警已经发送，且无新增告警，若重复告警需要间隔多久 默认4h 属于重复告警，时间间隔应根据告警的严重程度来设置
routes:
    - route：路由子节点 配置信息跟主节点的路由信息一致；
# 安装AlterManager
[root@node1 src]# tar xf alertmanager-0.21.0.linux-amd64.tar.gz 
[root@node1 src]# mv alertmanager-0.21.0.linux-amd64 /usr/local/alertmanager
# 查看默认配置文件
[root@node1 alertmanager]# cat alertmanager.yml
global:
  resolve_timeout: 5m

route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'web.hook' # 发送告警的receiver
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']
# 编写启动脚本
[root@node1 src]# cat > /lib/systemd/system/alertmanager.service << EOF
[Unit]
Description=alertmanager
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/alertmanager/alertmanager --config.file /usr/local/alertmanager/alertmanager.yml --storage.path=/data/alertmanager/data
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF
[root@node1 ~]# systemctl daemon-reload
# 配置AlterManager做最基础的报警
[root@node1 alertmanager]# cat alertmanager.yml
global:
  smtp_smarthost: 'smtp.163.com:25'
  smtp_from: 'mail0426@163.com'
  smtp_auth_username: 'mail0426@163.com'
  smtp_auth_password: 'ZUPYRGNTIUCCWVTZ'  # 此处为授权码，非登录密码
  smtp_require_tls: false
templates:
- 'templates/*.yaml'
route:
  receiver: email
  group_wait: 0s
receivers:
- name: 'email'
  email_configs:
  - to: 'cce@wangqueinfo.com'
AlterManager加入Prometheus
    利用AlterManager报警，首先需要将AlterManager，加入到Prometheus监控体系当中，作为整个监控体系的一部分，加入的方式有两种，一种是直接静态配置，另一种则是和Target一样，使用文件服务发现的方式动态添加，AlterManager到我们的Prometheus中；
    此外，AlterManager自己也提供了/metrcis接口，来暴露自己的状态指标，我们也可以将AlterManager加入到Prometheus监控体系当中，作为一个Target给它监控起来；

# 第一种，静态配置，直接将AlterManager加入到prometheus.yml主配置文件
[root@node1 ~]# cat /usr/local/prometheus/prometheus.yml
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - node1.cce.com:9093

# 第二种，使用文件服务发现的方式
[root@node1 ~]# cat /usr/local/prometheus/prometheus.yml
alerting:
  alertmanagers:
  - file_sd_configs:
    - files:
      - targets/altermanager*.yaml
# 配置altermanager基于文件的服务发现
[root@node1 ~]# cat /usr/local/prometheus/targets/altermanager-service.yaml
- targets:
  - node1.cce.com:9093
  labels:
    app: altermanager

# 将altermanager纳入prometheus监控中，在scrape_configs配置段加入altermanager的服务发现
[root@node1 ~]# cat /usr/local/prometheus/prometheus.yml
  - job_name: 'altermanager'
    file_sd_configs:
    - files:
      - targets/altermanager*.yaml
AlterManager告警
    上述只是将AlterManager加入到了我们的Prometheus里面来，接下来才是真正的告警实践环节，要想使用AlterManager进行告警首先我们得定义告警规则，定义告警规则，需要在Prometheus里面的rule_files配置段来配置，配置一个告警规则的文件，然后再在里面定义各种告警规则让Prometheus可以周期性的去评估告警规则，看一看它的Bool值是True还是False，如下就是一个告警规则示例；

alert：告警规则名称；
expr：基于PromQL表达式的告警触发条件(布尔表达式)，用于计算是否有时间序列可以满足该条件，也可以使用由Recording rule定义的指标；
for：表达式的值为True，但其持续时间未能满足for定义时长时，相关告警状态为pending，满足时长之后，相关告警将被触发，并转为firing状态；
labels：告警规则被激活时，相关时间序列上的所有标签都会添加到生成告警实例之上，而labels则允许在告警上附加其他自定义标签，该类标签支持模版化；
annotations：附加在告警之上的注解信息，其格式类似于标签，但不能被用于标示告警实例，经常用于存储告警摘要，且其值支持模版化；
# 配置告警规则文件
[root@node1 ~]# cat /usr/local/prometheus/prometheus.yml
rule_files:
  - rules/*.yaml
[root@node1 ~]# mkdir /usr/local/prometheus/rules
[root@node1 ~]# cat  /usr/local/prometheus/rules/altermanager.yaml
groups:
- name: Allinstance
  rules:
  - alert: InstanceDown
    expr: up == 0
    for: 1m
    annotations:
      title: 'instance down'
      description: 'instance has been down for more than 1 minute.'
    labels:
      severity: 'critcal'
告警模版
    Prometheus支持在告警中使用模版，告警模版是指的在告警中的注解和标签上引用时间序列的标签和样本值的方法，它使用标准的Go模版语法，并暴露一些包含时间序列标签和值的变量；
    若要在descriotion注解中引用触发告警的时间序列上的instance和job标签的值，可以分别使用'{{ $label.instance }}' 和 '{{ $label.job }}'，如下示例；
模版标签语法：{{ $labels.<label_name> }}        指标样本值引用：{{ $value }}

[root@node1 ~]# cat /usr/local/prometheus/rules/altermanager.yaml
groups:
- name: Allinstance
  rules:
  - alert: InstanceDown
    expr: up == 0
    for: 1m
    annotations:
      title: 'instance {{ $labels.instance }} down'
      description: 'instance {{ $labels.instance }} of {{ $labels.job }} has been down for more than 1 minute.'
    labels:
      severity: 'critcal'

告警路由
    上面介绍过AlterManager是支持树状路由表的，上面的示例只使用了一个根路由，只指定了一个route和一个receiver就完了，没有做任何区分，但事实上我们是完全可以使用match去区分对应的Alter的一些属性信息，如果能匹配到，可以根据匹配规则发给不同的receiver，以实现高级高级特性；

# 修改Prometheus告警规则
[root@node1 rules]# cat altermanager.yaml 
groups:
- name: instance_alerts
  rules:
  - alert: InstanceDown
    expr: up == 0
    for: 5s
    annotations:
      description: '节点 {{ $labels.instance }} 上的{{ $labels.app }} 已失联，请及时检查!!!'
    labels:
      severity: 'critcal'  # 级别
- name: disk_alerts
  rules:
  - alert: DiskFull
    expr: 100*((node_filesystem_size_bytes{device='/dev/sda2'}-node_filesystem_avail_bytes{device='/dev/sda2'})/node_filesystem_size_bytes{device='/dev/sda2'}) > 20
    for: 5s
    annotations:
      description: '节点{{ $labels.instance }}磁盘空间已经不足80%，请及时处理!!!'
    labels:
      severity: 'warning'  # 级别
# 修改AlterManager路由规则
[root@node1 ~]# cat /usr/local/alertmanager/alertmanager.yml
global:
  smtp_smarthost: 'smtp.qq.com:25'
  smtp_from: '986495818@qq.com'
  smtp_auth_username: '986495818@qq.com'
  smtp_auth_password: 'ftebhqbhshbjbfcb'  # 此处为授权码，非登录密码
  smtp_require_tls: false

templates:
- 'templates/*.yaml'

route:
  receiver: ops-team # 默认的receiver,标示没有匹配到的就发送给默认的receiver
  group_wait: 0s
  group_interval: 1m
  repeat_interval:  5m
  routes: # 定义子路由
  - receiver: ops-team # 定义一个receiver
    match: 
      severity: "critcal" # 匹配severity的值，如果为critcal，就发送给ops-team这个receiver
  - receiver: super-team
    match: 
      severity: "warning"

receivers: # 定义多个receiver
- name: 'ops-team'
  email_configs:
  - to: 'mail0426@yeah.net'
- name: 'super-team'
  email_configs:
  - to: 'mail0426@126.com'
# 停止node1节点的Grafana
[root@node1 ~]# systemctl stop grafana.service
# 将node3节点的使用存储超过20%
[root@node3 ~]# df -h|grep '/$'
/dev/sda2        46G   11G   36G  22% /


邮件模版
    可以看到上述图片，AlterManager默认的邮件模版非常丑陋，为了方便定制化需求，AlterManager也支持自定义模版，下面就使用一个简单的HTML文件作为邮件模版；

# 定义一个HTML模版
[root@node1 ~]# cat /usr/local/alertmanager/templates/email.html 
{{ define "email.to.html" }}
{{ range .Alerts }}
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    </haed>
<body style="margin: 0; padding: 0;">
<div align="center">
    <table border="1" style="border:5px solid #F2F2F2;" cellspacing="4" cellpadding="3" width="650"
           style="table-layout:fixed">
        <tr>
            <th align="center"><b>告警项</b></marquee></th>
            <th align="center"><b>内容信息</b></marquee></th>
        </tr>
        <tr>
            <td align="center" style="font-family:微软雅黑; width: 15%;WORD-WRAP:break-word">告警标题</td>
            <td align="center" style="font-family:微软雅黑; width: 60%;WORD-WRAP:break-word">{{ .Labels.alertname }}</td>
        </tr>
        <tr>
            <td align="center" style="font-family:微软雅黑; size=5;width: 20%;WORD-WRAP:break-word">告警描述</td>
            <td align="center" style="font-family:微软雅黑;width: 80%;color: red;WORD-WRAP:break-word">{{
                .Annotations.description }}
            </td>
        </tr>
        <tr>
            <td align="center" style="font-family:微软雅黑;width: 20%;WORD-WRAP:break-word">告警等级</td>
            <td align="center" style="font-family:微软雅黑;width: 80%;padding-center: 15px;font-weight: bold;">{{
                .Labels.severity }}
            </td>
        </tr>
        <tr>
            <td align="center" style="font-family:微软雅黑;width: 20%;WORD-WRAP:break-word">告警时间</td>
            <td align="center" style="font-family:微软雅黑;width: 80%;WORD-WRAP:break-word">{{ (.StartsAt.Add
                28800e9).Format "2006-01-02 15:04:05" }}
            </td>
        </tr>
        <tr>
            <td align="center" style="font-family:微软雅黑;width: 20%;WORD-WRAP:break-word">告警主机</td>
            <td align="center" style="font-family:微软雅黑;width: 80%;WORD-WRAP:break-word">{{ .Labels.instance }}</td>
        </tr>
    </table>
</body>
</html>
{{ end }}
{{ end }}
# 在AlterManager配置template
[root@node1 ~]# cat /usr/local/alertmanager/alertmanager.yml
global:
  smtp_smarthost: 'smtp.163.com:25'
  smtp_from: 'mail0426@163.com'
  smtp_auth_username: 'mail0426@163.com'
  smtp_auth_password: 'ZUPYRGNTIUCCWVTZ'  # 此处为授权码，非登录密码
  smtp_require_tls: false

templates:  # 定义邮件模版
- 'templates/*.html'

route:
  receiver: ops-team # 默认的receiver,标示没有匹配到的就发送给默认的receiver
  group_wait: 0s
  group_interval: 1s
  repeat_interval: 1m
  routes:
  - receiver: ops-team # 定义一个receiver
    match: 
      severity: "critcal" # 匹配severity的值，如果为critcal，就发送给ops-team这个receiver
  - receiver: super-team
    match: 
      severity: "warning"

receivers:
- name: 'ops-team'
  email_configs:
  - to: 'mail0426@yeah.net'
    html: '{{ template "email.to.html" . }}'
    headers: { Subject: "【监控报警】" }
- name: 'super-team'
  email_configs:
  - to: 'mail0426@126.com'
    html: '{{ template "email.to.html" . }}'
    headers: { Subject: "【监控报警】" }

PythonHook
    利用Python自定义webhook的方式进行告警更加灵活，我们可以不仅可以调用叮叮、微信、邮件，还可以使用短信，甚至是只能语音，给相关人员通过各种高级媒介发送告警信息，如下就是一个简单的示例；

# 配置altermanager支持webhook告警
[root@node1 alertmanager]# cat alertmanager.yml 
global:

route:
  receiver: python-hook # 配置指定的receiver
  group_wait: 0s
  group_interval: 1s
  repeat_interval: 5s

receivers:
- name: 'python-hook'
  webhook_configs:
  - url: http://172.16.1.254:8888/webhook/prometheus/alerting
    send_resolved: true
    如下为一个利用Flask编写的一个简单的Webhook接口，接受到信息之后直接打印，仅做测试；

import json,datetime
from flask import request, Flask

app = Flask(__name__)

@app.route('/webhook/prometheus/alerting', methods=['POST'])
def hook():
    data=json.loads(request.get_data().decode())
    description = data['commonAnnotations']['description']
    status = data['status']
    serverity = data['alerts'][0]['labels']['severity']
    job = data['alerts'][0]['labels']['job']
    instance = data['alerts'][0]['labels']['instance']
    start_time = data['alerts'][0]['startsAt']
    tran_time=datetime.datetime.strptime(start_time,'%Y-%m-%dT%H:%M:%S.%fZ')+datetime.timedelta(hours=8)
    message = str('告警描述：%s' %description + '\n'
                '告警状态：%s' %status + '\n'
                '告警级别：%s' %serverity + '\n'
                '告警节点：%s' %job + '\n'
                '告警地址：%s' %instance + '\n'
                '开始时间：%s' %tran_time + '\n'
    )
    print(message)
    return "OK", 200

if __name__ == '__main__':
    app.run(debug = False, host = '172.16.1.254', port = 8888)

抑制

    抑制主要是指当监控项存在依赖关系的时候，只对被依赖的故障报警了，依赖项就不需要报警了，比如一个节点运行了一个DB一个MQ，很显然，节点自己应该有一个node_exporter监控着节点的运行状况，假设，发现这个节点的node_exporter连不上了，那么这个时候Prometheus就会发出一条节点故障的告警信息；
    但是节点故障了，DB和MQ也会故障，所以在正常情况下，报警要报三个，分别是节点故障、DB故障和MQ故障，那么这个时候，为了避免连续报警，我们可以使用抑制的规则进行监控项的依赖，当被依赖项报警，依赖项就不会再报警了，像这种就叫做抑制机制；

source_match:
  [ <labelname>: <labelvalue>,... ]
source_match_re:
  [ <labelname>: <regex>,... ]

target_match:
  [ <labelname>: <labelvalue>,... ]
target_match_re:
  [ <labelname>: <regex>,... ]
    如果之前已经发送过类似的告警通知，能匹配到target_match或者target_match_re所定义的匹配条件，那么产生新的告警时，如果可以满足source_match或者source_match_re时，那么这个告警信息就认为它与我们的目标标签完全相同，就启动抑制机制，新的告警就不会被发送了；

source_match:
  alertname: NodeDown
  severity: critical
target_match:
  severity: critical
equal:
  - node
# 如果之前发生过NodeDown并且这个报警级别是critical，那么新产生的报警如果它的报警级别也是critical，并且之前的NodeDown报警时间序列的node标签和新产生的报警时间序列的node标签值一致，那么就开启抑制机制，新产生的报警将不会发送告警信息；
示例
    主要看下面的inhibit_rules部分，意思是当先前，如果有一个名为InstanceDown的监控已经触发告警通知了，那么如果现在又有一个InstanceDown的监控触发告警了，此时AlterManager会将先前的标签和现在的标签进行对比，如果两个标签的alertname一样，那么就抑制，意思是后者将不会再发送告警信息；
    在生成环境做，应该对每个标签的来源定义清除，来自同一个主机的指标，那么这些指标上面的某一个标签应该是一致的，此处案例是有缺陷的，因为没有做relabel，所以无法使用instance做对等比较，因为我的instance是172.16.1.1:3000和172.16.1.1:9100，这两者标签不一致，所以无法使用equal，故，使用alertname作为对等比较；

[root@node1 alertmanager]# cat alertmanager.yml
global:
  smtp_smarthost: 'smtp.qq.com:25'
  smtp_from: '986495818@qq.com'
  smtp_auth_username: '986495818@qq.com'
  smtp_auth_password: 'ftebhqbhshbjbfcb'  # 此处为授权码，非登录密码
  smtp_require_tls: false

templates:  # 定义邮件模版
- 'templates/*.html'

route:
  receiver: ops-team # 默认的receiver,标示没有匹配到的就发送给默认的receiver
  group_wait: 0s
  group_interval: 1s
  repeat_interval: 1m
  routes:
  - receiver: ops-team # 定义一个receiver
    match: 
      severity: "critcal" # 匹配severity的值，如果为critcal，就发送给ops-team这个receiver
  - receiver: super-team
    match: 
      severity: "warning"

receivers:
- name: 'ops-team'
  email_configs:
  - to: 'mail0426@yeah.net'
    html: '{{ template "email.to.html" . }}'
    headers: { Subject: "【监控报警】" }
- name: 'super-team'
  email_configs:
  - to: 'mail0426@126.com'
    html: '{{ template "email.to.html" . }}'
    headers: { Subject: "【监控报警】" }

inhibit_rules:
  - source_match:
      alertname: 'InstanceDown'
    target_match:
      alertname: 'InstanceDown'
    equal: ['alertname']

静默

    有的时候，我们的服务器可能需要例行维护，我们手动的把服务器宕机，那么就没必要告警了，像这种就叫做静默机制，对于静默机制而言，我们可以自己定义，就在AlertManager的Silence那里，指明从几点几分开始，持续多久，到什么时候结束，那么这段时间就是静默期；
    这一种叫做临时静默，因为时间段一过，它就失效了，我们也可以做周期性静默，周期性静默配置起来，稍微麻烦一点，我们在部署AlertManager的时候，有一个amtool，其实它也可以接入到AlterManager去帮我们做一系列的操作，比如更新静默，查询静默，触发报警等等；


# 使用amtool检测配置文件是否正确
[root@node1 ~]# /usr/local/alertmanager/amtool check-config /usr/local/alertmanager/alertmanager.yml 
Checking '/usr/local/alertmanager/alertmanager.yml'  SUCCESS
Found:
 - global config
 - route
 - 1 inhibit rules
 - 2 receivers
 - 1 templates
  SUCCESS
# 使用amtool查询是否有报警触发
[root@node1 ~]# /usr/local/alertmanager/amtool alert --alertmanager.url=http://localhost:9093
Alertname     Starts At                Summary  
InstanceDown  2021-06-21 09:06:31 UTC           
InstanceDown  2021-06-21 09:13:31 UTC
# 使用amtool查询存在的静默条目
[root@node1 ~]# /usr/local/alertmanager/amtool silence query --alertmanager.url=http://localhost:9093
ID                                    Matchers          Ends At                  Created By  Comment  
1d5149dd-e72e-43f9-afda-eace8f2be70c  severity=critcal  2021-06-21 20:53:55 UTC  cce         test

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注