如鯨向海，似鳥投林
在Alertmanager中通過路由(Route)來定義告警的處理方式。路由是一個基於標籤匹配的樹狀匹配結構。根據接收到告警的標籤匹配相應的處理方式。
Alertmanager主要負責對Prometheus產生的告警進行統一處理，因此在Alertmanager配置中一般會包含以下幾個主要部分：
全局配置（global）：用於定義一些全局的公共參數，如全局的SMTP配置，Slack配置等內容；
模板（templates）：用於定義告警通知時的模板，如HTML模板，郵件模板等；
告警路由（route）：根據標籤匹配，確定當前告警應該如何處理；
接收人（receivers）：接收人是一個抽象的概念，它可以是一個郵箱也可以是微信，Slack或者Webhook等，接收人一般配合告警路由使用；
抑制規則（inhibit_rules）：合理設置抑制規則可以減少垃圾告警的產生
其完整配置格式如下：
global:
[ resolve_timeout: <duration> | default = 5m ]
[ smtp_from: <tmpl_string> ]
[ smtp_smarthost: <string> ]
[ smtp_hello: <string> | default = "localhost" ]
[ smtp_auth_username: <string> ]
[ smtp_auth_password: <secret> ]
[ smtp_auth_identity: <string> ]
[ smtp_auth_secret: <secret> ]
[ smtp_require_tls: <bool> | default = true ]
[ slack_api_url: <secret> ]
[ victorops_api_key: <secret> ]
[ victorops_api_url: <string> | default = "https://alert.victorops.com/integrations/generic/20131114/alert/" ]
[ pagerduty_url: <string> | default = "https://events.pagerduty.com/v2/enqueue" ]
[ opsgenie_api_key: <secret> ]
[ opsgenie_api_url: <string> | default = "https://api.opsgenie.com/" ]
[ hipchat_api_url: <string> | default = "https://api.hipchat.com/" ]
[ hipchat_auth_token: <secret> ]
[ wechat_api_url: <string> | default = "https://qyapi.weixin.qq.com/cgi-bin/" ]
[ wechat_api_secret: <secret> ]
[ wechat_api_corp_id: <string> ]
[ http_config: <http_config> ]
templates:
[ - <filepath> ... ]
route: <route>
receivers:
- <receiver> ...
inhibit_rules:
[ - <inhibit_rule> ... ]
在全局配置中需要注意的是resolve_timeout，該參數定義了當Alertmanager持續多長時間未接收到告警後標記告警狀態爲resolved（已解決）。該參數的定義可能會影響到告警恢復通知的接收時間，用戶可根據自己的實際場景進行定義，其默認值爲5分鐘。
基於標籤的告警處理路由
在Alertmanager的配置中會定義一個基於標籤匹配規則的告警路由樹，以確定在接收到告警後Alertmanager需要如何對其進行處理：
route: <route>
其中route中則主要定義了告警的路由匹配規則，以及Alertmanager需要將匹配到的告警發送給哪一個receiver，一個最簡單的route定義如下所示：
route:
group_by: ['alertname']
receiver: 'web.hook'
receivers:
- name: 'web.hook'
webhook_configs:
- url: 'http://127.0.0.1:5001/'
如上所示：在Alertmanager配置文件中，我們只定義了一個路由，那就意味着所有由Prometheus產生的告警在發送到Alertmanager之後都會通過名爲web.hook的receiver接收。這裏的web.hook定義爲一個webhook地址。當然實際場景下，告警處理可不是這麼簡單的一件事情，對於不同級別的告警，我們可能會有完全不同的處理方式，因此在route中，我們還可以定義更多的子Route，這些Route通過標籤匹配告警的處理方式，route的完整定義如下：
[ receiver: <string> ]
[ group_by: '[' <labelname>, ... ']' ]
[ continue: <boolean> | default = false ]
match:
[ <labelname>: <labelvalue>, ... ]
match_re:
[ <labelname>: <regex>, ... ]
[ group_wait: <duration> | default = 30s ]
[ group_interval: <duration> | default = 5m ]
[ repeat_interval: <duration> | default = 4h ]
routes:
[ - <route> ... ]
路由匹配
每一個告警都會從配置文件中頂級的route進入路由樹，需要注意的是頂級的route必須匹配所有告警(即不能有任何的匹配設置match和match_re)，每一個路由都可以定義自己的接受人以及匹配規則。默認情況下，告警進入到頂級route後會遍歷所有的子節點，直到找到最深的匹配route，並將告警發送到該route定義的receiver中。但如果route中設置continue的值爲false，那麼告警在匹配到第一個子節點之後就直接停止。如果continue爲true，報警則會繼續進行後續子節點的匹配。如果當前告警匹配不到任何的子節點，那該告警將會基於當前路由節點的接收器配置方式進行處理。
其中告警的匹配有兩種方式可以選擇：
第一種方式基於字符串驗證，通過設置match規則判斷當前告警中是否存在標籤labelname並且其值等於labelvalue。
第二種方式則基於正則表達式，通過設置match_re驗證當前告警標籤的值是否滿足正則表達式的內容。
如果警報已經成功發送通知, 如果想設置發送告警通知之前要等待時間，則可以通過repeat_interval參數進行設置。
告警分組
Alertmanager可以對告警通知進行分組，將多條告警合合併爲一個通知。這裏我們可以使用group_by來定義分組規則。基於告警中包含的標籤，如果滿足group_by中定義標籤名稱，那麼這些告警將會合併爲一個通知發送給接收器。
有的時候爲了能夠一次性收集和發送更多的相關信息時，可以通過group_wait參數設置等待時間，如果在等待時間內當前group接收到了新的告警，這些告警將會合併爲一個通知向receiver發送。
而group_interval配置，則用於定義相同的Group之間發送告警通知的時間間隔。
例如，當使用Prometheus監控多個集羣以及部署在集羣中的應用和數據庫服務，並且定義以下的告警處理路由規則來對集羣中的異常進行通知。
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
默認情況下所有的告警都會發送給集羣管理員default-receiver，因此在Alertmanager的配置文件的根路由中，對告警信息按照集羣以及告警的名稱對告警進行分組。
如果告警時來源於數據庫服務如MySQL或者Cassandra，此時則需要將告警發送給相應的數據庫管理員(database-pager)。這裏定義了一個單獨子路由，如果告警中包含service標籤，並且service爲MySQL或者Cassandra,則向database-pager發送告警通知，由於這裏沒有定義group_by等屬性，這些屬性的配置信息將從上級路由繼承，database-pager將會接收到按cluster和alertname進行分組的告警通知。
而某些告警規則來源可能來源於開發團隊的定義，這些告警中通過添加標籤team來標示這些告警的創建者。在Alertmanager配置文件的告警路由下，定義單獨子路由用於處理這一類的告警通知，如果匹配到告警中包含標籤team，並且team的值爲frontend，Alertmanager將會按照標籤product和environment對告警進行分組。此時如果應用出現異常，開發就能清楚的知道哪一個環境(environment)中的哪一個應用程序出現了問題，可以快速對應用進行問題定位。
郵件報警示例文件：
$ cd /usr/local/alertmanager
$ vim alert-test.yml
global:
smtp_smarthost: 'smtp.163.com:25'
smtp_from: '[email protected]'
smtp_auth_username: '[email protected]'
smtp_auth_password: 'xxxxxx' # 郵箱的授權密碼
smtp_require_tls: false
templates:
- '/alertmanager/template/*.tmpl'
route:
group_by: ['alertname', 'cluster', 'service']
group_wait: 30s
group_interval: 5m
repeat_interval: 10m
receiver: default-receiver
receivers:
- name: 'default-receiver'
email_configs:
- to: '[email protected]'
html: '{ alert.html }'
headers: { Subject: "Prometheus[WARN] Test報警郵件" }
幫助文檔：https://yunlzheng.gitbook.io/prometheus-book/