對比 · Prometheus中文文檔

## 監控系統產品比較 ### Prometheus vs. Graphite #### 范圍 Graphite專注于查詢語言和圖表特征的時間序列數據庫。其他都需要依賴外部組件實現。 Prometheus是一個基于時間序列數據的完整監控系統和趨勢系統，包括內置和主動抓取、存儲、查詢、圖表展示和報警功能。它懂得監控系統和趨勢系統應該是什么樣的（哪些目標機應該存在，哪些時間序列模型存在問題等等），并積極地試著找出故障 #### 數據模型 Graphite和Prometheus一樣，存儲時間序列數值樣本。但是Prometheus的元數據模型更加豐富：Graphite的度量指標名稱是由"."分隔符，隱式地編碼多維度。而Prometheus度量指標是可以自定義名稱的，并以key-value鍵值對的標簽形式，成為度量指標的標簽屬性列表。并在此基礎上，使用Prometheus查詢語言可以輕松地進行過濾，分組和匹配操作。進一步地，當Graphite與StatsD結合使用時，Graphite就只是對一個聚合數據的存儲系統了，而不是把目標實例作為一個維度，并深入分析目標實例出現的各種問題。例如：我們用Graphite/StatsD統計HTTP請求api-server服務的數量，前置條件：返回碼是`500`，請求方法是`POST`，訪問URL為`/tracks` , key如下所示： ``` 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 ``` 由上可以看到，三個api-server各自的度量指標數據，Prometheus把api-server也作為了一個維度，便于分析api-server服務出現的各種問題 #### 存儲 Graphite存儲以[Whisper](http://graphite.readthedocs.org/en/latest/whisper.html)方式把時間序列數據存儲到本地磁盤，這種數據存儲格式是RRD格式數據庫，它期望樣本能夠定期到達。任何時間序列在一個單獨的文件中存儲，一段時間后新采集的樣本會覆蓋老數據 Prometheus也為每一個時間序列創建了一個本地文件，但是它允許時間序列以任意時間到達。新采集的樣本被簡單地追加到文件尾部，老數據可以任意長的時間保留。Prometheus對于短生命周期、且經常變化的時間序列集也可以表現得很好 #### 總結 Prometheus提供了一個豐富的數據模型和查詢語言，而且更加容易地運行和集成到你的環境中。如果你想要一個可以長期保留歷史數據的集群解決方案，Graphite可能是一個更好的選擇。 ### Prometheus vs. InfluxDB InfluxDB是一個開源的時間序列數據庫，它的商業版本具有可擴展和集群化的特性。在Prometheus剛剛開始開發時，InfluxDB項目已經發布了近一年時間。但是這兩款產品還是有很大的不同之處，這兩個系統也有一些略有不同的應用小場景。 #### 范圍公平起見，我們必須把InfluxDB和Kapacitor結合起來，與Prometheus和Prometheus的報警管理工具比較。 Graphite與Prometheus的范圍差異，同樣適用于InfluxDB本身。此外InfluxDB提供了連續查詢，和Prometheus的記錄規則一樣。 Kapacitor的作用范圍相當于，Prometheus的記錄規則、告警規則和警告通知功能的結合。Prometheus提供了一個更加豐富地用于圖表化和警告的查詢語言，Prometheus告警器還提供了分組、重復數據刪除和靜默功能(silencing functionality)。 #### 數據模型/存儲和Prometheus一樣，InfluxDB數據模型采用的標簽也是鍵值對形式，被稱為tags。而且InfluxDB有第二級標簽，被稱為fields，它被更多地限制使用。InfluxDB支持高達納秒級的時間戳，以及float64、int64、bool和string的數據類型。相反地，Prometheus僅僅支持float64的數據類型，strings和毫秒只能小范圍地支持 InfluxDB使用變種的日志結構合并樹結構來存儲預寫日志，并按時間分片。這比Prometheus的文件追加更適合事件記錄 [Logs and Metrics and Graphs, Oh My](https://blog.raintank.io/logs-and-metrics-and-graphs-oh-my)描述了事件日志和度量指標記錄的不同 #### 框架 Prometheus服務獨立運行，沒有集群架構，它僅僅依賴于本地存儲。Prometheus有四個核心的功能：抓取、規則處理和警告。InfluxDB的開源版本也是類似的。 InfluxDB的商業版本具有存儲和查詢的分布式版本, 存儲和查詢由集群中的節點同時處理。這意味著商業版本的InfluxDB更加容易的水平擴展，同時也表示你必須從一開始就要管理分布式存儲系統的復雜性。而Prometheus運行非常簡單，而且在某些時候，你需要在可擴展性邊界（如產品，服務，數據中心或者類似方面）明確分片服務器。單Prometheus服務也可以為您提供更好的可靠性和故障隔離。 Kapacitor對規則、警告和通知當前還沒有內置/冗余選項。相反地，通過運行Prometheus的冗余副本和使用警告管理器的高可用模式提供了冗余選項。Kapacitor通過用戶手動水平切分能夠被縮放，這點類似于Prometheus本身 #### 總結在兩個系統之間有許多相似點。1. 利用標簽（tags/labels）有效地支持多維度量指標。2. 使用相同的壓縮算法。3.都可擴展集成。4.允許使用第三方進行監控系統的擴展，如：統計分析工具、自動化操作 InfluxDB更好之處： - 使用事件日志 - 商業版本提供的集群方案，對于長期的時間序列存儲是非常不錯的 - 復制的數據最終一致性 Prometheus更好之處： - 主要做度量指標監控 - 更強大的查詢語言，警告和通知功能 - 圖表和警告的高可靠性和穩定性 InfluxDB是有一家商業公司按照開放核心模式運營，提供高級功能，如：集群是閉源的，托管和支持。Prometheus是一個完全開放和獨立的項目，有許多公司和個人維護，其中也提供一些商業服務和支持。 ### Prometheus vs. OpenTSDB [OpenTSDB](http://opentsdb.net/)是一個基于hadoop和Hbase的分布式時間序列數據庫 #### 范圍和Graphite vs. Prometheus的范圍一樣 #### 數據模型 OpenTSDB的數據模型幾乎和Prometheus一樣：時間序列由任意的tags鍵值對集合表示。所有的度量指標存放在一起，并限制度量指標的總數量大小。Prometheus和OpenTSDB有一些細微的差別，例如：Prometheus允許任意的標簽字符，而OpenTSDB的tags命名有一定的限制.OpenTSDB缺乏靈活的查詢語言支持，通過它提供的API只能簡單地進行聚合和數學計算 #### 存儲 OpenTSDB的存儲由Hadoop和HBase實現的。這意味著水平擴展OpenTSDB是非常容易的，但是你必須接受集群的總體復雜性 Prometheus初始運行非常簡單，但是一旦超過單個節點的容量，就需要進行水平切分服務操作 #### 總結 Prometheus提供了一個非常靈活且豐富的查詢語言，能夠支持更多的度量指標數量，組成整個監控系統的一部分。如果你對hadoop非常熟悉，并且對時間序列數據有長期的存儲要求，OpenTSDB是一個不錯的選擇 ### Prometheus vs. Nagios [Nagios](https://www.nagios.org/)是一款產生于90s年代的監控系統 #### 范圍 Nagios是基于腳本運行結果的警告系統，又稱"運行結果檢查"。有警告通知，但是沒有分組、路由和重復數據刪除功能。 Nagios有大量的插件。例如：perfData插件抓取數據后寫入到時間序列數據庫（Graphite）或者使用NRPE在遠程計算機上運行檢查 #### 數據模型 Nagios是基于主機的，每一臺主機有一個或者多個服務。其中一個是check運行檢查，但是沒有標簽和查詢語言的概念 Nagios除了檢查腳本運行狀態，沒有任何存儲功能。有第三方插件可以存儲數據，并可視化數據 #### 架構 Nagios是單實例服務，所有的檢查配置項統一由一個文件配置。 #### 總結 Nagios對于小型監控或者黑盒測試時非常有效的。如果你想要做白盒監控，或者動態地，基于云環境的數據監控，Prometheus是一個不錯的選擇 ### Prometheus vs. Sensu 廣義上說，[Sensu](https://sensuapp.org/)是一個更加現代的Nagios。 #### 范圍主要不同點在于Sensu客戶端注冊自己，并確定從本地還是其他地方獲取配置檢查。Senus對perfData的數量沒有限制。還有一個客戶端socket允許把任意檢查結果推送到Senus #### 數據模型和Nagios一樣 #### 存儲 Sensu在Redis中存儲數據，存儲被稱作stashes。主要是靜默存儲，同時它也存儲在Senus上注冊的所有客戶端 #### 架構 Sensu有很多組件。它使用Rabbit消息隊列進行數據傳輸，使用Redis存儲當前狀態，獨立的服務處理數據 RabbitMQ和Redis都可以是集群的，運行多個服務器副本可是實現副本和冗余 #### 總結如果已經有了Nagios服務，你希望擴展它，同時希望使用Senus的注冊特性，那么Senus是一個不錯的選擇如果你想要使用白盒、或者有一個動態的云環境，那么Prometheus是一個很好的選擇。