與其他方案的比較
Prometheus 對比 Graphite
範圍
Graphite 專注於作為一個帶查詢語言和圖表功能的被動時間序列資料庫。任何其他問題都由外部元件解決。
Prometheus 是一個完整的監控和趨勢系統，包含基於時間序列資料的內建且主動的抓取、儲存、查詢、圖表製作和告警功能。它瞭解世界“應該”是什麼樣子的（應該存在哪些端點、什麼樣的時間序列模式意味著故障等），並主動嘗試尋找故障。
資料模型
與 Prometheus 類似，Graphite 儲存命名時間序列的數值樣本。然而，Prometheus 的元資料模型更豐富：Graphite 的指標名稱由點分隔的元件組成，其中隱式編碼了維度，而 Prometheus 則將維度顯式編碼為附加到指標名稱上的鍵值對（稱為標籤）。這允許透過查詢語言輕鬆地按這些標籤進行過濾、分組和匹配。
此外，尤其是當 Graphite 與 StatsD 結合使用時，通常只儲存所有被監控例項的聚合資料，而不是將例項保留為一個維度，從而無法深入檢視單個出現問題的例項。
例如，將向 API 伺服器傳送的響應程式碼為 500、方法為 POST 且請求 /tracks 端點的 HTTP 請求數儲存在 Graphite/StatsD 中通常會被編碼成這樣：
stats.api-server.tracks.post.500 -> 93
而在 Prometheus 中，相同的資料可以編碼成這樣（假設有三個 api-server 例項）：
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample1>"} -> 34
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample2>"} -> 28
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample3>"} -> 31
儲存
Graphite 以 Whisper 格式將時間序列資料儲存在本地磁碟上，這是一種期待樣本定期到達的 RRD（輪循資料庫）風格的資料庫。每個時間序列都儲存在一個單獨的檔案中，新樣本在一定時間後會覆蓋舊樣本。
Prometheus 也為每個時間序列建立一個本地檔案，但允許在抓取或規則評估發生時以任意間隔儲存樣本。由於新樣本只是簡單地追加，因此舊資料可以保留任意長的時間。Prometheus 對於許多生命週期短暫、頻繁變化的時間序列集也能很好地工作。
總結
除了更易於執行和整合到您的環境中之外，Prometheus 還提供了更豐富的資料模型和查詢語言。如果您需要一個能夠長期儲存歷史資料的叢集解決方案，Graphite 可能是更好的選擇。
Prometheus 對比 InfluxDB
InfluxDB 是一個開源的時間序列資料庫，並提供用於橫向擴充套件和叢集的商業方案。InfluxDB 專案在 Prometheus 開始開發近一年後才釋出，因此我們當時無法將其作為替代方案進行考慮。儘管如此，Prometheus 和 InfluxDB 之間仍存在顯著差異，兩者的定位也針對稍微不同的使用場景。
範圍
為了公平起見，我們還必須將 Kapacitor 與 InfluxDB 結合起來考慮，因為它們組合起來解決的問題空間與 Prometheus 和 Alertmanager 相同。
對於 InfluxDB 本身，適用於 Graphite 的相同範圍差異在此處也同樣適用。此外，InfluxDB 提供了連續查詢（continuous queries），這等同於 Prometheus 的記錄規則。
Kapacitor 的範圍是 Prometheus 記錄規則、告警規則以及 Alertmanager 的通知功能的結合。Prometheus 為圖表製作和告警提供了更強大的查詢語言 。此外，Prometheus Alertmanager 還提供了分組、去重和靜默功能。
資料模型 / 儲存
與 Prometheus 類似，InfluxDB 的資料模型也使用鍵值對作為標籤，並在 InfluxDB 中稱為 tag。此外，InfluxDB 還有第二級標籤，稱為 field，其用途更受限制。InfluxDB 支援高達納秒級解析度的時間戳，以及 float64、int64、bool 和 string 資料型別。相比製造，Prometheus 支援 float64 資料型別、對字串的有限支援，以及毫秒級解析度的時間戳。
InfluxDB 在儲存上使用了日誌結構合併樹（LSM Tree）的變體並帶有預寫日誌（WAL） ，且按時間進行分片。與 Prometheus 的每個時間序列一個僅追加檔案的方案相比，這種方式更適合事件日誌記錄（event logging）。
《Logs and Metrics and Graphs, Oh My!》 描述了事件日誌記錄與指標記錄之間的區別。
架構
Prometheus 伺服器彼此獨立執行，並且其核心功能（抓取、規則處理和告警）僅依賴其本地儲存。開源版本的 InfluxDB 也與之類似。
商業版的 InfluxDB 在設計上是一個分散式儲存叢集，儲存和查詢由多個節點同時處理。
這意味著商業版的 InfluxDB 將更容易水平擴充套件，但也意味著您從一開始就必須管理分散式儲存系統的複雜性。Prometheus 執行起來會更簡單，但在某些時候，您需要顯式地根據可擴充套件性邊界（如產品、服務、資料中心或類似維度）對伺服器進行分片。獨立的伺服器（可以並行冗餘執行）也可能為您提供更好的可靠性和故障隔離。
Kapacitor 的開源版本沒有為規則、告警或通知提供內建的分散式/冗餘選項。開源版本的 Kapacitor 可以透過使用者手動分片來進行擴充套件，類似於 Prometheus 本身。Influx 提供了 Enterprise Kapacitor ，支援高可用/冗餘的告警系統。
相比之下，Prometheus 和 Alertmanager 透過執行 Prometheus 的冗餘副本並使用 Alertmanager 的高可用 模式，提供了一個完全開源的冗餘選擇。
總結
這兩個系統之間有許多相似之處。兩者都擁有標籤（在 InfluxDB 中稱為 tag）以高效地支援多維指標。兩者基本上使用相同的資料壓縮演算法。兩者都有廣泛的整合，包括相互整合。兩者都提供了允許您進一步擴充套件的鉤子，例如在統計工具中分析資料或執行自動化操作。
InfluxDB 更勝一籌的地方
- 如果您正在進行事件日誌記錄。
- 商業版本為 InfluxDB 提供了叢集功能，這也更適合長期資料儲存。
- 副本之間的資料最終一致性檢視。
Prometheus 更勝一籌的地方
- 如果您主要在進行指標監控。
- 更強大的查詢語言、告警和通知功能。
- 為圖表製作和告警提供更高的可用性和線上時間。
InfluxDB 由一家商業公司維護，遵循“開源核心（open-core）”模式，提供閉源叢集、託管和支援等高階功能。Prometheus 是一個完全開源且獨立的自主專案，由多家公司和個人共同維護，其中一些公司也提供商業服務和支援。
Prometheus 對比 OpenTSDB
OpenTSDB 是一個基於 Hadoop 和 HBase 的分散式時間序列資料庫。
範圍
在此處，適用於 Graphite 的相同範圍差異同樣適用。
資料模型
OpenTSDB 的資料模型與 Prometheus 幾乎相同：時間序列透過一組任意的鍵值對進行標識（OpenTSDB 的 tag 就是 Prometheus 的 label）。一個指標的所有資料都儲存在一起 ，這限制了指標的基數。不過也存在一些微小的差異：Prometheus 允許在標籤值中使用任意字元，而 OpenTSDB 的限制更多。此外，OpenTSDB 缺乏完整的查詢語言，僅允許透過其 API 進行簡單的聚合和數學運算。
儲存
OpenTSDB 的儲存實現基於 Hadoop 和 HBase 。這意味著水平擴充套件 OpenTSDB 很簡單，但您從一開始就必須接受執行 Hadoop/HBase 叢集的整體複雜性。
Prometheus 起步執行會更簡單，但在超出單節點容量後，將需要顯式分片。
總結
Prometheus 提供了豐富得多的查詢語言，能夠處理更高基數的指標，並構成完整監控系統的一部分。如果您已經運行了 Hadoop，並且相比這些優勢，您更看重長期儲存，那麼 OpenTSDB 是一個不錯的選擇。
Prometheus 對比 Nagios
Nagios 是一款監控系統，其前身是 20 世紀 90 年代的 NetSaint。
範圍
Nagios 主要基於指令碼的退出程式碼（稱為“檢查（checks）”）進行告警。它支援對單個告警進行靜默，但沒有分組、路由或去重功能。
它擁有各種各樣的外掛。例如，將允許外掛返回的幾 KB perfData 管道傳輸到諸如 Graphite 的時間序列資料庫 ，或者使用 NRPE 在遠端機器上執行檢查 。
資料模型
Nagios 是基於主機的。每個主機可以有一個或多個服務，每個服務可以執行一項檢查。
它沒有標籤或查詢語言的概念。
儲存
除了當前的檢查狀態之外，Nagios 本身沒有儲存。有一些外掛可以儲存資料，例如用於視覺化 。
架構
Nagios 伺服器是單機的。所有檢查的配置均透過檔案進行。
總結
Nagios 適用於對小型和/或靜態系統進行基本監控，在這種場景下黑盒探測就足夠了。
如果您想進行白盒監控，或者擁有動態或基於雲的環境，那麼 Prometheus 是一個不錯的選擇。
Prometheus 對比 Sensu
Sensu 是一個開源的監控和可觀測性管道，並提供有商業分發版本以支援額外的可擴充套件性功能。它可以重用現有的 Nagios 外掛。
範圍
Sensu 是一個可觀測性管道，專注於將可觀測性資料作為事件（Events） 流進行處理和告警。它為事件過濾 、聚合、轉換 和處理 提供了一個可擴充套件的框架——包括將告警傳送到其他系統以及將事件儲存在第三方系統中。Sensu 的事件處理能力在範圍上與 Prometheus 的告警規則和 Alertmanager 類似。
資料模型
Sensu 事件（Events） 以結構化資料格式表示服務健康狀況和/或指標 ，並透過實體（entity） 名稱（例如伺服器、雲計算例項、容器或服務）、事件名稱以及可選的、稱為“標籤”或“註解”的鍵值元資料 來標識。Sensu 事件的負載可能包含一個或多個指標points，表示為包含 name、tags（鍵/值對）、timestamp 和 value（始終為浮點數）的 JSON 物件。
儲存
Sensu 將當前和最近的事件狀態資訊以及即時資產資料儲存在嵌入式資料庫（etcd）或外部關係型資料庫（PostgreSQL）中。
架構
Sensu 部署的所有元件都可以進行叢集，以實現高可用性並提高事件處理吞吐量。
總結
Sensu 和 Prometheus 有一些共同的功能，但它們採用了非常不同的監控方法。兩者都為動態雲環境和臨時計算平臺提供了可擴充套件的發現機制，儘管底層機制大不相同。兩者都支援透過標籤和註解收集多維指標。兩者都擁有廣泛的整合，且 Sensu 原生支援從所有 Prometheus Exporter 中收集指標。兩者都能夠將可觀測性資料轉發到第三方資料平臺（例如事件儲存或 TSDB）。Sensu 和 Prometheus 區別最大的地方在於它們的使用場景。
Sensu 更勝一籌的地方
- 如果您正在收集和處理混合可觀測性資料（包括指標和/或事件）
- 如果您正在整合多個監控工具，並且需要對指標以及 Nagios 風格的外掛或檢查指令碼的支援
- 更強大的事件處理平臺
Prometheus 更勝一籌的地方
- 如果您主要在收集和評估指標
- 如果您正在監控同質的 Kubernetes 基礎設施（如果您監控的工作負載 100% 都在 K8s 中，Prometheus 提供了更好的 K8s 整合）
- 更強大的查詢語言，以及內建的歷史資料分析支援
Sensu 由一家商業公司維護，遵循“開源核心（open-core）”商業模式，提供閉源事件關聯與聚合、聯邦（federation）和支援等高階功能。Prometheus 是一個完全開源且獨立的自主專案，由多家公司和個人共同維護，其中一些公司也提供商業服務和支援。