本章節主要講解Alertmanager高可用的搭建與配置的詳細的內容。web
爲了提高Prometheus的服務可靠性，咱們會部署兩個或多個的Prometheus服務，兩個Prometheus具備相同的配置（Job配、告警規則、等），當其中一個Down掉了之後，能夠保證Prometheus持續可用。bash
AlertManager自帶警報分組機制，即便不一樣的Prometheus分別發送相同的警報給Alertmanager，Alertmanager也會自動把這些警報合併處理。微信
| 去重 | 分組 | 路由 |
|---|---|---|
| Daduplicates | Groups | Route |
| 將相同的警報合併成一個 | 根據定義的分組 | 通過路由分發給指定的receiver |
雖然Alertmanager 可以同時處理多個相同的Prometheus的產生的警報，若是部署的Alertmanager是單節點，那就存在明顯的的單點故障風險，當Alertmanager節點down機之後，警報功能則不可用。架構
解決這個問題的方法就是使用傳統的HA架構模式，部署Alertmanager多節點。可是因爲Alertmanager之間關聯存在不能知足HA的需求，所以會致使警報通知被Alertmanager重複發送屢次的問題。編輯器
Alertmanager爲了解決這個問題，引入了Gossip機制，爲多個Alertmanager之間提供信息傳遞機制。確保及時的在多個Alertmanager分別接受到相同的警報信息的狀況下，不會發送重複的警報信息給Receiver.測試
Gossip 機制
要知道什麼是Gossip機制，必須瞭解清楚Alertmanager中的每一次警報通知是如何產生的，下面一圖很詳細的闡述了警報個流程：flex
| 階段 | 描述 |
|---|---|
Silence |
在這個階段中Alertmanager會判斷當前通知是否匹配任何靜默規則；若是沒有則進入下一個階段，不然會中斷流程不發送通知。 |
Wait |
Alertmanager 會根據當前集羣中所處在的順序[index]，等待 index * 5s 的時間。 |
Dedup |
當等待結束完成，進入 Dedup 階段，這時會判斷當前Alertmanager TSDB中警報是否已經發送，若是發送則中斷流程，不發送警報。 |
Send |
若是上面的未發送，則進入 Send 階段，發送警報通知。 |
Gossip |
警報發送成功之後，進入最後一個階段 Gossip ，通知其餘Alertmanager節點，當前警報已經發送成功。其餘Alertmanager節點會保存當前已經發送過的警報記錄。 |
Gossip倆個關鍵：url
-
Alertmanager 節點之間的Silence設置相同，這樣確保了設置爲靜默的警報都不會對外發送spa
-
Alertmanager 節點之間經過Gossip機制同步警報通知狀態，而且在流程中標記Wait階段，保證警報是依次被集羣中的Alertmanager節點讀取並處理。.net
搭建本地 Alertmanager 集羣
啓動Alertmanager集羣以前，須要瞭解一些集羣相關的參數
| 參數 | 說明 |
|---|---|
--cluster.listen-address="0.0.0.0:9094" |
集羣服務監聽端口 |
--cluster.peer |
初始化關聯其餘節點的監聽地址 |
--cluster.advertise-address |
廣播地址 |
--cluster.gossip-interval |
集羣消息傳播時間，默認 200s |
--cluster.probe-interval |
各個節點的探測時間間隔 |
# 直接複製以前已經安裝過的Alertmanager文件夾
cp -r alertmanager/ /usr/local/alertmanager01cp -r alertmanager/ /usr/local/alertmanager02cp -r alertmanager/ /usr/local/alertmanager03
# 複製完成之後，寫入啓動腳本，
# Alertmanager01cat << EOF> /lib/systemd/system/alertmanager01.service[Unit]Description=alertmanagerDocumentation=https://prometheus.io/After=network.targetStartLimitIntervalSec=0
[Service]Type=simpleUser=prometheusExecStart=/usr/local/alertmanager01/bin/alertmanager \--config.file=/usr/local/alertmanager01/conf/alertmanager.yml \--storage.path=/usr/local/alertmanager01/data \--web.listen-address=":19093" \--cluster.listen-address=192.168.1.220:19094 \--log.level=debugRestart=alwaysRestartSec=1
[Install]WantedBy=multi-user.targetEOF
# Alertmanager02
cat << EOF> /lib/systemd/system/alertmanager02.service[Unit]Description=alertmanagerDocumentation=https://prometheus.io/After=network.targetStartLimitIntervalSec=0
[Service]Type=simpleUser=prometheusExecStart=/usr/local/alertmanager02/bin/alertmanager \--config.file=/usr/local/alertmanager02/conf/alertmanager.yml \--storage.path=/usr/local/alertmanager02/data \--web.listen-address=":29093" \--cluster.listen-address=192.168.1.220:29094 \--cluster.peer=192.168.1.220:19094 \--log.level=debugRestart=alwaysRestartSec=1
[Install]WantedBy=multi-user.targetEOF
# Alertmanager03
cat <<EOF > /lib/systemd/system/alertmanager03.service[Unit]Description=alertmanagerDocumentation=https://prometheus.io/After=network.targetStartLimitIntervalSec=0
[Service]Type=simpleUser=prometheusExecStart=/usr/local/alertmanager03/bin/alertmanager \--config.file=/usr/local/alertmanager03/conf/alertmanager.yml \--storage.path=/usr/local/alertmanager03/data \--web.listen-address=":39093" \--cluster.listen-address=192.168.1.220:39094 \--cluster.peer=192.168.1.220:19094 \--log.level=debugRestart=alwaysRestartSec=1
[Install]WantedBy=multi-user.targetEOF
# 開啓systemd腳本啓動systemctl enable alertmanager01 alertmanager02 alertmanager03systemctl start alertmanager01 alertmanager02 alertmanager03
啓動完成後，就能夠訪問http://192.168.1.220:19093能夠看到如下集羣狀態了，我這裏是爲了測試，本地啓動了多個端口，若是是實際生產環境中，是不一樣節點以及不一樣的IP，這些根據本身的需求設計便可。
Prometheus中的配置：
alerting: alert_relabel_configs: - source_labels: [dc] regex: (.+)\d+ target_label: dc alertmanagers: - static_configs: #- targets: ['127.0.0.1:9093'] - targets: ['192.168.1.220:19093','192.168.1.220:29093','192.168.1.220:39093']
配置完成之後，重啓或者reloadPrometheus服務，訪問http://192.168.1.220:19090/config就能夠看到具體的配置信息了。
到此，Alertmanager集羣配置就完成了，對於進羣中的警報測試很簡單，直接down掉一個端口，而後觸發警報，看看警報是否能夠正常發送。
本文分享自微信公衆號 - Kubernetes技術棧（k8stech）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。