Prometheus05-Alertmanager

5.alertmanager

altermanagre告警机制

·Prometheus server采集各类监控指标，然后基于PromQL对这些指标定义阈值告警规则（Rules）。
·Prometheus server对告警规则周期性地进行计算，如果满足告警触发条件，便生成一条告警信息，并将其推送到Alertmanager组件。
·alertmanager收到告警信息后，会处理告警，进行分组（grouping）并将它们路由（routing）到正确的接收器（receiver），如Email、PagerDuty和HipChat等，最终把异常事件的通知发送给接收者。

告警管理方式

告警分组
·AlertManager将同类型的告警进行分组，合并多条告警到一个通知中。避免接收大量告警信息，阻碍故障定位
·告警分组、告警时间和告警接收器均是通过Alertmanager的配置文件来完成配置的

告警抑制
·当某告警已经发出，停止重复发送由此告警引发的其他异常或故障的告警
·抑制机制也是通过Alertmanager的配置文件进行设置的

告警静默
·告警静默（Silences）提供了一个简单的机制，可以根据标签快速对告警进行静默处理。对传入的告警进行匹配检查，如果接收到的告警符合静默的配置，Alertmanager则不会发送告警通知。管理员可以直接在Alertmanager的Web界面中临时屏蔽指定的告警通知

altermanager启动选项

二进制安装altermanager

1.解压安装alertmanager
tar -zxf alertmanager-xxx.tar.gz -C /usr/local
cd /usr/local
chown -R root:root alertmanager-xxx
ln -sv altermanager-xxx altermanager
cd altermanagre
alertmanager --version

2.systemctl管理 altermanagre
vi /usr/lib/systemd/system/alertmanager.service
[Unit]
Description=Prometheus Alertmanager Service
After=network.target

[Service]
Type=simple
User=root
Group=root
ExecStart=/data/alertmanager/alertmanager
--config.file "/data/alertmanager/alertmanager.yml”
--storage.path="/data/alertmanager/data/“
--data.retention=120h
--web.external-url"http:// 192.168.186.7:9093”
--web.listen-address=":9093"
Restart=on-failure

[Install]
WantedBy=multi-user.target”

systemctl daemon-reload
systemctl start altermanager

3.查看状态
http://127.0.0.1:9093/#/status

altermanager配置文件结构

alertmanager.yaml配置文件包括global，templates，route，receivers等
global块
包含Alertmanager的全局配置

template块
用于指定保存警报模板的路径

route块
·规定了将告警发送到receiver指定的目的地址的规则
·通过浏览器访问 https://prometheus.io/webtools/alerting/routing-tree-editor/，粘贴Alertmanager配置文件内容到编辑工具中，点击“Draw Routing Tree”按钮即可看到路由结构信息。

receivers块
·指定警报目的地
·每个receiver需要设置一个全局唯一名称，并且对应一个或者多个通知方式，包括邮箱、微信、PagerDuty、Webhook等

templates块
·告警模板可以自定义告警通知的格式及其包含的对应告警数据
·在templates路径下存放模板文件

inhibit_rules块
配置告警抑制

使用alertmanager自带的工具检查配置文件语法

cd /data/alertmanager
./amtool check-config alertmanager.yml

alertmanager命令的参数：

* -h, --help
* --config.file="alertmanager.yml"：Alertmanager配置文件名。
* --storage.path="data/"：存储数据的目录。
* --data.retention=120h：要保存数据多长时间。
* --alerts.gc-interval=30m：告警GC之间的间隔。
* --web.config.file=""：（实验）启用TLS或鉴权的配置文件路径。
* --web.external-url=WEB.EXTERNAL-URL
    * Alertmanager对外可访问的URL(例如，如果Alertmanager通过反向代理提供服务)。用于生成返回的相对和绝对链接
    * Alertmanager本身。如果URL包含路径部分，则它将用于为Alertmanager提供的所有HTTP端点添加前缀。如果省略，相关的URL组件将自动派生。
* --web.route-prefix=WEB.ROUTE-PREFIX：web端点内部路由的前缀。默认为--web.external-url的路径。
* --web.listen-address=":9093"：用于监听web界面和API的地址。
* --web.get-concurrency=0：并发处理的最大GET请求数。如果为负或为零，则极限为GOMAXPROC或8，取较大的值。
* --web.timeout=0：HTTP请求超时。如果为负或为零，则不设置超时。
* --cluster.listen-address="0.0.0.0:9094"：当前alertmanager实例监听的地址（默认是“0.0.0.0:9094”）。设置为空字符串禁用HA模式。
* --cluster.peer=CLUSTER.PEER ...：初始化时关联的其他alertmanager实例的地址。(可能重复)。
* --cluster.advertise-address=CLUSTER.ADVERTISE-ADDRESS：集群广播地址。
* --cluster.peer-timeout=15s：alertmanager之间发送通知的等待时间（默认是“15s”）。
* --cluster.gossip-interval=200ms：发送gossip消息的间隔时间。通过降低该值(更频繁)，gossip消息可以更快地在集群中传播，但以增加带宽为代价。（默认是“200ms”）
* --cluster.pushpull-interval=1m0s：gossip状态同步的时间间隔。值越小收敛越快，但消耗的带宽也会增加（默认是“1m0s”）。
* --cluster.tcp-timeout=10s：在与其他alertmanager进行链接、读、写时TCP的超时时间（默认是“10s”）。
* --cluster.probe-timeout=500ms：在判定其他alertmanager不可用之前的等待时间（默认是“500ms”）。
* --cluster.probe-interval=1s：探测其他alertmanager节点的时间间隔（默认是“1s”）。该值越低(更频繁)就可以越快地检测到故障节点，但代价是增加了带宽使用量。
* --cluster.settle-timeout=1m0s：在评估通知之前等待集群连接解决的最大时间。
* --cluster.reconnect-interval=10s：尝试重新连接丢失的alertmanager的时间间隔。
* --cluster.reconnect-timeout=6h0m0s：试图重新连接丢失的alertmanager的时间长度。
* --cluster.tls-config=""：（实验）可以在gossip协议中启用双向TLS的配置yaml文件路径。
* --cluster.allow-insecure-public-advertise-address-discovery：（实验）允许alertmanager发现并监听公网IP地址。
* --log.level=info：只记录具有给定严重性或以上级别的消息。One of: [debug, info, warn, error]
* --log.format=logfmt：日志信息的输出格式。One of: [logfmt, json]
* --version：显示版本。

altermanager配置文件示例

cat alertmanager.yml
global: # 全局配置模块
resolve_timeout: 5m # 用于设置处理超时时间，默认是5分钟
route: # 路由配置模块
group_by: ['alertname'] # 告警分组
group_wait: 10s # 10s内收到的同组告警在同一条告警通知中发送出去
group_interval: 10s # 同组之间发送告警通知的时间间隔
repeat_interval: 1h # 相同告警信息发送重复告警的周期
receiver: 'web.hook' # 使用的接收器为web.hook
receivers: # 接收器配置模块

• name: 'web.hook' # 设置接收器名称为web.hook
  webhook_configs: # 设置webhook地址
  • url: 'http://127.0.0.1:5001/'
    inhibit_rules: # 告警抑制功能模块
  • source_match:
    severity: 'critical' # 当存在源标签告警触发时抑制含有目标标签的告警
    target_match:
    severity: 'warning'
    equal: ['alertname', 'dev', 'instance'] # 保证该配置下标签内容相同才会被抑制”

摘录来自
Prometheus监控技术与实践
陈金窗等
此材料可能受版权保护。

prometheus与alertmanager集成

1.配置prometheus.yaml
1.1.指定altermanager地址
vim prometheus.yml
...
alerting:
alertmanagers:

• static_configs:
  • targets: ['192.168.13.140:9093']

1.1.指定alertmanager地址还可以使用服务发现
alerting:
alertmanagers:

• dns_sd_configs:
  • names: ['_alertmanager._tcp.example.com']

1.2.创建alertmanager监控job

• job_name: 'alertmanager'
  static_configs:
  • targets: ['localhost:9093']

1.3.指定报警规则模板文件
rule_files:

• '/usr/local/prometheus/rule/*.yml'

2.创建报警规则模板文件
vim /usr/local/prometheus/rule/alert.yml
groups:

• name: 主机状态-监控告警
  rules:
  • alert: 主机状态
    expr: up == 0
    for: 5m # 异常持续时间
    labels:
    severity: warning
    annotations:
    summary: "{{\(labels.instance}}:服务器宕机" description: "{{\)labels.instance}}:服务器延时超过5分钟”

告警接收-邮件告警

vim alertmanagre.yml
global:
resolve_timeout: 5m
smtp_smarthost: 'smtp.163.com:25'
smtp_from: 'woxuexiyong@163.com'
smtp_auth_username: 'woxuexieyong@163.com'
smtp_auth_password: ' YourStrongPassword '
route:
group_by: ['alertname']
group_wait: 10s
group_interval: 10s
repeat_interval: 1h
receiver: 'email'
receivers:
- name: 'email'
email_configs:
- to: 'zhengweila@sohu.com’ # 接收告警的地址
headers: { Subject: " WARNING-告警邮件” } # 告警邮件的标题
send_resolved: true # 解除告警后是否发送通知，默认false
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance']”

告警接收-企微报警

1.创建企业微信号，创建prometheus应用

2.利用小工具测试在企业微信新建的Prometheus应用是否可用

下载，安装，使用
wget https://raw.githubusercontent.com/OneOaaS/weixin-alert/master/weixin_linux_amd64
chmod +x weixin_linux_amd64
./weixin_linux_amd64 --corpid=ww2f9229e0804f8faf
--corpsecret=U_HKt5xV7ZPjXTm4aFfDCfAwKguXmyrYhxTJFVTfynU
--msg="您好，告警测试，感谢工具提供者！"
--user=LiuZhengWei
--agentid=1000002

选项说明：
·--corpid：设置为企业微信中记录的“企业ID”。
·--corpsecret：设置为创建的Prometheus应用中记录的“Secret”内容。
·--msg：自定义的信息内容。
·--user：设置为企业微信中使用的成员账号。
·--agentid：设置为创建的Prometheus应用中记录的“AgentId”内容。

运行小工具后，显示结果：{"errcode":0,"errmsg":"ok","invaliduser":""}，表示成功发送信息，
同时在企业微信的Prometheus应用也收到了“您好，告警测试，感谢工具提供者！”，
说明企业微信中新建Prometheus应用工作正常。

3.编辑配置alertmanager配置文件
vim alertmanager.yaml
global:
resolve_timeout: 5m
# 企业微信API地址
wechat_api_url: 'https://qyapi.weixin.qq.com/cgi-bin/'
# 企业微信中记录的“企业ID”
wechat_api_corp_id: 'ww2f9229e0804f8faf'
# 企业微信中创建的Prometheus应用中记录的“Secret”内容
wechat_api_secret: 'U_HKt5xV7ZPjXTm4aFfDCfAwKguXmyrYhxTJFVTfynU'
route:
group_by: ['alertname']
group_wait: 10s
group_interval: 10s
repeat_interval: 1h
receiver: 'wechat'
receivers:
- name: 'wechat'
wechat_configs:
# 告警解除后是否发送通知，默认是false
- send_resolved: true
# 设置为企业微信中的“部门ID”
to_party: ‘1'
# 设置为企业微信中创建的Prometheus应用中记录的“AgentId”内容
agent_id: ‘1000002'
# 设置为企业微信中记录的“企业ID”，默认为全局配置内容，但建议设置
corp_id: ‘ww2f9229e0804f8faf'
# 设置为企业微信中使用的账号
to_user: ‘LiuZhengWei'
# 企业微信API地址，建议设置
api_url: 'https://qyapi.weixin.qq.com/cgi-bin/‘
# 设置为企业微信中新建的Prometheus应用中记录的“Secret”内容，建议设置，不要使用默认的全局设置
api_secret: 'U_HKt5xV7ZPjXTm4aFfDCfAwKguXmyrYhxTJFVTfynU'
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance’]”

检查配置文件

cd /data/alertmanager
./amtool check-config alertmanager.yml

告警接收-“基于Webhook的钉钉接收告警”

1.创建钉钉机器人

2.prometheus-webhook-dingtalk工具
用于生成DingTalk通知的工具

下载、安装、使用：
wget https://github.com/timonwong/prometheus-webhook-dingtalk/releases/download/v0.3.0/prometheus-webhook-dingtalk-0.3.0.linux-amd64.tar.gz
tar zxvf prometheus-webhook-dingtalk-0.3.0.linux-amd64.tar.gz -C /data
cd /data/ # 安装路径可以自定义修订
ln -sv prometheus-webhook-dingtalk-0.3.0.linux-amd64 prometheus-webhook-dingtalk
cd /data/prometheus-webhook-dingtalk

前台启动

./prometheus-webhook-dingtalk
--ding.profile="webhook1=https://oapi.dingtalk.com/robot/send?access_token=xxxxx"
--ding.profile="webhook2=https://oapi.dingtalk.com/robot/send?access_token=yyyyy”

后台启动

nohup ./prometheus-webhook-dingtalk
--ding.profile="ops_dingding=https://oapi.dingtalk.com/robot/send?access_token=ca001e3def5af95a5f294a34e3cc0b427ef4c0f139c09a414580b766c0767f8b"&

可以看到默认端口8060已经开启

netstat -antup |grep 8060

·使用./prometheus-webhook-dingtalk-h可以查看帮助
·多次使用--ding.profile可以在命令行中指定多个已经保存好的Webhook地址

3.编辑alertmanager配置文件
“# cat alertmanager.yml
global:
resolve_timeout: 5m”
route:
receiver: webhook
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
group_by: [alertname]
routes:
- receiver: webhook
group_wait: 10s
match:
team: node
receivers:
- name: webhook
webhook_configs:
# 发送HTTP POST请求的端点，也就是以上配置的工具地址
- url: http://localhost:8060/dingtalk/ops_dingding/send
send_resolved: true

告警通知模版

vim alertmanager.yml
…
templates:

• /usr/local/alertmanager/template/*.tmpl

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

“https://prometheus.io/docs/alerting/notifications/”

摘录来自
Prometheus监控技术与实践
陈金窗等
此材料可能受版权保护。

告警状态

·Inactive： 没有满足触发条件，警报未激活
·Pending： 已满足触发条件，但未满足告警持续时间，即未满足告警中for子句中指定的持续时间
·Firing： 已满足触发条件且已经超过for子句中指定的持续时间

·带有for子句的告警将首先转换为Pending状态，然后转换为Firing状态，至少需要两个计算周期告警才被触发。
·从Pending状态到Firing状态的转换，确保了告警的有效性。
·没有for子句的告警会自动从Inactive状态转换为Firing状态，只需要一个计算周期即可被触发。

在一系列的运行过程中，Prometheus还将为Pending或Firing状态的每个告警创建一个ALERTS指标名称，格式如下：
ALERTS{alertname="", alertstate="pending|firing", }

告警的生命周期

1·节点的CPU不断变化，每隔一段由scrape_interval定义的时间被Prometheus抓取一次，对我们来说是15秒。
2·根据每个evaluation_interval的指标来评估警报规则，对我们来说还是15秒。
3·当警报表达式为true时（对于我们来说是CPU超过80％），会创建一个警报并转换到Pending状态，执行for子句。
4·在下一个评估周期中，如果警报测试表达式仍然为true，则检查for的持续时间。如果超过了持续时间，则警报将转换为Firing，生成通知并将其推送到Alertmanager。
5·如果警报测试表达式不再为true，则Prometheus会将警报规则的状态从Pending更改为Inactive。

路由

route:
group_by: ['alertname']
group_wait: 30s
group_interval: 5m
repeat_interval: 3h # 重新发送相同警报的时间间隔
receiver: 'email' #对应下面receivers中的name
routes:

• match:
  severity: critical # severity标签的值为critical，将它们发送到pager接收器
  receiver: pager

• match_re:
  severity: ^(warning|critical)$
  receiver: support_team
  receivers:

• name: 'email'
  email_configs:

  • to: 'alerts@example.com'

• name: 'support_team'
  email_configs:

  • to: 'support@example.com'

• name: 'pager'
  email_configs:

  • to: 'pager@example.com'

  分组还会更改Alertmanager的行为。 如果引发了新警报， 那么Alertmanager将等待下一个选项group_wait中指定的时间段， 以便在触发警报之前查看是否收到该组中的其他警报。 你可以将其视为警报缓冲。 在我们的例子中， 这个等待时间是30秒。
  在发出警报后， 如果收到来自该分组的下一次评估的新警报， 那么Alertmanager将等待group_interval选项中指定的时间段（即5分钟） ， 然后再发送新警报。 这可以防止警报分组的警报泛滥。
  我们还指定了repeat_interval。 这个暂停并不适用于我们的警报组， 而是适用于单个警报， 并且是等待重新发送相同警报的时间段， 我们指定为3个小时。

路由分支
标签severity值为critical，并且标签service值为app，报警路由到support_team接收器
routes:

• match:
  severity: critical
  receiver: pager
  routes:
  • match:
    service: app
    receiver: support_team

silence（报警静音）

让系统知道我们已经停止服务并开始维护
可以使用以下两种方法来设置silence：
·通过Alertmanager Web控制台；
·通过amtool命令行工具。

通过Alertmanager Web控制台
新建silence，指定时间和匹配条件。preview alerts可以预览silence的作用范围

通过amtool命令行工具
设置
amtool --alertmanager.url=http://localhost:9093 silence add alertname=InstancesGone service=application1
使用amtool创建的silence被设置为一小时后自动过期， 可以使用--expires和--expire-on参数来指定更长的时间或窗口。
查询
amtool --alertmanager.url=http://localhost:9093 silence query
过期
amtool --alertmanager.url=http://localhost:9093 silence expire

amtool配置文件
默认配置文件路径是$HOME/.config/amtool/config.yml或/etc/amtool/config.yml(我这没有)
可以为某些选项创建一个YAML配置文件， 而不必每次都指定--alertmanager.url参数
alertmanager.url: "http://localhost:9093"
author: abc@example.com
comment_required: true

配置集群

am1、am2、am3为三台主句。启动三个alertmanager。要求配置文件完全相同
am1$alertmanager--config.filealertmanager.yml--cluster.listen-address172.19.0.10:8001am2$ alertmanager --config.file alertmanager.yml --cluster.listen-address 172.19.0.20:8001 --cluster.peer 172.19.0.10:8001
am3$ alertmanager --config.file alertmanager.yml --cluster.listen-address 172.19.0.30:8001 --cluster.peer 172.19.0.10:8001