告警介紹
如下所示,通過在Prometheus中定義AlertRule(告警規則),Prometheus會週期性的對告警規則進行計算,如果滿足告警觸發條件就會向Alertmanager發送告警信息,以郵件等方式通知運維人員。
Alertmanager可以對這些告警信息進行進一步的處理,比如當接收到大量重複告警時能夠消除重複的告警信息,同時對告警信息進行分組並且路由到正確的通知方。
告警規則rules
舉個告警規則配置的例子,在目錄/etc/prometheus/rules/
下創建告警規則文件test-alert.rules
內容如下:
groups:
- name: example
rules:
# Alert for any instance that is unreachable for >5 minutes.
- alert: InstanceDown
expr: up == 0
for: 5m
labels:
severity: page
annotations:
summary: "Instance {{ $labels.instance }} down"
description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."
# Alert for any instance that has a median request latency >1s.
- alert: APIHighRequestLatency
expr: api_http_request_latencies_second{quantile="0.5"} > 1
for: 10m
annotations:
summary: "High request latency on {{ $labels.instance }}"
description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"
修改Prometheus配置文件prometheus.yml
,添加以下配置:
rule_files:
- /etc/prometheus/rules/*.rules
重啓Prometheus後訪問Prometheus UI:http://127.0.0.1:9090/rules
可以查看當前以加載的規則文件。
對於上述例子,可以手動停止node exporter來模擬up == 0
時的告警。
在告警規則文件中,我們可以將一組相關的規則(rules)設置定義在一個group下。一條告警規則(rules)主要由以下幾部分組成:
- alert:告警規則的名稱。
- expr:基於PromQL表達式告警觸發條件,用於計算是否有時間序列滿足該條件。
- for:評估等待時間,可選參數。用於表示只有當觸發條件持續一段時間後才發送告警。在等待期間新產生告警的狀態爲
PENDING
,等待期後爲FIRING
。 - labels:自定義標籤,允許用戶指定要附加到告警上的一組附加標籤。
- annotations:用於指定一組附加信息,比如用於描述告警詳細信息的文字等,annotations的內容在告警產生時會一同作爲參數發送到Alertmanager。
Prometheus支持模板化label和annotations的中標籤的值。
通過$labels.<labelname>
變量可以訪問當前告警實例中指定標籤的值。$value
則可以獲取當前PromQL表達式計算的樣本值。
安裝Alertmanager
下載地址:https://prometheus.io/download/
tar -xvf alertmanager-0.16.2.linux-amd64.tar.gz
./alertmanager
編輯Prometheus配置文件prometheus.yml
,並添加以下內容:
alerting:
alertmanagers:
- static_configs:
targets: ['localhost:9093']
Alertmanager啓動後可以通過9093
端口訪問UI。
配置Alertmanager
Alertmanager主要負責對Prometheus產生的告警進行統一處理,Alertmanager解壓後會包含一個默認的alertmanager.yml
配置文件,內容如下所示:
global:
resolve_timeout: 5m
route:
group_by: ['alertname']
group_wait: 10s
group_interval: 10s
repeat_interval: 1h
receiver: 'web.hook'
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']
在Alertmanager配置中一般會包含以下幾個主要部分:
- 全局配置(global):用於定義一些全局的公共參數,如
resolve_timeout
,該參數定義了當Alertmanager持續多長時間未接收到告警後標記告警狀態爲resolved
(已解決); - 模板(templates):用於定義告警通知時的模板,如HTML模板,郵件模板等;
- 告警路由(route):主要定義了告警的路由匹配規則,以及Alertmanager需要將匹配到的告警發送給哪一個receiver,;
- 接收人(receivers):接收人是一個抽象的概念,它可以是一個郵箱也可以是微信,Slack或者Webhook等,接收人一般配合告警路由使用;
- 抑制規則(inhibit_rules):可以避免當某種問題告警產生之後用戶接收到大量由此問題導致的一系列的其它告警通知。合理設置抑制規則可以減少垃圾告警的產生。
路由route
在上述例子中,我們只定義了一個路由,那就意味着所有由Prometheus產生的告警在發送到Alertmanager之後都會通過名爲web.hook
的receiver接收。實際上,對於不同級別的告警,會有不同的處理方式,因此在route中,我們還可以定義更多的子Route。
每一個告警都會從配置文件中頂級的route進入路由樹,需要注意的是頂級的route必須匹配所有告警(即不能有任何的匹配設置match和match_re),默認情況下,告警進入到頂級route後會遍歷所有的子節點,直到找到最深的匹配route,並將告警發送到該route定義的receiver中。但如果route中設置continue
的值爲false,那麼告警在匹配到第一個子節點之後就直接停止。如果continue
爲true,報警則會繼續進行後續子節點的匹配。如果當前告警匹配不到任何的子節點,那該告警將會基於當前路由節點的接收器配置方式進行處理。
其中告警的匹配有兩種方式可以選擇。一種方式基於字符串驗證,通過設置match規則判斷當前告警中是否存在標籤labelname並且其值等於labelvalue。第二種方式則基於正則表達式,通過設置match_re驗證當前告警標籤的值是否滿足正則表達式的內容。
如下例子:
route:
receiver: 'default-receiver'
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
group_by: [cluster, alertname]
routes:
- receiver: 'database-pager'
group_wait: 10s
match_re:
service: mysql|cassandra
- receiver: 'frontend-pager'
group_by: [product, environment]
match:
team: frontend
分組group
Alertmanager可以對告警通知進行分組,將多條告警合合併爲一個通知。這裏我們可以使用group_by
來定義分組規則。基於告警中包含的標籤,如果滿足group_by
中定義標籤名稱,那麼這些告警將會合併爲一個通知發送給接收器。
有的時候爲了能夠一次性收集和發送更多的相關信息時,可以通過group_wait
參數設置等待時間,如果在等待時間內當前group接收到了新的告警,這些告警將會合併爲一個通知向receiver發送。
而group_interval
配置,則用於定義相同的Gourp之間發送告警通知的時間間隔。
郵件通知
集成163郵箱通知的配置例子如下:
global:
smtp_smarthost: 'smtp.163.com:25' #163服務器
smtp_from: '[email protected]' #發郵件的郵箱
smtp_auth_username: '[email protected]' #發郵件的郵箱用戶名,也就是你的郵箱
smtp_auth_password: 'XXX' #發郵件的郵箱密碼
route:
group_by: ['alertname']
repeat_interval: 1h
receiver: live-monitoring
receivers:
- name: 'live-monitoring'
email_configs:
- to: '[email protected]' #收郵件的郵箱