當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

新公司要上监控，我决定用Prometheus

發布時間：2025/3/16 编程问答 20 豆豆

生活随笔收集整理的這篇文章主要介紹了新公司要上监控，我决定用Prometheus 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

“

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

圖片來源：Pexels.com

之前主要做的是 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 準沒錯。

??· END ·

微信淘寶等平臺要互通！？騰訊阿里字節回應

2021-09-14

一文詳解 API 設計最佳實踐

2021-09-12

12 種經典億級流量架構之資源隔離思想與方法論

2021-09-09

拼夕夕訂單超時未支付自動關閉實現方案！

2021-09-08

在騰訊，我們如何做 Code Review

2021-09-24

紫色飛豬：基于K8s的集群穩定架構

2021-09-23

2W 字詳解設計模式！

2021-09-22

巨人大哥聊聊電商微服務體系中分層設計和領域的劃分

2021-09-20

億級流量架構怎么做資源隔離？口琴這篇寫得太好了！

2021-09-17

螞蟻集團于雨：萬級規模 K8S 集群 Etcd 高可用建設之路

2021-09-16

干貨丨千萬流量大型分布式系統架構設計實戰

2021-09-15

京東面試官：你是怎么理解 MySQL 的優化原理的？

2021-09-26