總覽
首先要明白, Prometheus 提供的是一整套監(jiān)控體系, 包括數(shù)據(jù)的采集,數(shù)據(jù)存儲,報(bào)警, 甚至是繪圖(只不過很爛,官方也推薦使用 grafana).
而 InfluxDB 只是一個(gè)時(shí)序數(shù)據(jù)庫, 使用它做監(jiān)控系統(tǒng)的話, 還需要物色數(shù)據(jù)采集器,如 telegraf, collectd 等. 甚至連報(bào)警模塊, 也需要使用同為 Influxdata 公司出的 Kapacitor.從這個(gè)角度來說, Prometheus 會有運(yùn)維上的優(yōu)勢, 因?yàn)樗闷饋泶_實(shí)很省事.
數(shù)據(jù)的采集
Prometheus 和 InfluxDB 在數(shù)據(jù)的采集上兩者就選擇了不同的極端, 前者只能 pull, 后者只能 push, 關(guān)于 pull 和 push 的對比,這里暫不多述.
Prometheus 把 數(shù)據(jù)的采集器叫做 exporter, xxx-exporter 運(yùn)行之后會在機(jī)器上占用一個(gè)端口, 等待 Prometheus server 拉取數(shù)據(jù).
InfluxDB 的數(shù)據(jù)采集器我們使用了 telegraf, 官方宣傳插件化驅(qū)動(dòng), 其實(shí)也就那么回事, 編譯的時(shí)候把很多東西的采集功能包進(jìn)去壓在一個(gè)二進(jìn)制里面, 再用配置文件控制插件是否開啟. 功能其實(shí)是蠻強(qiáng)大了. 也是 Go 編寫, 部署算不上困難, 但用起來總會覺得多了一點(diǎn)什么東西.
存在感.
沒錯(cuò), 多了一種存在感, 對于數(shù)據(jù)采集 agent 這種東西, 存在感越低越好.
Telegraf 的默認(rèn)配置文件就多達(dá)2000多行, 里面包括 push 的目的地址, 各種插件的控制目等等.相比之下, Prometheus 的 exporter 不需要任何配置文件, 不需要任何依賴, 真正的開箱即用.
但 Telgraf 有一個(gè)很吸引人的功能, 就是它能夠作為一個(gè)轉(zhuǎn)發(fā)代理接受來自不同程序的消息
比如可以運(yùn)行一段腳本, 將結(jié)果按照一定的格式輸出給 telegraf 默認(rèn)的8186端口, telegraf 再寫進(jìn) InfluxDB, 這樣就把一個(gè)特殊的第三方業(yè)務(wù)的數(shù)據(jù)采集起來了, 不需要重啟 Telegraf, 也不需要重啟 InfluxDB.
如果換用 Prometheus 要怎么做呢? 我們需要引入 prometheus 的 SDK 自己編寫 exporter, 而且 prometheus 會有四種指標(biāo)類型,編寫完之后需要去 Prometheus server 重新配置要抓取的目標(biāo), 整個(gè)下來是比 Telegraf 那一套要麻煩的.
如果你的需求很特殊, 要監(jiān)控的很多第三方特殊的指標(biāo), 而對于常見的資源如硬件,數(shù)據(jù)庫等監(jiān)控需求不大, 那么 Telegraf + InfluxDB 會是一個(gè)不錯(cuò)的組合.
數(shù)據(jù)的存儲
單單比較數(shù)據(jù)存儲的那一部分, 它們兩者之間也有很多不同.
InfluxDB 的存儲引擎是基于一種叫做TSM的自研引擎, Prometheus 則是柔和了 leveldb 與 自研的存儲引擎.
總的趨勢都是基于時(shí)序數(shù)據(jù)進(jìn)行優(yōu)化, 不僅要照顧讀寫性能, 還要照顧刪除性能與穩(wěn)定性.
不過不管怎樣,性能與數(shù)據(jù)的壓縮對于使用者來說都不是第一要考慮的因素, 不是不重要,而是因?yàn)樗麄儍烧叨甲龅煤馨? 對于一個(gè)監(jiān)控系統(tǒng)來說.
在使用的靈活性方面, InfluxDB 是優(yōu)于 Prometheus 的,這是由于他們的產(chǎn)品定位決定的: InfluxDB 是一個(gè)時(shí)序數(shù)據(jù)庫, Prometheus 是一個(gè)附帶數(shù)據(jù)庫的監(jiān)控系統(tǒng).舉個(gè)例子, InfluxDB 有類似 Mysql 中數(shù)據(jù)庫, 表的概念, 而且可以針對每個(gè)數(shù)據(jù)庫設(shè)置不同的存儲策略, 不得不說這些功能對于一個(gè)專門存放數(shù)據(jù)的軟件系統(tǒng)來說還是很有吸引力的.
數(shù)據(jù)的查詢
在數(shù)據(jù)查詢上面, InfluxDB 的查詢語言 InfluxQL 與 SQL 類似, 但是不能像 SQL 那樣做強(qiáng)大的表與表之間的操作.
Prometheus 的查詢語言也很有特點(diǎn), 看起來會像 JSON , 但是通過它也可以實(shí)現(xiàn)各種強(qiáng)大的查詢操作.
下面分別是 InfluxDB 和 Prometheus 查詢1分鐘內(nèi) CPU 使用率的語句
SELECT 100 - usage_idel FROM "autogen"."cpu" WHERE time > now() - 1m and "cpu"='cpu0'
100 - (node_cpu{job="node",mode="idle"}[1m])
如果硬要在查詢語言上分個(gè)高低的話,我會選擇 Prometheus, 原因很簡單, 我覺得它更有友好與簡單
高可用與集群功能
最后還要說一下集群和高可用性這塊.很遺憾他們兩個(gè)現(xiàn)在都做得不是很好,至少從免費(fèi)的角度來說:)
InfluxDB 的集群功能是商業(yè)功能, 但是有一個(gè)高可用的套件叫做 Influxdb-relay, 這個(gè)一個(gè)跑在 InfluxDB 實(shí)例前面的一個(gè)轉(zhuǎn)發(fā)代理, 數(shù)據(jù)經(jīng)過它的時(shí)候會被分發(fā)到各個(gè)數(shù)據(jù)庫實(shí)例上. 還湊合著能用吧,不過不支持 query 操作, 如果有需要的話可以參考這個(gè)fork https://github.com/shanexu/influxdb-relay
Prometheus 到目前為止還沒有看到集群功能的消息, 高可用也是僅僅通過部署多個(gè)實(shí)例來實(shí)現(xiàn), 這個(gè)方案是有局限性的, 就算不考慮資源的占用, 也會讓系統(tǒng)的架構(gòu)變得復(fù)雜.
筆者一直都在等待他們能一個(gè)高可用和集群部署的功能, 尤其是 Prometheus.因?yàn)楫吘箍傆泄拘枰獢?shù)據(jù)有可靠性的保證的, 尤其是面向政企客戶的公司.
有一段時(shí)間筆者學(xué)了 Raft 協(xié)議的后想要自己實(shí)現(xiàn) InfluxDB 的集群功能, 但總是怕自己做不好, 花的時(shí)間打了水漂, 畢竟對于筆者這樣的新手來選擇把精力花在打?qū)嵱?jì)算機(jī)基礎(chǔ)以及擴(kuò)充自己的知識面上面會更有性價(jià)比. 但是如果有哪位讀者也有實(shí)現(xiàn) InfluxDB 集群功能的想法, 請告訴我, 我很愿意一起協(xié)助...
報(bào)警
如果說在前面那兩個(gè)方面 InfluxDB 和 Prometheus 還各有特點(diǎn)的話, 那么在報(bào)警這方面 InfluxDB 簡直就是被 Prometheus 按在地上摩擦.
InfluxDB 官方出了一個(gè)叫做 Kapacitor 的軟件, 官方說可以用它實(shí)現(xiàn)報(bào)警.
但是這貨明明是拿來對 InfluxDB 做數(shù)據(jù)處理的, 用在監(jiān)控系統(tǒng)的報(bào)警功能上面真的很差.
一方面是因?yàn)樾实脑? 它的工作原理是定時(shí)得去從 InfluxDB 取數(shù)據(jù)出來進(jìn)行運(yùn)算來檢查是否觸發(fā)報(bào)警條件, 而且萬一數(shù)據(jù)庫掛了的話豈不是報(bào)警也失效了 ? 一方面是它的 DSL 使用起來體驗(yàn)真心差, 誰用誰知道 !
總結(jié)
幾個(gè)月體驗(yàn)下來, 筆者認(rèn)為對于監(jiān)控系統(tǒng)的選擇來說, Prometheus 是不二之選,市場的反應(yīng)也擺在我們面前了, 這就是趨勢.
另外一方面, 如果你的業(yè)務(wù)不單單是監(jiān)控系統(tǒng), 還需要使用到一些時(shí)序數(shù)據(jù)庫的特性用來存儲其他數(shù)據(jù), 那么也別糾結(jié)了, InfluxDB就是最適合的.
