首先要先說明, Prometheus 提供的是一整套監控系統, 包括資料的收集、資料儲存、報警, 甚至是繪圖(只不過很陽春,官方推薦使用 grafana) 。而 InfluxDB 只是一個時序資料庫, 使用它做監控系統的話, 還需要物色資料獲取器,如 telegraf, collectd 等. 甚至連報警模組, 也需要使用同為 Influxdata 公司出的 Kapacitor。從這個角度來說, Prometheus 會有運維上的優勢, 因為它用起來確實很省事(但其實 Prometheus 也需要 Node_exporter 或是wmi_exporter來擷取資料)。
資料的採集
Prometheus 和 InfluxDB 在資料的採集上兩者就選擇了不同的極端, 前者只能 pull, 後者只能 push, 關於 pull 和 push 的對比,這裡暫不多述。(Prometheus 也可以經由 PushGateway 來採集Push mode 的資料)。
Prometheus 把資料的採集器叫做 exporter, xxx-exporter 運行之後會在機器上佔用一個埠, 等待 Prometheus server 來拉取資料。
InfluxDB 的資料獲取器我們使用了 telegraf, 官方宣傳外掛程式化驅動, 其實也就那麼回事, 編譯的時候把很多東西的採集功能包進去壓在一個二進位裡面, 再用設定檔控制外掛程式是否開啟. 功能其實是蠻強大了. 也是 Go 編寫, 部署算不上困難, 但用起來總會覺得多了一點什麼東西 – “存在感 “ 。沒錯, 多了一種存在感, 對於資料獲取 agent 這種東西, 存在感越低越好。
Telegraf 的預設設定檔就多達2000多行, 裡面包括 push 的目的地址, 各種外掛程式的控制目等等.相比之下, Prometheus 的 exporter 不需要任何設定檔, 不需要任何依賴, 真正的開箱即用。但 Telgraf 有一個很吸引人的功能, 就是它能夠作為一個轉發代理接受來自不同程式的消息。比如可以運行一段腳本, 將結果按照一定的格式輸出給 telegraf 默認的8186埠, telegraf 再寫進 InfluxDB, 這樣就把一個特殊的協力廠商業務的資料獲取起來了, 不需要重啟 Telegraf, 也不需要重啟 InfluxDB.
如果換用 Prometheus 要怎麼做呢? 我們需要引入 prometheus 的 SDK 自己編寫 exporter, 而且 prometheus 會有四種指標類型,編寫完之後需要去 Prometheus server 重新配置要抓取的目標, 整個下來是比 Telegraf 那一套要麻煩的.
如果你的需求很特殊, 要監控的很多協力廠商特殊的指標, 而對於常見的資源如硬體,資料庫等監控需求不大, 那麼 Telegraf + InfluxDB 會是一個不錯的組合.
資料的存儲
單單比較資料存儲的那一部分, 它們兩者之間也有很多不同。InfluxDB 的存儲引擎是基於一種叫做TSM的引擎, Prometheus 則是揉和了 leveldb 與自行研發的存儲引擎.
不過趨勢都是基於時序資料進行調製優化, 不僅要考慮讀寫性能, 還要照顧刪除性能與穩定性。不管怎樣,性能與資料的壓縮對於使用者來說都不是第一要考慮的因素。 對於一個監控系統來說，他們兩者都做得很棒。
在使用的靈活性方面, InfluxDB 是優於 Prometheus 的,這是由於他們的產品定位決定的: InfluxDB 是一個時序資料庫, Prometheus 是一個附帶資料庫的監控系統.舉個例子, InfluxDB 有類似 Mysql 中資料庫, 表的概念, 而且可以針對每個資料庫設置不同的存儲策略, 不得不說這些功能對於一個專門存放資料的軟體系統來說還是很有吸引力的.
資料的查詢
在資料查詢上面, InfluxDB 的查詢語言 InfluxQL 與 SQL 類似, 但是不能像 SQL 那樣做強大的表與表之間的操作。
Prometheus 的查詢語言也很有特點, 看起來會像 JSON , 但是通過它也可以實現各種強大的查詢操作。如果硬要在查詢語言上分個高低的話,我會選擇 Prometheus, 原因很簡單, 我覺得它更有友好與簡單。
高可用與集群Cluster功能
最後還要說一下集群和高可用性這塊.很遺憾他們兩個現在都做得不是很好,至少從免費的角度來說:)InfluxDB 的集群功能是商業功能, 但是有一個高可用的套件叫做 Influxdb-relay, 這個一個跑在 InfluxDB 實例前面的一個轉發代理, 資料經過它的時候會被分發到各個資料庫實例上. 還湊合著能用吧,不過不支援 query 操作, 如果有需要的話可以參考這個fork https://github.com/shanexu/influxdb-relay Prometheus 到目前為止還沒有看到集群功能的消息, 高可用也是僅僅通過部署多個實例來實現, 這個
報警
如果說在前面那兩個方面 InfluxDB 和 Prometheus 還各有特點的話, 就是在報警功能上, Prometheus 比InfouxDB 要好太多了。
InfluxDB 官方出了一個叫做 Kapacitor 的軟體, 官方說可以用它實現報警.其實是拿來對 InfluxDB 做資料處理的, 用在監控系統的報警功能上面真的很差.一方面是因為效率的原因, 它的工作原理是定時得去從 InfluxDB 取資料出來進行運算來檢查是否觸發報警條件, 而且萬一資料庫掛了的話豈不是報警也失效了 ? 一方面是它的 DSL 使用起來體驗真心差, 誰用誰知道 !
總結
- 認為對於監控系統的選擇來說, Prometheus 是不二之選,市場的反應也擺在我們面前了, 這就是趨勢.(機房或主機監控)
- 另外一方面, 如果你的業務不單單是監控系統, 還需要使用到一些時序資料庫的特性用來存儲其他資料, 那麼也別糾結了, InfluxDB就是最適合的.(IoT 儲存、時序/實時聯網資料庫)。