在此之前，首先確認大家已經成功安裝prometheus和Alertmanager 在這裏不再贅述。
自定義Prometheus告警規則
修改Prometheus配置文件prometheus.yml,添加以下配置：
rule_files:
- /etc/prometheus/rules/*.rules
在目錄/etc/prometheus/rules/下創建告警文件hoststats-alert.rules內容如下：
groups:
- name: hostStatsAlert
rules:
- alert: hostCpuUsageAlert
expr: sum(avg without (cpu)(irate(node_cpu{mode!='idle'}[5m]))) by (instance) > 0.85
for: 1m
labels:
severity: page
annotations:
summary: "Instance {{ $labels.instance }} CPU usgae high"
description: "{{ $labels.instance }} CPU usage above 85% (current value: {{ $value }})"
- alert: hostMemUsageAlert
expr: (node_memory_MemTotal - node_memory_MemAvailable)/node_memory_MemTotal > 0.85
for: 1m
labels:
severity: page
annotations:
summary: "Instance {{ $labels.instance }} MEM usgae high"
description: "{{ $labels.instance }} MEM usage above 85% (current value: {{ $value }})"
重啓Prometheus後訪問Prometheus 9090端口可以查看當前以加載的規則文件。
Alertmanager配置
Alertmanager解壓後會包含一個默認的alertmanager.yml配置文件，內容如下所示：
global:
resolve_timeout: 5m
route:
group_by: ['altername']
group_wait: 10s # 最初即第一次等待多久時間發送一組警報的通知
group_interval: 10s # 在發送新警報前的等待時間
repeat_interval: 1m # 未解決告警的重複提醒
receiver: 'lanxin'
receivers:
- name: 'lanxin'
webhook_configs:
- url: 'http://10.202.209.8:20499/docs/index.html'
#一個inhibition規則是在與另一組匹配器匹配的警報存在的條件下，
#使匹配一組匹配器的警報失效的規則。兩個警報必須具有一組相同的標籤。
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance']
如上所示：在Alertmanager配置文件中，我們只定義了一個路由，那就意味着所有由Prometheus產生的告警在發送到Alertmanager之後都會通過名爲lanxin的receiver接收。當然實際場景下，告警處理可不是這麼簡單的一件事情，對於不同級別的告警，我們可能會不完全不同的處理方式，因此在route中，我們還可以定義更多的子Route，這些Route通過標籤匹配告警的處理方式。
路由匹配
Alertmanager的配置主要包含兩個部分：路由(route)以及接收器(receivers)。所有的告警信息都會從配置中的頂級路由(route)進入路由樹，根據路由規則將告警信息發送給相應的接收器，這部分與許多開源框架類似，比如說flutter和beego。默認情況下，告警進入到頂級route後會遍歷所有的子節點，直到找到最深的匹配route，並將告警發送到該route定義的receiver中。但如果route中設置continue的值爲false，那麼告警在匹配到第一個子節點之後就直接停止。如果continue爲true，報警則會繼續進行後續子節點的匹配。如果當前告警匹配不到任何的子節點，那該告警將會基於當前路由節點的接收器配置方式進行處理。
在Alertmanager中可以定義一組接收器，比如可以按照角色(比如系統運維，數據庫管理員)來劃分多個接收器。接收器可以關聯郵件，Slack以及其它方式接收告警信息。
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
啓動Alertmanager
Alermanager會將數據保存到本地中，默認的存儲路徑爲data/。因此，在啓動Alertmanager之前需要創建相應的目錄：./alertmanager。Alertmanager啓動後可以通過9093端口訪問。
Alert菜單下可以查看Alertmanager接收到的告警內容。Silences菜單下則可以通過UI創建靜默規則，這部分我們會在後續部分介紹。進入Status菜單，可以看到當前系統的運行狀態以及配置信息。
關聯Prometheus與Alertmanager
在Prometheus的架構中被劃分成兩個獨立的部分。Prometheus負責產生告警，而Alertmanager負責告警產生後的後續處理。因此Alertmanager部署完成後，需要在Prometheus中設置Alertmanager相關的信息。
編輯Prometheus配置文件prometheus.yml,並添加以下內容：
alerting:
alertmanagers:
- static_configs:
- targets: ['localhost:9093']
重啓Prometheus服務，成功後，可以從9090 查看alerting配置是否生效。
屏蔽告警通知
示例如下：
- source_match:
alertname: NodeDown
severity: critical
target_match:
severity: critical
equal:
- node
例如當集羣中的某一個主機節點異常宕機導致告警NodeDown被觸發，同時在告警規則中定義了告警級別severity=critical。由於主機異常宕機，該主機上部署的所有服務，中間件會不可用並觸發報警。根據抑制規則的定義，如果有新的告警級別爲severity=critical，並且告警中標籤node的值與NodeDown告警的相同，則說明新的告警是由NodeDown導致的，則啓動抑制機制停止向接收器發送通知。
