Prometheus 警示系統健壯性提升最佳實踐

– 7 分鐘閱讀

Prometheus 警示系統的健壯性對於保障系統穩定至關重要。本文將探討如何設計有效的症狀導向警示策略，並結合邏輯運算元和 _over_time 函式，避免誤判和漏報。同時，我們將介紹如何使用單元測試驗證警示規則的正確性，確保系統在各種情況下都能及時發出警示。此外，隨著監控規模的擴大，Prometheus 的效能瓶頸也日益凸顯。本文將進一步探討如何利用分片、聯邦和高可用性架構來提升 Prometheus 的效能，應對高基數資料和長期儲存的挑戰。

技術主題標題：Prometheus 警示系統健壯性提升與最佳實踐

使用Prometheus建立強健的警示系統

在現代IT基礎設施中，監控系統的警示功能至關重要。Prometheus作為一個強大的監控系統，提供了豐富的功能來建立有效的警示規則。本文將深入探討如何使用Prometheus建立強健的警示系統，包括症狀導向的警示策略設計、邏輯運算元的應用、_over_time函式的使用，以及單元測試的方法。

設計有效的警示

設計有效的警示需要考慮多個因素。症狀導向的方法關注系統的實際表現，而不是試圖預測可能的原因。例如，可以建立一個在記憶體使用率過高且主要頁面錯誤率也高的情況下才觸發的警示。

# 示例：記憶體使用率過高且主要頁面錯誤率高的警示
((node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes > 0.8)
and
(rate(node_vmstat_pgmajfault[5m]) > 10)

內容解密：

此PromQL查詢首先計算記憶體使用率，如果使用率超過80%，並且主要頁面錯誤率（表示記憶體壓力）每5分鐘大於10次，則觸發警示。這種組合條件可以更準確地反映系統是否真正遇到記憶體壓力問題。

使用邏輯和集合二元運算元

Prometheus提供了豐富的邏輯和集合二元運算元，如and、or和unless，這些運算元可以用來建立更複雜的警示條件。

# 示例：NTP同步警示，除非節點在30分鐘內重新啟動
(node_timex_offset_seconds > 0.05)
unless on (instance)
(changes(node_boot_time_seconds[30m]) > 0)

圖表翻譯：

  flowchart TD
 A[開始檢查NTP同步] --> B{節點是否在30分鐘內重新啟動？}
 B -->|是| C[不觸發NTP同步警示]
 B -->|否| D{檢查NTP偏移是否大於0.05秒？}
 D -->|是| E[觸發NTP同步警示]
 D -->|否| F[不觸發NTP同步警示]

圖表翻譯：

此圖表展示瞭如何根據節點是否在30分鐘內重新啟動來決定是否觸發NTP同步警示。如果節點最近重新啟動，則不會觸發警示；否則，將檢查NTP偏移是否超過閾值，以決定是否觸發警示。

適當使用「for」持續時間

適當的「for」持續時間可以幫助減少噪音警示。一般來說，警告警示可以使用較長的「for」持續時間（例如15分鐘），而危急警示則可以使用較短的「for」持續時間（例如5分鐘）。

使用_over_time函式

當使用較長的「for」持續時間時，可能會遇到因抓取失敗而重置警示狀態的問題。使用_over_time函式，如last_over_time、avg_over_time和max_over_time，可以避免這種情況。

# 示例：使用last_over_time函式確保SSH連線警示的穩健性
(last_over_time(probe_success{job="blackbox_ssh"}[5m]) != 1)

內容解密：

此查詢使用last_over_time函式檢查在過去5分鐘內SSH探針是否成功。如果在這段時間內的最後一次探針失敗（即probe_success不等於1），則觸發警示。

Prometheus 警示規則單元測試詳解

Prometheus 提供了強大的警示機制，而單元測試是確保警示規則正確性的關鍵步驟。

建立測試檔案

要進行單元測試，首先需要建立一個測試檔案，通常以 unit-test.yaml 命名。

# unit-test.yaml
rule_files:
 - ./test-rule.yaml
evaluation_interval: 1m
tests:
 - interval: 1m
 input_series:
 - series: 'probe_success{instance="server1", job="blackbox_ssh"}'
 values: "1 1 1 0 +0x12"
 - series: 'probe_success{instance="server2", job="blackbox_ssh"}'
 values: "1 1 1 _1 +0x12"

圖表：

  flowchart TD
 A[開始測試] --> B{檢查資料}
 B -->|資料有效| C[執行測試]
 B -->|資料無效| D[回報錯誤]
 C --> E[評估結果]
 D --> E

圖表翻譯：

此圖示展示了單元測試的執行流程。流程始於「開始測試」階段，接著進行資料有效性檢查。若資料有效，系統會進入「執行測試」階段；若資料無效，則轉向「回報錯誤」階段。最後，無論測試成功與否，流程都會到達「評估結果」階段。

編寫測試案例

在測試檔案中，我們定義了輸入的時間序列資料和預期的警示輸出。

tests:
 - interval: 1m
 input_series:
 # 省略輸入序列定義
 alert_rule_test:
 - alertname: SSHDown
 eval_time: 9m
 exp_alerts: []
 - alertname: SSHDown
 eval_time: 14m
 exp_alerts:
 - exp_labels:
 severity: warning
 team: sre
 instance: server1
 job: blackbox_ssh
 exp_annotations:
 description: "Cannot SSH to server1"
 instance: "server1"

執行測試

使用 promtool 命令列工具執行測試：

$ promtool test rules unit-test.yaml
Unit Testing: unit-test.yaml
SUCCESS

提升Prometheus效能：分片、聯邦與高可用性架構

Prometheus作為一個強大的監控工具，在初期使用時往往能滿足大多數需求。然而，隨著資料量的增長，其侷限性逐漸顯現。

Prometheus的侷限性

Prometheus的侷限性主要體現在兩個方面：基數（Cardinality）和長期儲存。

基數問題

基數是指資料集中唯一值的數量。高基數資料意味著存在大量唯一值，如IP地址、UUID和時間戳等。

# 模擬高基數資料對記憶體使用的影響
import random

def generate_high_cardinality_data(num_samples):
 data = {}
 for _ in range(num_samples):
 uuid = str(random.uuid4())
 data[uuid] = random.random()
 return data

high_cardinality_data = generate_high_cardinality_data(1000000)

圖表1：高基數資料對記憶體影響示意圖

  flowchart TD
 A[開始] --> B[生成高基數資料]
 B --> C[儲存資料]
 C --> D{檢查記憶體使用}
 D -->|記憶體使用超標| E[最佳化資料儲存]
 D -->|記憶體使用正常| F[結束]

圖表翻譯：

此圖示展示了高基數資料對記憶體使用的影響流程。

分片Prometheus

當Prometheus例項的資料量過大時，可以透過分片來解決。分片是指將資料分散到多個Prometheus例項中。

使用重新標記進行分片

另一種更動態的分片方法是利用Prometheus的重新標記功能，特別是hashmod函式。

# 使用hashmod進行分片的範例組態
scrape_configs:
 - job_name: 'example_job'
 relabel_configs:
 - source_labels: [__address__]
 modulus: 4
 target_label: __tmp_hash
 action: hashmod
 - source_labels: [__tmp_hash]
 regex: ^1$
 action: keep

圖表2：使用hashmod進行分片的流程圖

  sequenceDiagram
 participant Prometheus1 as "Prometheus例項1"
 participant Prometheus2 as "Prometheus例項2"
 participant Target1 as "目標1"
 participant Target2 as "目標2"
 Target1->>Prometheus1: 檢查hashmod值
 Target2->>Prometheus2: 檢查hashmod值
 Prometheus1->>Prometheus1: 保留符合條件的目標
 Prometheus2->>Prometheus2: 保留符合條件的目標

圖表翻譯：

此圖示展示了使用hashmod進行分片的流程。

聯邦與高可用性架構

除了分片外，聯邦和高可用性架構也是提升Prometheus效能的重要手段。

聯邦架構

聯邦架構透過在多個Prometheus例項之間分享資料，實作了資料的集中管理和查詢。

# 聯邦組態範例
scrape_configs:
 - job_name: 'federate'
 honor_labels: true
 metrics_path: '/federate'
 params:
 'match[]':
 - '{job="prometheus"}'
 - '{__name__=~"job:.*"}'
 static_configs:
 - targets:
 - 'source-prometheus-1:9090'
 - 'source-prometheus-2:9090'

圖表3：聯邦架構示意圖

  graph LR
 subgraph "聯邦層"
 Federation[聯邦Prometheus]
 end
 subgraph "資料來源層"
 Prometheus1[Prometheus例項1]
 Prometheus2[Prometheus例項2]
 end
 Prometheus1 -->|資料同步|> Federation
 Prometheus2 -->|資料同步|> Federation

圖表翻譯：

此圖示展示了聯邦架構的資料同步流程。

Prometheus 已成為監控領域的關鍵技術。本文深入探討了Prometheus 警示系統的健壯性提升方法與最佳實踐，涵蓋了從症狀導向的警示策略設計、邏輯運算元的應用、_over_time 函式的使用，到單元測試的完整流程。透過這些方法，可以有效降低誤報率，提升警示的準確性，並確保警示系統的可靠性。此外，文章也分析了Prometheus 在處理高基數資料和長期儲存方面的侷限性，並提出了分片、聯邦和高可用性架構等解決方案。這些架構層面的最佳化策略，能有效提升 Prometheus 的效能和擴充套件性，使其能更好地適應日益增長的監控需求。技術限制深析顯示，單純依靠 Prometheus 本身難以應對所有監控挑戰，整合其他工具和技術至關重要。對於追求高效能和高可靠性的企業，建議採用分片策略搭配聯邦架構，並結合 Thanos 或 Cortex 等解決方案進行長期儲存。玄貓認為，Prometheus 的未來發展將更緊密地與雲原生生態整合，並在可觀測性領域扮演更重要的角色。隨著雲原生技術的普及，預計 Prometheus 的應用場景將進一步擴大，其周邊工具和生態系統也將持續發展完善。

玄貓

玄貓

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