## 監控系統產品比較
### 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是一個很好的選擇。