整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
快速完成Prometheus搭建中，我們部署了alertmanager，但是并不能跑起來。接下來我們需要考慮是用slack通知，還是郵件通知。
# vi /etc/alertmanager/alertmanager.yml
# 全局配置項
global:
resolve_timeout: '5m' #處理超時時間，默認為5min
smtp_smarthost: 'smtp.qq.com:587' # 郵箱smtp服務器代理
smtp_from: 'xxx@qq.com' # 發送郵箱名稱
smtp_auth_username: 'xxx@qq.com' # 郵箱名稱
smtp_auth_password: 'xxxxxxx' # 郵箱密碼或授權碼
smtp_require_tls: false
# 定義模板郵件
templates:
- '/etc/alertmanager/template/*.tmpl'
# 定義路由樹信息
route:
group_by: ['alertname'] # 報警分組依據
group_wait: 10s # 最初即第一次等待多久時間發送一組警報的通知
group_interval: 10s # 在發送新警報前的等待時間
repeat_interval: 5m # 發送重復警報的周期 對于email配置中，此項不可以設置過低，否則將會由于郵件發送太多頻繁，被smtp服務器拒絕
receiver: operations-team
# 定義警報接收者信息
receivers:
- name: 'operations-team'
email_configs: # 郵箱配置
- to: 'xxx@foxmail.com' # 接收警報的email配置
html: '{{ template "test.html" . }}' # 設定郵箱的內容模板
headers: { Subject: "[WARN] 報警郵件"} # 接收郵件的標題
slack_configs:
- api_url: "https://hooks.slack.com/services/TAX2D1UFK/B01GJE6SGV7/xxxxxxxxxxx"
channel: "#prometheus"
text: "{{ range .Alerts }} {{ .Annotations.description}}\n {{end}} {{ .CommonAnnotations.username}} "
title: "{{.CommonAnnotations.summary}}"
title_link: "{{.CommonAnnotations.link}}"
color: "{{.CommonAnnotations.color}}"
send_resolved: true
# 一個inhibition規則是在與另一組匹配器匹配的警報存在的條件下，使匹配一組匹配器的警報失效的規則。兩個警報必須具有一組相同的標簽。
# 這里的critical 會抑制warning 規則， 比如磁盤使用率超過90%， 那80%的告警就不會發送通知。
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname','instance']
- source_match:
alertname: 'NodeFilesystemSpaceUsage'
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname','instance']說明:
以上配置，會發送slack，同時發送郵件通知。如果只需要一個，去掉不需要的即可。
inhibit_rules是我們配置的抑制規則。
郵件通知，我們使用了test.html模板。
重啟alertmanager
systemctl restart alertmanager檢查下alertmanager頁面 http://192.168.0.107:9093/#/alerts ，如下界面說明啟動成功。
alertmanager
郵件通知模板/etc/alertmanager/template/test.html
{{ define "test.html" }}
<table border="1">
<tr>
<td>報警項</td>
<td>實例</td>
<td>概要</td>
<td>描述</td>
<td>開始時間</td>
<td>link</td>
</tr>
{{ range $i, $alert :=.Alerts }}
<tr>
<td>{{ .Labels.alertname }} </td>
<td>{{ .Labels.instance }} </td>
<td>{{ .Annotations.summary }}</td>
<td>{{ .Annotations.description }}</td>
<td>{{ .StartsAt.Format "2021-01-23 16:01:01" }}</td>
<td><a href="{{ .GeneratorURL }}">鏈接到Prometheus</a></td>
</tr>
{{ end }}
</table>
{{ end }}獲取slack webhook地址
1.打開https://slack.com/ ，注冊賬號
2.創建一個channel #prometheus
創建channel
3.添加APP
選中channel #prometheus
add an app
搜索"incoming-webhook",選中直接安裝即可。
incoming-webhook
在彈出的link里面找到 webhook URL
這個url 就是 alertmanager配置文件里面的api_url
api_url: "https://hooks.slack.com/services/TAX2D1UFK/B01GJE6SGV7/xxxxxxxxxxx"slack 配置完成。
1.登陸QQ郵箱網頁版，點擊設置
獲取授權碼，填入alertmanager里smtp_auth_password
smtp_auth_password: 'xxxxxxx' SLACK通知結果展示:
郵件通知結果展示:
rometheus發出告警時分為兩部分。首先，Prometheus按告警規則(rule_files配置塊)向Alertmanager發送告警（即告警規則是在Prometheus上定義的）。然后，由Alertmanager來管理這些告警，包括去重(Deduplicating)、分組(Grouping)、靜音(silencing)、抑制(inhibition)、聚合(aggregation )，最終將面要發出的告警通過電子郵件、webhook等方式將告警通知路由(route)給對應的聯系人。
分組：就是將具有相同性質的告警先分類，然后當作單個通知發送出來。比如A和B兩臺主機的磁盤(CPU/內存)使用率都在告警，則磁盤的告警就可以合并在一個通知中發送出來。可以想像某個服務部署了100個節點，在一次升版后因為bug，日志中均報同樣一類錯誤，如果不合并這類通知，那就是告警風暴。
抑制：就是某些告警觸發后，則抑制（禁止）另一些告警。比如收到一條告警提示集群故障無法訪問，那么在該集群上的所有其他警告應該被抑制。
靜音(默)：將某些在預期內的告警設置為靜默（即不發送告警）。靜默是基于配置匹配規則。Alertmanager會檢查從Prometheus推送過來的告警事件，看這些告警事件是否與配置的靜默規則能匹配上，如果匹配則不發送任何通知。配置靜默方法是在Alertmanager的Web界面中，也可以使用amtool工具。
總之：Alertmanager制定這一系列規則目的只有一個，就是提高告警質量。
配置Alertmanager來做告警通知主要分三個步驟：
一、安裝并配置Alertmanager
# tar -xvf alertmanager-0.20.0.linux-amd64.tar.gz
mv alertmanager-0.20.0.linux-amd64 /usr/local/alertmanager
# cat alertmanager.yml
global:
resolve_timeout: 5m
smtp_smarthost: 'smtp.mxhichina.com:465'
smtp_from: 'noreply@demo.com'
smtp_auth_username: 'noreply@demo.com'
smtp_auth_password: '1235698'
smtp_require_tls: false
templates:
- '/usr/local/alertmanager/template/default.tmpl'
route:
group_by: ['alertname']
group_wait: 30s
group_interval: 2m
repeat_interval: 10m
receiver: 'email'
# continue default is false
continue: true
receivers:
- name: 'email'
email_configs:
- to: 'cookingit222@163.com,itcooking222@163.com'
send_resolved: true
html: '{{ template "default.html" . }}'
headers: { Subject: "{{ .GroupLabels.SortedPairs.Values }} [{{ .Status | toUpper }}:{{ .Alerts.Firing | len }}]" }
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance']
alertmanager配置簡要說明：
global：全局配置，主要配置告警方式，如郵件、webhook等。
route：Prometheus的告警先是到達alertmanager的根路由(route)，alertmanager的根路由不能包含任何匹配項，因為根路由是所有告警的入口點。另外，根路由需要配置一個接收器(receiver)，用來處理那些沒有匹配到任何子路由的告警（如果沒有配置子路由，則全部由根路由發送告警），即缺省接收器。告警進入到根route后開始遍歷子route節點，如果匹配到，則將告警發送到該子route定義的receiver中，然后就停止匹配了。因為在route中continue默認為false，如果continue為true，則告警會繼續進行后續子route匹配。如果當前告警仍匹配不到任何的子route，則該告警將從其上一級(匹配)route或者根route發出（按最后匹配到的規則發出郵件）。
group_by：用于分組聚合，對告警通知按標簽(label)進行分組，將具有相同標簽或相同告警名稱(alertname)的告警通知聚合在一個組，然后作為一個通知發送。如果想完全禁用聚合，可以設置為group_by: [...]
group_wait: 當一個新的告警組被創建時，需要等待'group_wait'后才發送初始通知。這樣可以確保在發送等待前能聚合更多具有相同標簽的告警，最后合并為一個通知發送。
group_interval: 當第一次告警通知發出后，在新的評估周期內又收到了該分組最新的告警，則需等待'group_interval'時間后，開始發送為該組觸發的新告警，可以簡單理解為，group就相當于一個通道(channel)。
repeat_interval: 告警通知成功發送后，若問題一直未恢復，需再次重復發送的間隔。
查看你的告警路由樹，將alertmanager.yml配置文件復制到對話框，然后點擊"Draw Routing Tree"
https://www.prometheus.io/webtools/alerting/routing-tree-editor/
修改好配置文件后，可以使用amtool工具檢查配置
# ./amtool check-config alertmanager.yml
Checking 'alertmanager.yml' SUCCESS
# cat >/usr/lib/systemd/system/alertmanager.service <<EOF
[Unit]
Description=alertmanager
[Service]
ExecStart=/usr/local/alertmanager/alertmanager --config.file=/usr/local/alertmanager/alertmanager.yml --storage.path=/usr/local/alertmanager/data --web.listen-address=:9093 --data.retention=120h
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF
# systemctl enable alertmanager
# systemctl restart alertmanager
alertmanager默認運行端口是：9093
alertmanager也可以同prometheus一樣熱加載配置
1）向alertmanager進程發送SIGHUP信號，如：kill -SIGHUP alertmanager_pid
2）curl -X POST http://prometheus_ip:9093/-/reload
二、修改prometheus的配置，關聯Alertmanager服務，同時添加對alertmanager的監控
# Alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets:
- monitor01:9093
rule_files:
- "rules/*_rules.yml"
- "rules/*_alerts.yml"
......
- job_name: 'alertmanager'
static_configs:
- targets: ['localhost:9093']
labels:
app: alertmanager
三、修改prometheus的配置，添加記錄規則和告警規則。
# cat node_rules.yml
groups:
- name: node_rules
#interval: 15s
rules:
- record: instance:node_cpu_usage
expr: 100 - avg(irate(node_cpu_seconds_total{mode="idle"}[1m])) by (nodename) * 100
labels:
metric_type: CPU_monitor
- record: instance:node_1m_load
expr: node_load1
labels:
metric_type: load1m_monitor
- record: instance:node_mem_usage
expr: 100 - (node_memory_MemAvailable_bytes)/(node_memory_MemTotal_bytes) * 100
labels:
metric_type: Memory_monitor
- record: instance:node_root_partition_predit
expr: round(predict_linear(node_filesystem_free_bytes{device="rootfs",mountpoint="/"}[2h],12*3600)/(1024*1024*1024), 1)
labels:
metric_type: root_partition_monitor
# cat node_alerts.yml
groups:
- name: node_alerts
rules:
- alert: cpu_usage_over_threshold
expr: instance:node_cpu_usage > 80
for: 1m
labels:
severity: warning
annotations:
summary: 主機 {{ $labels.nodename }} 的 CPU使用率持續1分鐘超出閾值,當前為 {{humanize $value}} %
- alert: system_1m_load_over_threshold
expr: instance:node_1m_load > 20
for: 1m
labels:
severity: warning
annotations:
summary: 主機 {{ $labels.nodename }} 的 1分負載超出閾值,當前為 {{humanize $value}}
- alert: mem_usage_over_threshold
expr: instance:node_mem_usage > 80
for: 1m
annotations:
summary: 主機 {{ $labels.nodename }} 的 內存 使用率持續1分鐘超出閾值,當前為 {{humanize $value}} %
- alert: root_partition_usage_over_threshold
expr: instance:node_root_partition_predit < 60
for: 1m
annotations:
summary: 主機 {{ $labels.nodename }} 的 根分區 預計在12小時使用將達到 {{humanize $value}}GB,超出當前可用空間，請及時擴容!
for 表示告警持續的時長，若持續時長小于該時間就不發給alertmanager了，大于該時間再發。for的值不要小于prometheus中的scrape_interval，例如scrape_interval為30s，for為15s，如果觸發告警規則，則再經過for時長后也一定會告警，這是因為最新的度量指標還沒有拉取，在15s時仍會用原來值進行計算。另外，要注意的是只有在第一次觸發告警時才會等待(for)時長。
例如：10:43:00 觸發了集群A中的h1告警；10:43:10又觸發了集群A中的h2告警。則在10:44:10后發生一條告警是只包含h1的郵件，在10:44:20時會收到h1和h2聚合后的告警郵件，若h1和h2持續未恢復，則在repeat_interval后仍以聚合方式發送告警。
注：h1和h2告警名相同，只是在不同主機上。
完成上述配置后，主機CPU、負載、內存、磁盤超出閾值時就發觸發郵件告警。
上述配置僅是對主機資源做了監控，并且告警只發到了缺省聯系人組。設想一下，在實際生產環境中，可能會按產品線或業務功能進行分組來研發，不同的服務出現告警時只發送通知到對應的聯系人組，其他不相關的組不需要接告警收通知，這就需要我們修改告警路由規則，而Alertmanager的核心和最復雜的地方就在告警路由規則的設置上。
Prometheus的告警規則在推送給Alertmanager前有的三種狀態：
1、沒有觸發告警閾值時，狀態為：inactive
2、觸發了告警閾值但未滿足告警持續時間(for)時，狀態為：pending，如果不配置for或者指定for的值為0，則將跳過pending狀態。
3、已觸發告警閾值并達到告警持續時間，開始將告警事件推送到Alertmanager，此時狀態為：firing。
配置告警靜默(silence)，用于在預期內的維護升級等操作。
當我們在對系統進行維護升級時，通常不希望觸發告警通知；另外，當上游服務出現異常，想讓下游的服務不觸發告警，Prometheus將用于這種配置稱為silence（靜默）。silence用于設定一個(維護)時間段，如1小時，也可提前手動觸發silence過期，表示維護結束，恢復對應服務的告警通知功能。
設置silence的方式有以下2種：
1、登錄到alertmanager的控制臺操作
2、通過amtool命令進行操作
配置告警模板
Alertmanager的通知模板是基于Go模板系統，詳細可參考官網。
https://golang.org/pkg/text/template/
https://prometheus.io/docs/alerting/latest/notifications/#alert
https://prometheus.io/docs/prometheus/latest/configuration/template_reference/
模板配置步驟：
1、修改alertmanager.yml，配置模板地址，然后在每個receiver引用模板
templates:
- '/usr/local/alertmanager/template/default.tmpl'
...
...
html: '{{ template "default.html" . }}'
headers: { Subject: "{{ .GroupLabels.SortedPairs.Values }} [{{ .Status | toUpper }}:{{ .Alerts.Firing | len }}]" }
2、配置模板
default.tmpl
{{ define "default.html" }}
{{- if gt (len .Alerts.Firing) 0 -}}
[{{ .Status | toUpper }}:{{ .Alerts.Firing | len }}]
{{ range $i, $alert :=.Alerts }}
<pre>
告警節點：{{ index $alert.Labels "nodename" }}
告警服務：{{ index $alert.Labels "alertname" }}
報警詳情：{{ index $alert.Annotations "summary" }}
開始時間：{{ $alert.StartsAt }}
</pre>
{{ end }}
{{ end }}
{{- if gt (len .Alerts.Resolved) 0 -}}
[{{ .Status | toUpper }}:{{ .Alerts.Resolved | len }}]
{{ range $i, $alert :=.Alerts }}
<pre>
恢復節點：{{ index $alert.Labels "nodename" }}
恢復服務：{{ index $alert.Labels "alertname" }}
狀 態：{{ index $alert.Status }}
開始時間：{{ $alert.StartsAt }}
恢復時間：{{ $alert.EndsAt }}
</pre>
{{ end }}
{{ end }}
{{- end }}
注：告警模板如果配置有問題，會導致郵件發送失敗，注意觀察日志。
以下是靜默設置步驟：
1、登錄到alertmanager控制臺(http://IP:9093/#/alerts)，點擊上方菜單欄中Alerts，可看到當前有2個告警。
2、點擊右上角"New Silence"，創建Silence任務，具體設置如下，匹配規則支持正則。
注：可按instance或job_name等方式來進行正則匹配。
3、Silence創建成功后，可以看到處于Active狀態的Silence
總之，多實踐。
者 | 渡渡鳥
分享 | 喬克
與Zabbix告警不同，Prometheus將告警分為兩個部分：Prometheus 和 Alertmanager。其中Prometheus配置告警觸發規則，對指標進行監控和計算，將再將告警信息發送到Alertmanager中。Alertmanager對告警進行管理，比如合并抑制等操作。
image.png
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
