Prometheus 是什麼#
Prometheus 是一套開源的監控與告警系統，由 SoundCloud 在 2012 年開發，2016 年成為 CNCF 繼 Kubernetes 之後的第二個畢業專案。如今它已是雲原生生態系中 Metrics 領域的事實標準。
Prometheus 的核心設計理念可以用三個關鍵詞概括：
- Pull-based：由 Prometheus Server 主動到各個目標拉取指標，而非被動等待推送
- 單機優先：每一台 Prometheus Server 都是獨立且完整的，不依賴分散式儲存或外部服務就能運作
- 本地 TSDB：內建高效的時間序列資料庫，針對指標資料的寫入與查詢做了深度最佳化
Pull-based 的一個重要附帶好處是健康偵測免費送。如果 Prometheus 無法拉取某個目標的指標，它就知道那個目標掛了 ── 不需要額外的健康檢查機制。
核心元件#
Prometheus 生態系由幾個角色分工明確的元件組成。理解每個元件的職責，才能判斷你的架構需要哪些。
Prometheus Server#
整個生態系的核心，同時扮演三個角色：
- 抓取器（Scraper）：按照設定的 Scrape Job，定期到各個 Target 的 HTTP Endpoint 拉取指標
- 儲存引擎（TSDB）：將抓取到的指標寫入本地的時間序列資料庫
- 查詢引擎：提供 PromQL 查詢介面，供 Dashboard 和告警規則使用
這種「三合一」的設計讓 Prometheus 非常容易部署 ── 一個二進位檔就能跑起來。但也因為如此，單機的資源就是它的天花板。
Exporter#
並不是每個系統都原生支援 Prometheus 格式的指標輸出。Exporter 是一座橋樑，它連接到第三方系統（資料庫、硬體、中介軟體），將指標轉換為 Prometheus 能理解的格式並暴露出來。
常見的 Exporter 類型：
- Node Exporter：匯出 Linux 主機的 CPU、記憶體、磁碟、網路等作業系統層級指標
- Database Exporter：如 MySQL Exporter、PostgreSQL Exporter，匯出資料庫的連線數、查詢效能等
- Blackbox Exporter：從外部探測目標（HTTP、TCP、ICMP），監控服務的可用性和回應時間
選擇 Exporter 時，優先使用 Prometheus 官方或社群廣泛維護的版本。品質參差不齊的第三方 Exporter 可能帶來安全風險或指標不準確的問題。
Client Library#
當你需要在自己的應用程式中記錄業務指標時，使用 Client Library 進行埋點。它提供 Counter、Gauge、Histogram、Summary 這四種 Metric Type 的 API，讓你在程式碼中方便地記錄和暴露指標。
Client Library 支援多種語言（Go、Java、Python、Ruby 等），並且自動處理指標的暴露 ── 通常是在你的應用程式上開一個 /metrics HTTP Endpoint。
四種 Metric Types#
Prometheus 定義了四種語義明確的指標類型，每一種適用於不同性質的量測：
Counter#
只增不減的累計值。適合記錄「發生了幾次」的事件。
- 典型場景：HTTP 請求總數、處理的位元組數、發生的錯誤次數
- 重點觀念：Counter 的絕對值通常沒有意義（因為會隨著程序重啟歸零），真正有用的是它的變化率──「每秒增加了多少」
Gauge#
可增可減的即時值。適合記錄「現在是多少」的狀態。
- 典型場景：CPU 使用率、記憶體使用量、佇列中的待處理任務數、溫度
- 重點觀念：Gauge 的絕對值本身就有意義，你關心的就是「現在這個值是多少」
Histogram#
將觀測值分佈到預定義的桶（Bucket）中。適合記錄「數值的分佈狀況」。
- 典型場景：請求延遲分佈、回應大小分佈
- 重點觀念：Histogram 在 Server 端計算分位數（如 P50、P95、P99），因此可以跨多個實例聚合。缺點是桶的邊界必須預先定義，選擇不當會影響精確度
Summary#
類似 Histogram，但在 Client 端直接計算分位數。
- 典型場景：與 Histogram 相同，但當你需要精確的分位數且不需要跨實例聚合時使用
- 重點觀念：因為分位數在客戶端計算，無法跨多個實例聚合。這是 Summary 最大的限制
在大多數情況下，優先選擇 Histogram 而非 Summary。Histogram 支援跨實例聚合，這在微服務架構中至關重要 ── 你通常想知道的是「整個服務的 P99 延遲」，而不是「某一台實例的 P99 延遲」。
PromQL：專為時間序列設計的查詢語言#
Prometheus 沒有使用 SQL，而是設計了自己的查詢語言 PromQL（Prometheus Query Language）。這個選擇乍看之下增加了學習成本，但它針對時間序列的操作模式做了深度最佳化。
PromQL 最核心的能力包括：
- 比率計算：將 Counter 的累計值轉換為每秒速率，這是最常見的操作。例如計算每秒請求數、每秒錯誤數
- 聚合：對多條時間序列做加總、平均、取最大值等運算。例如把所有 Pod 的 CPU 使用率加總得到整個服務的用量
- 向量匹配：將兩組指標做數學運算。例如「錯誤請求數 / 總請求數」算出錯誤率
- 預測：根據歷史趨勢預測未來值。例如根據磁碟空間的下降速度預測何時會滿
PromQL 的學習曲線是 Prometheus 生態系中最常被提及的痛點之一。但一旦掌握了
rate()、sum()、histogram_quantile()這幾個核心函數，就能覆蓋日常 80% 以上的查詢需求。
Alerting 的運作機制#
Prometheus 的告警分為兩個階段，由兩個不同的元件負責：
階段一：規則評估（Prometheus Server）#
Prometheus Server 定期評估告警規則。規則本質上就是一個 PromQL 查詢加上持續時間條件 ── 例如「錯誤率超過 5% 且持續超過 5 分鐘」。當條件滿足時，Prometheus 觸發一個 Alert 並發送給 AlertManager。
階段二：通知管理（AlertManager）#
AlertManager 負責接收 Alert 後的所有處理：
- 路由（Routing）：根據 Label 將 Alert 送到不同的接收者。例如：資料庫相關的告警送給 DBA 團隊，應用層告警送給開發團隊
- 分組（Grouping）：將同時觸發的多個相關 Alert 合併為一則通知，避免告警風暴
- 靜音（Silencing）：在已知的維護窗口期間，暫時壓制特定告警
- 抑制（Inhibition）：當高優先級的告警已經觸發時，自動壓制由它引起的低優先級告警
這種分離設計是刻意的。Prometheus Server 專注於「判斷是否異常」，AlertManager 專注於「異常了要通知誰、怎麼通知」。職責分離讓每個元件都更容易理解和維護。
適用場景與限制#
Prometheus 擅長什麼#
- 雲原生環境：與 Kubernetes 深度整合，Service Discovery 讓動態環境中的監控變得簡單
- 多維度指標查詢：Label 機制讓你能靈活地按任意維度切片分析
- 中小規模部署：單機就能處理數百萬條活躍時間序列，對大多數團隊來說綽綽有餘
Prometheus 的限制#
- 單機擴展性天花板：當指標量超過單機承載能力時，需要引入 Thanos、Cortex、VictoriaMetrics 等方案做水平擴展
- 長期儲存非原生：本地 TSDB 預設保留 15 天的資料，需要長期保存（數月到數年）的場景需要額外整合 Remote Write 到外部儲存
- 不適合事件型資料：Metrics 是聚合後的數值，不適合記錄個別事件的詳細資訊。日誌和追蹤有更合適的工具
- 不適合精確計費：Prometheus 在設計上允許少量資料遺失（例如抓取間隔之間的瞬間事件），因此不適合需要精確計數的計費場景
Prometheus 的「單機完整」設計既是它的優點也是它的限制。對於大多數團隊來說這已經足夠，但如果你的環境有數千萬條時間序列或需要跨地域的全域檢視，就需要在 Prometheus 之上疊加聯邦（Federation）或遠端儲存方案。