[[335066]]

作者介紹

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

背景

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

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

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

Nagios+Ganglia

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

Zabbix+Ganglia

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2、Yarn隊列獲取

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

范例代碼如下：

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

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

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

故障自愈

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

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

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

故障自愈通知界面如下：

1、自愈通知

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

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

監(jiān)控成效

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

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ù)、總隊列及子隊列資源監(jiān)控等)

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

集群告警通知：

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

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

總結(jié)與展望

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

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

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

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

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