最近幾年一直在使用監控系統，主要使用Zabbix和Prometheus 兩個監控工具，對于這兩個監控系統有一些使用實踐方面的經驗，通過對比的方式來和大家分享一下，
一、Zabbix 和 Prometheus 的出現和發展
Zabbix 和 Prometheus 都是監控系統中很流行的工具，Zabbix 的出現要更早一些，在 2001 年的時候發布了 0.1，彼時時序資料庫還沒有應用在監控領域，Zabbix 基于當時的環境采用了關系型資料庫來存盤資料，
最早的時序資料庫 RRDTool 出現于 1999 年 7 月 16 日，Influxdb 在 2013 年 10 月 24 日發布了 0.0.1 版本，Prometheus 于 2014 年 3 月 13 日發布了 0.1.0 版本 ，直到 2016 年，時序資料庫徹底火了起來，
現在 Zabbix 按照每 6 個月一個穩定版本，每 2 年一個大版本的節奏在逐步發展，當前是 5.x 版本，6.x 版本也在規劃中了，
Prometheus 按照每 6 周一個小版本的迭代在逐步前進，目前已經在 2.X 時代，最新版本是 2.30.0，
站在當前這個時間節點，Prometheus 即將發布 2.31.0 ，Zabbix 也已經發布了 5.4.0 ，Zabbix 看到了時序資料庫在監控領域的前景，在 5.x 開始支持使用時序資料庫來存盤資料，并且在 4.4 的時候就支持收集 Prometheus 的 資料存盤在自己的關系型資料庫中，Zabbix 站在企業級監控系統的角度，開始支持包含各種監控工具，進一步向一個臃腫的大而全的系統演進，并且開始小范圍的嘗試新的技術，Prometheus 按照自己最初的設計，只做監控，其他部分交給更專業的人來做，基于時序資料庫，基于 Golang，不斷優化，提高性能，目前來看，Prometheus 基本已經是云原生監控系統的事實標準，最佳選擇，Zabbix 扎根企業市場以功能大而全的優點毅力不倒，
二、 Zabbix 和 Prometheus 的優缺點
最近在使用Zabbix 時被同事寫的一個介面呼叫的bug導致Zabbix 的主機資訊、模版資訊、以及他們的關聯關系全丟了，因為配置了自動注冊，在這些資料丟失以后，Zabbix Agent 又把自己注冊了一次，然后通過備份資料恢復的時候這兩部分就發生了沖突，一個表一個表的解決問題，恢復好以后，這個事情又發生了一次，不同的是，第一次恢復緊急恢復花費了一晚上十幾個小時的時間，全部恢復大概花了一周時間，第二次全部恢復花了兩個小時，
另外的一個事情就是Zabbix Server版本升級，由于一些安全原因和實際碰到的 BUG，我們決定對 Zabbix Server 進行版本升級，僅僅是從 4.4.0升級到4.4.10花費了大約一周時間，各種測驗，各種升級回滾解決問題，當然這也和當前的部署結構有關系，結構不合理，負載不均衡等等，
這個月主要就耗費在這里了，
針對 Zabbix 總結一下，有以下的優點：
1、監控模版可以包含多個指標，在不涉及自定義采集腳本等其他方式的情況下，使用SNMP、Zabbix Agent 的情況下可以做到開箱即用；
2、指標和觸發器（Zabbix的告警規則叫觸發器）的關聯互動挺好用；
3、宏和宏變數的使用可以大大的提高告警的便捷性，基本可以做到每個label 不同的閾值；
4、Zabbix 的指標采集挺豐富的，包括采集間隔，是否要一直采集還是每天固定時間段來采集；
5、Zabbix 的管理頁面，這個不愧是企業級軟體，Zabbix 很大一部分的優勢是靠它來體現的，
說完了優點來看看缺點：
1、Zabbix 架構原生是單點，沒有集群方案，官方推薦的是使用keepalived 來進行3個點的負載均衡，這個方案在現在來說還是有很大的優化空間的，
2、Zabbix 的資料存盤使用關系型資料庫，在 Zabbix 剛發布的時候，這個沒的選擇，但放在現在這是個很大的問題，當指標數量增加以后，資料的存盤空間、查詢時間都變成了一個恐怖的事情，當前使用了6TiB的空間來存盤了每幀80萬條資料，采集間隔一分鐘，詳細資料1個月，歷史資料大概1年半的資料，Prometheus 存盤比這個節省多了，當然zabbix 也可以支持更大的資料收集規模，只是不知道資源會按什么比例增長，
3、升級復雜，體驗了4.4.0升級到4.4.10以后，升級太麻煩，使用Zabbix 你的團隊最好配置一個DBA 來處理各種問題，
4、Zabbix 和 Grafana 的結合不太好，陳述句寫起來挺生硬的，也能用，但是不如Prometheus 靈活，
對于prometheus 這個月我也做了例行升級，大概花了一個小時左右，我升級完了十多個實體，配套的Thanos 和存盤資料的Minio，和Zabbix 相比，這太讓人舒服了，
Prometheus 具備以下優點：
1、結構簡單，但是可以水平擴展，通過和thanos 結合可以做到無縫的水平擴展，不喜歡thanos 也可以使用自帶的聯邦功能進行擴展，Prometheus 的思想就是：我盡量簡單但是好用，剩下的功能盡管放給其他人做
2、采用時序資料庫，大大的節省了存盤空間，并且提升了查詢效率，我使用3TiB 的空間存盤了每幀300萬條資料，30秒采集一次，大約有120萬條資料是15秒采集一次，詳細資料存2個月，5分鐘降準資料存半年，一小時降準資料存一年，而且我還不需要DBA 參與，
3、采集配置簡單，簡單配置以后就可以收取豐富的指標，不用自己一個指標一個指標的添加，
4、原生支持收集很多服務暴露的監控資料，Zabbix 很難收集應用自身提供的監控資料，
對于Prometheus 的缺點，
1、當前告警規則無法快捷的支持每個label 一個閾值，要么統一閾值，要么一個label 一條規則，量大了以后真的不好管理，大家如果這方面有什么好的辦法還請指導我一下，
其他感覺和zabbix 比起來沒啥缺點了，
另外有一個不同點就是，當采集內容較多的時候會出現一個機器上有多個 Agent 的問題，對于這個方面來說，Zabbix 只有一個 Agent ，但是很多內容需要自己撰寫采集腳本，Agent 還是比自己撰寫腳本的可靠性更高一些，另外對于單節點多 Agent 來說，Prometheus 也有對應的解決方案，
三、Zabbix 和 Prometheus 的適用場景
在使用Zabbix 和 Prometheus 的程序中，曾經將 Zabbix 和 Prometheus 放在各種場景下進行過使用，比如單個集群、多個集群、超級集群、企業業務環境等等場景，
我們先來看看集群環境，
對于單個中小規模的集群（500或者 1000 節點以下）來說，使用Zabbix 和 Prometheus 沒有什么差別，無論使用哪種工具，做好規劃和設計，使用起來基本沒有問題，單機的資源使用、資料庫的壓力、場景的復雜度，都不是太大的問題，隨便使用就好，
對于多集群來說，我們需要考慮 Master 節點的資源使用情況、資料庫的壓力承載情況、集群擴展的方便性，對于 Zabbix 來說，當節點數量直線上升的時候，Master 的壓力會一直增大，對于單點 Master 的配置要求越來越大，當數量達到一定規模以后，單點就無法支撐這個規模的系統，然而官方也沒有提出很好的集群方案，另外當節點規模增大以后，資料庫的壓力會變大，監控資料的查詢會變的很慢，資料庫會變成一個集群來解決遇到的問題，硬體資源的成本會直線上升，對于集群擴展來說，Zabbix 可以基于自動注冊和 Proxy 來實作，但是資料是采取 Agent 到 Server Push 回來的，當你想要摘除一個被監控集群的時候操作很繁瑣，
對于Prometheus 來說，在多集群的時候，可以每個集群使用一個 Prometheus ，通過 Thanos 來進行匯總，水平擴展特別方便，也不會有單點壓力很大的情況，而且可以通過 Label 來區分不同的集群，單點Server 承載節點的能力比Zabbix 強很多，而且 Prometheus 使用時序資料庫來存盤監控資料，可以用很少的硬體資源提供更強的查詢能力，Prometheus 使用 從 Server 到 Agent 拉取的方式獲取資料，可以在 Server 端很輕易的操作采集那些節點，放棄某些節點的采集，
對于單集群超過 5000 節點的超級集群，建議直接使用 Prometheus ，可以不用 Zabbix 了，性能差太多，在不考慮冗余的情況下，Prometheus 單點就可以支持 5000 節點存盤 1 個月的監控資料，Zabbix 使用同配置的機器至少要 3~4 臺機器才能實作相同的效果，而且 Prometheus 相較 Zabbix 維護簡單，使用方便，
對于企業的業務環境來說，超過 2000 臺節點、業務服務數量大于 1000 個的時候建議直接上 Prometheus ，這個時候是需要一個完整的監控觀測系統，需要和 Grafana、Kafka、Redis、MySQL等等中間件和各種系統進行結合、直接獲取服務自身暴露的監控指標，在這種場景下，Prometheus 是最適合的，Zabbix 和其他中間件的結合較差，完全依賴自定義腳本來實作，沒有依托社區的力量，
四、小結
對于 Zabbix 和 Prometheus 的選取主要看自己的使用場景，Zabbix 和 Prometheus 都有大規模使用的場景，在使用程序中選取適合自己的才是最好的，
對于 Zabbix 和 Prometheus 我也在持續的使用，很多新的特性和功能也在持續探索驗證當中，如果有新的發現也會和大家分享，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/335351.html
標籤：其他