Skip to main content

Prometheus 專家導覽

rhincodon-studio

作為 Prometheus 專家，我們將這套指標與警報平台拆解為兩種常見的部署姿態：以 Kubernetes 為控制核心的雲原生版本，與在其他環境（VM、裸機、混合雲）運行的非 Kubernetes 版本。無論是哪一種，核心哲學是一致：可觀察性、可擴展性與可行動的警報。

Kubernetes 版本​

  • Operator 驅動：透過 Prometheus Operator 及 Kube-Prometheus Stack，簡化 CRD 管理、service discovery、自動生成 ServiceMonitor 及Rule。
  • 自動擴縮：配合 HorizontalPodAutoscaler 或 Keda，依指標頻率與資源使用量調整 Prometheus Pod 數量。
  • 多租戶分層：可將集群指標與應用指標分開監控，利用 Thanos/ Cortex 做跨集群資料聚合與長期儲存。
  • GitOps Friendly：宣告式的 PrometheusRule、ServiceMonitor 與 PodMonitor 可納入 Git pull request 流程，以版本控制指標配置。

非 Kubernetes 版本​

  • 系統型部署：利用二進位、容器或 systemd + Prometheus binary，直接在 VM 或裸機上部署 node_exporter、blackbox_exporter 等。
  • 靈活發現：透過 file_sd_configs 搭配 Consul、DNS 與自訂腳本自動化發現實體主機，或利用 relabel_configs 處理複雜網段。
  • Sidecar 結構：如果已有 legacy 或 edge 平台，可以在附近部署 Prometheus 實例，將資料推送到集中化的遠端寫入（Remote Write）。
  • 容量預測：藉由指標採樣率與保留期限的設定，搭配 storage.tsdb.retention.time 及磁碟監控，避免資料爆表。

綜合觀察​

  1. 架構一致性：不論在哪種環境，Prometheus 皆以 pull 為主，確保每一次 scraping 都可追溯。
  2. 警報策略：將 alertmanager 與通知頻道分層管理，避免 high-cardinality 指標導致頻繁噪音。
  3. 長期資料：若需要存放歷史資料請搭配 Thanos/Cortex，或使用 remote storage hooks 將快取資料同步至 object storage。

架構概覽​

這張架構圖展示了 Kubernetes 中由 Operator 長出 Prometheus 實例、透過 ServiceMonitor / PodMonitor 掃描指標來源、再與 Thanos/Cortex 做遠端寫入；非 Kubernetes 節點則以 exporters/Pushgateway 直接對 Prometheus 提供指標，而 Alertmanager 將通知送給營運團隊。

歡迎進一步探索 /prometheus/kubernetes 與 /prometheus/non-kubernetes 等章節，讓團隊在任一基礎上都能建立符合 Rhincodon Studio 標準的可觀察性平台。