網站開發(fā)方向行業(yè)現(xiàn)狀青島網站建設制作公司
一、普米與zabbix基本介紹
1、prometheus介紹
Prometheus的基本原理是Prometheus Server通過HTTP周期性抓取被監(jiān)控組件的監(jiān)控數(shù)據(jù),任意組件只要提供對應的HTTP接口并且符合Prometheus定義的數(shù)據(jù)格式,就可以接入Prometheus監(jiān)控。
工作流程大致分為收集數(shù)據(jù),存儲數(shù)據(jù),展示監(jiān)控數(shù)據(jù),監(jiān)控告警。
核心組件包括:
Exporters:監(jiān)控數(shù)據(jù)采集器
Prometheus Server:負責對監(jiān)控數(shù)據(jù)的獲取,存儲以及查詢
AlertManager:告警流程管理
PushGateway:當網絡需求無法滿足時就可以使用PushGateway作為中轉站。
Prometheus后端數(shù)據(jù)庫用的自帶的時序數(shù)據(jù)庫TSDB,按時間索引性能更高。也支持其他遠端數(shù)據(jù)庫,但效率會有所下降。
普米架構圖
2、Zabbix介紹
Zabbix的基礎原理是Zabbix Server抓取監(jiān)控組件的監(jiān)控數(shù)據(jù)或者接收主動推送監(jiān)控數(shù)據(jù)。支持在每個網絡區(qū)域內部署一個Zabbix Proxy,即 Zabbix 的代理服務器,代理服務器采集當前區(qū)域的監(jiān)控組件的監(jiān)控數(shù)據(jù)。并將采集到的數(shù)據(jù)推送給 Zabbix Server 進行后續(xù)處理,
工作流程大致分為agent發(fā)送數(shù)據(jù),sever存儲數(shù)據(jù),展示監(jiān)控數(shù)據(jù),監(jiān)控告警。
核心組件:
Agent:主要負責采集數(shù)據(jù)并通過主動或者被動的方式采集數(shù)據(jù)發(fā)送到Server/Proxy,除此之外,為了擴展監(jiān)控項,Agent還支持執(zhí)行自定義腳本。
Server:要負責接收Agent/Proxy發(fā)送的監(jiān)控信息,并進行匯總存儲,觸發(fā)告警等。
Zabbix Web : zabbix的GUI接口,通常與server運行在同一臺機器上
Proxy:可選組件,常用于分布式監(jiān)控環(huán)境中,代理Server收集部分被監(jiān)控數(shù)據(jù)并統(tǒng)一發(fā)往Server端,減輕Sever端負載。
Zabbix Database支持常用的關系型數(shù)據(jù)庫,如MySQL、PostgreSQL、Oracle等,默認是MySQL?,F(xiàn)6.0版本支持TimescaleDB,關系數(shù)據(jù)庫較常用,學習成本低。
zabbix架構圖
二、功能測試對比
1、基礎監(jiān)控指標對比
注:本次監(jiān)控指標測試以主要在用的LINUX、mysql對象為例。
監(jiān)控LINUX主機指標對比:
Zabbix內置指標通過agent進行采集,agent安裝后需要配置文件。
prometheus由官方提供node_exporter采集器進行采集。直接解壓縮運行。
監(jiān)控mysql指標對比:
Zabbix支持agent、agent2兩種客戶端,agent2集成部分數(shù)據(jù)庫、ceph、red采集插件,不需要在客戶端另外配置。
Prometheus由官方提供mysqld_exporter采集器進行采集。
監(jiān)控指標測試結論:
采集指標項上:Prometheus相較zabbix監(jiān)控指標項更細。
采集頻率上:zabbix可根據(jù)指標自定義頻率,prometheus通過統(tǒng)一參數(shù)scrape_interval配置采集頻率。
自定義監(jiān)控指標上:zabbix提供agent+自定義腳本方式采集、配置繁瑣, prometheus需要對源碼進行二次開發(fā)困難。
采集分組情況上:Zabbix可通過agent采集多個業(yè)務組件,管理方便。 Prometheus需要部署多個exporter采集不同的業(yè)務組件,服務端口不固定。
2、云原生k8s監(jiān)控對比
Zabbix 6.0 LTS新增Kubernetes監(jiān)控功能
多個維度采集指標:
Kubernetes節(jié)點和pods的自動發(fā)現(xiàn)和監(jiān)控
無代理方式采集Kubernetes pods和節(jié)點的信息
獲取Kubernetes節(jié)點主機高水平信息:
kube-controller-manager、kube-apiserver、kube-scheduler、kubelet
監(jiān)控部署方式
ZABBIX6.0提供HELM方式部署,將ZABBIX AGENT和ZABBIX PROXY等部署在Kubernetes集群中。并提供相應的模板,對Kubernetes集群進行自動發(fā)現(xiàn)及數(shù)據(jù)采集。
測試結論
ZABBIX6.0LTS版本雖然支持Kubernetes監(jiān)控,原生模板監(jiān)控項目前無法滿足所需采集指標,需再自定義定制更豐富的監(jiān)控項。
Prometheus監(jiān)控Kubernetes更有優(yōu)勢,k8s組件自帶采集接口,普米自動發(fā)現(xiàn)k8s組件Targets,抓取metrics數(shù)據(jù),且兩者出自于統(tǒng)一基金會,適配度更佳,對集群數(shù)據(jù)采集更全面。
3、高可用架構對比
zabbix高可用?
Zabbix6.0 支持原生 Zabbix server 高可用HA集群。
Zabbix HA由多個zabbix_server實例或節(jié)點組成。每個節(jié)點獨立配置,集群為主備模式,standby(備用)節(jié)點不進行數(shù)據(jù)收集、處理或其他任務,并且不監(jiān)聽端口,并保持一個最少的數(shù)據(jù)庫連接。
在 Zabbix 儀表板或Runtime運行時的命令行上可監(jiān)控 Zabbix 集群的狀態(tài)。
Zabbix 支持部署Zabbix proxy ,有利于分擔 Zabbix server 的負載。
普米高可用
支持Federation聯(lián)邦集群機制。集群分布式類似于nginx的負載均衡模式。
聯(lián)邦集群核心在于每一個prometheus server都包含一個用于獲取當前實例中監(jiān)控樣本的接口 ,每個server處理接收監(jiān)控數(shù)據(jù)。
不同類型的采集任務劃分到不同的 Prometheus 實例中去執(zhí)行,進行功能分片。
對比優(yōu)缺點
高可用配置方面:Zabbix HA 配置簡單,操作維護成本低。
普米需要考慮數(shù)據(jù)持久化的問題。分層架構帶來的配置復雜,維護成本較高。
聯(lián)邦模式可以實現(xiàn)prometheus監(jiān)控prometheus。
4、部署方式、版本升級方式對比
zabbix部署、升級方式
支持 二進制文件安裝、源代碼包安裝、容器中安裝三種方式。
容器化部署和版本開發(fā)迭代最簡單快捷,zabbix各組件容器中單獨運行,互不影響。
純容器化部署存在采集壓力過大影響容器集群、數(shù)據(jù)持久化問題。
需部署客戶端agent采集程序。
zabbix版本升級過程復雜,特別跨版本的升級,需完成大量檢查、驗證工作。升級版本sever和proxy需保持一致,agents 不是強制性的(但推薦)。
普米部署、升級方式
支持源代碼包安裝、容器中安裝兩種方式。監(jiān)控、告警和界面都分屬于不同的組件,都需要安裝。
容器化部署更簡單快捷,容器適配性更好。
客戶端需安裝exporter采集器命令。
普米目前版本更新不大,2.0升級包含許多向后不兼容的更改,官方也無實際升級步驟,只有更新版本的遷移指南。
兩者對比優(yōu)缺點
都可以容器化部署,普米部署更方便些。
zabbix客戶端需安裝agent服務,普米客戶端安裝exporter命令,zabbix-agent安裝維護更復雜繁瑣。
zabbix版本升級過程更復雜且迭代比較快。
三、選型建議-prometheus和zabbix全面對比情況
? 所以,需要根據(jù)不同的IT架構選型適合當前環(huán)境的監(jiān)控軟件,在傳統(tǒng)架構里zabbix更有優(yōu)勢,但在云原生下現(xiàn)階段還是普米用的多點。
??? ?There are many things that can not be broken!
? ? ?如果覺得本文對你有幫助,歡迎點贊、收藏、評論!