原文地址：https://yq.aliyun.com/articles/692033
目錄
Prometheus 與 Graphite
範圍
Graphite 專注於成爲一個具有查詢語言和繪圖功能的被動時間序列數據庫。任何其他問題都由外部組件處理。
Prometheus 是一個完整的監控和趨勢系統，包括內置和活動的抓取、存儲、查詢、繪圖和基於時間序列數據的報警。它知道監控應該是什麼樣子(監控點應該存在，時間序列模式意味着什麼問題，等等)，並積極地尋找錯誤。
數據模型
Graphite 存儲命名時間序列的數字樣本和 Prometheus 所做的一樣。然而，Prometheus 的元數據模型更豐富。
Graphite metric 名稱由點分隔的編碼組成，這些編碼較爲隱藏。而 Prometheus 將顯式地編碼爲 key-value 對稱爲 label，附加到 metric 名稱上。這允許通過查詢語言對這些 label 進行簡單的篩選、分組和匹配。
此外，特別是當使用 Graphite 與 StatsD 結合使用時，通常只在所有被監視的實例上存儲聚合數據，而不是將實例作爲維度保存，並能夠深入到各個有問題的實例中。
例如，Graphite / StatsD 存儲 api-server 返回值爲 500 的 HTTP 請求的數據會像下面一樣
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 格式存儲在本地磁盤上，Whisper 格式是一種期望樣本定期到達 RRD-style 數據庫。
每個時間序列都存儲在一個單獨的文件中，新的採樣數據會在一段時間後覆蓋舊的採樣數據。
Prometheus 也爲每個時間序列數據創建一個本地文件，允許在發生剪貼或規則評估時以任意間隔存儲數據。
由於新數據只是簡單地追加，舊數據可以任意地保持較長時間。
Prometheus 也適用於許多短暫的、頻繁變化的時間序列。
總結
Prometheus 提供了更豐富的數據模型和查詢語句，並且更易於運行和集成到您的環境中。如果您想要能夠長期保存歷史數據的集羣解決方案，那麼 Graphite 可能是更好的選擇。
Prometheus 與 InfluxDB
InfluxDB 是一個開放源碼的時間序列數據庫，具有可伸縮和集羣的商業選項。
在 Prometheus 開發項目開始將近一年後，InfluxDB 項目發佈了，因此我們當時無法考慮將其作爲替代方案。
儘管如此，Prometheus 和 InfluxDB 之間仍然存在顯著的差異，而且這兩個系統都針對稍微不同的用例。
範圍
爲了進行公平的比較，我們還必須將 Kapacitor 和 InfluxDB 一起考慮，因爲它們結合起來處理與 Prometheus 和 Alertmanager 相同的問題場景。
InfluxDB 提供連續查詢，這相當於 Prometheus 記錄規則。
Kapacitor 的場景是 Prometheus 記錄規則、警報規則和 Alertmanager 通知功能的組合。
Prometheus 提供了一種更強大的查詢語言，用於繪圖和警報。
Prometheus 的 Alertmanager 還提供了分組，去重功能和靜默功能。
數據模型和存儲
與 Prometheus 一樣，InfluxDB 數據模型也有 key-value 作爲 labels ，稱爲 tag。
此外，InfluxDB 還有一個二級 labels 稱爲 field ，在使用上更加有限。
InfluxDB 支持納秒級的時間戳，以及float64、int64、bool和字符串數據類型。
相比之下，Prometheus 支持 float64 數據類型，但對字符串和毫秒級分辨率時間戳的支持有限。
InfluxDB 使用了用於存儲的一個變種 具有寫前日誌的日誌結構合併樹 （Storage Engine），用時間分片。
這比 Prometheus 的 “每個時間序列只添加一個文件” 方法更適合於事件日誌記錄。
Logs and Metrics and Graphs, Oh My! 這篇文章描述了事件日誌記錄和指標記錄之間的差異。
體系結構
Prometheus 的服務器彼此獨立運行，僅依賴本地存儲實現核心功能:抓取、規則處理和警報。開源版本的 InfluxDB 也是類似的。
根據設計，商業的 InfluxDB 產品是一個分佈式存儲集羣，存儲和查詢由多個節點同時處理。
這意味着商業的 InfluxDB 將更容易橫向擴展，但也意味着您必須從一開始就管理分佈式存儲系統的複雜性。
Prometheus 將更易於運行，但在某些時候，您將需要根據可伸縮性邊界(如產品、服務、數據中心或類似方面)顯式地對服務器進行切分。獨立服務器(可以冗餘地並行運行)還可以提供更好的可靠性和故障隔離。
Kapacitor 的開源版本沒有用於規則、警報或通知的內置的分佈式/冗餘選項，。
Kapacitor 的開源版本可以通過用戶手工分片進行擴展，類似於 Prometheus 本身。
Influx 提供企業級的 Kapacitor，支持HA/冗餘警報系統。
相比之下，Prometheus 和 Alertmanager 通過運行 Prometheus 的冗餘副本並使用Alertmanager 的高可用性模式，提供了一個完全開源的冗餘選項。
總結
這兩個系統有許多相似之處。
它們都有 labels (在 InfluxDB 中稱爲 tag)來有效地支持多維 metric 。
兩者使用的數據壓縮算法基本相同。
兩者都有廣泛的集成，包括彼此之間的集成。
它們都有鉤子，允許您進一步擴展它們，例如在統計工具中分析數據或執行自動化操作。
InfluxDB 的優點
- 存儲事件日誌
- 商業版本提供集羣功能，對於存儲長期數據是有幫助的。
- 數據副本之間的視圖是一致的
Prometheus 的優點
- 存儲指標數據。
- 更強大的查詢語言、警報和通知功能。
- 高可用、很好的繪圖功能、警報功能。
InfluxDB 由一個單一的商業公司遵循開放核心模型，提供高級功能，如閉源集羣、託管和支持。
普羅米修斯是一個完全開源和獨立的項目，由許多公司和個人維護，其中一些還提供商業服務和支持。
Prometheus 與 OpenTSDB
OpenTSDB 是基於 Hadoop 和 HBase 的分佈式時間序列數據庫。
範圍
這裏適用的一般範圍差異與 Graphite 的情況相同。
數據模型
OpenTSDB 的數據模型幾乎與 Prometheus 的數據模型相同:時間序列由一組任意的 key-value 對(OpenTSDB 是 tag 而 Prometheus 是 label )。
所有 metric 數據存儲在一起，限制了 metric 的基數。但是有一些細微的區別: Prometheus 允許在label 值中使用任意字符，而 OpenTSDB 的限制更嚴格。
OpenTSDB 也缺乏完整的查詢語言，只允許通過其 API 進行簡單的聚合和數學運算。
數據存儲
OpenTSDB 的存儲是在 Hadoop 和 HBase 上實現的。這意味着很容易橫向擴展 OpenTSDB，但是您必須從一開始就接受運行 Hadoop/HBase 集羣的總體複雜性。
Prometheus 最初運行起來會更簡單，但一旦超過單個節點的容量，就需要手動的分開。
總結
Prometheus 提供了更豐富的查詢語言，可以處理更高的基數指標，並構成一個完整監控系統的一部分。
如果您已經在運行 Hadoop，並且看重長期存儲而不是這些好處，那麼 OpenTSDB 是一個不錯的選擇。
Prometheus 與 Nagios
Nagios 是一種起源於20世紀90年代的監視系統，名爲 NetSaint。
範圍
Nagios 主要是基於腳本的退出代碼發出警報。這些被稱爲“check”。有個別報警會靜默，但沒有分組，路由或重複數據刪除。
Nagios 有各種各樣的插件。例如，允許通過管道將幾千字節的插件數據返回到時間序列數據庫，如 Graphite ，或者使用 NRPE 在遠程機器上運行檢查。
數據模型
Nagios是基於主機的。每個主機可以有一個或多個服務，每個服務可以執行一個檢查。
沒有標籤或查詢語言的概念
數據存儲
除了當前的檢查狀態外，Nagios本身沒有存儲。有一些插件可以存儲數據，比如 visualisation。
結構體系
Nagios服務器是獨立的。所有檢查的配置都是通過文件進行的。
總結
Nagios適用於基本監視小型系統或者靜態系統，在這些系統中，黑盒探測就足夠了。
如果您想進行白盒監控，或者擁有一個動態或基於雲的環境，那麼 Prometheus 是一個不錯的選擇。
Prometheus 與 Sensu
Sensu 是一個可組合的監視工作流，可以複用現有的 Nagios 檢查。
範圍
這裏適用的一般範圍差異與 Nagios 的情況相同。
還有一個客戶端套接字允許將特別的檢查結果推送到Sensu中。
數據模型
Sensu 擁有與 Nagios 相同的粗略數據模型。
數據存儲
Sensu使用Redis持久化監控數據，包括Sensu客戶端註冊表、檢查結果、檢查執行歷史和當前事件數據。
體系結構
Sensu有許多組件。它使用RabbitMQ作爲傳輸，使用Redis表示當前狀態，使用單獨的服務器進行處理和API訪問。
可以對Sensu部署的所有組件(RabbitMQ、Redis和Sensu服務器/API)進行集羣，以實現高可用性和冗餘配置。
總結
如果您希望按原樣擴展現有 Nagios 設置，或者希望利用 Sensu 的自動註冊特性，那麼 Sensu 是一個不錯的選擇。
如果您想進行白盒監控，或者擁有一個非常動態的或基於雲的環境，那麼 Prometheus 是一個不錯的選擇。
原文鏈接
- https://prometheus.io/docs/introduction/comparison/ ， by Prometheus
其他閱讀：
Grafana + Prometheus 監控PostgreSQL