Prometheus Alertmanager 警示管理與路由設定

Prometheus 的警示規則根據時間序列資料的條件判斷，結合 Alertmanager 可實作彈性且精確的告警通知。Alertmanager 提供分組、路由、抑制等機制，避免警示洪水，同時確保關鍵警示能及時觸達相關團隊。透過 Go 範本語言，可自定義通知內容，提升資訊的可讀性。靜默功能允許工程師在維護期間或已知問題存在時，暫時抑制特定警示，減少不必要的幹擾。整合 Prometheus 與 Alertmanager，能有效提升監控系統的可靠性和效率，及時應對潛在問題。

第6章：警示系統與Alertmanager

警示規則與狀態

在Prometheus中，警示規則（alerting rule）是用於定義特定條件的規則，當這些條件被滿足時，Prometheus會發出警示。這些規則由名稱、表示式（expr）、標籤（labels）和註解（annotations）組成。標籤代表了警示的身份，而註解則提供了額外的資訊，如描述或處理警示的指示。

當Prometheus評估警示規則時，警示可以處於三種狀態之一：

不活動（Inactive）：警示未被觸發。
待定（Pending）：警示條件被滿足，但仍在等待指定的持續時間（for子句）。
觸發（Firing）：警示條件持續滿足指定的持續時間，警示被觸發。

警示生命週期

Prometheus每隔一段時間（evaluation_interval）評估一次警示規則。
當警示條件被滿足時，警示轉變為待定狀態。
如果條件持續滿足指定的持續時間，警示轉變為觸發狀態，並向Alertmanager傳送通知。
如果條件不再滿足，警示狀態會變回不活動。

Alertmanager的作用

Alertmanager接收來自Prometheus的警示通知，並根據組態將其路由到適當的接收者，如電子郵件或Webhook。在我們的例子中，Alertmanager將HighNodeCPU警示路由到電子郵件接收者。

圖6.5：Alertmanager中的觸發警示

我們可以在Alertmanager的網頁控制檯檢視觸發的警示，並根據標籤進行搜尋、查詢和分組。

新增警示規則與範本

為了演示路由功能，我們新增了兩個警示規則：DiskWillFillIn4Hours和InstanceDown。這些規則使用範本語法來動態生成註解中的文字。

清單6.22：新增警示規則

groups:
  - name: node_alerts
    rules:
      # ...
      - alert: DiskWillFillIn4Hours
        expr: predict_linear(node_filesystem_free{mountpoint="/"}[1h], 4*3600) < 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }}磁碟空間將在約4小時內耗盡。"
      - alert: InstanceDown
        expr: up{job="node"} == 0
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.job }}的{{ $labels.instance }}主機已關閉！"

範本語法使用Go範本，並暴露了包含時間序列標籤和值的變數。這使得我們可以在註解和標籤中使用動態內容。

內容解密：

predict_linear函式用於預測未來的值，在這裡用於預測磁碟空間是否會在4小時內耗盡。
for子句指定了警示條件需要持續滿足的時間，才能將警示狀態轉變為觸發。
labels和annotations分別定義了警示的標籤和註解，用於提供額外的資訊。
summary註解中使用了範本語法，動態生成了包含例項名稱的文字。

程式碼最佳化建議

在定義警示規則時，應仔細選擇for子句的持續時間，以避免過多的誤報或漏報。
使用範本語法可以使註解更加動態和資訊豐富，但需要注意範本的正確性和可讀性。

此圖示顯示了警示的生命週期和Alertmanager的作用

  graph LR;
    A[不活動] -->|條件滿足|> B[待定];
    B -->|持續滿足for子句|> C[觸發];
    C -->|通知Alertmanager|> D[Alertmanager路由通知];
    B -->|條件不滿足|> A;
    C -->|條件不滿足|> A;

內容解密：

圖表展示了警示的三種狀態及其轉換條件。
當警示條件滿足時，狀態從不活動轉變為待定。
如果條件持續滿足指定的持續時間，狀態轉變為觸發，並通知Alertmanager。
Alertmanager根據組態將通知路由到適當的接收者。

第6章：警示和Alertmanager

警示範本與變數使用

在Prometheus的警示系統中，我們可以使用範本來定義警示的內容。範本中可以使用變數，如 $labels 和 $value，來參照標籤和指標的值。例如，在summary註解中使用 {{ $labels.instance }} 來參照instance標籤的值。

Prometheus還提供了一些函式，如 humanize，可以將數字轉換為更易讀的形式。例如：

annotations:
  summary: High Node CPU of {{ humanize $value }}% for 1 hour

這將顯示指標的值為一個兩位小數的百分比，例如88.23%。

Prometheus警示

為了監控Prometheus伺服器本身的健康狀態，我們需要新增一些規則來檢測問題並發出警示。我們建立一個新的檔案 prometheus_alerts.yml 來存放這些規則。

建立prometheus_alerts.yml檔案

$ touch rules/prometheus_alerts.yml

prometheus_alerts.yml檔案內容

groups:
- name: prometheus_alerts
  rules:
  - alert: PrometheusConfigReloadFailed
    expr: prometheus_config_last_reload_successful == 0
    for: 10m
    labels:
      severity: warning
    annotations:
      description: Reloading Prometheus configuration has failed on {{ $labels.instance }}.
  - alert: PrometheusNotConnectedToAlertmanagers
    expr: prometheus_notifications_alertmanagers_discovered < 1
    for: 10m
    labels:
      severity: warning
    annotations:
      description: Prometheus {{ $labels.instance }} is not connected to any Alertmanagers

這裡定義了兩個新的規則：PrometheusConfigReloadFailed 和 PrometheusNotConnectedToAlertmanagers。第一個規則檢查Prometheus組態是否重新載入失敗，第二個規則檢查Prometheus伺服器是否能夠發現Alertmanagers。

可用性警示

我們的最後一批警示用於檢測主機和服務的可用性。第一個警示利用了透過Node Exporter收集的systemd指標。

Node服務下線警示

- alert: NodeServiceDown
  expr: node_systemd_unit_state{state="active"} != 1
  for: 60s
  labels:
    severity: critical
  annotations:
    summary: Service {{ $labels.name }} on {{ $labels.instance }} is no longer active!
    description: Werner Heisenberg says - "OMG Where's my service?"

這個警示會在 node_systemd_unit_state 指標的active標籤為0時觸發，表示某個服務已經失敗至少60秒。

主機不可達警示

- alert: HostUnreachable
  expr: up{job="node"} == 0
  for: 10s
  labels:
    severity: critical
  annotations:
    summary: Host {{ $labels.instance }} is unreachable!
    description: Werner Heisenberg says - "OMG Where's my host?"

這個警示會在 up 指標的值為0時觸發，表示某個主機已經停止回應抓取請求。

多個例項下線警示

- alert: MultipleInstancesDown
  expr: avg(up) by (job) <= 0.50
  for: 10s
  labels:
    severity: critical
  annotations:
    summary: Multiple instances down in job {{ $labels.job }}!
    description: Werner Heisenberg says - "OMG Where are my instances?"

這個警示會在某個job下的平均 up 指標值低於50%時觸發，表示該job下的多個例項已經下線。

absent函式的使用

Prometheus提供了 absent 函式來檢測某個指標是否缺失。例如：

- alert: InstancesGone
  expr: absent(up{job="node"})
  for: 10s
  labels:
    severity: critical
  annotations:
    summary: Host {{ $labels.instance }} is no longer reporting!
    description: 'Werner Heisenberg says, OMG Where are my instances?'

這個警示會在 up{job="node"} 指標缺失時觸發，表示某個主機已經停止回報指標。

路由組態

現在我們已經定義了一系列具有不同屬性的警示，接下來需要將它們路由到不同的人員。Alertmanager的路由組態是一個樹狀結構，頂層的預設路由會比對所有未被子路由比對的警示。

Alertmanager組態示例

route:
  receiver: 'team-a'
  group_by: ['alertname']
  routes:
  - receiver: 'team-b'
    match:
      severity: critical

這個組態示例定義了一個路由樹，將警示路由到不同的接收者。根據 severity 標籤的值，將警示路由到不同的團隊。#### 組態解密：此組態中，我們定義了一個路由樹，其中頂層路由將所有警示傳送到 team-a。子路由則根據 severity 標籤的值，將嚴重性為 critical 的警示傳送到 team-b。這樣，可以根據不同的警示屬性，將其路由到不同的接收者，從而實作更靈活的警示處理機制。

Alertmanager 設定與路由

Alertmanager 是 Prometheus 生態系統中的關鍵元件，負責處理和路由警示。本章節將探討 Alertmanager 的設定細節，特別是路由組態和接收器的使用。

路由組態基礎

路由組態是 Alertmanager 的核心功能之一，它決定了如何對警示進行分組、等待、重複傳送等操作。

route:
  group_by: ['instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h
  receiver: email

設定解析：

group_by: 指定根據哪些標籤對警示進行分組。例如，設定 ['instance'] 表示根據 instance 標籤進行分組。
group_wait: 當新警示到達時，等待指定時間（此例中為 30 秒）後再傳送，以避免警示洪水。
group_interval: 對已存在的分組，更新警示的間隔時間（此例中為 5 分鐘）。
repeat_interval: 對單一警示的重複傳送間隔（此例中為 3 小時）。

路由與比對規則

Alertmanager 支援多層級路由和不同型別的比對規則。

routes:
  - match:
      severity: critical
    receiver: pager
  - match_re:
      severity: ^(warning|critical)$
    receiver: support_team

設定解析：

match: 簡單標籤比對。例如，將 severity 為 critical 的警示傳送到 pager 接收器。
match_re: 正規表示式比對。例如，將 severity 為 warning 或 critical 的警示傳送到 support_team 接收器。

路由分支與 continue 選項

路由支援分支結構，並且可以透過 continue 選項控制警示是否繼續比對後續路由。

routes:
  - match:
      severity: critical
    receiver: pager
    continue: true
    routes:
      - match:
          service: application1
        receiver: support_team

設定解析：

continue: 若設為 true，警示在比對當前路由後仍會繼續遍歷後續路由。

接收器與通知範本

接收器定義了警示的通知方式，例如電子郵件、Slack 等。

receivers:
  - name: 'pager'
    email_configs:
      - to: 'alert-pager@example.com'
    slack_configs:
      - api_url: https://hooks.slack.com/services/ABC123/ABC123/
        channel: '#monitoring'
        text: '{{ .CommonAnnotations.summary }}'

設定解析：

email_configs 和 slack_configs: 定義了接收器的通知方式和目標。
text: 使用 Go 範本語法自定義 Slack 通知的內容。

最佳實踐與注意事項

合理設定分組和間隔時間：避免警示洪水，同時確保及時通知。
使用多層級路由：根據不同的警示級別和型別進行精確路由。
自定義通知範本：提升通知的可讀性和有效性。
謹慎使用 send_resolved：避免因解決通知導致的警示疲勞。

透過上述設定和最佳實踐，可以有效地管理和路由警示，提升監控系統的效率和可靠性。

第6章：警示與Alertmanager

自定義通知範本

在前面的章節中，我們已經瞭解瞭如何組態Alertmanager來傳送Slack通知。現在，我們將探討如何透過範本自定義通知內容。Alertmanager允許我們使用Go範本語言來定義通知的格式和內容。

建立範本檔案

首先，我們需要在指定的範本目錄中建立一個新的範本檔案。在我們的例子中，範本目錄位於/etc/alertmanager/templates/。

$ touch /etc/alertmanager/templates/slack.tmpl

接下來，我們填充這個範本檔案。

{{ define "slack.example.text" }}{{ .CommonAnnotations.summary }}{{ end}}

在這裡，我們定義了一個名為slack.example.text的範本，它使用了.CommonAnnotations.summary來顯示警示的摘要資訊。

在Alertmanager組態中使用範本

現在，我們需要在Alertmanager的組態檔案中參照剛剛建立的範本。

slack_configs:
- api_url: https://hooks.slack.com/services/ABC123/ABC123/
  channel: #monitoring
  text: '{{ template "slack.example.text" . }}'

透過使用template函式，我們指定了要使用的範本名稱。這樣，通知的內容將根據我們的範本生成。

靜默（Silences）與維護

在實際維運過程中，我們經常需要暫時關閉某些警示，以避免在維護或已知問題期間收到不必要的通知。Alertmanager提供了“靜默”（Silence）功能來實作這一需求。

透過Alertmanager網頁控制檯管理靜默

我們可以透過Alertmanager的網頁控制檯來建立和管理靜默。點選“New Silence”按鈕即可建立新的靜默。

靜默的建立需要指定開始時間、結束時間或持續時間，並且需要透過標籤比對來確定哪些警示應該被靜默。我們還需要填寫建立者的姓名和靜默的原因。

透過amtool命令列工具管理靜默

除了網頁控制檯，Alertmanager還提供了一個名為amtool的命令列工具來管理靜默。

$ amtool --alertmanager.url=http://localhost:9093 silence add alertname=InstancesGone service=application1

這個命令會在指定的Alertmanager例項上建立一個新的靜默，比對具有特定標籤的警示。

查詢和過期靜默

我們可以使用amtool查詢現有的靜默。

$ amtool --alertmanager.url=http://localhost:9093 silence query

並且可以根據靜默ID來過期某個靜默。

$ amtool --alertmanager.url=http://localhost:9093 silence expire 784ac68d-33ce-4e9b-8b95-431a1e0fc268

組態amtool

為了避免每次使用amtool時都需要指定--alertmanager.url，我們可以建立一個組態檔案。預設情況下，amtool會查詢$HOME/.config/amtool/config.yml或/etc/amtool/config.yml。

alertmanager.url: "http://localhost:9093"
author: sre@example.com
comment_required: true

在這個組態檔案中，我們可以設定Alertmanager的URL、預設的建立者以及是否需要評論等。

內容解密：

本章節主要講解了兩個重要的Alertmanager功能：自定義通知範本和靜默管理。自定義通知範本允許使用者根據自己的需求格式化警示通知的內容，而靜默管理則提供了一種機制，可以在特定時間內暫時關閉某些警示，避免不必要的幹擾。這兩個功能對於提升警示管理的效率和準確性具有重要意義。

Alertmanager 工作流程圖示

  graph LR;
    A[開始] --> B{是否需要靜默?};
    B -->|是| C[建立靜默];
    B -->|否| D[傳送警示];
    C --> E[指定靜默時間];
    C --> F[比對警示標籤];
    D --> G[使用範本生成通知];
    G --> H[傳送通知至Slack];

此圖示展示了Alertmanager的基本工作流程，包括是否需要建立靜默、如何建立靜默以及如何傳送警示通知。

進一步探討

進一步探討 Alertmanager 的高階功能，例如何整合其他通知通路、如何最佳化靜默管理的策略等，將有助於更深入地理解和運用 Alertmanager。

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。