Prometheus之Alertmanager告警(七)
一、部署Alertmanager服務
1.1 alertmanager服務介紹
在Prometheus平臺中,警報由獨立的組件Alertmanager處理。通常情況下,我們首先告訴Prometheus Alertmanager所在的位置,然后在Prometheus配置中創建警報規則,最后配置Alertmanager來處理警報并發送給接收者(郵件,webhook、slack等)。
軟件下載地址:
https://prometheus.io/download/ https://github.com/prometheus/alertmanager/releases
1.2alertmanager服務部署
Anertmanager可以不用和Prometheus部署在同一臺機器,只要服務之間可以通信即可。
# wget https://github.com/prometheus/alertmanager/releases/download/v0.20.0/alertmanager-0.20.0.linux-amd64.tar.gz # tar xf alertmanager-0.20.0.linux-amd64.tar.gz -C /usr/local/ # ln -s /usr/local/alertmanager-0.20.0.linux-amd64/ /usr/local/alertmanager # 修改alertmanager配置文件 # cat alertmanager.yml global: resolve_timeout: 5m smtp_smarthost: 'smtp.163.com:25' smtp_from: 'gaojing@163.com' smtp_auth_username: 'gaojing@163.com' smtp_auth_password: 'password' smtp_require_tls: false route: group_by: ['alertname'] # 分組標簽 group_wait: 10s # 分組等待時間,同一組內在10秒鐘內還有其它告警,如果有則一同發送 group_interval: 10s # 上下兩組間隔時間 repeat_interval: 1h # 重復告警間隔時間 receiver: 'mail' # 接收者是誰 receivers: # 定義接收者,將告警發送給誰 - name: 'web.hook' webhook_configs: - url: 'http://127.0.0.1:5001/' - name: 'mail' email_configs: - to: '532141928@qq.com' # 檢查配置文件 # ./amtool check-config alertmanager.yml # 使用systemd來管理alertmanager服務 # cat /usr/lib/systemd/system/alertmanager.service [Unit] Description=https://prometheus.io [Service] Restart=on-failure ExecStart=/usr/local/alertmanager/alertmanager --config.file=/usr/local/alertmanager/alertmanager.yml [Install] WantedBy=multi-user.target # 啟動alertmanager服務 # systemctl daemon-reload # systemctl start alertmanager # systemctl enable alertmanager
二、配置Prometheus與alertmanager集成
2.1配置prometheus與alertmanager告警
配置告警規則可參考:https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/
# vim /usr/local/prometheus/prometheus.yml
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
alerting:
alertmanagers:
- static_configs:
- targets:
- 127.0.0.1:9093 # alertmanager的通信地址
rule_files:
- "rules/*.yml" # alertmanager使用的配置文件存放地址
# mkdir /usr/local/prometheus/rules
# cat /usr/local/prometheus/rules/general.yml
groups:
- name: example
rules:
- alert: InstanceDown
expr: up == 0 # 表達式當前實例服務狀態,1為正常
for: 3m # 告警持續時間5分鐘
labels:
severity: page # 告警級別
annotations:
summary: "Instance {{ $labels.instance }} down"
description: "{{ $labels.instance }} of job {{ $labels.job }} 已經停止工作3分鐘."
# /usr/local/prometheus/promtool check config /usr/local/prometheus/prometheus.yml
Checking /usr/local/prometheus/prometheus.yml
SUCCESS: 1 rule files found
Checking /usr/local/prometheus/rules/general.yml
SUCCESS: 1 rules found
# systemctl restart prometheus.service
重啟服務之后就能看到新的規則:
停止一個服務進行驗證
2.2告警狀態
Inactive:這里什么都沒有發生。
Pending:已觸發閾值,但未滿足告警持續時間(即rule中的for字段)
Firing:已觸發閾值且滿足告警持續時間。警報發送到Notification Pipeline,經過處理,發送給接受者。
這樣的目的是多次判斷失敗才發告警,減少郵件。
查看郵箱已經收到郵件:
2.3告警分配到指定接收到組,處理流程如下
1.接收到Alert,根據labels判斷屬于哪些Route(可存在多個Route,一個Route有多個Group,一個Group有多個Alert)。
2.將Alert分配到Group中,沒有則新建Group。
3.新的Group等待group_wait指定的時間(等待時可能收到同一Group的Alert),根據resolve_timeout判斷Alert是否解決,然后發送通知。
4.已有的Group等待group_interval指定的時間,判斷Alert是否解決,當上次發送通知到現在的間隔大于repeat_interval或者Group有更新時會發送通知。
route:
receiver: 'default-receiver' # 所有不匹配以下子路由的告警都將保留在根節點,并發送到“default-receiver”
group_wait: 30s # 為一個組發送通知的初始等待時間,默認30s
group_interval: 5m # 在發送新告警前的等待時間。通常5m或以上
repeat_interval: 1h # 發送重復告警的周期。如果已經發送了通知,再次發送之前需要等待多長時間。
group_by: [cluster, alertname] # 報警分組依據
routes:
- receiver: 'database-pager' # 所有service=mysql或者service=cassandra的告警分配到數據庫接收端
group_wait: 10s
match_re:
service: mysql|cassandra
- receiver: 'frontend-pager' # 所有帶有team=frontend標簽的告警都與此子路由匹配,它們是按產品和環境分組的,而不是集群
group_by: [product, environment]
match:
team: frontend
receivers: # 定義接收者,將告警發送給誰
- name: 'database-pager'
webhook_configs:
- url: 'http://127.0.0.1:5001/'
- name: 'frontend-pager'
email_configs:
- to: '532141928@qq.com'
三、告警的收斂(分組、抑制、靜默)
告警面臨最大問題,是警報太多,相當于狼來了的形式。收件人很容易麻木,不再繼續理會。關鍵的告警常常被淹沒。在一問題中,alertmanger在一定程度上得到很好解決。
Prometheus成功的把一條告警發給了Altermanager,而Altermanager并不是簡簡單單的直接發送出去,這樣就會導致告警信息過多,重要告警被淹沒。所以需要對告警做合理的收斂。
告警收斂手段:
分組(group):將類似性質的警報分類為單個通知 (相同組中的告警合并到一封郵件中進行發送 - alert: InstanceDown)
抑制(Inhibition):當警報發出后,停止重復發送由此警報引發的其他警報
靜默(Silences):是一種簡單的特定時間靜音提醒的機制
抑制
# vim /usr/local/alertmanager/alertmanager.yml
inhibit_rules: # 抑制 告警收斂 發送關鍵告警
- source_match:
severity: 'critical' # 如果是此級別的告警,就會忽略下面warning級別告警郵件的發送
target_match:
severity: 'warning'
equal: ['app', 'instance'] # 根據標簽來判斷主機
靜默
特定的時間內不再發送告警,訪問IP:9093端口在WEB頁面進行配置,一般用來在維護階段組止預期的告警通知。
觸發告警的流程:
1.Prometheus Server監控目標主機上暴露的http接口(這里假設接口A),通過上述Promethes配置的'scrape_interval'定義的時間間隔,定期采集目標主機上監控數據。
2.當接口A不可用的時候,Server端會持續的嘗試從接口中取數據,直到"scrape_timeout"時間后停止嘗試。這時候把接口的狀態變為"DOWN"。
3.Prometheus同時根據配置的"evaluation_interval"的時間間隔,定期(默認1min)的對Alert Rule進行評估;當到達評估周期的時候,發現接口A為DOWN,即UP=0為真,激活Alert,進入“PENDING”狀態,并記錄當前active的時間;
4.當下一個alert rule的評估周期到來的時候,發現UP=0繼續為真,然后判斷警報Active的時間是否已經超出rule里的"for" 持續時間,如果未超出,則進入下一個評估周期;如果時間超出,則alert的狀態變為"FIRING";同時調用Alertmanager接口,發送相關報警數據。
5.AlertManager收到報警數據后,會將警報信息進行分組,然后根據alertmanager配置的"group_wait"時間先進行等待。等wait時間過后再發送報警信息。
6.屬于同一個Alert Group的警報,在等待的過程中可能進入新的alert,如果之前的報警已經成功發出,那么間隔"group_interval"的時間間隔后再重新發送報警信息。比如配置的是郵件報警,那么同屬一個group的報警信息會匯總在一個郵件里進行發送。
7.如果Alert Group里的警報一直沒發生變化并且已經成功發送,等待"repeat_interval"時間間隔之后再重復發送相同的報警郵件;如果之前的警報沒有成功發送,則相當于觸發第6條條件,則需要等待group_interval時間間隔后重復發送。
8.同時最后至于警報信息具體發給誰,滿足什么樣的條件下指定警報接收人,設置不同報警發送頻率,這里有alertmanager的route路由規則進行配置。
四、自定義告警
自定義磁盤、CPU、內存大于80%的告警
# vim /usr/local/prometheus/rules/node.yml
groups:
- name: node.rules
rules:
- alert: NodeFilesystemUsage
expr: 100 - (node_filesystem_free_bytes{fstype=~"ext4|xfs"} / node_filesystem_size_bytes{fstype=~"ext4|xfs"} * 100) > 80
for: 2m
labels:
severity: warning
annotations:
summary: "{{$labels.instance}}: {{$labels.mountpoint }} 分區使用過高"
description: "{{$labels.instance}}: {{$labels.mountpoint }} 分區使用大于 80% (當前值: {{ $value }})"
- alert: NodeMemoryUsage
expr: 100 - (node_memory_MemFree_bytes+node_memory_Cached_bytes+node_memory_Buffers_bytes) / node_memory_MemTotal_bytes * 100 > 80
for: 2m
labels:
severity: warning
annotations:
summary: "{{$labels.instance}}: 內存使用過高"
description: "{{$labels.instance}}: 內存使用大于 80% (當前值: {{ $value }})"
- alert: NodeCPUUsage
expr: 100 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100) > 80
for: 2m
labels:
severity: warning
annotations:
summary: "{{$labels.instance}}: CPU使用過高"
description: "{{$labels.instance}}: CPU使用大于 80% (當前值: {{ $value }})"
# /usr/local/prometheus/promtool check config /usr/local/prometheus/prometheus.yml
Checking /usr/local/prometheus/prometheus.yml
SUCCESS: 2 rule files found
Checking /usr/local/prometheus/rules/general.yml
SUCCESS: 1 rules found
Checking /usr/local/prometheus/rules/node.yml
SUCCESS: 3 rules found
# systemctl restart prometheus.service
總結
以上是生活随笔為你收集整理的Prometheus之Alertmanager告警(七)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: iOS H5页面打开APP技术总结
- 下一篇: 手动添加Keil的固件包Packs