[[335066]]

作者介紹

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

背景

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

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

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

Nagios+Ganglia

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

Zabbix+Ganglia

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

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

鑒于以上兩種組合存在的缺點，根據(jù)實際工作需要，筆者對監(jiān)控平臺的選型進行了優(yōu)化，選擇了Prometheus+Alertmanager+Grafana的組合。之所以選擇該組合作為平臺核心，是因為其具有以下幾點優(yōu)勢：

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

Prometheus+Alertmanager+Grafana平臺架構如下圖所示：

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

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

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

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

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

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

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

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

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

2、Yarn隊列獲取

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

范例代碼如下：

實時消息發(fā)送

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

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

故障自愈

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

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

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

故障自愈通知界面如下：

1、自愈通知

2、可ping通無法ssh主機通知：

3、無法ping通主機通知：

監(jiān)控成效

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

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

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

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

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

集群告警通知：

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

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

總結與展望

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

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

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

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

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