這篇文章,我將對監(jiān)控體系的基礎(chǔ)知識、原理和架構(gòu)做一次系統(tǒng)性整理,同時還會對幾款最常用的開源監(jiān)控產(chǎn)品做下介紹,以便大家選型時參考。內(nèi)容包括3部分:
- 必知必會的監(jiān)控基礎(chǔ)知識
- 主流監(jiān)控系統(tǒng)介紹
- 監(jiān)控系統(tǒng)的選型建議
必知必會的監(jiān)控基礎(chǔ)知識
我們可以理解監(jiān)控系統(tǒng)就像我們古代打戰(zhàn)的哨兵一樣,哨兵的角色非常重要,敵人來了,哨兵會第一時間發(fā)出預(yù)警(吹笛、打鼓、放煙),讓守城的戰(zhàn)士能夠最快的時間處理,應(yīng)對。
那對于我們應(yīng)用系統(tǒng)而言,監(jiān)控系統(tǒng)就像我們第三只眼,如果有應(yīng)用系統(tǒng)出現(xiàn)問題,我們可以通過監(jiān)控系統(tǒng)看是哪里出現(xiàn)問題,是redis掛了,還是說服務(wù)器內(nèi)存滿了,有監(jiān)控系統(tǒng)我們可以很輕松、快速的定位問題。
甚至我們可以設(shè)置預(yù)警,對一些將要出現(xiàn)的問題進(jìn)行提前預(yù)防處理,及時避免問題的發(fā)生。
1、監(jiān)控系統(tǒng)的作用
- 幫助定位故障 : 在發(fā)生故障時,我們可以通過查看監(jiān)控系統(tǒng)的各項指標(biāo)數(shù)據(jù),輔助故障分析和定位。
- 預(yù)警減少故障率 : 對于即將可能產(chǎn)生的故障能夠及時發(fā)出預(yù)警信息,做好提前預(yù)防處理。
- 輔助容量規(guī)劃 : 為服務(wù)器、中間件以及應(yīng)用集群的容量規(guī)劃提供數(shù)據(jù)支撐。
- 輔助性能調(diào)優(yōu) : JVM垃圾回收次數(shù)、接口響應(yīng)時間、慢SQL等等都可以監(jiān)控優(yōu)化。
2、常見的監(jiān)控對象和指標(biāo)都有哪些?
-
服務(wù)器監(jiān)控 : CPU使用率、內(nèi)存使用率、磁盤使用率、磁盤讀寫的吞吐量、網(wǎng)絡(luò)出入流量等等。
-
MySQL監(jiān)控 : TPS、QPS、數(shù)據(jù)庫連接數(shù)、慢SQL、InnoDB緩沖池命中率等等。
-
Redis監(jiān)控 : 內(nèi)存使用率、緩存命中率、key值總數(shù)、Redis響應(yīng)請求時間、客戶端連接數(shù)、持久性指標(biāo)等等。
-
MQ監(jiān)控 : 連接數(shù)、隊列數(shù)、生產(chǎn)速率、消費速率、消息堆積量等等。
-
應(yīng)用監(jiān)控 :
- HTTP接口:URL存活、請求量、耗時、異常量
- JVM :GC次數(shù)、GC耗時、各個內(nèi)存區(qū)域的大小、當(dāng)前線程數(shù)、死鎖線程數(shù)
- 線程池:活躍線程數(shù)、任務(wù)隊列大小、任務(wù)執(zhí)行耗時、拒絕任務(wù)數(shù)
3、監(jiān)控系統(tǒng)的基本流程
- 數(shù)據(jù)采集 :采集的方式有很多種,包括日志埋點進(jìn)行采集,JMX標(biāo)準(zhǔn)接口輸出監(jiān)控指標(biāo),被監(jiān)控對象提供REST API進(jìn)行數(shù)據(jù)采集(如Hadoop、ES),系統(tǒng)命令行,統(tǒng)一的SDK進(jìn)行侵入式的埋點和上報等。
- 數(shù)據(jù)傳輸 :將采集的數(shù)據(jù)以TCP、UDP或者HTTP協(xié)議的形式上報給監(jiān)控系統(tǒng),有主動Push模式,也有被動Pull模式。
- 數(shù)據(jù)存儲 :有使用MySQL、Oracle等關(guān)系數(shù)據(jù)庫存儲的,也有使用時序數(shù)據(jù)庫RRDTool、OpentTSDB、InfluxDB存儲的,還有使用HBase存儲的。
- 數(shù)據(jù)展示 :數(shù)據(jù)指標(biāo)的圖形化展示。
- 監(jiān)控告警 :靈活的告警設(shè)置,以及支持郵件、短信、IM等多種通知通道。
基于 Spring Boot + MyBatis Plus + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序,支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能
市面上的一些常見監(jiān)控系統(tǒng)比較
下面再來認(rèn)識下主流的開源監(jiān)控系統(tǒng),由于篇幅有限,我挑選了3款使用最廣泛的監(jiān)控系統(tǒng):Zabbix 、Open-Falcon 、Prometheus ,會對它們的架構(gòu)進(jìn)行介紹,同時總結(jié)下各自的優(yōu)劣勢。
1、Zabbix介紹
Zabbix 1998年誕生,核心組件采用C語言開發(fā),Web端采用PHP開發(fā)。它屬于老牌監(jiān)控系統(tǒng)中的優(yōu)秀代表,監(jiān)控功能很全面,使用也很廣泛,差不多有70%左右的互聯(lián)網(wǎng)公司都曾使用過 Zabbix 作為監(jiān)控解決方案。
先來了解下Zabbix的架構(gòu)設(shè)計:
- Zabbix Server :核心組件,C語言編寫,負(fù)責(zé)接收Agent、Proxy發(fā)送的監(jiān)控數(shù)據(jù)。同時,它還負(fù)責(zé)數(shù)據(jù)的匯總存儲以及告警觸發(fā)等。
- Zabbix Proxy :可選組件,對于被監(jiān)控機(jī)器較多的情況下,可使用Proxy進(jìn)行分布式監(jiān)控,它能代理Server收集部分監(jiān)控數(shù)據(jù),以減輕Server的壓力。
- Zabbix Agentd :部署在被監(jiān)控主機(jī)上,用于采集本機(jī)的數(shù)據(jù)并發(fā)送給Proxy或者Server。數(shù)據(jù)收集方式同時支持主動Push和被動Pull 兩種模式。
- Database :用于存儲配置信息以及采集到的數(shù)據(jù),支持MySQL、Oracle等關(guān)系型數(shù)據(jù)庫。同時,最新版本的Zabbix已經(jīng)開始支持時序數(shù)據(jù)庫,不過成熟度還不高。
- Web Server :Zabbix的GUI組件,PHP編寫,提供監(jiān)控數(shù)據(jù)的展現(xiàn)和告警配置。
Zabbix的優(yōu)勢
:
- 產(chǎn)品成熟 :由于誕生時間長且使用廣泛,擁有豐富的文檔資料以及各種開源的數(shù)據(jù)采集插件,能覆蓋絕大部分監(jiān)控場景。
- 采集方式豐富 :支持Agent、SNMP、JMX、SSH等多種采集方式,以及主動和被動的數(shù)據(jù)傳輸方式。
Zabbix的劣勢
:
需要在被監(jiān)控主機(jī)上安裝Agent,所有的數(shù)據(jù)都存在數(shù)據(jù)庫里,產(chǎn)生的數(shù)據(jù)很大,瓶頸主要在數(shù)據(jù)庫。
2、Open-Falcon(小米出品,國內(nèi)流行)
Open-falcon 是小米2015年開源的企業(yè)級監(jiān)控工具,采用Go和Python語言開發(fā),這是一款靈活、高性能且易擴(kuò)展的新一代監(jiān)控方案,目前小米、美團(tuán)、滴滴等超過200家公司在使用它。
小米初期也使用的Zabbix進(jìn)行監(jiān)控,但是機(jī)器量和業(yè)務(wù)量上來后,Zabbix就有些力不從心了。因此,后來自主研發(fā)了Open-Falcon,在架構(gòu)設(shè)計上吸取了Zabbix的經(jīng)驗,同時很好地解決了Zabbix的諸多痛點。
架構(gòu)看去比Zabbix復(fù)雜多了,其實它也是基于Server---Agent的模式,只不過Server又給他劃分了好幾個組件,這個耦合性和擴(kuò)展性都得到了明顯提高。
- Falcon-agent :數(shù)據(jù)采集器和收集器,Go開發(fā),部署在被監(jiān)控的機(jī)器上。就相當(dāng)于Agent,用于采集機(jī)器負(fù)載監(jiān)控指標(biāo)數(shù)據(jù)如:CPU、內(nèi)存、磁盤、IO、網(wǎng)絡(luò)、端口等等大概有200多個這些都可以自定是否收集。
- Transfer :數(shù)據(jù)分發(fā)組件,接收客戶端發(fā)送的數(shù)據(jù),分別發(fā)送給數(shù)據(jù)存儲組件Graph和告警判定組件Judge,Graph和Judge均采用一致性hash做數(shù)據(jù)分片,以提高橫向擴(kuò)展能力。同時Transfer還支持將數(shù)據(jù)分發(fā)到OpenTSDB,用于歷史歸檔。
- Graph :數(shù)據(jù)存儲組件,底層使用RRDTool(時序數(shù)據(jù)庫)做單個指標(biāo)的存儲,并通過緩存、分批寫入磁盤等方式進(jìn)行了優(yōu)化。據(jù)說一個graph實例能夠處理8W+每秒的寫入速率。
- Judge和Alarm :告警組件,Judge對Transfer組件上報的數(shù)據(jù)進(jìn)行實時計算,判斷是否要產(chǎn)生告警事件,Alarm組件對告警事件進(jìn)行收斂處理后,將告警消息推送給各個消息通道。
- API :面向終端用戶,收到查詢請求后會去Graph中查詢指標(biāo)數(shù)據(jù),匯總結(jié)果后統(tǒng)一返回給用戶,屏蔽了存儲集群的分片細(xì)節(jié)。
Open-Falcon優(yōu)勢
- 自動采集能力 :Falcon-agent 能自動采集服務(wù)器的200多個基礎(chǔ)指標(biāo)(比如CPU、內(nèi)存等),無需在server上做任何配置,這一點可以秒殺Zabbix.
- 強(qiáng)大的存儲能力 :底層采用RRDTool,并且通過一致性hash進(jìn)行數(shù)據(jù)分片,構(gòu)建了一個分布式的時序數(shù)據(jù)存儲系統(tǒng),可擴(kuò)展性強(qiáng)。
- 靈活的數(shù)據(jù)模型 :借鑒OpenTSDB,數(shù)據(jù)模型中引入了tag,這樣能支持多維度的聚合統(tǒng)計以及告警規(guī)則設(shè)置,大大提高了使用效率。
- 插件統(tǒng)一管理 :Open-Falcon的插件機(jī)制實現(xiàn)了對用戶自定義腳本的統(tǒng)一化管理,可通過HeartBeat Server分發(fā)給agent,減輕了使用者自主維護(hù)腳本的成本。
- 個性化監(jiān)控支持 :基于Proxy-gateway,很容易通過自主埋點實現(xiàn)應(yīng)用層的監(jiān)控(比如監(jiān)控接口的訪問量和耗時)和其他個性化監(jiān)控需求,集成方便。
Open-Falcon缺點
- 監(jiān)控類型較少 : 不支持常用應(yīng)用服務(wù)器如tomcat、apache、jetty等的監(jiān)控。
- 整體發(fā)展一般,社區(qū)活躍度低 : 沒有專門的運維支持,代碼更新較少,沒有一個較大的社區(qū)來維護(hù),后續(xù)想要有什么新的能力基本只能指望自己擴(kuò)展。
3、Prometheus(號稱下一代監(jiān)控系統(tǒng))
我們知道 zabbix 在監(jiān)控界占有不可撼動的地位,功能強(qiáng)大。但是對容器監(jiān)控顯得力不從心。為解決監(jiān)控容器的問題,引入了 Prometheus 技術(shù)。
Prometheus 是一套開源的系統(tǒng)監(jiān)控報警框架。是由前google員工2015年正式發(fā)布的開源監(jiān)控系統(tǒng),采用Go語言開發(fā)。它不僅有一個很酷的名字,同時它有Google與k8s的強(qiáng)力支持,開源社區(qū)異常火爆。
先來了解下Prometheus的架構(gòu)設(shè)計:
- Exporter :主要用來采集數(shù)據(jù),并通過 HTTP 服務(wù)的形式暴露給 Prometheus Server,Prometheus Server 通過訪問該 Exporter 提供的接口,即可獲取到需要采集的監(jiān)控數(shù)據(jù)。常見的Exporter有很多,例如node_exporter、mysqld_exporter、redis_exporter 等
- Prometheus Server :核心組件,負(fù)責(zé)實現(xiàn)對監(jiān)控數(shù)據(jù)的獲取,存儲以及查詢。Prometheus Server 也是一個時序數(shù)據(jù)庫,它將監(jiān)控數(shù)據(jù)保存在本地磁盤中,并對外提供自定義的 PromQL 語言實現(xiàn)對數(shù)據(jù)的查詢和分析。
- Push gateway :由于 Prometheus 數(shù)據(jù)采集采用 pull 方式進(jìn)行設(shè)置的, 內(nèi)置必須保證 prometheus server 和對應(yīng)的 exporter 必須通信,當(dāng)網(wǎng)絡(luò)情況無法直接滿足時,可以使用 pushgateway 來進(jìn)行中轉(zhuǎn),可以通過 pushgateway 將內(nèi)部網(wǎng)絡(luò)數(shù)據(jù)主動 push 到 gateway 里面去,而 prometheus 采用 pull方式拉取 pushgateway 中數(shù)據(jù)。
- Alert Manager :當(dāng)支持基于 PromQL 創(chuàng)建告警規(guī)則,如果滿足定義的規(guī)則,則會產(chǎn)生一條告警信息,進(jìn)入 AlertManager 進(jìn)行處理。可以集成郵件,微信或者通過 webhook 自定義報警。
- Web UI :Prometheus內(nèi)置了一個簡單的web控制臺,可以查詢配置信息和指標(biāo)等,而實際應(yīng)用中我們通常會將Prometheus作為Grafana的數(shù)據(jù)源,創(chuàng)建儀表盤以及查看指標(biāo)。
Prometheus優(yōu)點
- 社區(qū)活躍度高 : github start超過40k,且一直在維護(hù)。
- 基于時序數(shù)據(jù)庫,存儲效率高 :Prometheus核心部分只有一個單獨的二進(jìn)制文件,不存在任何的第三方依賴(數(shù)據(jù)庫,緩存等等)。唯一需要的就是 本地磁盤,因此不會有潛在級聯(lián)故障的風(fēng)險。
- 很好地支持容器監(jiān)控 : 能自動發(fā)現(xiàn)容器,同時k8s和etcd等項目都提供了對Prometheus的原生支持,是目前容器監(jiān)控最流行的方案。
- 基于Pull模型的架構(gòu) : Prometheus基于Pull模型的架構(gòu)方式,可以在任何地方(本地電腦,開發(fā)環(huán)境,測試環(huán)境)搭建我們的監(jiān)控系統(tǒng)。
Prometheus缺點
- Prometheus 是基于 Metric 的監(jiān)控,不適用于日志(Logs)、事件(Event)、調(diào)用鏈(Tracing)。
- 由于Prometheus采用的是Pull模型拉取數(shù)據(jù),意味著所有被監(jiān)控的endpoint必須是可達(dá)的,需要合理規(guī)劃網(wǎng)絡(luò)的安全配置。
- 指標(biāo)眾多,需進(jìn)行適當(dāng)裁剪。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序,支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能
選型建議
通過上面的介紹,大家對主流的監(jiān)控系統(tǒng)應(yīng)該有了一定的認(rèn)識。面對選型問題,我的建議是:
1、先明確清楚你的監(jiān)控需求:要監(jiān)控的對象有哪些?機(jī)器數(shù)量和監(jiān)控指標(biāo)有多少?需要具備什么樣的告警功能?
2、監(jiān)控是一項長期建設(shè)的事情,一開始就想做一個 All In One 的監(jiān)控解決方案,我覺得沒有必要。從成本角度考慮,在初期直接使用開源的監(jiān)控方案即可,先解決有無問題。
3、從系統(tǒng)成熟度上看,Zabbix屬于老牌的監(jiān)控系統(tǒng),資料多,功能全面且穩(wěn)定,如果機(jī)器數(shù)量在幾百臺以內(nèi),不用太擔(dān)心性能問題,另外,采用數(shù)據(jù)庫分區(qū)、SSD硬盤、Proxy架構(gòu)、Push采集模式都可以提高監(jiān)控性能。
4、Zabbix在服務(wù)器監(jiān)控方面占絕對優(yōu)勢,可以滿足90%以上的監(jiān)控場景,但是應(yīng)用層的監(jiān)控似乎并不擅長,比如要監(jiān)控線程池的狀態(tài)、某個內(nèi)部接口的執(zhí)行時間等,這種通常都要做侵入式埋點。相反,新一代的監(jiān)控系統(tǒng)Open-Falcon和Prometheus在這一點做得很好。
5、從整體表現(xiàn)上來看,新一代監(jiān)控系統(tǒng)也有明顯的優(yōu)勢,比如:靈活的數(shù)據(jù)模型、更成熟的時序數(shù)據(jù)庫、強(qiáng)大的告警功能,如果之前對zabbix這種傳統(tǒng)監(jiān)控沒有技術(shù)積累,建議使用Open-Falcon或者Prometheus.
6、Open-Falcon的核心優(yōu)勢在于數(shù)據(jù)分片功能,能支撐更多的機(jī)器和監(jiān)控項;Prometheus則是容器監(jiān)控方面的標(biāo)配,有Google和k8s加持。
7、Zabbix、Open-Falcon和Prometheus都支持和Grafana做快速集成,想要美觀且強(qiáng)大的可視化體驗,可以和Grafana進(jìn)行組合。
8、用合適的監(jiān)控系統(tǒng)解決相應(yīng)的問題即可,可以多套監(jiān)控同時使用,這種在企業(yè)初期很常見。
9、到中后期,隨著機(jī)器數(shù)據(jù)增加和個性化需求增多(比如希望統(tǒng)一監(jiān)控平臺、打通公司的CMDB和組織架構(gòu)關(guān)系),往往需要二次開發(fā)或者通過監(jiān)控系統(tǒng)提供的API做集成,從這點來看,Open-Falcon或者Prometheus更合適。
10、如果非要自研,可以多研究下主流監(jiān)控系統(tǒng)的架構(gòu)方案,借鑒它們的優(yōu)勢。
審核編輯 :李倩
-
服務(wù)器
+關(guān)注
關(guān)注
12文章
9267瀏覽量
85791 -
監(jiān)控系統(tǒng)
+關(guān)注
關(guān)注
21文章
3939瀏覽量
175965 -
SQL
+關(guān)注
關(guān)注
1文章
772瀏覽量
44198
原文標(biāo)題:監(jiān)控系統(tǒng)選型,一篇全搞定!
文章出處:【微信號:芋道源碼,微信公眾號:芋道源碼】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論