# **方案比較（Comparison to alternatives）** <br /> ## **Prometheus vs. Graphite** ### 領域范圍（Scope） Graphite 專注于成為具有查詢語言（Query language）和圖形功能的被動時間序列數據庫。 其他任何問題都采取通過外部組件解決。 Prometheus 是一個完整的監控和趨勢分析系統，其中包括內置的基于時間序列數據的主動抓取，存儲，查詢，制圖和報警。 它知道世界應該是什么樣（應該存在哪些 endpoint，什么時間序列模式有問題等），并且能積極嘗試查找錯誤。 ### 數據模型（Data model） Graphite 為已命名的時間序列存儲數值樣本，就像 Prometheus 一樣。但是，Prometheus 的元數據模型更加豐富：雖然 Graphite metric 名稱由點分割的組件（dot-separated components）組成，這些組件隱含地編碼構建了維度（encode dimensions），但是 Prometheus 顯式地將維度通過 K-V pair（稱為標簽 labels）進行編碼，其將標簽附加到一個 metric 上。這使得通過查詢這些標簽來過濾、聚合/分組、匹配更加的簡單。 此外，尤其是當將 Graphite 與 StatsD 結合使用時，通常只在所有受監控的實例上存儲聚合的數據，而不是將實例（instance）保留為一個維度，并能夠深入分析單個有問題的實例。 例如，通常在 Graphite / StatsD 中，存儲`通過 POST 請求 /tracks 且 response code 是 500 的 HTTP 請求數`的編碼如下： ~~~ stats.api-server.tracks.post.500 -> 93 ~~~ 在 Prometheus 中，可以像這樣編碼相同的數據（假設三個api服務器實例）： ~~~ 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 ~~~ ### 存儲（Storage） Graphite 以 Whisper 格式將時間序列數據存儲在本地磁盤上，這是一種 RRD 樣式的數據庫，它希望樣本以固定的時間間隔到達。 每個時間序列都存儲在一個單獨的文件中，新樣本在一定時間后會覆蓋舊樣本。 Prometheus 也對每個時間序列創建一個本地文件，但任意時間間隔抓取（arbitrary intervals as scrapes）和規則評估（rule evaluations）發生時，都允許存儲樣本。 由于新的樣本是簡單的追加到文件中，因此舊數據可以保留任意久。Prometheus 也適用于許多短生命周期的，經常變化的時間序列。 ### 總結（Summary） Prometheus 除了更易于運行和集成到您的環境之外，還提供了更豐富的數據模型和查詢語言。 如果您想要一個可以長期保存歷史數據的集群解決方案，那么Graphite 可能是一個更好的選擇。 ## **Prometheus vs. InfluxDB** ## **Prometheus vs. OpenTSDB** ## **Prometheus vs. Nagios** ## **Prometheus vs. Sensu**