常見問題

常規

什麼是 Prometheus？

Prometheus 是一個開源的系統監控和告警工具包，擁有活躍的生態系統。它是唯一由 Kubernetes  直接支援的系統，也是 雲原生生態系統  事實上的標準。請參閱 概述。

Prometheus 與其他監控系統相比如何？

請參閱 對比 頁面。

Prometheus 有哪些依賴？

Prometheus 主伺服器作為單個單體二進位制檔案獨立執行，沒有任何外部依賴。

這是雲原生的嗎？

是的。

雲原生是一種靈活的執行模式，它打破了舊的服務邊界，以實現更靈活、更具擴充套件性的部署。

Prometheus 的 服務發現 與大多數工具和雲進行了整合。它的多維資料模型以及支援數千萬活躍時間序列的規模，使其能夠監控大型雲原生部署。在執行服務時總需要進行權衡，而 Prometheus 認為最重要的事情是可靠地向人類傳送告警。

Prometheus 可以實現高可用嗎？

可以，在兩臺或多臺獨立的機器上執行相同的 Prometheus 伺服器。

像 Thanos  這樣的系統可以對資料進行去重。許多支援 遠端寫入 的 外部系統 也可以對資料進行去重。

相同的告警將由 Alertmanager  進行去重。

Alertmanager 透過互連多個 Alertmanager 例項來構建 Alertmanager 叢集，從而支援 高可用 。

有人告訴我 Prometheus “無法擴充套件”。

這往往更多是一種營銷說辭，而非事實。

單個 Prometheus 例項的效能可能比某些標榜為 Prometheus 長期儲存解決方案的系統還要高。您可以可靠地執行擁有數千萬活躍時間序列的 Prometheus。

如果您需要比這更大的規模，有幾種選擇。Robust Perception 部落格上的 Scaling and Federating Prometheus  是一個很好的起點，我們 整合頁面 上列出的長期儲存系統也是不錯的選擇。

Prometheus 是用什麼語言編寫的？

大多數 Prometheus 元件都是用 Go 編寫的。也有一些是用 Java、Python 和 Ruby 編寫的。

Prometheus 的功能、儲存格式和 API 的穩定性如何？

Prometheus GitHub 組織中所有已達到 1.0.0 版本的倉庫都大致遵循 語義化版本規範 。破壞性變更透過主版本號的增加來體現。實驗性元件可能會有例外，這些在公告中都會有明確的標記。

即使是尚未達到 1.0.0 版本的倉庫，通常也相當穩定。我們的目標是為每個倉庫建立適當的釋出流程，並最終釋出 1.0.0 版本。無論如何，破壞性變更都會在釋出說明中指出（標記為 [CHANGE]），或者針對尚未正式釋出的元件進行明確的溝通。

為什麼你們使用拉取（pull）而不是推送（push）？

透過 HTTP 進行拉取提供了許多優勢：

• 您可以根據需要啟動額外的監控例項，例如在開發變更時在您的筆記型電腦上啟動。
• 您可以更容易、更可靠地判斷目標是否宕機。
• 您可以手動訪問目標，並使用瀏覽器檢查其健康狀態。

總體而言，我們認為拉取比推送略好，但在選擇監控系統時，這不應被視為一個決定性因素。

對於必須推送的情況，我們提供了 Pushgateway。

如何將日誌輸入到 Prometheus 中？

簡短的回答：不要這樣做！請改用像 Grafana Loki  或 OpenSearch  這樣的系統。

更詳細的回答：Prometheus 是一個收集和處理指標的系統，而不是事件日誌系統。Grafana 部落格文章 Logs and Metrics and Graphs, Oh My!  提供了有關日誌和指標之間差異的更多細節。

如果您想從應用程式日誌中提取 Prometheus 指標，Grafana Loki 正是為此而設計的。請參閱 Loki 的 指標查詢  文件。

誰編寫了 Prometheus？

Prometheus 最初是由 Matt T. Proud  和 Julius Volz  私下發起的。其早期的大部分開發工作由 SoundCloud  贊助。

它現在由眾多 公司  和 個人 共同維護和擴充套件。

Prometheus 是在什麼許可證下發布的？

Prometheus 是在 Apache 2.0  許可證下發布的。

Prometheus 的複數形式是什麼？

經過 深入研究 ，確定 “Prometheus” 的正確複數形式是 “Prometheis”。

如果您記不住，可以使用 “Prometheus 例項” 作為替代方案。

我可以重新載入 Prometheus 的配置嗎？

可以，向 Prometheus 程序傳送 SIGHUP 訊號，或向 /-/reload 端點發送 HTTP POST 請求，都將重新載入並應用配置檔案。各個元件會嘗試優雅地處理失敗的變更。

我可以傳送告警嗎？

可以，透過 Alertmanager 。

我們支援透過 電子郵件、各種原生整合，以及 任何人都可以新增整合的 Webhook 系統 傳送告警。

我可以建立儀表盤嗎？

可以，我們推薦在生產環境中使用 Grafana。此外，還有 控制檯模板。

我可以更改時區嗎？為什麼一切都是 UTC 時間？

為了避免任何形式的時區混亂，特別是涉及到所謂的夏令時，我們決定在 Prometheus 的所有元件中，內部一律使用 Unix 時間，顯示一律使用 UTC。未來可以在 UI 中引入精心設計的時區選擇功能。歡迎貢獻程式碼。關於此項工作的進展情況，請參見 issue #500 。

程式碼插樁

哪些語言擁有插樁庫？

有許多客戶端庫可用於對您的服務進行插樁以收集 Prometheus 指標。詳情請參閱 客戶端庫 文件。

如果您有興趣為新語言貢獻客戶端庫，請參閱 資料暴露格式。

我可以監控機器嗎？

可以，Node Exporter  在 Linux 和其他 Unix 系統上暴露了大量的機器級指標，例如 CPU 使用率、記憶體、磁碟利用率、檔案系統飽滿度和網路頻寬。

我可以監控網路裝置嗎？

可以，SNMP Exporter  允許監控支援 SNMP 的裝置。對於工業網路，還有一個 Modbus exporter 。

我可以監控批處理任務嗎？

可以，使用 Pushgateway。另請參閱監控批處理任務的 最佳實踐。

Prometheus 開箱即用可以監控哪些應用程式？

請參閱 Exporter 和整合列表。

我可以透過 JMX 監控 JVM 應用程式嗎？

可以，對於無法直接使用 Java 客戶端進行插樁的應用程式，您可以單獨使用 JMX Exporter ，或者將其作為 Java Agent 使用。

程式碼插樁對效能有什麼影響？

不同客戶端庫和語言的效能可能會有所不同。對於 Java，基準測試  表明，使用 Java 客戶端增加計數器（Counter）/儀表（Gauge）將耗時 12-17 納秒，具體取決於競爭情況。除了對延遲要求極高的程式碼之外，這對於其他所有程式碼都是微不足道的。

實現

為什麼所有樣本值都是 64 位浮點數？

為了簡化設計，我們僅限使用 64 位浮點數。IEEE 754 雙精度二進位制浮點格式  支援最高 2⁵³ 的整數精度。只有當您需要高於 2⁵³ 但低於 2⁶³ 的整數精度時，支援原生 64 位整數才會有所幫助。原則上，可以實現對不同樣本值型別（包括支援超過 64 位的某種大整數）的支援，但這目前不是優先事項。一個計數器即使每秒遞增 100 萬次，也只有在 285 年後才會遇到精度問題。