Prometheus 分片技術與效能最佳化實踐

Prometheus 分片技術是解決大規模監控效能瓶頸的關鍵。透過重新標記機制，Prometheus 將監控目標分散至多個例項，有效降低單點負載。本文除了詳細說明分片原理及 Kube-Prometheus 的設定方式外，也涵蓋聯邦機制，讓使用者能集中查詢分散的資料。此外，文章也深入探討高用性架構的設計，並提供基數控制的最佳實踐，以確保監控系統的穩定性和效能。最後，文章提供除錯和最佳化 Prometheus 的實用技巧，例如控制資料基數、使用記錄規則和查詢日誌記錄等，協助讀者建構和維護高效能的 Prometheus 監控系統。

Prometheus 分片技術詳解與實作

Prometheus 作為一個強大的監控系統，其可擴充套件性和高用性是許多企業關注的重點。在大規模的監控環境中，單一 Prometheus 例項可能面臨效能瓶頸和資源限制。為瞭解決這些問題，Prometheus 提供了分片（Sharding）技術，允許將監控目標分散到多個 Prometheus 例項中。

什麼是 Prometheus 分片？

Prometheus 分片是一種將監控目標分散到多個 Prometheus 例項的技術，透過將不同的監控目標分配到不同的 Prometheus 例項上，可以有效地分散負載，提高系統的可擴充套件性和可用性。

分片原理

Prometheus 的分片技術主要依賴於重新標記（relabeling）機制。在每次抓取（scrape）之前，Prometheus 會根據預先設定的規則對目標進行重新標記，從而決定是否保留該目標。

# 使用雜湊函式進行目標分配的範例程式碼
from hashlib import md5

SEPARATOR = ";"
MOD = 2

targetA = ["app=nginx", "instance=node2"]
targetB = ["app=nginx", "instance=node23"]

hashA = int(md5(SEPARATOR.join(targetA).encode("utf-8")).hexdigest(), 16)
hashB = int(md5(SEPARATOR.join(targetB).encode("utf-8")).hexdigest(), 16)

print(f"{targetA} % {MOD} = ", hashA % MOD)
print(f"{targetB} % {MOD} = ", hashB % MOD)

內容解密：

此程式碼展示瞭如何使用雜湊函式和模運算來決定監控目標的分片結果。透過計算目標標籤的雜湊值並取模，可以將目標均勻分配到不同的 Prometheus 例項。

圖表剖析：

此圖表展示了 Prometheus 分片的邏輯流程。首先計算目標的雜湊值，然後進行模運算，根據運算結果決定是否保留該目標。這種機制確保了目標被均勻分配到不同的 Prometheus 例項。

在 Kube-Prometheus 中實作分片

Kube-Prometheus 提供了一個簡便的方式來啟用 Prometheus 分片。只需在 PrometheusSpec 中指定分片數量即可。

# Kube-Prometheus 中的分片組態範例
prometheus:
 prometheusSpec:
 shards: 2
 cleanPrometheusOperatorObjectNames: true

程式碼解說：

這段設定檔指定了 Prometheus 的分片數量為2，並啟用了 cleanPrometheusOperatorObjectNames 選項以簡化資源名稱。這使得 Kube-Prometheus 可以自動建立多個 Prometheus 例項並進行負載分片。

Prometheus 分片的實際運作

在實際運作中，Prometheus Operator 會自動為每個 Prometheus 例項組態重新標記規則，以實作分片。

# Prometheus 中的重新標記規則組態
relabel_configs:
- source_labels: [__address__]
 separator: ;
 regex: (.*)
 modulus: 2
 target_label: __tmp_hash
 replacement: $1
 action: hashmod
- source_labels: [__tmp_hash]
 separator: ;
 regex: "1"
 replacement: $1
 action: keep

程式碼解說：

這段重新標記規則首先計算目標地址的雜湊值並取模2，將結果儲存在 __tmp_hash 標籤中。然後根據 __tmp_hash 的值決定是否保留該目標。這種機制確保了目標被正確分配到指定的 Prometheus 例項。

分片的挑戰與限制

雖然 Prometheus 分片可以提高系統的可擴充套件性，但也帶來了一些挑戰。例如，分片後的資料分散在多個 Prometheus 例項中，可能導致查詢複雜度增加。此外，分片不一定能保證負載的完全均衡。

# 查詢各 Prometheus 例項上的目標數量
count(up)

查詢結果分析：

透過執行 count(up) 查詢，可以觀察到不同 Prometheus 例項上的目標數量。在實際環境中，可能會發現目標分佈並不完全均勻，這是分片技術的正常現象。

聯邦（Federation）機制簡介

為瞭解決分片後的多例項查詢問題，Prometheus 提供了聯邦機制。聯邦允許將多個 Prometheus 例項的資料匯總到一個中央例項中，提供單一的查詢入口。

聯邦的適用場景

聯邦機制適用於需要集中查詢多個 Prometheus 例項的場景。然而，過度使用聯邦可能會導致中央例項的效能問題。因此，建議僅對必要的指標進行聯邦查詢。

# 透過聯邦端點查詢特定指標
curl http://prometheus:9090/federate?match[]=up{job="node-exporter"}

使用範例：

透過呼叫 /federate 端點並指定 match[] 引數，可以從 Prometheus 例項中提取特定的指標。這種方式允許對多個例項的資料進行集中查詢。

Prometheus 聯邦與高用性實作

Prometheus 聯邦機制允許從多個 Prometheus 例項中收集指標資料至中央位置，實作資料集中管理。本文將詳細介紹 Prometheus 聯邦的組態方法及其在高用性架構中的應用。

Prometheus 聯邦機制實作

Prometheus 聯邦透過 /federate 端點實作指標資料的收集。以下是一個典型的聯邦查詢範例：

http://localhost:9090/federate?match[]=up{job="node-exporter"}&match[]=node_os_info

這種查詢方式雖然有效，但隨著匹配條件的增加會變得複雜難讀。Prometheus 提供 YAML 格式的組態方式來簡化這一過程。

聯邦組態範例

# Prometheus 聯邦組態範例
scrape_configs:
 - job_name: 'federate'
 scrape_interval: 15s
 honor_labels: true
 metrics_path: '/federate'
 params:
 'match[]':
 - 'up{job="prometheus"}'
 - 'node_os_info'
 static_configs:
 - targets:
 - 'prometheus-shard-1:9090'
 - 'prometheus-shard-2:9090'

重要組態引數解析

honor_labels: true 的作用

確保在收集過程中不會覆寫原始指標的標籤
避免因標籤衝突導致的資料丟失

引陣列態

使用 params 定義多個匹配條件
支援多個 Prometheus 例項的指標收集

Kubernetes 環境下的 Prometheus 聯邦實作

在 Kubernetes 叢集中，可以透過定義 ServiceMonitor 和 Prometheus 資源來實作聯邦組態。

ServiceMonitor 組態範例

# ServiceMonitor 組態範例
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
 name: federated-prometheus
 namespace: prometheus
spec:
 endpoints:
 - path: /federate
 port: http-web
 honorLabels: true
 params:
 'match[]':
 - 'up{job="prometheus"}'
 - 'node_os_info'
 namespaceSelector:
 matchNames:
 - prometheus
 selector:
 matchLabels:
 app: kube-prometheus-stack-prometheus
 release: mastering-prometheus

Prometheus 例項組態

# Prometheus 例項組態範例
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
 name: federated-prometheus
 namespace: prometheus
spec:
 scrapeInterval: 15s
 serviceMonitorSelector:
 matchLabels:
 # 選擇對應的 ServiceMonitor
 replicas: 1
 retention: 24h
 serviceAccountName: mastering-prometheus-kube-prometheus

Prometheus 高用性架構實作

單一 Prometheus 例項存在單點故障風險，為實作高用性，需要佈署多個相同的 Prometheus 例項。

高用性架構設計要點

多例項佈署

佈署多個 Prometheus 例項監控相同的目標
使用不同的 external_labels 區分各例項

Alertmanager 整合

組態 alert_relabel_configs 移除重複標籤
確保 Alertmanager 能夠正確去重警示

警示重複資料刪除組態

# 警示重複資料刪除組態範例
alerting:
 alert_relabel_configs:
 - regex: prometheus_replica
 action: labeldrop

最佳實踐與注意事項

聯邦機制的限制

聯邦不是萬能解決方案，多數情況下只是臨時措施
需要評估是否真正需要聯邦架構

高用性考量

建議將 Prometheus 例項佈署在不同可用區
使用外部 SaaS 工具進行額外監控

效能與成本平衡

需要權衡高用性帶來的額外成本
考慮使用 Thanos 等方案進行長期擴充套件

架構視覺化說明

圖表翻譯：

此圖示展示了 Prometheus 聯邦架構的資料流向。多個 Prometheus 例項將指標資料彙總至中央的聯邦 Prometheus 例項，使用者透過該中央節點進行統一查詢。同時，系統將警示資訊傳送至 Alertmanager 進行處理後傳送通知。

最佳化與除錯 Prometheus

即使我們將 Prometheus 擴充套件到多個副本甚至分片，仍然會遇到需要識別和解決的效能問題。因此，本章將重點介紹如何最佳化 Prometheus 以充分利用其資源，以及在出現問題時如何除錯。

本章主要內容

控制資料基數
記錄規則
抓取抖動
使用 pprof
查詢日誌記錄
調優垃圾回收

技術需求

本章將使用在第2章中建立的 Kubernetes 叢集和 Prometheus 環境。因此，我們需要安裝以下工具來與其互動：

Prometheus

控制資料基數

在前一章中，我們討論了資料基數的概念。簡單來說，基數是指資料集中唯一值的數量。我們知道，時序資料函式庫通常難以管理高基數資料集，否則將嚴重影響查詢效能。

識別基數問題

識別基數問題的第一步是檢視 Prometheus 的網頁介面中的 TSDB 頁面（可在 Status 下拉選單中找到，或直接存取 /tsdb-status）。在這個頁面中，提供了多項與基數相關的指標：

圖表翻譯：

此圖示展示了檢查和處理 Prometheus 中基數問題的基本流程。首先檢查 TSDB 的狀態，如果發現高基數問題，則進一步分析相關指標，並採取最佳化措施，如改進標籤使用或調整資料儲存策略。如果沒有基數問題，則繼續監控系統狀態。

識別基數問題的方法

檢查 TSDB 狀態頁面：這個頁面提供了多項指標，可以幫助我們瞭解目前的基數狀況。
分析指標資料：重點關注那些具有高基數的指標，並分析其標籤使用情況。
最佳化標籤使用：減少不必要的標籤或合併相似標籤，可以有效降低基數。
使用適當的資料儲存策略：根據實際需求選擇合適的儲存方案。

最佳實踐

# 正確使用標籤的範例程式碼
def create_metric(name, labels):
 """建立指標並正確設定標籤"""
 # 避免使用過多的標籤
 necessary_labels = {'instance', 'job'}
 filtered_labels = {k: v for k, v in labels.items() if k in necessary_labels}
 return Metric(name, filtered_labels)

內容解密：

此程式碼展示瞭如何建立指標並正確設定標籤。透過過濾不必要的標籤，可以有效控制指標的基數，從而提升 Prometheus 的效能。

記錄規則

記錄規則是 Prometheus 中一個重要的功能，可以用來預先計算並儲存常用的查詢結果，從而提高查詢效率。

使用記錄規則的最佳實踐

定義有用的記錄規則：根據實際需求建立常用的查詢規則。
合理命名規則：使用清晰且具有描述性的名稱。
定期檢視和更新規則：確保規則仍然符合目前的監控需求。

查詢效能最佳化

除了控制基數和善用記錄規則外，還可以透過以下方法進一步最佳化查詢效能：

使用適當的查詢語法：避免使用過於複雜的 PromQL 查詢。
利用索引：確保 TSDB 的索引機制有效運作。
分散查詢負載：使用分片或複製來分散查詢負載。

進一步閱讀

要了解更多本章涵蓋的主題，請參考以下資源：

Prometheus 官方檔案關於 TSDB 的說明
PromQL 查詢語言

清理工作

為了保持環境的整潔，請記得清理不再需要的資源。

附錄：Prometheus 效能調優檢查清單

圖表翻譯：

此圖示展示了 Prometheus 效能調優的基本流程。首先檢查資料基數，如果基數過高則進行最佳化。接著檢查查詢效能，根據效能狀況進行相應的最佳化。最後檢查儲存空間使用情況，並在必要時進行擴充套件。

Prometheus 效能調優檢查清單使用

定期執行檢查：建議每週或每月定期執行一次完整的檢查流程。
重點關注高基數指標：對於高基數指標，應優先進行最佳化。
持續監控查詢效能：定期檢查查詢效能，及時發現並解決效能瓶頸。
合理規劃儲存空間：根據實際資料增長情況，提前規劃儲存擴充套件方案。

透過遵循上述和檢查清單，可以有效提升 Prometheus 系統的穩定性和效能，確保監控系統的長期可靠運作。

最佳化 Prometheus 的基數控制：提升監控系統效能的關鍵技術

技術背景與重要性

在現代監控系統中，Prometheus 作為一項流行的開源監控解決方案，廣泛應用於雲端運算、微服務架構和 DevOps 實踐中。其高效能和靈活性使其成為眾多企業的首選。然而，隨著監控規模的擴大，基數（cardinality）問題逐漸成為影響 Prometheus 效能的關鍵因素。本文將深入探討如何最佳化 Prometheus 的基數控制，以提升系統的穩定性和效能。

瞭解基數問題及其影響

基數的定義

基數是指一個標籤（label）擁有的唯一值的數量。在 Prometheus 中，高基數通常與特定的指標（metric）相關聯，並可能對系統效能產生重大影響。高基數的指標會導致查詢變慢，並增加資源消耗，從而影響整體監控系統的效能。

基數問題的來源

動態標籤值：如容器 ID、Pod 名稱等動態生成的標籤值，容易導致基數過高。
高基數指標：某些指標（如 kubernetes_feature_enabled）可能包含大量唯一值。
不當的標籤設計：標籤設計不當，如使用高基數欄位作為標籤。

使用 Prometheus 監控基數

Prometheus 從 2.46.0 版本開始提供了一系列工具來幫助使用者監控和控制基數。這些工具包括：

基數統計資料

標籤名稱與值計數：顯示具有最多唯一值的標籤。
按指標名稱劃分的序列計數：顯示具有最高基數的指標。
高記憶體使用率的標籤名稱：顯示對記憶體消耗影響最大的標籤。
按標籤劃分的序列計數：顯示特定標籤的序列數量。

這些統計資料幫助使用者快速識別高基數的來源。其中，標籤名稱與值計數是最關鍵的資訊。

分析高基數指標

透過 PromQL 查詢，可以進一步分析哪些指標具有高基數。例如，要查詢具有最高基數的 name 標籤，可以使用以下查詢：

# 查詢具有最高基數的 name 標籤
sort_desc(
 count by (__name__) ({name!=""})
)
# 結果顯示具有最高基數的指標名稱

內容解密：

上述 PromQL 查詢陳述式用於統計具有 name 標籤且值不為空的指標數量，並按照數量降序排列。查詢結果可以幫助識別哪些指標具有高基數，從而有針對性地進行最佳化。

解決基數問題的策略

使用 `metric_relabel_configs` 刪除高基數指標

Prometheus 的 metric_relabel_configs 組態允許使用者刪除特定的指標或標籤。例如，可以透過以下組態刪除 kubernetes_feature_enabled 指標：

# 組態 metric_relabel_configs 刪除高基數指標
kubeApiServer:
 serviceMonitor:
 metricRelabelings:
 - action: drop
 regex: kubernetes_feature_enabled
 sourceLabels: [ __name__ ]
# 刪除特定指標以降低基數

圖表剖析：

此圖示展示瞭如何透過刪除高基數指標來最佳化 Prometheus 的基數。流程首先檢查指標的基數，如果發現高基數指標，則透過組態 metric_relabel_configs 進行刪除，最後應用組態以完成最佳化。

謹慎使用 `labeldrop` 操作

使用 labeldrop 操作可以減少標籤數量，但必須確保刪除標籤後，序列仍然保持唯一性，否則會導致抓取失敗。

設定限制以防止基數爆炸

Prometheus 提供了多種限制來防止基數爆炸，包括：

限制型別

樣本限制（sample_limit）：限制單次抓取的樣本數量。
標籤限制（label_limit）：限制每個樣本的標籤數量。
標籤值長度限制（label_value_length_limit）：限制標籤值的最大長度。
標籤名稱長度限制（label_name_length_limit）：限制標籤名稱的最大長度。

組態示例

# 全域限制設定
global:
 sample_limit: 2000
 label_limit: 20
 label_value_length_limit: 50
 label_name_length_limit: 20

# 特定抓取任務的限制設定
scrape_configs:
 - job_name: exampleJob
 sample_limit: 10000
 label_limit: 15
 label_value_length_limit: 20
 label_name_length_limit: 12

圖表翻譯：

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Prometheus 分片技術與效能最佳化實踐

package "系統架構" {
    package "前端層" {
        component [使用者介面] as ui
        component [API 客戶端] as client
    }

    package "後端層" {
        component [API 服務] as api
        component [業務邏輯] as logic
        component [資料存取] as dao
    }

    package "資料層" {
        database [主資料庫] as db
        database [快取] as cache
    }
}

ui --> client : 使用者操作
client --> api : HTTP 請求
api --> logic : 處理邏輯
logic --> dao : 資料操作
dao --> db : 持久化
dao --> cache : 快取

note right of api
  RESTful API
  或 GraphQL
end note

@enduml

此圖示展示了在 Prometheus 中設定限制的流程。首先，選擇是進行全域設定還是針對特定抓取任務進行設定。根據選擇，定義相應的限制引數（如 sample_limit 和 label_limit），最後應用這些組態以防止基數爆炸。

最佳實踐與效能最佳化

定期監控基數

使用 Prometheus 提供的工具定期檢查基數狀況，及時發現並處理高基數問題。

合理設定限制

根據實際需求設定合理的限制，避免基數爆炸對系統造成影響。

最佳化指標和標籤

刪除不必要的指標和標籤，減少基數，提高系統效能。

透過上述措施，可以有效控制 Prometheus 中的基數問題，提升系統的穩定性和效能。合理的基數控制策略不僅能最佳化監控系統的效能，還能確保監控資料的準確性和可靠性。未來，隨著監控需求的持續增長，基數控制將成為 Prometheus 維運中的重要課題。

Prometheus 作為雲原生監控的根本，其分片和聯邦機制有效應對了日益增長的監控資料規模和複雜度。深入剖析 Prometheus 的分片技術，可以發現其核心是根據重新標記和雜湊模數的負載平衡策略，但也存在查詢複雜度增加的挑戰。透過聯邦機制，Prometheus 提供了集中查詢的入口，有效整合分散的資料，但仍需謹慎評估聯邦規模以避免效能瓶頸。技術限制深析顯示，單純的分片或聯邦並非解決所有擴充套件性問題的銀彈。實務落地分析表明，高基數指標和標籤管理是影響 Prometheus 效能的關鍵因素，需要結合 metric_relabel_configs、labeldrop 等機制以及基數統計資料進行精細化控制。前瞻性地來看，隨著邊緣計算和物聯網場景的興起，預計 Prometheus 將持續演進其分片和聯邦策略，以適應更分散、更動態的監控環境。玄貓認為，深入理解 Prometheus 的分片和聯邦機制，並結合基數控制的最佳實踐，才能真正釋放其強大的監控能力，賦能企業構建更可靠、更高效的雲原生監控體系。

玄貓 BlackCat

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

Prometheus 分片技術與效能最佳化實踐

Prometheus 分片技術詳解與實作

什麼是 Prometheus 分片？

分片原理

內容解密：

圖表剖析：

在 Kube-Prometheus 中實作分片

程式碼解說：

Prometheus 分片的實際運作

程式碼解說：

分片的挑戰與限制

查詢結果分析：

聯邦（Federation）機制簡介

聯邦的適用場景

使用範例：

Prometheus 聯邦與高用性實作

Prometheus 聯邦機制實作

聯邦組態範例

重要組態引數解析

Kubernetes 環境下的 Prometheus 聯邦實作

ServiceMonitor 組態範例

Prometheus 例項組態

Prometheus 高用性架構實作

高用性架構設計要點

警示重複資料刪除組態

最佳實踐與注意事項

架構視覺化說明

圖表翻譯：

最佳化與除錯 Prometheus

本章主要內容

技術需求

控制資料基數

識別基數問題

圖表翻譯：

識別基數問題的方法

最佳實踐

內容解密：

記錄規則

使用記錄規則的最佳實踐

查詢效能最佳化

進一步閱讀

清理工作

附錄：Prometheus 效能調優檢查清單

圖表翻譯：

Prometheus 效能調優檢查清單使用

最佳化 Prometheus 的基數控制：提升監控系統效能的關鍵技術

技術背景與重要性

瞭解基數問題及其影響

基數的定義

基數問題的來源

使用 Prometheus 監控基數

基數統計資料

分析高基數指標

內容解密：

解決基數問題的策略

使用 metric_relabel_configs 刪除高基數指標

圖表剖析：

謹慎使用 labeldrop 操作

設定限制以防止基數爆炸

限制型別

組態示例

圖表翻譯：

最佳實踐與效能最佳化

定期監控基數

合理設定限制

最佳化指標和標籤

玄貓 BlackCat

使用 `metric_relabel_configs` 刪除高基數指標

謹慎使用 `labeldrop` 操作