普羅米修斯prometheus配置記錄

在此之前,首先確認大家已經成功安裝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導致的,則啓動抑制機制停止向接收器發送通知。

發佈了22 篇原創文章 · 獲贊 9 · 訪問量 7862
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章