做的网站客户拿去维违法,北京网站建设好,百度我的订单,做外链那些网站比较好文章目录 一、介绍二、核心概念1 Grouping 分组2 Inhibition 抑制3 Silences 静默#xff08;静音#xff09;5 High Availability 高可用性 三、部署1 二进制方式下载配置 systemd 2 docker-compose 方式 四、配置1 配置文件介绍1.1 全局配置1.2 receiver 接收器标准接收器相… 文章目录 一、介绍二、核心概念1 Grouping 分组2 Inhibition 抑制3 Silences 静默静音5 High Availability 高可用性 三、部署1 二进制方式下载配置 systemd 2 docker-compose 方式 四、配置1 配置文件介绍1.1 全局配置1.2 receiver 接收器标准接收器相关设置接收器集成设置 1.3 time_interval 时间间隔time_intervaltime_interval_spectime_rangeweekday_rangedays_of_month_rangemonth_rangeyear_rangelocation 1.4 路由相关配置route 根路由标签匹配器 matcherrouters子路由配置 1.5 抑制相关配置 Inhibitioninhibit_rules 2 静默配置 一、介绍
Alertmanager 用于接收 Prometheus 推送的警报信息并对这些警报信息进行分组、路由、删除重复数据等处理还可以进一步设置某些警报的静默抑制等。最后还可以使用 邮件Webhook 方式等发送通知。 二、核心概念
1 Grouping 分组
分组将性质相似的警报分类到单个通知中。这 在多个系统同时发生故障的较大中断期间特别有用并且 数百到数千个警报可能会同时触发。
试想一个部署有 MySQL 的服务器网络中断导致 k8s 集群中所有应用示例无法连接到这台MySQL。假设 k8s 集群中有成百上千个应用实例将会同时发送警报信息到 Alertmanager。
其实作为管理者只想获得一个警报信息即可并且可以看到都有哪些实例受到影响。因此 Alertmanager 可以配置按机器和警报名称进行分组以便发送一条比较紧凑、有汇总的通知。
2 Inhibition 抑制
抑制是指如果某些其他警报已经启动则抑制某些警报的通知的概念。 某些其他警报和某些警报是存在一定的关联性。
例如正在触发警报通知无法访问整个群集。Alertmanager可以配置为如果该特定警报正在启动则将与该集群有关的所有其他警报静音。这将阻止数百或数千个与实际问题无关的触发警报的通知。
抑制 可通过Alertmanager的配置文件进行配置。
3 Silences 静默静音
静默是在给定时间内简单地静音警报的一种简单方法。 静默是基于匹配器配置的就像路由树一样。将检查传入警报是否与激活状态的静默的所有条件相等或正则表达式相匹配。如果符合或者匹配则不会发出该警报的通知。
静默是在Alertmanager的web界面中配置的。
5 High Availability 高可用性
Alertmanager支持为实现高可用性而创建集群的配置。这可以使用 --cluster-*标志进行配置。 重要的是不要在Prometheus及其AlertManager之间进行流量负载平衡而是将Prometheus指向所有AlertManager的列表。 要创建警报管理器的高可用性集群实例需要 配置为相互通信。这是使用标志配置的。--cluster.*
--cluster.listen-address 字符串集群监听地址默认为 “0.0.0.0:9094”; 空字符串 “” 表示禁用 HA 模式--cluster.advertise-address 字符串集群公告地址--cluster.peer 值初始对等体对每个附加对等方重复标志--cluster.peer-timeout 值对等超时期限默认为“15s”--cluster.gossip-interval 值集群消息传播速度 默认为“200ms”--cluster.pushpull-interval 值值越低值越大 以牺牲带宽为代价的收敛速度默认为“1m0s”--cluster.settle-timeout 值等待群集的最长时间 在评估通知之前要解决的连接。--cluster.tcp-timeout 值TCP 连接、读取和写入的超时值默认为“10s”--cluster.probe-timeout 值在标记节点不正常之前等待 ACK 的时间 默认为“500ms”--cluster.probe-interval 值随机节点探测器之间的间隔默认“1s”--cluster.reconnect-interval 值尝试重新连接到丢失的对等体之间的间隔默认为“10s”--cluster.reconnect-timeout 值尝试重新连接到丢失的对等体的时间长度默认值“6H0m0s”--cluster.label 值标签是要包含在每个数据包和流上的可选字符串。它唯一标识集群并防止发送八卦消息时出现交叉通信问题默认“”
高可用架构图
三、部署
1 二进制方式
下载
在 Prometheus 下载页面可以找到不同的版本和适合不同平台的二级制部署包 这里以 Linux amd64 为例。
curl -o alertmanager.tgz -L https://github.com/prometheus/alertmanager/releases/download/v0.26.0/alertmanager-0.26.0.linux-amd64.tar.gz
配置 systemd
命令行启动参数
参数含义--config.filealertmanager.yml指定配置文件--storage.pathdata/指定数据存储基础路径--data.retention120h数据保留时长--web.listen-address:9093用于公开度量和web界面的地址。--web.external-urlWEB.EXTERNAL-URL指定一个 FQDN 比如 --web.external-urlhttp://grafana.host.com 这样警报信息中会包含查看当时这个警报的图形链接。
命令行的所有配置参数可以使用此命令获取 alertmanager -h
[Unit]
DescriptionAlertmanager 警报管理器
Afternetwork-online.target
Wantsnetwork-online.target[Service]
#EnvironmentFile-
ExecStart/usr/local/bin/alertmanagerKillSignalSIGQUITRestartalwaysRestartPreventExitStatus1 6 SIGABRTTimeoutStopSec5
KillModeprocess
PrivateTmptrue
LimitNOFILE1048576
LimitNPROC1048576[Install]
WantedBymulti-user.target
2 docker-compose 方式
version: 3.9
services:alertmanager:user: 65534image: quay.io/prometheus/alertmanagercommand: --config.file/etc/alertmanager/alertmanager.yml --storage.path/alertmanager --web.listen-address:9093 --web.listen-address:9098volumes:- ./alertmanager.yml:/etc/alertmanager/alertmanager.yml- ./data:/alertmanagernetwork_mode: hostexpose:# web 端口- 9093# 集群端口- 9094# 还是 web 端口- 9098 --web.listen-address 参数可以使用多次指定多个 四、配置
配置文件中一般配置 静默规则、通知路由通知接收器等。
Alertmanager 和 Prometheus 一样支持热加载配置只需要向进程发送信号SIGHUP 或者向服务发送POST 请求
curl -X POST http://ip:9093/-/reload
如果配置文件中有错误配置文件将不会更新。
1 配置文件介绍
下面是一些配置示例覆盖了最主要的基础配置, 这里有完整的配置说明
1.1 全局配置
global:# 用于发送电子邮件的默认SMTP智能主机包括端口号.# 端口号通常为 25 或者 TLS 的 SMTP 为 465smtp_smarthost: stmpt.126.com:25 # 默认的SMTP发件人标头字段smtp_from: xxx126.com# 要显示给SMTP服务器的默认主机名。[ smtp_hello: 126.com | default localhost ]# 使用CRAM-MD5、LOGIN和PLAIN的SMTP身份验证用户名一般是邮箱的用户名。# 如果为空则Alertmanager不会对SMTP服务器进行身份验证。如果 SMTP 需要认证则会失败。# 此邮箱需在其邮箱服务器上开通 SMTP 功能。[ smtp_auth_username: xxx126.com ]# 身份验证秘钥不是登录密码。[ smtp_auth_password: secret ]# 发送邮件是否使用 TLS, 如果是true smtp_smarthost 的值中的端口应该是 465# 请注意Go不支持到远程 SMTP 服务器的未加密连接。[ smtp_require_tls: bool | default true ]# 如果警报不包括EndsAtResolveTimeout是alertmanager使用的默认值。# 经过这段时间后如果警报尚未更新它可以将其声明为已解决。# 这对普罗米修斯的警报没有影响因为它们总是包括EndsAt。[ resolve_timeout: duration | default 5m ]# 从中读取自定义通知模板定义的文件。
# 最后一个元素可以使用通配符匹配器例如 templates/*.tmpl
templates:[ - filepath ... ]# 路由的根节点称为根路由.
route: route# 通知接收者的列表。这里可以配置邮件、webhook 等接收告警消息者。
receivers:- receiver ...# 一个包含一个或多个静默规则的列表.
inhibit_rules:[ - inhibit_rule ... ]# 指定可在路由树 active_time_intervals 字段中引用的时间间隔名称以便在一天中的特定时间静音/激活特定路由。
# 具体如何设置继续参看接下来的章节
time_intervals:[ - time_interval ... ]1.2 receiver 接收器
标准接收器相关设置
接收器是一个或多个通知集成的命名配置。 包含如下字段
receivers:# 接收器的唯一名称。- name: string# 多个通知集成的配置如下仅展示和介绍经常使用的几种。email_configs: # 发邮件[ - email_config, ... ]webhook_configs: # 利用 webhook 发送钉钉消息[ - webhook_config, ... ]wechat_configs: # 发企业微信[ - wechat_config, ... ]接收器集成设置
这些设置允许配置特定的接收器集成。
email_config
# 是否通知已解决的警报。
[ send_resolved: boolean | default false ]# 接收警报信息的邮件地址多个用英文逗号分开。例如 xxxqq.com,yyy.qq.com
to: tmpl_string# 向接收人展示的发件人的地址。
[ from: tmpl_string | default global.smtp_from ]# 发送电子邮件的SMTP主机。
[ smarthost: string | default global.smtp_smarthost ]# 要标识给SMTP服务器的主机名。
[ hello: string | default global.smtp_hello ]# SMTP身份验证信息
[ auth_username: string | default global.smtp_auth_username ]
[ auth_password: secret | default global.smtp_auth_password ]# SMTP TLS要求。
# 请注意Go不支持到远程SMTP终结点的未加密连接
[ require_tls: bool | default global.smtp_require_tls ]# TLS configuration.
tls_config:[ tls_config ]# 电子邮件通知的HTML正文这里一般使用定义好的模板这里的 email.default.html 是模板名称.
# 模板名称是在全局的 templates 字段指定的模板文件中定义的。
[ html: tmpl_string | default {{ template email.default.html . }} ]
# 电子邮件通知的文本正文。
[ text: tmpl_string ]# 其他邮件头电子邮件头键/值对。
[ headers: { string: tmpl_string, ... } ]示例
receivers:
- name: team-X-mailsemail_configs:- to: team-Xalertsexample.org, team-Yalertsexample.org- name: team-X-pageremail_configs:- to: team-Xalerts-criticalexample.orgpagerduty_configs:- routing_key: team-X-key- name: team-Y-mailsemail_configs:- to: team-Yalertsexample.orgheaders:subject: 邮件标题from: 邮件来自哪儿to: 发给谁的webhook_config webhook接收器允许配置通用接收器。
如果发送钉钉需要配合一个插件 prometheus-webhook-dingtalk
prometheus-webhook-dingtalk 会启动一个服务并暴露一个接口。
alertmanager 可以通过 webhook_config 中的 url 字段的配置向 prometheus-webhook-dingtalk 发送一个 POST 的 HTTP 请求。从而实现警报信息向钉钉发送的目的。
# 是否通知已解决的警报。
[ send_resolved: boolean | default true ]# 要向其发送HTTP POST请求的端点。
url: secret# 要包含在单个webhook消息中的最大警报数。超过此阈值的警报将被截断。
# 将其保留为默认值0时将包括所有警报。
[ max_alerts: int | default 0 ]Alertmanager将以以下JSON格式向配置的端点发送HTTP POST请求
{version: 4,groupKey: string, // key identifying the group of alerts (e.g. to deduplicate)truncatedAlerts: int, // how many alerts have been truncated due to max_alertsstatus: resolved|firing,receiver: string,groupLabels: object,commonLabels: object,commonAnnotations: object,externalURL: string, // backlink to the Alertmanager.alerts: [{status: resolved|firing,labels: object,annotations: object,startsAt: rfc3339,endsAt: rfc3339,generatorURL: string, // identifies the entity that caused the alertfingerprint: string // fingerprint to identify the alert},...]
}其实webhoook_config 的配置不仅仅支持钉钉它是一个通用的 webhook 工具。 有一个与此功能集成的列表。
要实现钉钉告警需要安装一个钉钉插件的 webhook 服务具体点击链接 wechat_config 微信通知通过微信API发送。
# Whether to notify about resolved alerts.
[ send_resolved: boolean | default false ]# The API key to use when talking to the WeChat API.
[ api_secret: secret | default global.wechat_api_secret ]# The WeChat API URL.
[ api_url: string | default global.wechat_api_url ]# The corp id for authentication.
[ corp_id: string | default global.wechat_api_corp_id ]# API request data as defined by the WeChat API.
[ message: tmpl_string | default {{ template wechat.default.message . }} ]
# Type of the message type, supported values are text and markdown.
[ message_type: string | default text ]
[ agent_id: string | default {{ template wechat.default.agent_id . }} ]
[ to_user: string | default {{ template wechat.default.to_user . }} ]
[ to_party: string | default {{ template wechat.default.to_party . }} ]
[ to_tag: string | default {{ template wechat.default.to_tag . }} ]1.3 time_interval 时间间隔
time_interval
指定可在路由树中引用的命名时间间隔以表示在一天中的特定时间处于 静音或者激活 状态的特定路由。
time_intervals:# 一个 time_interval 开始- name: string # 此时间间隔的名称,可以在子路由中被引用。time_intervals:# 下面定义一个一个的时间间隔[ - time_interval_spec ... ]# 一个time_interval 结束time_interval_spec
包含时间间隔的实际定义。语法支持以下字段
time_intervals:- name: string # 此时间间隔的名称,可以在子路由中被引用。time_intervals:- times:[ - time_range ...]weekdays:[ - weekday_range ...]days_of_month:[ - days_of_month_range ...]months:[ - month_range ...]years:[ - year_range ...]location: string所有字段都是列表。在每个非空列表中必须满足至少一个元素才能与字段匹配。
如果未指定字段则任何值都将与该字段匹配。
为了使某个瞬间的时间与完整的时间间隔相匹配所有字段都必须匹配。
如果未指定时区则时间以UTC为单位。
一些字段支持区间和负指数详情如下。
time_range
包含开始时间和不包含结束时间的范围可以方便地表示在小时边界上开始/结束的时间。 例如start_time:17:00 和 end_time:24:00 将从 17:00 开始并在 24:00 之前结束。它们是这样规定的
time_intervals:- times:- start_time: HH:MMend_time: HH:MMweekday_range
一周中的日期列表一周从周日开始到周六结束。应按名称指定日期例如“Sunday”。
为了方便起见还接受形式为start_day:end_day的范围并且范围两端都包含。 例如要表示: 星期一到星期三星期六星期日应写成[monday:wednesday,saturday, sunday]
days_of_month_range
一个月中的数字天数列表。
天数从1开始。负值也可以接受从月底开始例如1月份的-1表示1月31日。 例如[1:5-3:-1]。超过月初或月底将导致它被钳制。 例如在2月份指定 [1:31] 将根据闰年将实际结束日期固定为28或29。包括两端。
month_range
由不区分大小写的名称例如“January”或数字标识的日历月份列表其中January1。
也可接受范围。例如[1:3may:augustdecember]。包括两端。
year_range
年份的数字列表。接受范围。例如[2020:20222030]。两端均包含。
location
与IANA时区数据库中的位置匹配的字符串例如 东八区即中国时区Asia/Shanghai。 location: Asia/Shanghai您也可以使用 Local 表示使用 Alertmanager 运行的机器作为本地时间的位置, 或使用 UTC 表示UTC时间。
如果未提供时区则时间间隔以UTC时间为单位。
注意在Windows上只有 Local 或 UTC 才受支持除非您使用 ZONEINFO 环境变量提供自定义时区数据库。
关于中国时区可以参考这篇知乎的文章 https://zhuanlan.zhihu.com/p/450867597
1.4 路由相关配置
通过与路由相关的设置可以根据时间配置警报的路由、聚合、抑制和静音方式。
route 根路由
route 块定义路由树中的节点及其子节点。
如果子节点中的某些可选配置未设置那些可选的配置参数就是用中括号括起来的配置参数将从其父节点继承。
每个警报都进入配置的顶级路由的路由树该路由树必须匹配所有警报即没有任何配置的匹配器。
然后它遍历子节点。如果 continue 设置为 false则在第一个匹配的子路由之后就停止继续匹配。
如果 continue 为 true则警报将继续与后续同级路由匹配。
如果警报与节点的任何子节点都不匹配没有匹配的子节点或不存在则会根据当前节点的配置参数来处理警报,一般会由默认 route 块配置的 receiver 处理。
# 根路由每个传入的警报都会经过这里
route:# 根路由不能有任何匹配器因为它是所有警报的入口点。# 它需要配置一个默认的接收器以便将与任何子路由不匹配的警报发送给此接收器。# 其值需要是全局 receivers 中配置的其中一个。[ receiver: string ]# 传入警报分组所依据的标签。# 例如 含有 clusterA 和 alertnameLatencyHigh 标签的多个警报将被批处理到一个组中。# 若要按所有可能的标签进行聚合请使用特殊值...作为唯一的标签名称例如group_by:[...]# 这有效地完全禁用了聚合按原样传递所有警报。# 这不太可能是你想要的除非你的警报量很低或者你的上游通知系统执行自己的分组。group_by: [alertname, cluster]# 当传入警报创建新的警报组时请至少等待 group_wait 时间后再发送初始通知。# 这种方式可以确保您在 group_wait 时间内获得同一组的多个警报这些警报在这个时间内进行批处理后再一起开始触发。group_wait: 30s# 百度翻译发送 有关添加到已发送初始通知的警报组中的新警报的通知之前等待的时间。# 自己的理解基本意思就是 对于一个已经发送过初始通知的组再次发送新的警报需要等待的时间。# 通常 5m 或者更长# 这个附上原文# How long to wait before sending a notification about new alerts # that are added to a group of alerts for which an initial notification has already been sent.group_interval: 5m# 如果已成功发送警报通知则在再次发送通知之前等待多长时间。通常约3小时或更长时间。# 请注意此参数由Alertmanager的“--data.reduration”配置标志隐式绑定。通知将在repeat_interval或数据保留期结束后重新发送以先发生的为准repeat_interval不应小于group_interval。repeat_interval: 3h# 警报是否应继续匹配后续同级节点。[ continue: boolean | default false ]# 警报必须满足的匹配器列表才能匹配节点, 一般在子路由中设置。matchers:[ - matcher ... ]# 路由应该静默的时间。# 与全局设置 time_intervals 字段中定义的静音时间间隔的名称相匹配。# 此外根节点不能有任何静音时间。# 当路由被静音时它不会发送任何通知但在其他情况下会正常工作包括如果未设置“continue”选项则结束路由匹配过程mute_time_intervals:[ - string ...]# 路由应处于活动状态的时间。它们必须与全局设置 time_intervals 字段中定义的时间间隔的名称相匹配。# 空值表示路线始终处于活动状态。 此外根节点不能有任何 active times。# 路由将仅在活动时发送通知但在其他情况下正常运行包括如果未设置 continue 选项则结束路由匹配过程。active_time_intervals:[ - string ...]# 以上所有属性都由所有子路由继承并且可以在每个路由上覆盖。# 一个或者更多子路由routers:[ - router ...]标签匹配器 matcher
标签匹配器是用在 routes and inhibition rules 之间进行警报的匹配。 也就是使用标签匹配器配置了匹配的规则如果哪个警报中所包含的标签和匹配的规则相符合就代表此警报是要处理的警报如果某个 子路由中使用此 匹配器那就是此子路由要处理这个警报如果某个 inhibition rules 中使用了此匹配器那就是这个 inhibition rules 处理此警报。
匹配器是一个字符串具体语法由三个标记组成
有效的标签名, !, ~, or !~ 中其中的一个运算符。~ 和 !~ 用于正则表达式的 匹配和不匹配。运算符后面是 UTF-8字符串可以用双引号括起来。在每个标记之前或之后可能存在任意数量的空白。
运算符右边的内容可以是空字符串支持反斜杠转义规则。
当有多个匹配器规则时候他们的书写语法是将每一个规则放在一个 yaml 语法的列表中它们之间的关系是 and。这意味着在针对给定警报上的标签进行测试时匹配器的所有规则评估结果必须为“true”。例如具有以下标签的警报
{project:beijing,service:mysql}必须使用如下匹配器规则进行匹配
route:routers:- matchers:- project beijing- service mysql下面使用正则表达式的匹配规则也是可以的
route:routers:- matchers:- project beijing- service ~ mysql|postgresql当然将上述匹配规则写成一行使用 [] 进行包裹也是可以的。
route:routers:- matchers:[project beijing, service ~ mysql|postgresql]将匹配规则内层在包上一层大括号也是支持的。
route:routers:- matchers:[{projectbeijing, service~ mysql|postgresql}]routers子路由配置 # 具体的一个一个的子路由树.routes:# 此子路由使用正则表达式进行匹配凡是警报的标签 service 的值是 foo1 或者 foo2 或者 baz 的警报就会# 走这个子路由- matchers:- service ^(foo1|foo2|baz)$# 凡是走这个子路由的警报使用如下的接收器接收警报信息 team-X-mails 是在全局中的 receivers 配置块中定义的# 一个接收器名称。 receiver: team-X-mails# 子路由中可以嵌套一个或者多个子路由# 当这个子路由中出现包含并且匹配标签 severity 的值是 critical 的# 将警报信息从 team-X-pager 接收器发送出去。# 否则还是返回给父级路由中定义的接收器 team-X-mails 发送警报。routes:- matchers:- severity criticalreceiver: team-X-pager- matchers:- service filesreceiver: team-Y-mails# 同样这个是在符合 service 的值是 files 中的警报中再挑选出配置 severity: critical 的警报# 从接收器 team-Y-pager 发送警报信息。否则继续返回给父级定义的接收器 team-Y-mails 发送出去警报信息。routes:- matchers:- severity criticalreceiver: team-Y-pager# This route handles all alerts coming from a database service. If theres# no team to handle it, it defaults to the DB team.- matchers:- service databasereceiver: team-DB-pager# Also group alerts by affected database.group_by: [alertname, cluster, database]routes:- matchers:- owner team-Xreceiver: team-X-pager- matchers:- owner team-Yreceiver: team-Y-pager示例 #根路具有的所有参数如果子路由中未设置这些参数则这些参数将由子路由继承。
route:group_wait: 30sgroup_interval: 5mrepeat_interval: 4hgroup_by: [cluster, alertname]receiver: default-receiver# 所有与以下子路由不匹配的警报都将保留在根节点上并使用接收器 default-receiver 发送警报信息。routes:# 所有servicemysql或servicecasandra的警报都使用接收器 database-pager 发送警报信息- receiver: database-pagergroup_wait: 10smatchers:- service~mysql|cassandra#所有带有 teamfrontend 标签的警报都匹配此子路由.# 它们按 product 和 environment 分组而不是按根路由中定义的 cluster 和 alertname 分组。# 并使用接收器 frontend-pager 发送警报信息。- receiver: frontend-pagergroup_by: [product, environment]matchers:- teamfrontend# 所有带有serviceinhouse服务标签的警报都与此子路由匹配。# 该路线将在下班时间和节假日期间静音。# 即使匹配它也将继续到下一个子路线- receiver: dev-pagermatchers:- serviceinhouse-servicemute_time_intervals:- offhours- holidayscontinue: true# 所有带有 serviceinhouse-service 标签的警报都与此子路由匹配# 该路由将仅在非工作时间和节假日期间有效。- receiver: on-call-pagermatchers:- serviceinhouse-serviceactive_time_intervals:- offhours- holidays1.5 抑制相关配置 Inhibition
这允许在系统或服务之间建立依赖关系以便在中断期间仅发送一组互连警报中最相关的警报。 例如一台服务器网络中断同时也配置的这台服务器上的相关服务的状态检查等警报那只需要发送此服务器网络中断的警报即可,服务器上的服务的状态告警可以被处理为 静音因为服务器上的服务状态的检查依赖此服务器的网络。
inhibit_rules
抑制规则允许在一个或多个匹配了 source_matchers 定义的匹配规则的警报正在触发的情况下使一组匹配了 target_matchers 定义的匹配规则的警报静默。
从语义上讲缺失的标签和值为空的标签是一回事。因此如果源警报和目标警报中都缺少以等号列出的所有标签名称则将应用禁止规则。
为了防止警报抑制自身与规则的目标端和源端匹配的警报不能被相同情况的警报包括自身抑制。但是我们建议选择目标和源匹配器以使警报永远不会同时匹配双方。它更容易推理而且不会引发这种特殊情况。
# 使抑制生效的匹配规则。
# 至少需要有一个警报完全匹配如下列表中的匹配规则抑制才会生效。
source_matchers:[ - matcher ... ]
# 同时满足的如下列表中匹配规则的所有警报将会被静音。
target_matchers:[ - matcher ... ]# 匹配 source_matchers 的源警报和匹配 target_matchers 的目标警报中它们的标签名必须都含有 equal 值中的标签名,且标签值必须相等才会使抑制生效。
[ equal: [ labelname, ... ] ]
示例
#如果同一警报的级别已经是严重级别我们将任何 warning 级别的通知都设为静默。
inhibit_rules:
- source_matchers:- severitycriticaltarget_matchers:- severitywarning# 如果警报名称相同则应用抑制。# 注意# 如果源警报和目标警报中都缺少“equal”中列出的所有标签名称则将应用抑制规则equal: [alertname]
2 静默配置
静默是可以让一个或多个警报在指定的某个时间段进入静默状态。
适用于单不限于如下场景
升级服务时候对所要升级的服务设置在升级的时间段不发送警报通知。在服务迁移的时候对涉及到的服务在迁移的时间段不发送警报通知。 ① 点击日历图标选择开始时间和结束时间 ② Matchers 中填写的是匹配标签的规则值需要使用双引号引起来③ Creater 填写创建者可以任意写④ 点击 进行添加可以多次添加⑤ Comment 填写关于这个静默的说明文字⑥ 最后点击 Create
添加之后再次点击 Silences 会看到所有的 静默列表。
