這款監控系統有點牛逼

語言: CN / TW / HK

新公司要上監控,面試提到了 Prometheus 是公司需要的監控解決方案,作為喜新厭舊的程式設計師,我當然是選擇跟風了。

之前主要做的是 Zabbix,既然公司需要 Prometheus,那沒辦法,只能好好對比一番,瞭解下,畢竟技多不壓身。

但稍稍深入一點,我就體會到了 Prometheus 的優點,總結一下這兩種監控方式。

兩種監控工具的歷史簡介

①Prometheus

Kubernetes 自從 2012 年開源以來便以不可阻擋之勢成為容器領域排程和編排的領頭羊。

Kubernetes 是 Google Borg 系統的開源實現,於此對應 Prometheus 則是 Google BorgMon 的開源實現。

Prometheus 是由 SoundCloud 開發的開源監控報警系統和時序列資料庫。

從字面上理解, Prometheus 由兩個部分組成,一個是監控報警系統,另一個是自帶的時序資料庫(TSDB)

2016 年,由 Google 發起的 Linux 基金會旗下的原生雲基金會(Cloud Native Computing Foundation)將 Prometheus 納入其第二大開源專案。

Prometheus 在開源社群也十分活躍,在 GitHub 上擁有兩萬多 Star,並且系統每隔一兩週就會有一個小版本的更新,而 Prometheus 與它的“師兄”Kubernetes 都自帶雲原生的光環,天然能夠友好協作。

②Zabbix

Zabbix 官方的發行版本時間可以追朔到 2012 年,時間上比 Prometheus 早了四年。

Zabbix 是由 Alexei Vladishev 開源的分散式監控系統,是一個企業級的分散式開源監控方案。能夠監控各種網路引數以及伺服器健康性和完整性的軟體。使用靈活的通知機制,允許使用者為幾乎任何事件配置基於郵件的告警。

這樣可以快速反饋伺服器的問題。基於已儲存的資料,提供了出色的報告和資料視覺化功能。

架構對比

①Prometheus

Prometheus 的基本原理是通過 HTTP 週期性抓取被監控元件的狀態,任意元件只要提供對應的 HTTP 介面並且符合 Prometheus 定義的資料格式,就可以接入 Prometheus 監控。

Prometheus Server 負責定時在目標上抓取 Metrics(指標)資料並儲存到本地儲存裡面。

Prometheus 採用了一種 Pull(拉)的方式獲取資料,不僅降低客戶端的複雜度,客戶端只需要採集資料,無需瞭解服務端情況,而且服務端可以更加方便的水平擴充套件。

如果監控資料達到告警閾值 Prometheus Server 會通過 HTTP 將告警傳送到告警模組 alertmanger,通過告警的抑制後觸發郵件或者 webhook。

Prometheus 支援 PromQL 提供多維度資料模型和靈活的查詢,通過監控指標關聯多個 tag 的方式,將監控資料進行任意維度的組合以及聚合。

②Zabbix

Zabbix 由 2 部分構成,Zabbix Server 與可選元件 Zabbix Agent。Zabbix Server 可以通過 SNMP,Zabbix Agent,ping,埠監視等方法提供對遠端伺服器/網路狀態的監視,資料收集等功能。

它可以執行在 Linux,Solaris,HP-UX,AIX,Free BSD,Open BSD,OS X 等平臺上。

核心元件主要是 Agent 和 Server,其中 Agent 主要負責採集資料並通過主動或者被動的方式採集資料傳送到 Server/Proxy,除此之外,為了擴充套件監控項,Agent 還支援執行自定義指令碼。

Server 主要負責接收 Agent 傳送的監控資訊,並進行彙總儲存,觸發告警等。

Zabbix Server 將收集的監控資料儲存到 Zabbix Database 中。Zabbix Database 支援常用的關係型資料庫,如果 MySQL、PostgreSQL、Oracle 等,預設是 MySQL,並提供 Zabbix Web 頁面(PHP 編寫)資料查詢。

Zabbix 由於使用了關係型資料儲存時序資料,所以在監控大規模叢集時常常在資料儲存方面捉襟見肘。

所以從 Zabbix 4.2 版本後開始支援 TimescaleDB 時序資料庫,不過目前成熟度還不高。

綜合對比

如上面的表格,從開發語言上看,為了應對高併發和快速迭代的需求,監控系統的開發語言已經慢慢從 C 語言轉移到 Go。

不得不說,Go 憑藉簡潔的語法和優雅的併發,在 Java 佔據業務開發,C 佔領底層開發的情況下,準確定位中介軟體開發需求,在當前開源中介軟體產品中被廣泛應用。

從系統成熟度上看, Zabbix 是老牌的監控系統 :Zabbix 是在 1998 年就出現的,系統功能比較穩定,成熟度較高。

Prometheus 是最近幾年才誕生的 ,雖然功能還在不斷迭代更新,但站在巨人的肩膀之上,在架構設計上借鑑了很多老牌監控系統的經驗。

從資料儲存方面來看,Zabbix 採用關係資料庫儲存,這極大限制了 Zabbix 採集的效能,而 Prometheus 自研一套高效能的時序資料庫,在 V3 版本可以達到每秒千萬級別的資料儲存,通過對接第三方時序資料庫擴充套件歷史資料的儲存。

從配置複雜度上看,Prometheus 只有一個核心 server 元件,一條命令便可以啟動,相比而言,其他系統配置相對麻煩。

從社群活躍度上看,目前 Zabbix 比較活躍,但基本都是國內的公司參與,Prometheus 在這方面佔據絕對優勢,社群活躍度雖然不如,但是受到 CNCF 的支援,後期的發展值得期待。

從容器支援角度看,由於 Zabbix 出現得比較早,當時容器還沒有誕生,自然對容器的支援也比較差。

而 Prometheus 的動態發現機制,不僅可以支援 Swarm 原生叢集,還支援 Kubernetes 容器叢集的監控,是目前容器監控最好解決方案。

總結

綜合來看,Zabbix 的成熟度更高,上手更快,但更好的整合導致靈活性較差,問題更大是,監控資料的複雜度增加後,Zabbix 做進一步定製難度很高,即使做好了定製,也沒法利用之前收集到的資料了(關係型資料庫造成的問題)。

Prometheus 基本上是正相反,上手難度大一些,但由於定製靈活度高,資料也有更多的聚合可能,起步後的使用難度遠小於 Zabbix。

但如果已經對傳統監控系統有技術積累的話,還是要謹慎考慮更換監控。

如果監控的是物理機,用 Zabbix 沒毛病,Zabbix 在傳統監控系統中,尤其是在伺服器相關監控方面,佔據絕對優勢。

甚至環境變動不會很頻繁的情況下,Zabbix 也會比 Prometheus 好使;但如果是雲環境的話,除非是 Zabbix 玩的非常溜,可以做各種定製,否則還是 Prometheus 吧,畢竟人家就是幹這個的。

Prometheus 開始成為主導及容器監控方面的標配,並且在未來可見的時間內被廣泛應用。

如果是剛剛要上監控系統的話,不用猶豫了,Prometheus 準沒錯。

作者:小雨淅淅o0 

出處:cnblogs.com/xiaoyuxixi/p/12235979.html

推薦閱讀 點選標題可跳轉

《Docker是什麼?》

《Kubernetes是什麼?》

《Kubernetes和Docker到底有啥關係?》

《教你如何快捷的查詢選擇網路倉庫映象tag》

《Docker映象進階:瞭解其背後的技術原理》

《教你如何修改執行中的容器埠對映》

《k8s學習筆記:介紹&上手》

《k8s學習筆記:縮擴容&更新》

《Docker 基礎用法和命令幫助》

《在K8S上搭建Redis叢集》

《灰度部署、滾動部署、藍綠部署》

《PM2實踐指南》

《Docker垃圾清理》

《Kubernetes(k8s)底層網路原理刨析》

《容器環境下Node.js的記憶體管理》

《MySQL 快速建立千萬級測試資料》

《Linux 與 Unix 到底有什麼不同?》

《淺談幾種常見 RAID 的異同》

《Git 筆記-程式設計師都要掌握的 Git》

《老司機必須懂的MySQL規範》

《Docker中Image、Container與Volume的遷移》

《漫畫|如何用Kubernetes搞定CICD》

《寫給前端的Docker實戰教程》

《Linux 作業系統知識地圖2.0,我看行》

《16個概念帶你入門 Kubernetes》

《程式設計師因接外包坐牢456天,長文敘述心酸真實經歷》

《IT 行業老鳥,有話對你說》

《HTTPS 為什麼是安全的? 說一下他的底層實現原理?

免責宣告:本文內容來源於網路,所載內容僅供參考。轉載僅為學習和交流之目的,如無意中侵犯您的合法權益,請及時聯絡Docker中文社群!