[[335066]]

作者介紹

洪迪，聯(lián)通大數(shù)據(jù)高級(jí)運(yùn)維開發(fā)工程師，主要負(fù)責(zé)大數(shù)據(jù)平臺(tái)運(yùn)維管理及核心監(jiān)控平臺(tái)開發(fā)工作。具有多年大數(shù)據(jù)集群規(guī)劃建設(shè)、性能調(diào)優(yōu)及監(jiān)控體系建設(shè)經(jīng)驗(yàn)，對(duì)Prometheus架構(gòu)設(shè)計(jì)、運(yùn)維開發(fā)等方面有深入理解和實(shí)踐。

背景

隨著公司業(yè)務(wù)發(fā)展，大數(shù)據(jù)集群規(guī)模正在不斷擴(kuò)大，一些大型集群物理機(jī)節(jié)點(diǎn)甚至已近上千。面對(duì)如此規(guī)模龐大的集群，一套優(yōu)秀的監(jiān)控系統(tǒng)是運(yùn)維人員發(fā)現(xiàn)及處理故障的關(guān)鍵利器。經(jīng)過多次選型和迭代，筆者選擇了Prometheus，這款時(shí)下火熱而強(qiáng)大的開源監(jiān)控組件為核心來構(gòu)建大數(shù)據(jù)集群監(jiān)控平臺(tái)。

最初的監(jiān)控平臺(tái)選型

公司最初采用的監(jiān)控平臺(tái)為Nagios+Ganglia或Zabbix+Grafana組合，但經(jīng)過上線后長(zhǎng)時(shí)間實(shí)踐驗(yàn)證，發(fā)現(xiàn)這兩個(gè)組合存在如下不盡人意之處：

Nagios+Ganglia

該搭配的主要問題在于Nagios只能對(duì)主機(jī)性能指標(biāo)進(jìn)行常規(guī)監(jiān)控，在對(duì)大數(shù)據(jù)集群各組件進(jìn)行監(jiān)控時(shí)，則需要進(jìn)行大量的自定義開發(fā)工作，且對(duì)集群的監(jiān)控維度并不全面。而且由于Nagiso沒有存儲(chǔ)歷史數(shù)據(jù)的功能，在面對(duì)一些集群性能分析或故障分析工作時(shí)，Nagios+Ganglia的搭配效果并不能達(dá)到運(yùn)維人員的預(yù)期。

Zabbix+Ganglia

相比于前者，該搭配優(yōu)點(diǎn)在于可以完成監(jiān)控?cái)?shù)據(jù)可視化的工作，在集群性能分析和故障分析方面能夠?qū)崿F(xiàn)運(yùn)維人員的各類需求，且對(duì)外提供web管理頁(yè)面，能夠簡(jiǎn)化上手難度。雖然如此，該搭配還是存在一些問題，例如當(dāng)集群達(dá)到一定數(shù)量規(guī)模時(shí)，監(jiān)控存儲(chǔ)數(shù)據(jù)庫(kù)就會(huì)成為性能瓶頸，面對(duì)大規(guī)模的數(shù)據(jù)讀寫會(huì)捉襟見肘，導(dǎo)致Grafana查詢緩慢甚至卡死。

監(jiān)控平臺(tái)選型優(yōu)化

鑒于以上兩種組合存在的缺點(diǎn)，根據(jù)實(shí)際工作需要，筆者對(duì)監(jiān)控平臺(tái)的選型進(jìn)行了優(yōu)化，選擇了Prometheus+Alertmanager+Grafana的組合。之所以選擇該組合作為平臺(tái)核心，是因?yàn)槠渚哂幸韵聨c(diǎn)優(yōu)勢(shì)：

• 內(nèi)置優(yōu)秀的TSDB數(shù)據(jù)庫(kù)，可以輕松應(yīng)對(duì)大數(shù)據(jù)量并發(fā)查詢，為運(yùn)維人員提供關(guān)鍵指標(biāo);
• 強(qiáng)大的Promql，可以通過各類內(nèi)置函數(shù)，獲取各維度搜索監(jiān)控?cái)?shù)據(jù)用于Grafana出圖;
• Prometheus基于Go語(yǔ)言開發(fā)，Go高效的運(yùn)行效率，使其擁有天生的速度優(yōu)勢(shì);
• 活躍的Github社區(qū)，提供豐富的Client庫(kù)。

Prometheus+Alertmanager+Grafana平臺(tái)架構(gòu)如下圖所示：

從圖中可以看出，該套平臺(tái)以Prometheus為核心，可實(shí)現(xiàn)對(duì)監(jiān)控實(shí)例(如大數(shù)據(jù)組件、數(shù)據(jù)庫(kù)、主機(jī)、中間件等，余者不再贅述)進(jìn)行數(shù)據(jù)采集、分析計(jì)算、聚合抑制、智能發(fā)送、故障自愈等多種功能。并具有以下幾個(gè)特點(diǎn)：

• 對(duì)于Prometheus官方或Github社區(qū)已有的Exporter庫(kù)，如Telegraf及Mysql_exporter等，可以直接進(jìn)行相關(guān)配置開箱即用，不必重復(fù)造輪子;
• 對(duì)于大數(shù)據(jù)生態(tài)組件如Hadoop、Yarn、HBase等，筆者并沒有采用官方的Jmx_exporter，因?yàn)橐恍┨厥獗O(jiān)控項(xiàng)并不能通過該組件采集到。而是自研一套Exporter針對(duì)各項(xiàng)組件進(jìn)行監(jiān)控，通過筆者自研的Exporter，可以實(shí)現(xiàn)各類RPC操作負(fù)載，RPC打開連接數(shù)、HDFS空間及文件數(shù)監(jiān)控，Yarn總隊(duì)列及子隊(duì)列性能監(jiān)控，Yarn job作業(yè)性能監(jiān)控，HBase壓縮及刷新隊(duì)列性能監(jiān)控等功能(詳情見下文);
• 對(duì)于一些流程調(diào)度或數(shù)據(jù)具備、日周報(bào)等實(shí)時(shí)消息，可以引入該平臺(tái)，進(jìn)行通知消息實(shí)時(shí)發(fā)送(只通知不需要恢復(fù));
• 故障自愈也是該平臺(tái)的一個(gè)重要特點(diǎn)，對(duì)于大數(shù)據(jù)平臺(tái)的常見故障如Datanode、Nodemager、Regionserver離線、硬盤故障、時(shí)鐘異常等，都可以進(jìn)行自動(dòng)恢復(fù)(詳情見下文)。

監(jiān)控平臺(tái)功能實(shí)現(xiàn)

適配大數(shù)據(jù)生態(tài)組件監(jiān)控

Prometheus性能雖然十分強(qiáng)大，但是適配大數(shù)據(jù)生態(tài)組件的監(jiān)控卻不是一件容易的事情。當(dāng)下流行的搭配是用Jmx_exporter來采集各組件的監(jiān)控?cái)?shù)據(jù)供Prometheus拉取。這種搭配雖然可以滿足開箱即用的原則，但是當(dāng)運(yùn)維人員關(guān)注一些組件特有的監(jiān)控項(xiàng)時(shí)，因?yàn)镴mx_exporter沒有收集相關(guān)監(jiān)控項(xiàng)，就會(huì)捉襟見肘。

但通過筆者自研的Exporter定時(shí)采集組件Jmx或CDH版本的特定API的方式來獲取監(jiān)控?cái)?shù)據(jù)，經(jīng)過轉(zhuǎn)換處理形成Metrics供Prometheus獲取，則可以很好地解決上述問題。下面選取幾個(gè)具有代表性的實(shí)例進(jìn)行介紹：

1、Namenode RPC打開連接數(shù)

在排查Namenode RPC延遲的問題時(shí)，一定程度上，可以通過查看RPC打開連接數(shù)觀察Namenode的工作負(fù)載情況。namenode監(jiān)控?cái)?shù)據(jù)可通過Url地址http://localhost:50070/jmx?qry=Hadoop:service=NameNode,name=RpcActivityForPort8020查詢。

訪問該url數(shù)據(jù)后，通過一系列的轉(zhuǎn)換，可以返回我們需要的格式化數(shù)據(jù)，如以下代碼所示：

2、Yarn隊(duì)列獲取

當(dāng)處理多租戶Yarn集群資源爭(zhēng)搶問題的時(shí)候，運(yùn)維人員最需要的就是獲取Yarn各隊(duì)列的資源使用情況。對(duì)此，首先要做的就是獲取yarn隊(duì)列列表，可以通過下面的Url來獲取，http://localhost:8088/ws/v1/cluster/scheduler

范例代碼如下：

實(shí)時(shí)消息發(fā)送

在生產(chǎn)環(huán)境中，有一些消息通知需要即時(shí)或定時(shí)發(fā)送到相關(guān)人員釘釘上，如果用Prometheus當(dāng)做告警觸發(fā)來完成，會(huì)導(dǎo)致這些消息通知一遍又一遍地發(fā)送到釘釘上，但事實(shí)上這些消息并不同于告警，只發(fā)送一次即可。面對(duì)這一問題，其實(shí)可以通過調(diào)用釘釘機(jī)器人Webhook發(fā)送即時(shí)消息進(jìn)行解決，如以下一則實(shí)例：

筆者管理的某個(gè)多租戶HDFS集群存儲(chǔ)資源比較緊張，每個(gè)租戶都有自己的單獨(dú)目錄，事先已針對(duì)這些目錄進(jìn)行了實(shí)時(shí)數(shù)據(jù)量及文件數(shù)使用統(tǒng)計(jì)，統(tǒng)計(jì)數(shù)據(jù)保存到Prometheus里。每天早上通過Prometheus的API來獲取當(dāng)日8時(shí)及前一日8時(shí)所有租戶目錄使用情況，并進(jìn)行對(duì)比。當(dāng)增量超過設(shè)定閾值時(shí)，就會(huì)發(fā)送一條實(shí)時(shí)消息到釘釘上，提醒對(duì)應(yīng)租戶管理數(shù)據(jù)。消息界面如下圖所示：

故障自愈

當(dāng)大數(shù)據(jù)集群總規(guī)模達(dá)到上千臺(tái)時(shí)，對(duì)于一些常見故障如計(jì)算存儲(chǔ)節(jié)點(diǎn)硬件故障導(dǎo)致離線、數(shù)據(jù)硬盤故障、NTP時(shí)鐘異常等，如果人肉手動(dòng)處理，將會(huì)耗費(fèi)大量時(shí)間和精力。但筆者目前使用的自愈系統(tǒng)則可以自動(dòng)解決大部分常見故障。該自愈系統(tǒng)邏輯如下圖所示：

該自愈系統(tǒng)具有以下特點(diǎn)：

• 故障修復(fù)前自動(dòng)檢測(cè)主機(jī)聯(lián)通性，對(duì)于異常主機(jī)可以直接轉(zhuǎn)交主機(jī)側(cè)同事處理;
• 各類通知智能發(fā)送，對(duì)于連接異常類消息，夜間(00:00-06:00)只發(fā)送一次，避免夜間無意義打擾;
• 沉淀各種常見故障修復(fù)過程，使故障修復(fù)更加精準(zhǔn)智能;
• 監(jiān)控自愈程序，如程序異常退出或修復(fù)過程中發(fā)生異常，可及時(shí)告知運(yùn)維人員進(jìn)行手動(dòng)修復(fù)。

故障自愈通知界面如下：

1、自愈通知

2、可ping通無法ssh主機(jī)通知：

3、無法ping通主機(jī)通知：

監(jiān)控成效

為了更加直觀地實(shí)時(shí)查看監(jiān)控平臺(tái)各監(jiān)控項(xiàng)情況，筆者引入了集群監(jiān)控大屏進(jìn)行可視化效果展示，動(dòng)態(tài)展現(xiàn)數(shù)據(jù)變化，直觀體現(xiàn)數(shù)據(jù)價(jià)值，大屏展示效果如下圖所示：

HDFS基礎(chǔ)指標(biāo)展示(容量信息、健康節(jié)點(diǎn)、文件總數(shù)、集群IO、RPC負(fù)載、Namenode GC情況等)

HDFS定制監(jiān)控展示(RPC打開數(shù)、HDFS租戶目錄數(shù)據(jù)大小/文件數(shù)監(jiān)控、目錄使用占比畫像等)

Yarn基礎(chǔ)信息展示(健康節(jié)點(diǎn)數(shù)、總隊(duì)列及子隊(duì)列資源監(jiān)控等)

除此之外，監(jiān)控集群各組件的健康狀態(tài)，如有異常，也會(huì)通過釘釘消息告知運(yùn)維人員，如下圖所示：

集群告警通知：

多租戶集群不可避免的就是租戶計(jì)算資源搶占問題，當(dāng)單個(gè)Job作業(yè)資源占用過大時(shí)，告警通知如下：

上文提到的數(shù)據(jù)具備、流程具備通知消息：

總結(jié)與展望

該套監(jiān)控平臺(tái)目前承載10個(gè)大型的大數(shù)據(jù)集群、50+個(gè)數(shù)據(jù)庫(kù)、若干中間件及業(yè)務(wù)流程監(jiān)控任務(wù)，平均每秒5W左右監(jiān)控?cái)?shù)據(jù)入庫(kù)。通過對(duì)告警數(shù)據(jù)的精確分析、判斷、預(yù)警，能夠幫助運(yùn)維人員深入了解業(yè)務(wù)集群及其他監(jiān)控對(duì)象的運(yùn)行狀態(tài)，從而及時(shí)規(guī)避或協(xié)助處理嚴(yán)重問題，將隱患扼殺在萌芽之時(shí)。

接下來，筆者計(jì)劃對(duì)監(jiān)控平臺(tái)的智能發(fā)送、存儲(chǔ)周期及高可用性進(jìn)行研究和優(yōu)化，使其更加智能、高效、規(guī)范，并陸續(xù)向其他業(yè)務(wù)體系進(jìn)行推廣，打通與其他業(yè)務(wù)體系的數(shù)據(jù)交互通道，從而全面深度挖掘數(shù)據(jù)的價(jià)值。

我們正在經(jīng)歷一個(gè)數(shù)據(jù)量高速膨脹的時(shí)代，但這些海量的、分散的異構(gòu)數(shù)據(jù)導(dǎo)致了數(shù)據(jù)資源價(jià)值低、應(yīng)用難度大等問題。

如何將海量數(shù)據(jù)充分挖掘與運(yùn)用，來支撐決策、驅(qū)動(dòng)業(yè)務(wù)發(fā)展、進(jìn)行產(chǎn)品創(chuàng)新?如何利用大數(shù)據(jù)平臺(tái)優(yōu)化流程、服務(wù)、產(chǎn)品?可以說，所有的一切都離不開數(shù)據(jù)治理與數(shù)據(jù)資產(chǎn)管理。

本文轉(zhuǎn)載自微信公眾號(hào)「DBAplus社群」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系DBAplus社群公眾號(hào)。