Thanos Sidecar 佈署應用與效能調校

– 9 分鐘閱讀

Prometheus 的本地儲存容量有限，在面對大規模監控資料時容易遇到瓶頸。Thanos Sidecar 作為 Thanos 生態系的重要元件，能有效解決此問題，提供長期儲存和全域性查詢能力。本文將詳細介紹 Sidecar 的佈署流程、設定方式及工作原理，並探討如何進行效能調校以提升監控系統的效率和穩定性。同時，我們也會比較 VictoriaMetrics、Grafana Mimir 和 Thanos 等方案，分析其各自的優缺點，協助讀者根據實際需求選擇最佳的監控架構。最後，我們將探討 Sidecar 的安全考量和最佳實踐，確保監控系統的安全性和可靠性。

VictoriaMetrics：高效能時間序列資料函式庫的佈署與應用

VictoriaMetrics 是一種高效能的時間序列資料函式庫，廣泛應用於監控系統和可觀察性解決方案中。它提供了單節點和叢集兩種佈署模式，以滿足不同規模和需求的使用場景。

佈署模式選擇與效能優勢

VictoriaMetrics 提供單節點和叢集兩種佈署模式。單節點模式適合大多數中小型環境，而叢集模式則適用於超大規模的資料處理需求。根據官方測試，單節點佈署能夠處理每秒超過150萬個樣本的寫入速率，超過5000萬個活躍時間序列，且總共超過50億個時間序列。這些效能指標表明，單節點 VictoriaMetrics 在大多數情況下足以滿足需求。

圖表1：VictoriaMetrics佈署架構圖

  flowchart TD
 A[Kubernetes叢集] --> B[VictoriaMetrics單節點佈署]
 B --> C[Prometheus組態遠端寫入]
 C --> D[資料儲存於VictoriaMetrics]
 D --> E[Grafana資料視覺化]
 E --> F[監控儀錶板展示]

圖表剖析：

此圖表展示了在 Kubernetes 叢集中佈署 VictoriaMetrics 的完整架構。首先，在 Kubernetes 中佈署單節點 VictoriaMetrics。接著，組態 Prometheus 將監控資料遠端寫入 VictoriaMetrics。資料儲存於 VictoriaMetrics 後，透過 Grafana 進行資料視覺化，最終在監控儀錶板中展示系統執行狀態。

在 Kubernetes 上佈署 VictoriaMetrics

使用 Helm chart 在 Kubernetes 叢集中佈署 VictoriaMetrics 十分簡便。首先，需要新增 VictoriaMetrics 的 Helm 儲存函式庫並更新：

$ helm repo add victoria-metrics https://victoriametrics.github.io/helm-charts/
$ helm repo update

接著，建立一個 values.yaml 檔案來組態 VictoriaMetrics 的佈署引數：

server:
 persistentVolume:
 enabled: true
 storageClass: "standard"
 size: 100Gi
scrape:
 enabled: false
insert:
 enabled: true

這個設定啟用了持久化儲存卷的建立，並指定了儲存類別和大小。接下來，使用 Helm 安裝 VictoriaMetrics：

$ helm install vmsingle victoria-metrics/victoria-metrics-single \
 --namespace prometheus \
 --values values.yaml

安裝完成後，Helm chart 會輸出相關的使用資訊，包括 VictoriaMetrics 的服務 URL 和寫入 URL。記下寫入 URL，因為稍後需要用來組態 Prometheus 將資料傳送到 VictoriaMetrics。

程式碼範例：Prometheus遠端寫入組態

import yaml

# 定義Prometheus的遠端寫入組態
remote_write_config = {
 "remoteWrite": [
 {
 "url": "http://vmsingle-victoria-metrics-single-server:8428/api/v1/write",
 "headers": {
 "X-Scope-OrgID": "monitoring-team"
 }
 }
 ]
}

# 將組態轉換為YAML格式
yaml_config = yaml.dump(remote_write_config, default_flow_style=False)

print(yaml_config)

內容解密：

此程式碼範例展示瞭如何使用 Python 的 yaml 模組生成 Prometheus 的遠端寫入組態。程式首先定義了一個包含遠端寫入 URL 和自定義 HTTP 標頭的組態字典，然後使用 yaml.dump() 方法將其轉換為 YAML 格式的字串。輸出的 YAML 組態可以直接用於 Prometheus 的組態檔案中，以實作遠端寫入功能。自定義的 X-Scope-OrgID 標頭可用於多租戶環境中的組織識別。

利用遠端儲存系統提升 Prometheus 的可擴充套件性

Prometheus 的本地儲存設計在處理大量資料時會遇到瓶頸。遠端儲存解決方案可以提供更好的可擴充套件性和永續性儲存，適合長期儲存監控資料。本文將深入探討 VictoriaMetrics、Grafana Mimir 和 Thanos 等技術的實作細節和比較。

為何需要遠端儲存

Prometheus 的本地儲存雖然簡單高效，但在處理大量資料時會遇到效能瓶頸。遠端儲存解決方案可以將資料儲存在更適合長期儲存的系統中，如物件儲存或專門的時間序列資料函式庫。

圖表2：Prometheus遠端儲存架構比較

  graph LR
 A[Prometheus] -->|遠端寫入|> B[VictoriaMetrics]
 A -->|遠端寫入|> C[Grafana Mimir]
 A -->|遠端寫入|> D[Thanos]
 B --> E[本地儲存]
 C --> F[物件儲存S3]
 D --> G[物件儲存GCS]

圖表剖析：

此圖表比較了 Prometheus 與不同遠端儲存解決方案的整合架構。VictoriaMetrics 使用本地儲存，而 Grafana Mimir 和 Thanos 支援物件儲存（如 S3 和 GCS）。不同的儲存方案適用於不同的使用場景和雲端環境。

VictoriaMetrics 與其他方案的比較

儲存架構

VictoriaMetrics 使用本地儲存或區塊儲存，而 Mimir 和 Thanos 則專注於物件儲存。這使得 Mimir 和 Thanos 在雲環境中更具成本優勢。

效能比較

根據基準測試，VictoriaMetrics 在儲存效率和資源利用率方面表現出色。不過，Mimir 在查詢延遲方面表現較佳。Thanos 則提供了更好的全球查詢能力和多租戶支援。

def compare_storage_systems(vm_metrics, mimir_metrics, thanos_metrics):
 """比較不同遠端儲存方案的儲存效率"""
 vm_efficiency = calculate_efficiency(vm_metrics)
 mimir_efficiency = calculate_efficiency(mimir_metrics)
 thanos_efficiency = calculate_efficiency(thanos_metrics)

print(f"VictoriaMetrics 效率: {vm_efficiency:.2f}")
 print(f"Mimir 效率: {mimir_efficiency:.2f}")
 print(f"Thanos 效率: {thanos_efficiency:.2f}")

def calculate_efficiency(metrics):
 """計算儲存效率"""
 total_samples = metrics['total_samples']
 storage_used = metrics['storage_used']
 return total_samples / storage_used if storage_used >0 else0

內容解密：

此 Python 程式碼比較了 VictoriaMetrics、Mimir 和 Thanos 的儲存效率。透過計算每個系統的樣本數量與儲存使用量的比率，函式能夠判斷哪個系統更高效，並輸出對比結果。這種分析方法可以幫助使用者根據實際需求選擇最合適的遠端儲存方案。

技術主題標題

Thanos Sidecar 在監控系統中的應用與實踐

Thanos Sidecar 概述

Thanos Sidecar 是 Thanos 監控系統中的重要元件，主要負責與 Prometheus 協同工作，提供長期儲存和全域性查詢能力。Sidecar 透過與 Prometheus 的緊密整合，能夠無縫地將即時監控資料傳輸至儲存系統，實作高效的監控資料管理。

Thanos Sidecar 的核心功能

  1. 資料同步：Sidecar 持續監控 Prometheus 的 TSDB（Time Series Database），並將資料上傳至物件儲存系統，如 S3 或 GCS。
  2. 全域性查詢：透過 Sidecar，Thanos Querier 能夠跨多個 Prometheus 例項執行全域性查詢，提供統一的監控資料檢視。
  3. 高用性：Sidecar 支援多個 Prometheus 例項的佈署，確保監控系統的高用性和可擴充套件性。

Thanos Sidecar 的佈署與設定

要正確佈署 Thanos Sidecar，需要確保 Prometheus 和 Sidecar 在相同的 Kubernetes 叢集中執行。以下是一個典型的佈署範例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: thanos-sidecar
spec:
  replicas: 1
  selector:
    matchLabels:
      app: thanos-sidecar
  template:
    metadata:
      labels:
        app: thanos-sidecar
    spec:
      containers:
      - name: thanos-sidecar
        image: thanosio/thanos:latest
        args:
        - "sidecar"
        - "--prometheus.url=http://prometheus:9090"
        - "--tsdb.path=/prometheus"
        - "--objstore.config=$(OBJSTORE_CONFIG)"
        env:
        - name: OBJSTORE_CONFIG
          value: |
            type: S3
            config:
              bucket: "thanos-data"
              endpoint: "s3.amazonaws.com"
              region: "us-east-1"
              access_key: "your-access-key"
              secret_key: "your-secret-key"
        volumeMounts:
        - name: prometheus-data
          mountPath: /prometheus
      volumes:
      - name: prometheus-data
        persistentVolumeClaim:
          claimName: prometheus-data-pvc

設定解說

此範例展示瞭如何啟動 Thanos Sidecar。Sidecar 需要與 Prometheus 一起佈署，並指定 Prometheus 的 URL 和 TSDB 資料路徑。這些設定確保了 Sidecar 能夠正確地與 Prometheus 互動，並提供即時資料的查詢能力。

內容解密：

Thanos Sidecar 的佈署組態主要涉及以下幾個關鍵引數：

  1. prometheus.url：指定 Prometheus 服務的 URL，確保 Sidecar 能夠正確連線至 Prometheus。
  2. tsdb.path：指定 Prometheus 的 TSDB 資料儲存路徑，這是 Sidecar 同步資料的來源。
  3. objstore.config：組態物件儲存的詳細資訊，包括儲存型別、儲存桶名稱、端點、存取金鑰等，用於將資料上傳至遠端儲存。

透過這些設定，Thanos Sidecar 能夠高效地與 Prometheus 協同工作，實作監控資料的長期儲存和全域性查詢。

Thanos Sidecar 的工作原理

Thanos Sidecar 的工作原理可以透過以下架構圖來理解：

  graph LR
    A[Prometheus] -->|TSDB 資料|> B[Thanos Sidecar]
    B -->|上傳資料|> C[物件儲存系統 S3/GCS]
    D[Thanos Querier] -->|查詢請求|> B
    B -->|查詢結果|> D

圖表剖析：

  1. Prometheus：負責收集和儲存監控資料，Sidecar 從 Prometheus 的 TSDB 中取得資料。
  2. Thanos Sidecar：負責將 Prometheus 的 TSDB 資料上傳至物件儲存系統，並回應 Querier 的查詢請求。
  3. 物件儲存系統：長期儲存監控資料，支援 S3 或 GCS 等儲存方案。
  4. Thanos Querier：負責執行全域性查詢請求，透過 Sidecar 取得所需的監控資料。

透過這樣的架構，Thanos Sidecar 能夠實作高效的資料同步和全域性查詢，滿足大規模監控系統的需求。

實際應用案例

在某大型企業的監控系統中，Thanos Sidecar 被用於整合多個 Prometheus 例項的資料，實作全域性監控和長期資料儲存。具體實施步驟如下：

  1. 佈署 Prometheus 和 Thanos Sidecar：在 Kubernetes 叢集中佈署 Prometheus 和 Thanos Sidecar，確保 Sidecar 正確連線至 Prometheus。
  2. 組態物件儲存：設定物件儲存的相關引數，將監控資料上傳至 S3。
  3. 執行全域性查詢：透過 Thanos Querier 執行全域性查詢，取得所需的監控資料。

案例效果

透過 Thanos Sidecar 的佈署，該企業實作了以下效果：

  1. 高效的資料同步：Sidecar 能夠實時將 Prometheus 的資料上傳至物件儲存系統。
  2. 全域性查詢能力：Querier 能夠跨多個 Prometheus 例項執行查詢，提供統一的監控資料檢視。
  3. 高用性：透過多個 Sidecar 例項的佈署，確保了監控系統的高用性。

效能測試與分析

為了評估 Thanos Sidecar 的效能，進行了以下測試：

  1. 基準測試：在不同負載條件下測試 Sidecar 的資料上傳速率和查詢回應時間。
  2. 效能監控：透過 Prometheus 和 Grafana 監控 Sidecar 的效能指標，如 CPU 使用率、記憶體使用率等。

測試結果

測試結果表明，Thanos Sidecar 在高負載條件下仍能保持穩定的資料上傳速率和查詢回應時間，展現了良好的效能表現。

  graph TD
    A[開始測試] --> B[基準測試]
    B --> C[效能監控]
    C --> D[測試結果分析]
    D --> E[最佳化建議]

圖表剖析：

  1. 開始測試：啟動效能測試流程。
  2. 基準測試：在不同負載條件下測試 Sidecar 的效能。
  3. 效能監控：監控 Sidecar 的效能指標。
  4. 測試結果分析：分析測試結果，評估 Sidecar 的效能表現。
  5. 最佳化建議：根據測試結果提出最佳化建議，提升 Sidecar 的效能。

安全考量與最佳實踐

在佈署 Thanos Sidecar 時，需要考慮以下安全因素：

  1. 存取控制：確保物件儲存的存取金鑰安全，避免未授權存取。
  2. 資料加密：對傳輸中的資料進行加密，保護資料安全。
  3. 網路隔離：透過網路隔離措施，限制對 Sidecar 和 Prometheus 的存取。

最佳實踐

  1. 定期更新：定期更新 Thanos 和 Prometheus 的版本，修補已知的安全漏洞。
  2. 監控日誌：監控 Sidecar 和 Prometheus 的日誌，及時發現和處理安全事件。
  3. 備份資料：定期備份物件儲存中的資料，防止資料丟失。

透過遵循這些最佳實踐，可以確保 Thanos Sidecar 的安全佈署和穩定執行。

VictoriaMetrics憑藉其高效能和易於佈署的特性，正在快速成為監控領域的新興力量。分析其單節點架構和叢集模式，可以發現VictoriaMetrics在資源利用率和資料寫入速度方面展現出顯著優勢，尤其單節點模式足以應付大多數中小型企業的需求，簡化了佈署和維護的複雜性。然而，VictoriaMetrics的長期儲存策略仍需考量與物件儲存服務的整合，以進一步提升成本效益和擴充套件性。預計VictoriaMetrics將持續最佳化其查詢效能和多租戶支援，並強化與其他可觀察性工具的整合，以滿足更廣泛的應用場景。玄貓認為，對於追求效能和簡潔性的監控系統而言，VictoriaMetrics是一個值得深入評估和應用的解決方案。

玄貓

玄貓

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