本文由 dbaplus 社羣授權轉載。
背景
隨着公司業務發展，大數據集羣規模正在不斷擴大，一些大型集羣物理機節點甚至已近上千。面對如此規模龐大的集羣，一套優秀的監控系統是運維人員發現及處理故障的關鍵利器。經過多次選型和迭代，筆者選擇了Prometheus，這款時下火熱而強大的開源監控組件爲核心來構建大數據集羣監控平臺。
最初的監控平臺選型
公司最初採用的監控平臺爲Nagios+Ganglia或Zabbix+Grafana組合，但經過上線後長時間實踐驗證，發現這兩個組合存在如下不盡人意之處：
Nagios+Ganglia
該搭配的主要問題在於Nagios只能對主機性能指標進行常規監控，在對大數據集羣各組件進行監控時，則需要進行大量的自定義開發工作，且對集羣的監控維度並不全面。而且由於Nagiso沒有存儲歷史數據的功能，在面對一些集羣性能分析或故障分析工作時，Nagios+Ganglia的搭配效果並不能達到運維人員的預期。
Zabbix+Ganglia
相比於前者，該搭配優點在於可以完成監控數據可視化的工作，在集羣性能分析和故障分析方面能夠實現運維人員的各類需求，且對外提供web管理頁面，能夠簡化上手難度。雖然如此，該搭配還是存在一些問題，例如當集羣達到一定數量規模時，監控存儲數據庫就會成爲性能瓶頸，面對大規模的數據讀寫會捉襟見肘，導致Grafana查詢緩慢甚至卡死。
監控平臺選型優化
鑑於以上兩種組合存在的缺點，根據實際工作需要，筆者對監控平臺的選型進行了優化， 選擇了Prometheus+Alertmanager+Grafana的組合 。之所以選擇該組合作爲平臺核心，是因爲其具有以下幾點優勢：
- 內置優秀的TSDB數據庫，可以輕鬆應對大數據量併發查詢，爲運維人員提供關鍵指標；
- 強大的Promql，可以通過各類內置函數，獲取各維度搜索監控數據用於Grafana出圖；
- Prometheus基於Go語言開發，Go高效的運行效率，使其擁有天生的速度優勢；
- 活躍的Github社區，提供豐富的Client庫。
Prometheus+Alertmanager+Grafana平臺架構如下圖所示：
從圖中可以看出，該套平臺以Prometheus爲核心，可實現對監控實例（如大數據組件、數據庫、主機、中間件等，餘者不再贅述）進行數據採集、分析計算、聚合抑制、智能發送、故障自愈等多種功能。並具有以下幾個特點：
- 對於Prometheus官方或Github社區已有的Exporter庫，如Telegraf及Mysql_exporter等，可以直接進行相關配置開箱即用，不必重複造輪子；
- 對於大數據生態組件如Hadoop、Yarn、HBase等，筆者並沒有採用官方的Jmx_exporter，因爲一些特殊監控項並不能通過該組件採集到。而是自研一套Exporter針對各項組件進行監控，通過筆者自研的Exporter，可以實現各類RPC操作負載，RPC打開連接數、HDFS空間及文件數監控，Yarn總隊列及子隊列性能監控，Yarn job作業性能監控，HBase壓縮及刷新隊列性能監控等功能（詳情見下文）；
- 對於一些流程調度或數據具備、日週報等實時消息，可以引入該平臺，進行通知消息實時發送（只通知不需要恢復）；
- 故障自愈也是該平臺的一個重要特點，對於大數據平臺的常見故障如Datanode、Nodemager、Regionserver離線、硬盤故障、時鐘異常等，都可以進行自動恢復（詳情見下文）。
監控平臺功能實現
適配大數據生態組件監控
Prometheus性能雖然十分強大，但是適配大數據生態組件的監控卻不是一件容易的事情。當下流行的搭配是用Jmx_exporter來採集各組件的監控數據供Prometheus拉取。這種搭配雖然可以滿足開箱即用的原則，但是當運維人員關注一些組件特有的監控項時，因爲Jmx_exporter沒有收集相關監控項，就會捉襟見肘。
但通過筆者自研的Exporter定時採集組件Jmx或CDH版本的特定API的方式來獲取監控數據，經過轉換處理形成Metrics供Prometheus獲取，則可以很好地解決上述問題。下面選取幾個具有代表性的實例進行介紹：
1、Namenode RPC打開連接數
在排查Namenode RPC延遲的問題時，一定程度上，可以通過查看RPC打開連接數觀察Namenode的工作負載情況。namenode監控數據可通過Url地址http://localhost:50070/jmx?qry=Hadoop:service=NameNode,name=RpcActivityForPort8020查詢。
訪問該url數據後，通過一系列的轉換，可以返回我們需要的格式化數據，如以下代碼所示：
2、Yarn隊列獲取
當處理多租戶Yarn集羣資源爭搶問題的時候，運維人員最需要的就是獲取Yarn各隊列的資源使用情況。對此，首先要做的就是獲取yarn隊列列表，可以通過下面的Url來獲取，http://localhost:8088/ws/v1/cluster/scheduler
範例代碼如下：
實時消息發送
在生產環境中，有一些消息通知需要即時或定時發送到相關人員釘釘上，如果用Prometheus當做告警觸發來完成，會導致這些消息通知一遍又一遍地發送到釘釘上，但事實上這些消息並不同於告警，只發送一次即可。面對這一問題，其實可以通過調用釘釘機器人Webhook發送即時消息進行解決，如以下一則實例：
筆者管理的某個多租戶HDFS集羣存儲資源比較緊張，每個租戶都有自己的單獨目錄，事先已針對這些目錄進行了實時數據量及文件數使用統計，統計數據保存到Prometheus裏。每天早上通過Prometheus的API來獲取當日8時及前一日8時所有租戶目錄使用情況，並進行對比。當增量超過設定閾值時，就會發送一條實時消息到釘釘上，提醒對應租戶管理數據。消息界面如下圖所示：
故障自愈
當大數據集羣總規模達到上千臺時，對於一些常見故障如計算存儲節點硬件故障導致離線、數據硬盤故障、NTP時鐘異常等，如果人肉手動處理，將會耗費大量時間和精力。但筆者目前使用的自愈系統則可以自動解決大部分常見故障。該自愈系統邏輯如下圖所示：
該自愈系統具有以下特點：
- 故障修復前自動檢測主機聯通性，對於異常主機可以直接轉交主機側同事處理；
- 各類通知智能發送，對於連接異常類消息，夜間（00:00-06:00）只發送一次，避免夜間無意義打擾；
- 沉澱各種常見故障修復過程，使故障修復更加精準智能；
- 監控自愈程序，如程序異常退出或修復過程中發生異常，可及時告知運維人員進行手動修復。
故障自愈通知界面如下：
1、自愈通知
2、可ping通無法ssh主機通知：
3、無法ping通主機通知：
監控成效
爲了更加直觀地實時查看監控平臺各監控項情況，筆者引入了集羣監控大屏進行可視化效果展示，動態展現數據變化，直觀體現數據價值，大屏展示效果如下圖所示：
除此之外，監控集羣各組件的健康狀態，如有異常，也會通過釘釘消息告知運維人員，如下圖所示：
集羣告警通知：
多租戶集羣不可避免的就是租戶計算資源搶佔問題，當單個Job作業資源佔用過大時，告警通知如下：
上文提到的數據具備、流程具備通知消息：
總結與展望
該套監控平臺目前承載10個大型的大數據集羣、50+個數據庫、若干中間件及業務流程監控任務，平均每秒5W左右監控數據入庫。通過對告警數據的精確分析、判斷、預警，能夠幫助運維人員深入瞭解業務集羣及其他監控對象的運行狀態，從而及時規避或協助處理嚴重問題，將隱患扼殺在萌芽之時。
接下來，筆者計劃對監控平臺的智能發送、存儲週期及高可用性進行研究和優化，使其更加智能、高效、規範，並陸續向其他業務體系進行推廣，打通與其他業務體系的數據交互通道，從而全面深度挖掘數據的價值。
作者介紹：
洪迪，聯通大數據高級運維開發工程師，主要負責大數據平臺運維管理及核心監控平臺開發工作。具有多年大數據集羣規劃建設、性能調優及監控體系建設經驗，對Prometheus架構設計、運維開發等方面有深入理解和實踐。
原文鏈接：