Prometheus：生態系統的豐富性

Prometheus 生態系統的豐富性

圍繞 Prometheus 已經發展出豐富的生態系統：

**各種語言的程式碼檢測函式庫：讓開發者能輕鬆在自己的應用程式中加入 Prometheus 指標。
指標匯出器（Exporters）：從應用程式中提取資料並生成 Prometheus 格式的指標。在我的實踐中，這些匯出器大簡化了對第三方服務的監控工作。
知識中心：提供可信賴的資源和檔案，幫助團隊快速上手。

這些資源使得在開始使用 Prometheus 進行新的監控專案時，能輕鬆找到所需的資源和資訊。

Prometheus 安裝：從開發到生產環境

在過去幾年搭建監控系統的經驗中，我發現 Prometheus 的安裝方式多樣，可以根據不同需求選擇最適合的方式。

安裝方式概覽

Prometheus 的安裝方式主要分為兩大類別：

直接在主機上作為單一二進位檔案執行：適合學習、測試和開發目的，但不適合容器化佈署。
作為 Docker 容器執行，有多種協調選擇：
- 原生 Docker 容器
- Kubernetes Deployments / 有狀態集合s
- Helm Kubernetes 套件管理器
- Kubernetes 運算元（Operators）等

根據你選擇的安裝方法，Prometheus 安裝可以手動完成或透過自動化佈署完成：

手動安裝選項

單一二進位檔案
Docker 容器

自動化佈署選項

Helm 圖表
Prometheus Operator

單一二進位檔案安裝

你可以直接在主機上下載並執行 Prometheus 二進位檔案：

prometheus-2.21.0.linux-amd64$ ./prometheus
./prometheus
level=info ts=2020-09-25T10:04:24.911Z caller=main.go:310 msg="No time or size retention was set so using the default time retention" duration=15d
[...]
level=info ts=2020-09-25T10:04:24.916Z caller=main.go:673 msg="Server is ready to receive web requests."

這種方式可以快速瞭解 Prometheus 網頁介面（預設連線埠 9090）。然而，對於正式環境，我更推薦在容器中佈署 Prometheus 伺服器。

Docker 容器安裝

使用 Docker 執行 Prometheus 非常簡單：

docker run -p 9090:9090 -v /tmp/prometheus.yml:/etc/prometheus/prometheus.yml \
prom/prometheus

值得注意的是，你可以輕鬆將此 Docker 容器調整為適當的 Kubernetes Deployment 物件，該物件將從 ConfigMap 掛載設定，暴露服務，佈署多個副本等。

Kubernetes 上的 Helm 安裝

在我管理的大型生產環境中，在 Kubernetes 叢集中安裝 Prometheus 最簡單的方法是使用 Helm。Prometheus 社群維護著一個 Helm chart，使安裝和設定 Prometheus 及其生態系統中的不同應用程式變得非常容易。

要在 Kubernetes 叢集中安裝 Prometheus，只需執行以下命令：

首先，將 Prometheus charts 儲存函式庫到你的 helm 設定中：

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo add stable https://kubernetes-charts.storage.googleapis.com/
helm repo update

然後，安裝 Prometheus：

helm install prometheus prometheus-community/prometheus

這種方法的優勢在於它不僅安裝了 Prometheus 伺服器，還設定了常見的指標匯出器和預設的告警規則，讓你能夠快速開始監控你的 Kubernetes 叢集。

Prometheus 在實際佈署中的考量

在實際佈署 Prometheus 時，玄貓認為需要考慮幾個關鍵因素：

儲存需求：根據你要監控的服務數量和指標收集頻率，規劃足夠的儲存空間。
高用性：對於生產環境，考慮佈署多個 Prometheus 例項以確保高用性。
資料保留期：決定保留歷史資料的時間長度，這會直接影響儲存需求。
擴充套件性：隨著監控範圍的擴大，考慮使用聯邦叢集或遠端儲存解決方案。

從我的經驗來看，在大型環境中，使用 Prometheus Operator 提供了最佳的管理體驗，特別是當你需要管理多個 Prometheus 例項和複雜的監控設定時。

Prometheus 的彈性和可擴充套件性使其成為監控雲基礎架構、叢集或應用程式時的預設選擇。在後續章節中，我們將探討更多細節，這些細節對於在生產環境中可靠地執行 Prometheus 系統至關重要。

當我們完成 Prometheus 的安裝後，下一步就是開始設定它來收集指標並設定適合你環境的警示規則。這是一個迭代過程，隨著對系統行為的瞭解不斷深入，你的監控策略也會不斷完善。

在現代雲原生環境中，Prometheus 已成為監控基礎設施的核心元件。透過掌握 PromQL 和了解不同的佈署選項，你可以建立一個強大而靈活的監控系統，幫助你的團隊在問題影響使用者之前發現並解決它們。

透過本文的介紹，我希望你對 Prometheus 的強大功能和靈活性有了更深入的理解。從簡單的指標收集到複雜的查詢語言，再到多種佈署選項，Prometheus 提供了一套完整的解決方案，可以滿足從小型專案到大型企業環境的各種監控需求。隨著雲原生技術的不斷發展，掌握這些監控工具將成為每個 DevOps 和 SRE 專業人員的必備技能。

佈署 Prometheus 監控系統：從安裝到實作全面監控

Helm 指令與安裝方式

使用 Helm 安裝 Prometheus 非常直接。根據你使用的 Helm 版本，執行以下指令：

# Helm 3 安裝指令
helm install [RELEASE_NAME] prometheus-community/prometheus

# Helm 2 安裝指令
helm install --name [RELEASE_NAME] prometheus-community/prometheus

幾秒鐘後，你應該能在叢集中看到 Prometheus 相關的 Pod：

NAME                                           READY   STATUS    RESTARTS   AGE
prometheus-kube-state-metrics-66cc6888bd-x9llw 1/1     Running   0          93d
prometheus-node-exporter-h2qx5                 1/1     Running   0          10d
prometheus-node-exporter-k6jvh                 1/1     Running   0          10d
prometheus-node-exporter-thtsr                 1/1     Running   0          10d
prometheus-server-0                            2/2     Running   0          90m

值得一提的是，Helm chart 不僅佈署了 Prometheus 本身，還同時佈署了 node-exporter、kube-state-metrics 和 alertmanager，讓你能立即開始監控節點和叢集狀態。

若需要更進階與自動化的選項，可以考慮使用 Prometheus Operator。它可視為一種元佈署 (meta-deployment)，能管理其他佈署，並根據高階服務規格來設定和更新它們。

Prometheus Exporters：橋接各式資料源

雖然某些服務和應用程式已採用 Prometheus 指標格式並提供相應端點，但許多熱門的伺服器應用程式如 Nginx 或 PostgreSQL 的存在遠早於 Prometheus 指標/OpenMetrics 標準。這些應用程式通常有自己的指標格式和展示方法，若你試圖使用 Prometheus 指標統一多個微服務和主機的指標管道，這可能會是個問題。

為解決這個障礙，Prometheus 社群建立並維護了大量的 Prometheus exporters。Exporter 是一種「翻譯器」或「轉接器」程式，能收集伺服器原生指標（或觀察伺服器行為產生自己的資料），並使用 Prometheus 指標格式和 HTTP 協定重新釋出這些指標。

這些小型二進位檔案可以作為 sidecar 與主要監控伺服器位於同一個 Pod，或隔離在自己的 Pod 甚至不同的基礎架構中。然後，你可以透過抓取 exporter 暴露的轉換成 Prometheus 格式的指標來收集服務指標。

Exporter 的多樣性與選擇考量

網路上有數百種 Prometheus exporters 可用，每種 exporter 都因其監控的應用程式而不同。在大多數情況下，exporter 需要驗證方法來存取應用程式並產生指標。這些驗證方式包括從純文字 URL 連線字串到憑證或具有應用程式特殊許可權的專用使用者。

在某些情況下，exporter 可能需要掛載與應用程式分享的卷來解析日誌或檔案。此外，應用程式有時需要特殊設定才能允許 exporter 取得資料並生成指標。

偶爾，同一應用程式可能有多個 exporter。這可能是因為它們提供不同功能、被分叉或停止維護的專案，甚至是針對應用程式不同版本的不同 exporter。正確識別要監控的應用程式、所需的指標以及能為監控解決方案提供最佳方法的適當 exporter 非常重要。

為了減少尋找、驗證和設定這些 exporters 所需的維護工作，Sysdig 建立了一個名為 PromCat.io 的網站，在那裡他們企劃最佳 exporters，提供詳細的設定範例，並支援希望使用它們的客戶。可以在該網站上檢視最新的 Prometheus exporters 和整合列表。

MongoDB Exporter 安裝範例

MongoDB exporter 收集 MongoDB 的指標並以 Prometheus 格式暴露它們。要在 Kubernetes 叢集中安裝 MongoDB exporter，我們將使用可用的 Helm chart。

首先，建立一個包含以下引數的 values.yaml 檔案：

fullnameOverride: "mongodb-exporter"
podAnnotations:
  prometheus.io/scrape: "true"
  prometheus.io/port: "9216"
serviceMonitor:
  enabled: false
mongodb:
  uri: mongodb://exporter-user:exporter-pass@mongodb:27017

請注意，mongodb.uri 引數是一個有效的 MongoDB URI。在此 URI 中，包含 exporter 的使用者和密碼。Helm chart 將使用該 URI 建立一個 Kubernetes Secret，使其不可見。MongoDB 中的使用者需要在 MongoDB 控制檯中使用以下指令建立：

use admin
db.auth("your-admin-user", "your-admin-password")
db.createUser(
  {
    user: "exporter-user",
    pwd: "exporter-pass",
    roles: [
      { role: "clusterMonitor", db: "admin" },
      { role: "read", db: "admin" },
      { role: "read", db: "local" }
    ]
  }
)

根據需要更改使用者名稱和密碼。指標將在 exporter pod 的 9216 連線埠上可用。

然後，使用以下指令在 Kubernetes 叢集中安裝 exporter：

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

Prometheus Exporter 的運作原理

玄貓在實施多個監控系統時發現，理解 exporter 的運作模式非常重要。Exporter 基本上執行三個主要功能：

連線到目標系統：使用設定的認證和連線引數
收集原始指標：從目標系統取得原始資料或日誌
轉換並釋出：將原始資料轉換為標準 Prometheus 格式並透過 HTTP 端點釋出

這種模式使得 Prometheus 可以統一從各種不同系統收集指標，無論這些系統原本使用什麼格式記錄其效能和狀態資料。

選擇正確的 Exporter 的關鍵因素

在選擇 exporter 時，需要考慮幾個關鍵因素：

維護狀態：選擇活躍維護的 exporter，確保它能適應用程式的變化
覆寫範圍：確保 exporter 收集你所需的特定指標
效能影響：評估 exporter 對被監控系統的效能影響
安全考量：檢查 exporter 所需的許可權級別是否符合安全政策
社群支援：具有良好檔案和活躍社群的 exporter 通常更可靠

在實際佈署中，玄貓發現測試 exporter 的最佳方法是在非生產環境中先進行試驗，確保其不會對系統造成不良影響，並能提供所需的監控資料。

在大型系統中，合理規劃 exporter 的佈署策略也很重要。有時將 exporter 作為 sidecar 佈署在應用程式 Pod 中是最佳選擇，而在其他情況下，將其作為獨立服務可能更合適，特別是當單個 exporter 需要監控多個相同類別的應用程式例項時。

透過這種方式，Prometheus 與各種 exporters 的結合為現代混合雲環境提供了強大與靈活的監控解決方案，能夠適應從傳統應用到最新微服務的各種工作負載。

玄貓

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