一篇運維老司機的大資料平臺監控寶典(1)-聯通大資料叢集平臺監控體系程序詳解

系統監控大資料程序 · 發表 2019-04-03 12:33:29

摘要：“如果你是一個經驗豐富的運維開發人員，那麼你一定知道ganglia、nagios、zabbix、elasticsearch、grafana等元件。這些開源元件都有著深厚的發展背景及功能價值，但需要合理搭配選擇，如何配比資源從而達到效能的最優，這裡就體現了運維人的深厚功力。” 下文中，聯通大資料平...

“如果你是一個經驗豐富的運維開發人員，那麼你一定知道ganglia、nagios、zabbix、elasticsearch、grafana等元件。這些開源元件都有著深厚的發展背景及功能價值，但需要合理搭配選擇，如何配比資源從而達到效能的最優，這裡就體現了運維人的深厚功力。”

下文中，聯通大資料平臺維護團隊將對幾種常見監控組合進行介紹，並基於豐富的實戰經驗，對叢集主機及其介面機監控進行系統性總結。

科普篇幾種常見的監控工具選擇

目前常見的監控組合如下:

Nagios+Ganglia

Zabbix

Telegraf or collect + influxdb or Prometheus or elasticsearch + Grafana +alertmanager

Nagios、Ganglia、Zabbix屬於較早期的開源監控工具，而grafana、prometheus則屬於後起之秀。下面，將分別介紹三種監控告警方式的背景及其優缺點:

Nagios+Ganglia

Nagios最早是在1999年以“NetSaint”釋出，主要應用在Linux和Unix平臺環境下的監控告警，能夠監控網路服務、主機資源，具備並行服務檢查機制。

其可自定義shell指令碼進行告警，但隨著大資料平臺承載的服務、資料越來越多之後，nagios便逐漸不能滿足使用場景。例如:其沒有自動發現的功能，需要修改配置檔案;只能在終端進行配置，不方便擴充套件，可讀性比較差;時間控制檯功能弱，外掛易用性差;沒有歷史資料，只能實時報警，出錯後難以追查故障原因。

Ganglia是由UC Berkeley發起的一個開源監控專案，設計用於測量數以千計的節點。Ganglia的核心包含gmond、gmetad以及一個Web前端。主要用來監控系統性能，如:cpu 、mem、硬碟利用率，I/O負載、網路流量情況等，通過曲線很容易見到每個節點的工作狀態，對合理調整、分配系統資源，提高系統整體效能起到重要作用。但隨著服務、業務的多樣化，ganglia覆蓋的監控面有限，且自定義配置監控比較麻煩，展示頁面查詢主機繁瑣、展示影象粗糙不精確是其主要缺點。

Zabbix

Zabbix是近年來興起的監控系統，易於入門，能實現基礎的監控，但是深層次需求需要非常熟悉Zabbix並進行大量的二次定製開發，難度較大;此外，系統級別報警設定相對比較多，如果不篩選的話報警郵件會很多;並且自定義的專案報警需要自己設定，過程比較繁瑣。

jmxtrans or Telegraf or collect + influxdb or Prometheus or elasticsearch + Grafana +alertmanager

這套監控系統的優勢在於資料採集、儲存、監控、展示、告警各取所長。效能、功能可擴充套件性強，且都有活躍的社群支援。缺點在於其功能是鬆耦合的，較為考驗使用者對於使用場景的判斷與運維功力。畢竟，對於運維體系來說，沒有“最好”，只有“最適合”。

早期，聯通大資料平臺通過ganglia與nagios有效結合，發揮ganglia的監控優勢和nagios的告警優勢，做到平臺的各項指標監控。但隨著大資料業務的突增、平臺複雜程度的增加，nagios與ganglia對平臺的監控力度開始稍顯不足，並且開發成本過高。主要體現在配置繁瑣，不易上手;開發監控採集指令碼過於零散，不好統一配置管理，並且nagios沒有歷史資料，只能實時報警，出錯後難以追查故障原因。

中期，我們在部分叢集使用了zabbix，發現其對於叢集層、服務層、角色層及角色例項監控項的多維度監控開發管理相對繁瑣，並且如果想要把平臺所有機器及業務的監控和告警整合到zabbix上，對於zabbix的效能將是很大的挑戰。

於是我們採用以Prometheus+ Grafana+ alertmanager為核心元件的監控告警方式，搭建開發以完成對現有大規模叢集、強複雜業務的有效監控。採用PGA(Prometheus+ Grafana+ alertmanager)監控告警平臺的原因是其在資料採集選型、儲存工具選型、監控頁面配置、告警方式選擇及配置方面更加靈活，使用場景更加廣泛，且功能效能更加全面優秀。

實戰篇平臺搭建、元件選型、監控配置的技巧

1採集丶儲存工具的選型

採集器選擇

常見的採集器有collect、telegraf、jmxtrans(對於暴露jmx埠的服務進行監控)。筆者在經過對比之後選擇了telegraf，主要原因是其比較穩定，並且背後有InfluxData公司支援，社群活躍度不錯，外掛版本更新週期也不會太長。Telegraf是一個用Go語言編寫的代理程式，可採集系統和服務的統計資料，並寫入InfluxDB、prometheus、es等資料庫。Telegraf具有記憶體佔用小的特點，通過外掛系統，開發人員可輕鬆新增支援其他服務的擴充套件。

資料庫選型

對於資料庫選擇，筆者最先使用influxdb，過程中需要注意調整增加influxdb的併發能力，並且控制資料的存放週期。對於上千臺伺服器的叢集監控，如果儲存到influxdb裡，通過grafana介面查詢時，會產生大量的執行緒去讀取influxdb資料，很可能會遇到influxdb讀寫資料大量超時。

遇到這種情況，可以先檢視副本儲存策略:SHOW RETENTION POLICIES ON telegraf

再修改副本儲存的週期:

ALTER RETENTION POLICY "autogen" ON "telegraf" DURATION 72h REPLICATION 1 SHARD DURATION 24h DEFAULT

需理解以下引數:

duration:持續時間，0代表無限制

shardGroupDuration:shardGroup的儲存時間，shardGroup是InfluxDB的一個基本儲存結構，大於這個時間的資料在查詢效率上有所降低。

replicaN:全稱是REPLICATION，副本個數

default:是否是預設策略

但是，由於influxdb開源版對於分散式支援不穩定，單機版的influxdb伺服器對於上千臺的伺服器監控存在效能瓶頸(資料儲存使用的普通sata盤，非ssd)。筆者後來選擇使用es 或 promethaus聯邦來解決(關於es的相關許可權控制、搭建、調優、監控維護，以及promethaus的相關講解將在後續文章具體闡述)。

2 Grafana展示技巧

Grafana是近年來比較受歡迎的一款監控配置展示工具，其優點在於能對接各種主流資料庫，並且能在官網及社群上下載精緻的模板，通過匯入json模板做到快速的展示資料。

主機監控項

主機監控項概覽:核心、記憶體、負載、磁碟io、網路、磁碟儲存、inode佔用、程序數、執行緒數。

主機監控大屏:以一臺主機監控展示為樣例，大家先看下效果圖。

主機用途分類

聯通大資料公司作為專業的大資料服務運營商，後臺支援的主機數量規模龐大，各主機用途大不相同，那麼就需要做好主機分類。用盒子的概念來說，機房是父類盒子，裡面放置叢集計算節點子盒子和介面機子盒子。叢集主機、介面機分離，這樣當一臺主機故障時，方便更快的查詢定位。

主機資源佔用top10

主要從cpu佔用、記憶體佔用、負載、執行緒數多個維度統計同一主機群體(如:A機房介面機是一個主機群體，B機房計算節點是一個主機群體)佔用資源最多的前十臺機器。

程序資源佔用top10

通過主機監控大屏和主機資源佔用top10定位故障主機的故障時間段和異常指標，只能初步的幫助運維人員排查機器故障的原因。例如，當機器負載過高時，在主機監控大屏中往往能看出主機的cpu使用，讀寫io、網路io會發生急速增長，卻不能定位是哪個程序導致。當重啟故障主機之後，又無法排查歷史故障原因。因此對於主機層面監控，增加了程序資源佔用top10，能獲取佔用cpu，記憶體最高的程序資訊(程序開始執行時間、已執行時長、程序pid、cpu使用率、記憶體使用率等有用資訊)。這樣，當主機因為跑了未經測試的程式，或者因執行程式過多，或程式執行緒併發數過多時，就能有效的通過歷史資料定位機器故障原因。

總結:主機層面可監控項還有很多，關鍵點在於對症下藥，把排查故障的運維經驗轉化為採集資料的合理流程，再通過資料關聯來分析排查故障。

平臺監控項

平臺監控項種類繁多，有hdfs、yarn、zookeeper、kafka、storm、spark、hbase等平臺服務。每個服務下有多種角色類別，如hdfs服務中包括Namenode、Datenode、Failover Controller、JournalNode 。每個角色類別下又有多個例項。如此產生的監控指標例項達幾十萬個。目前聯通大資料使用的CDH版本大資料平臺，基礎監控指標全面多樣。根據現狀，平臺層面我們主要配置比較關鍵的一些監控項。

叢集yarn佇列資源佔用多維畫像

幫助平臺管理人員合理評估個佇列資源使用情況，快速做出適當調整。

zeeplin操作日誌

zeepline並沒有相關的視覺化審計日誌，通過實時的獲取zeeplin操作日誌來展現zeeplin操作，方便運維人員審計。

hdfs各目錄檔案數及儲存多維畫像

實時統計各業務使用者的資料目錄儲存，便於分析hdfs儲存增量過大的目錄。

叢集namenode RPC 實時多維畫像

當hadoop叢集節點數達到千臺左右時，叢集業務對於yarn佇列資源使用達到百分之八十以上，且叢集寫多讀少，很容易造成namenode-rpc等待佇列深度過大，造成namenode-rpc延遲，這將會嚴重影響叢集整體業務的執行。半小時能跑完的任務，可能會跑數個小時。根本原因還是叢集承載業務數量過多，並且業務邏輯設計不合理，造成yarn任務執行過程頻繁操作hdfs檔案系統，產生了大量的rpc操作。更底層的，每個dn節點的磁碟負載也會過高，造成資料讀寫io超時。

通過提取namenode日誌、hdfs審計日誌，多維度分析，可通過hdfs目錄和hdfs操作型別兩個方面確認rpc操作過多的業務。並且根據具體是哪種型別的操作過多，來分析業務邏輯是否合理來進行業務優化。例如有某大資料業務的邏輯是每秒往hdfs目錄寫入上千個檔案，並且每秒遍歷下hdfs目錄。但觸發加工是十分鐘觸發一次，因此該業務產生了大量的rpc操作，嚴重影響到叢集效能，後調優至5分鐘遍歷次hdfs目錄，叢集效能得到極大優化。