Prometheus監控系統入門與實踐

– 10 分鐘閱讀

Prometheus 採用提取式資料收集方法，並結合多維度資料模型和 PromQL 查詢語言，使其成為監控系統的理想選擇。藉由 Exporter，Prometheus 能夠從各種來源收集指標，並將其儲存在本地的時間序列資料函式庫中。Alertmanager 則負責處理告警規則，並透過各種管道通知相關人員。本文將逐步引導讀者搭建 Prometheus 監控環境，並示範如何使用 PromQL 查詢和分析資料，以及如何組態告警規則。此外，文章還會探討 Prometheus 的高用性和擴充套件性，以及如何與其他工具整合，構建更全面的監控體系。

Prometheus 監控系統入門與實踐

Prometheus 是一種強大的開源監控系統與時間序列資料函式庫，專門用於收集和處理各種應用程式的指標資料。本文將探討 Prometheus 的基本概念、架構、安裝組態及使用方法，並結合實際案例分析其在現代監控系統中的重要性。

什麼是監控？

監控是確保系統、應用程式和服務正常運作的關鍵過程。它不僅涉及收集和分析系統的執行狀態資料，還需要對異常情況進行預警，以便及時採取措施避免或減少損失。良好的監控系統能夠提供即時的系統健康狀態資訊，幫助開發和維運團隊快速定位問題並最佳化系統效能。

Prometheus 簡介

Prometheus 是由 SoundCloud 開發的開源監控系統，現已成為雲原生計算基金會（CNCF）的一部分。它採用提取（Pull）模式收集指標資料，並支援多維度資料模型和強大的查詢語言 PromQL。

Prometheus 的主要特性

  1. 多維度資料模型：Prometheus 使用標籤（Label）來標識時間序列資料，使得資料查詢和過濾更加靈活高效。
  2. 靈活的查詢語言：PromQL 允許使用者對時間序列資料進行複雜的查詢和分析操作。
  3. 高效的儲存：Prometheus 採用本地儲存機制，能夠高效地儲存大量的時間序列資料。
  4. 自動服務發現：支援多種服務發現機制，能夠動態地發現和監控目標。
  5. 告警管理：與 Alertmanager 整合，提供靈活的告警規則組態和通知機制。

安裝與組態 Prometheus

在 Linux 上安裝 Prometheus

  1. 下載 Prometheus：從官方網站下載適合的版本。
    wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz
  2. 解壓縮檔案：
    tar -xvf prometheus-2.45.0.linux-amd64.tar.gz
  3. 進入目錄並執行：
    cd prometheus-2.45.0.linux-amd64
./prometheus --config.file=prometheus.yml

組態 Prometheus

Prometheus 的主要組態檔案是 prometheus.yml，用於定義抓取目標、告警規則等。

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

啟動 Prometheus 伺服器

執行以下命令啟動 Prometheus：

./prometheus --config.file=prometheus.yml

使用 Prometheus 進行監控

收集指標資料

Prometheus 透過 HTTP 介面抓取目標的指標資料。預設情況下，Prometheus 每隔一段時間會提取一次目標的指標。

使用 PromQL 查詢資料

PromQL 是 Prometheus 提供的查詢語言，用於檢索和分析時間序列資料。例如：

http_requests_total{job="prometheus"}

這條查詢陳述式會傳回 job 為 prometheus 的 http_requests_total 指標的所有時間序列資料。

結合實際案例分析

案例：監控 Web 伺服器請求量

假設我們有一個 Web 伺服器，需要監控其請求量。我們可以在 Web 伺服器上佈署 Prometheus 的客戶端函式庫，定期暴露請求量的指標。

from prometheus_client import Counter, start_http_server

REQUESTS = Counter('http_requests_total', 'Total HTTP requests')

def handle_request():
    REQUESTS.inc()

if __name__ == '__main__':
    start_http_server(8000)
    while True:
        handle_request()

然後在 Prometheus 組態檔案中新增該 Web 伺服器的抓取目標：

scrape_configs:
  - job_name: 'web_server'
    static_configs:
      - targets: ['web_server_ip:8000']
此圖示說明

此圖示展示了 Prometheus 的基本架構，包括 Prometheus Server 如何抓取 Targets 的指標資料，並將告警資訊傳送給 Alertmanager，最終通知使用者。

監控系統的擴充套件與可靠性探討

擴充套件監控系統的挑戰

在現代的IT基礎設施中，監控系統扮演著至關重要的角色。隨著系統規模的不斷擴大，如何確保監控系統的可靠性和擴充套件性成為了一項重大挑戰。

監控系統的可靠性需求

監控系統需要具備高可靠性，以確保在任何情況下都能提供準確的監控資料。這包括了硬體和軟體層面的冗餘設計，以及容錯移轉機制。

Prometheus的高用性架構

Prometheus作為一個流行的監控系統，其高用性架構設計是確保監控資料可靠性的關鍵。

雙重Prometheus伺服器架構

透過佈署雙重Prometheus伺服器，可以實作監控資料的冗餘儲存和查詢。這種架構下，兩個Prometheus例項會抓取相同的目標資料，從而確保即使其中一個例項發生故障，另一個例項仍然能夠提供完整的監控資料。

# Prometheus組態示例
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9090']

Alertmanager叢集組態

Alertmanager是Prometheus生態系統中的另一個重要元件，負責處理報警規則。組態Alertmanager叢集可以提高報警處理的可靠性和可用性。

# Alertmanager叢集組態示例
global:
  resolve_timeout: 5m

route:
  receiver: 'team-a'
  group_by: ['alertname']

receivers:
  - name: 'team-a'
    email_configs:
      - to: 'team-a@example.com'

內容解密：

  1. global.resolve_timeout: 5m：設定了解決超時時間為5分鐘，表示如果在5分鐘內未收到新的警示，則認為警示已經解決。
  2. route.receiver: 'team-a'：指定了預設的接收者為team-a，意味著所有符合路由規則的警示將預設傳送給team-a團隊。
  3. group_by: ['alertname']：設定了根據alertname標籤進行分組，這樣具有相同alertname的警示將被分組在一起處理。
  4. receivers：定義了接收者的組態，包括郵件通知組態。
  5. email_configs：指定了郵件通知的詳細組態，包括收件人地址。

監控資料的長期儲存

為了支援長期的趨勢分析和歷史資料查詢，監控資料需要被儲存到遠端儲存系統中。

使用遠端儲存系統

Prometheus支援多種遠端儲存系統，如InfluxDB、OpenTSDB等。透過組態遠端儲存，Prometheus可以將歷史監控資料儲存到這些系統中，以支援更長時間範圍的資料分析和查詢。

監控系統的架構與實踐：Prometheus 深度解析

Prometheus 是一個強大的開源監控系統與時間序列資料函式庫，廣泛應用於現代化的 DevOps 與 SRE 實踐中。本文將探討 Prometheus 的核心概念、架構設計及其在實際監控場景中的應用。

Prometheus 的核心架構

Prometheus 的架構設計高度模組化，主要由以下幾個核心元件組成：

  1. Prometheus Server：負責收集、儲存和查詢時間序列資料
  2. Exporters：將非 Prometheus 格式的資料轉換為 Prometheus 可讀的格式
  3. Pushgateway：支援短期任務的指標推播
  4. Alertmanager：處理告警相關的邏輯

Prometheus Server 的工作流程

  graph LR
    A[Prometheus Server] --> B[Scrape Targets]
    B --> C[Store Time Series Data]
    C --> D[Handle Queries]
    D --> E[Provide Alerting Data]

此圖示展示了 Prometheus Server 的主要工作流程，包括從目標服務抓取指標、儲存時間序列資料、處理查詢請求以及提供告警資料。

內容解密：

  1. Scrape Targets：Prometheus 定期從組態的目標服務提取指標資料
  2. Store Time Series Data：將收集到的指標資料儲存在本地的時間序列資料函式庫中
  3. Handle Queries：支援透過 PromQL 語言進行複雜的資料查詢
  4. Provide Alerting Data：將觸發的告警資訊傳送給 Alertmanager 進行處理

Exporters 的重要性

Exporters 在 Prometheus 生態系統中扮演著至關重要的角色，它們負責將現有的系統和應用指標轉換為 Prometheus 可讀的格式。例如：

  • Node Exporter：收集主機層級的指標，如 CPU 使用率、記憶體使用情況等
  • MySQL Exporter：收集 MySQL 資料函式庫的效能指標
  • Blackbox Exporter：進行黑盒測試，監控服務的可用性和效能

Node Exporter 的佈署實踐

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
spec:
  selector:
    matchLabels:
      name: node-exporter
  template:
    metadata:
      labels:
        name: node-exporter
    spec:
      containers:
      - name: node-exporter
        image: prometheus/node-exporter:latest
        ports:
        - containerPort: 9100

內容解密：

  1. DaemonSet：確保在每個節點上執行一個 Node Exporter 的 Pod
  2. containerPort: 9100：暴露 Node Exporter 的預設埠號，用於 Prometheus 抓取指標
  3. 這種佈署方式確保了叢集中的每個節點都能被監控

Pushgateway 的應用場景

Pushgateway 主要用於支援短期任務或批次作業的指標收集。例如，在 Kubernetes 中執行一次性任務時，可以使用 Pushgateway 將指標推播到 Prometheus。

使用 Pushgateway 的注意事項

  1. 指標會持久儲存，直到被明確刪除
  2. 需要謹慎處理指標的生命週期，避免資料冗餘
  3. 不建議用於長期執行的服務指標收集

監控系統導論：Prometheus 介紹

本文主要介紹 Prometheus，一個開源的監控系統。Prometheus 提供即時的時間序列資料收集，並具備強大的規則引擎，幫助識別所需的資訊以監控環境。在下一章中，我們將介紹 Prometheus 及其架構和元件。我們將使用 Prometheus 來引導讀者建立監控環境，重點關注動態雲端、Kubernetes 和容器環境的監控。同時，我們也會探討如何檢測應用程式並利用這些資料進行警示和視覺化。

何謂監控？

從技術角度來看，監控是指用於測量和管理技術系統的工具和流程。但監控遠不止於此。在介紹 Prometheus 之前，我們將先探討一些監控基礎知識，包括監控的定義、不同監控方法，以及一些本文後續會用到的術語和概念。

監控基礎

在深入 Prometheus 之前，瞭解監控的基本概念是非常重要的。監控不僅僅是收集資料，還包括如何利用這些資料來管理和最佳化技術系統。

監控方法

有多種監控方法，每種方法都有其優缺點。常見的監控方法包括：

  • 主動監控：透過定期測試或輪詢來檢查系統狀態。
  • 被動監控：透過收集系統發出的日誌或事件來進行監控。

監控術語和概念

在監控領域，有一些重要的術語和概念需要了解，例如：

  • 時間序列資料：按照時間順序記錄的資料，用於跟蹤系統狀態的變化。
  • 警示：當系統出現異常時，觸發通知或警告的機制。
  • 視覺化：透過圖表或儀錶板等方式，將複雜的資料以直觀的形式呈現出來。

本文架構

本文將首先介紹 Prometheus 的基本概念和架構，然後探討如何使用 Prometheus 來建立監控環境，包括檢測應用程式、使用資料進行警示和視覺化等內容。同時，本文也會提供一些監控的最佳實踐和經驗分享。

監控系統的核心價值與實務挑戰

監控系統在現代技術環境中扮演著至關重要的角色，不僅為技術團隊提供即時系統狀態資訊，也為業務決策提供關鍵資料支援。一個完善的監控系統能夠將系統和應用程式產生的指標資料轉化為衡量使用者經驗的指標，從而幫助企業確保其提供的服務符合客戶需求。

監控系統的雙重客戶：技術與業務

監控系統有兩個主要客戶群體：技術團隊和業務部門。

技術團隊作為客戶

技術團隊依賴監控系統來瞭解技術環境的當前狀態，並利用監控資料來檢測、診斷和解決系統故障與問題。監控資料為技術決策提供了重要的依據，並衡量了技術專案的成效。它是產品管理生命週期的基礎，也幫助證明企業的技術投資是有效的。

業務部門作為客戶

業務部門同樣依賴監控系統來做出明智的產品和技術投資決策。監控系統提供了必要的報告，使業務部門能夠評估技術交付的價值。沒有完善的監控，企業將難以理解其技術環境的狀態，無法有效地進行問題診斷、容量規劃，或向組織內部提供有關效能、成本或狀態的資訊。

監控的基本原則

監控應該是管理基礎設施和業務的核心工具。它應該與應用程式一同構建和佈署。缺乏有效的監控，企業將無法充分了解其技術環境的狀態，也無法提供有關效能和成本的有效資訊。

Google 的服務層級圖表清晰地展示了監控在整個技術架構中的基礎地位。

圖 1.1：服務層級架構圖

  graph LR;
    A[使用者] --> B[應用服務];
    B --> C[基礎設施];
    C --> D[硬體資源];

此圖示展示了從使用者到硬體資源的層級關係，強調了監控在各個層級的重要性。

監控設計：從業務邏輯開始

設計監控方案時，應從業務邏輯和業務輸出開始，逐步向下延伸至應用邏輯和基礎設施。這種自頂向下的監控設計方法確保了監控的重點是交付價值的關鍵部分。

圖 1.2：監控設計流程圖

  graph TD;
    A[業務邏輯] --> B[應用邏輯];
    B --> C[基礎設施];
    C --> D[硬體資源];

此圖示闡述了監控設計的優先順序，強調從業務邏輯開始的重要性。

內容解密：

  1. 業務邏輯優先：監控設計首先關注的是業務邏輯層面，這確保了監控的重點是與業務價值直接相關的部分。
  2. 逐層深入：從業務邏輯到應用邏輯，再到底層的基礎設施，每一層的監控都是為了更好地理解和確保整個系統的運作狀態。
  3. 硬體資源監控：雖然基礎設施和硬體資源的監控同樣重要，但它們通常用於診斷和容量規劃，而不是直接衡量業務價值。

監控實施中的常見反模式

  1. 事後追加的監控：將監控視為附加功能而非核心功能，可能導致關鍵指標被忽略。

    • 內容解密：

      • 將監控納入應用程式開發的初期階段，可以避免遺漏重要指標。
      • 自動化和自助服務可以簡化這一過程。

  2. 機械式監控：重複使用過去的監控檢查而不適應新系統或應用的需求。

    • 內容解密：

      • 根據具體應用設計專屬的監控方案，而非一味重用舊有的檢查。
      • 重點監控那些直接影回應用功能的關鍵服務。

  3. 忽略正確性監控：僅檢查服務是否執行而非其正確性。

    • 內容解密：

      • 不僅要檢查服務是否在執行，還要驗證其傳回內容的正確性。
      • 正確性監控能夠更準確地反映使用者經驗。

  4. 靜態閾值監控：使用靜態閾值進行監控，無法適應動態環境。

    • 內容解密：

      • 靜態閾值往往不夠靈活，無法有效應對複雜系統的動態變化。
      • 應該採用更為動態和智慧的監控策略，以適應系統的實際運作狀況。

綜上所述，一個有效的監控系統不僅需要覆寫技術和業務兩個層面，還需要避免常見的反模式，採取自頂向下、動態適應的監控設計方法，才能真正發揮出監控的核心價值。

玄貓

玄貓

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