如果你是一個(gè)經(jīng)驗(yàn)豐富的運(yùn)維開發(fā)人員，那么你一定知道ganglia、nagios、zabbix、elasticsearch、grafana等組件。這些開源組件都有著深厚的發(fā)展背景及功能價(jià)值，但需要合理搭配選擇，如何配比資源從而達(dá)到性能的最優(yōu)，這里就體現(xiàn)了運(yùn)維人的深厚功力。

下文中，聯(lián)通大數(shù)據(jù)平臺(tái)維護(hù)團(tuán)隊(duì)將對(duì)幾種常見監(jiān)控組合進(jìn)行介紹，并基于豐富的實(shí)戰(zhàn)經(jīng)驗(yàn)，對(duì)集群主機(jī)及其接口機(jī)監(jiān)控進(jìn)行系統(tǒng)性總結(jié)。

目前常見的監(jiān)控組合如下：

• Nagios+Ganglia

• Zabbix

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

Nagios、Ganglia、Zabbix屬于較早期的開源監(jiān)控工具，而grafana、prometheus則屬于后起之秀。下面，將分別介紹三種監(jiān)控告警方式的背景及其優(yōu)缺點(diǎn)：

Nagios最早是在1999年以“NetSaint”發(fā)布，主要應(yīng)用在Linux和Unix平臺(tái)環(huán)境下的監(jiān)控告警，能夠監(jiān)控網(wǎng)絡(luò)服務(wù)、主機(jī)資源，具備并行服務(wù)檢查機(jī)制。

其可自定義shell腳本進(jìn)行告警，但隨著大數(shù)據(jù)平臺(tái)承載的服務(wù)、數(shù)據(jù)越來越多之后，nagios便逐漸不能滿足使用場(chǎng)景。例如：其沒有自動(dòng)發(fā)現(xiàn)的功能，需要修改配置文件；只能在終端進(jìn)行配置，不方便擴(kuò)展，可讀性比較差；時(shí)間控制臺(tái)功能弱，插件易用性差；沒有歷史數(shù)據(jù)，只能實(shí)時(shí)報(bào)警，出錯(cuò)后難以追查故障原因。

Ganglia是由UC Berkeley發(fā)起的一個(gè)開源監(jiān)控項(xiàng)目，設(shè)計(jì)用于測(cè)量數(shù)以千計(jì)的節(jié)點(diǎn)。Ganglia的核心包含gmond、gmetad以及一個(gè)Web前端。主要用來監(jiān)控系統(tǒng)性能，如：cpu 、mem、硬盤利用率，I/O負(fù)載、網(wǎng)絡(luò)流量情況等，通過曲線很容易見到每個(gè)節(jié)點(diǎn)的工作狀態(tài)，對(duì)合理調(diào)整、分配系統(tǒng)資源，提高系統(tǒng)整體性能起到重要作用。但隨著服務(wù)、業(yè)務(wù)的多樣化，ganglia覆蓋的監(jiān)控面有限，且自定義配置監(jiān)控比較麻煩，展示頁面查找主機(jī)繁瑣、展示圖像粗糙不精確是其主要缺點(diǎn)。

Zabbix是近年來興起的監(jiān)控系統(tǒng)，易于入門，能實(shí)現(xiàn)基礎(chǔ)的監(jiān)控，但是深層次需求需要非常熟悉Zabbix并進(jìn)行大量的二次定制開發(fā)，難度較大；此外，系統(tǒng)級(jí)別報(bào)警設(shè)置相對(duì)比較多，如果不篩選的話報(bào)警郵件會(huì)很多；并且自定義的項(xiàng)目報(bào)警需要自己設(shè)置，過程比較繁瑣。

這套監(jiān)控系統(tǒng)的優(yōu)勢(shì)在于數(shù)據(jù)采集、存儲(chǔ)、監(jiān)控、展示、告警各取所長(zhǎng)。性能、功能可擴(kuò)展性強(qiáng)，且都有活躍的社區(qū)支持。缺點(diǎn)在于其功能是松耦合的，較為考驗(yàn)使用者對(duì)于使用場(chǎng)景的判斷與運(yùn)維功力。畢竟，對(duì)于運(yùn)維體系來說，沒有“最好”，只有“最適合”。

早期，聯(lián)通大數(shù)據(jù)平臺(tái)通過ganglia與nagios有效結(jié)合，發(fā)揮ganglia的監(jiān)控優(yōu)勢(shì)和nagios的告警優(yōu)勢(shì)，做到平臺(tái)的各項(xiàng)指標(biāo)監(jiān)控。但隨著大數(shù)據(jù)業(yè)務(wù)的突增、平臺(tái)復(fù)雜程度的增加，nagios與ganglia對(duì)平臺(tái)的監(jiān)控力度開始稍顯不足，并且開發(fā)成本過高。主要體現(xiàn)在配置繁瑣，不易上手；開發(fā)監(jiān)控采集腳本過于零散，不好統(tǒng)一配置管理，并且nagios沒有歷史數(shù)據(jù)，只能實(shí)時(shí)報(bào)警，出錯(cuò)后難以追查故障原因。

中期，我們?cè)诓糠旨菏褂昧藌abbix，發(fā)現(xiàn)其對(duì)于集群層、服務(wù)層、角色層及角色實(shí)例監(jiān)控項(xiàng)的多維度監(jiān)控開發(fā)管理相對(duì)繁瑣，并且如果想要把平臺(tái)所有機(jī)器及業(yè)務(wù)的監(jiān)控和告警集成到zabbix上，對(duì)于zabbix的性能將是很大的挑戰(zhàn)。

于是我們采用以Prometheus+ Grafana+ alertmanager為核心組件的監(jiān)控告警方式，搭建開發(fā)以完成對(duì)現(xiàn)有大規(guī)模集群、強(qiáng)復(fù)雜業(yè)務(wù)的有效監(jiān)控。采用PGA（Prometheus+ Grafana+ alertmanager）監(jiān)控告警平臺(tái)的原因是其在數(shù)據(jù)采集選型、存儲(chǔ)工具選型、監(jiān)控頁面配置、告警方式選擇及配置方面更加靈活，使用場(chǎng)景更加廣泛，且功能性能更加全面優(yōu)秀。

常見的采集器有collect、telegraf、jmxtrans（對(duì)于暴露jmx端口的服務(wù)進(jìn)行監(jiān)控）。筆者在經(jīng)過對(duì)比之后選擇了telegraf，主要原因是其比較穩(wěn)定，并且背后有InfluxData公司支持，社區(qū)活躍度不錯(cuò)，插件版本更新周期也不會(huì)太長(zhǎng)。Telegraf是一個(gè)用Go語言編寫的代理程序，可采集系統(tǒng)和服務(wù)的統(tǒng)計(jì)數(shù)據(jù)，并寫入InfluxDB、prometheus、es等數(shù)據(jù)庫。Telegraf具有內(nèi)存占用小的特點(diǎn)，通過插件系統(tǒng)，開發(fā)人員可輕松添加支持其他服務(wù)的擴(kuò)展。

對(duì)于數(shù)據(jù)庫選擇，筆者最先使用influxdb，過程中需要注意調(diào)整增加influxdb的并發(fā)能力，并且控制數(shù)據(jù)的存放周期。對(duì)于上千臺(tái)服務(wù)器的集群監(jiān)控，如果存儲(chǔ)到influxdb里，通過grafana界面查詢時(shí)，會(huì)產(chǎn)生大量的線程去讀取influxdb數(shù)據(jù)，很可能會(huì)遇到influxdb讀寫數(shù)據(jù)大量超時(shí)

遇到這種情況，可以先查看副本存儲(chǔ)策略：SHOW RETENTION POLICIES ON telegraf

再修改副本存儲(chǔ)的周期：

需理解以下參數(shù)：

• duration：持續(xù)時(shí)間，0代表無限制

• shardGroupDuration：shardGroup的存儲(chǔ)時(shí)間，shardGroup是InfluxDB的一個(gè)基本儲(chǔ)存結(jié)構(gòu)，大于這個(gè)時(shí)間的數(shù)據(jù)在查詢效率上有所降低。

• replicaN：全稱是REPLICATION，副本個(gè)數(shù)

• default：是否是默認(rèn)策略

但是，由于influxdb開源版對(duì)于分布式支持不穩(wěn)定，單機(jī)版的influxdb服務(wù)器對(duì)于上千臺(tái)的服務(wù)器監(jiān)控存在性能瓶頸（數(shù)據(jù)存儲(chǔ)使用的普通sata盤，非ssd）。筆者后來選擇使用es 或 promethaus聯(lián)邦來解決（關(guān)于es的相關(guān)權(quán)限控制、搭建、調(diào)優(yōu)、監(jiān)控維護(hù)，以及promethaus的相關(guān)講解將在后續(xù)文章具體闡述）。

Grafana是近年來比較受歡迎的一款監(jiān)控配置展示工具，其優(yōu)點(diǎn)在于能對(duì)接各種主流數(shù)據(jù)庫，并且能在官網(wǎng)及社區(qū)上下載精致的模板，通過導(dǎo)入json模板做到快速的展示數(shù)據(jù)。

• 主機(jī)監(jiān)控項(xiàng)概覽：內(nèi)核、內(nèi)存、負(fù)載、磁盤io、網(wǎng)絡(luò)、磁盤存儲(chǔ)、inode占用、進(jìn)程數(shù)、線程數(shù)。

• 主機(jī)監(jiān)控大屏：以一臺(tái)主機(jī)監(jiān)控展示為樣例，大家先看下效果圖。

• 主機(jī)用途分類

聯(lián)通大數(shù)據(jù)公司作為專業(yè)的大數(shù)據(jù)服務(wù)運(yùn)營商，后臺(tái)支持的主機(jī)數(shù)量規(guī)模龐大，各主機(jī)用途大不相同，那么就需要做好主機(jī)分類。用盒子的概念來說，機(jī)房是父類盒子，里面放置集群計(jì)算節(jié)點(diǎn)子盒子和接口機(jī)子盒子。集群主機(jī)、接口機(jī)分離，這樣當(dāng)一臺(tái)主機(jī)故障時(shí)，方便更快的查找定位。

• 主機(jī)資源占用 top 10

主要從cpu占用、內(nèi)存占用、負(fù)載、線程數(shù)多個(gè)維度統(tǒng)計(jì)同一主機(jī)群體（如：A機(jī)房接口機(jī)是一個(gè)主機(jī)群體，B機(jī)房計(jì)算節(jié)點(diǎn)是一個(gè)主機(jī)群體）占用資源最多的前十臺(tái)機(jī)器。

• 進(jìn)程資源占用 top 10

通過主機(jī)監(jiān)控大屏和主機(jī)資源占用top10定位故障主機(jī)的故障時(shí)間段和異常指標(biāo)，只能初步的幫助運(yùn)維人員排查機(jī)器故障的原因。例如，當(dāng)機(jī)器負(fù)載過高時(shí)，在主機(jī)監(jiān)控大屏中往往能看出主機(jī)的cpu使用，讀寫io、網(wǎng)絡(luò)io會(huì)發(fā)生急速增長(zhǎng)，卻不能定位是哪個(gè)進(jìn)程導(dǎo)致。當(dāng)重啟故障主機(jī)之后，又無法排查歷史故障原因。因此對(duì)于主機(jī)層面監(jiān)控，增加了進(jìn)程資源占用top10，能獲取占用cpu，內(nèi)存最高的進(jìn)程信息（進(jìn)程開始運(yùn)行時(shí)間、已運(yùn)行時(shí)長(zhǎng)、進(jìn)程pid、cpu使用率、內(nèi)存使用率等有用信息）。這樣，當(dāng)主機(jī)因?yàn)榕芰宋唇?jīng)測(cè)試的程序，或者因運(yùn)行程序過多，或程序線程并發(fā)數(shù)過多時(shí)，就能有效的通過歷史數(shù)據(jù)定位機(jī)器故障原因。

平臺(tái)監(jiān)控項(xiàng)種類繁多，有hdfs、yarn、zookeeper、kafka、storm、spark、hbase等平臺(tái)服務(wù)。每個(gè)服務(wù)下有多種角色類別，如hdfs服務(wù)中包括Namenode、Datenode、Failover Controller、JournalNode 。每個(gè)角色類別下又有多個(gè)實(shí)例。如此產(chǎn)生的監(jiān)控指標(biāo)實(shí)例達(dá)幾十萬個(gè)。目前聯(lián)通大數(shù)據(jù)使用的CDH版本大數(shù)據(jù)平臺(tái)，基礎(chǔ)監(jiān)控指標(biāo)全面多樣。根據(jù)現(xiàn)狀，平臺(tái)層面我們主要配置比較關(guān)鍵的一些監(jiān)控項(xiàng)。

• 集群yarn隊(duì)列資源占用多維畫像

幫助平臺(tái)管理人員合理評(píng)估個(gè)隊(duì)列資源使用情況，快速做出適當(dāng)調(diào)整。

• zeeplin操作日志

zeepline并沒有相關(guān)的可視化審計(jì)日志，通過實(shí)時(shí)的獲取zeeplin操作日志來展現(xiàn)zeeplin操作，方便運(yùn)維人員審計(jì)。

hdfs各目錄文件數(shù)及存儲(chǔ)多維畫像實(shí)時(shí)統(tǒng)計(jì)各業(yè)務(wù)用戶的數(shù)據(jù)目錄存儲(chǔ)，便于分析hdfs存儲(chǔ)增量過大的目錄。

• 集群namenode RPC 實(shí)時(shí)多維畫像

當(dāng)hadoop集群節(jié)點(diǎn)數(shù)達(dá)到千臺(tái)左右時(shí)，集群業(yè)務(wù)對(duì)于yarn隊(duì)列資源使用達(dá)到百分之八十以上，且集群寫多讀少，很容易造成namenode-rpc等待隊(duì)列深度過大，造成namenode-rpc延遲，這將會(huì)嚴(yán)重影響集群整體業(yè)務(wù)的運(yùn)行。半小時(shí)能跑完的任務(wù)，可能會(huì)跑數(shù)個(gè)小時(shí)。根本原因還是集群承載業(yè)務(wù)數(shù)量過多，并且業(yè)務(wù)邏輯設(shè)計(jì)不合理，造成yarn任務(wù)執(zhí)行過程頻繁操作hdfs文件系統(tǒng)，產(chǎn)生了大量的rpc操作。更底層的，每個(gè)dn節(jié)點(diǎn)的磁盤負(fù)載也會(huì)過高，造成數(shù)據(jù)讀寫io超時(shí)。

通過提取namenode日志、hdfs審計(jì)日志，多維度分析，可通過hdfs目錄和hdfs操作類型兩個(gè)方面確認(rèn)rpc操作過多的業(yè)務(wù)。并且根據(jù)具體是哪種類型的操作過多，來分析業(yè)務(wù)邏輯是否合理來進(jìn)行業(yè)務(wù)優(yōu)化。例如有某大數(shù)據(jù)業(yè)務(wù)的邏輯是每秒往hdfs目錄寫入上千個(gè)文件，并且每秒遍歷下hdfs目錄。但觸發(fā)加工是十分鐘觸發(fā)一次，因此該業(yè)務(wù)產(chǎn)生了大量的rpc操作，嚴(yán)重影響到集群性能，后調(diào)優(yōu)至5分鐘遍歷次hdfs目錄，集群性能得到極大優(yōu)化。

• 生產(chǎn)報(bào)表

由于聯(lián)通大數(shù)據(jù)平臺(tái)承載業(yè)務(wù)體量很大，通過后臺(tái)查詢繁瑣，而通過可視化展示能方便生產(chǎn)運(yùn)維人員快速了解日生產(chǎn)情況，定位生產(chǎn)延遲原因。

結(jié)語：關(guān)于平臺(tái)監(jiān)控的內(nèi)容在本文中就先介紹到這里，在下一篇中，筆者將針對(duì)平臺(tái)告警做出經(jīng)驗(yàn)分享，介紹如何建立統(tǒng)一采集模板、告警各集群的全量監(jiān)控指標(biāo)、進(jìn)行分組告警并自動(dòng)化恢復(fù)等內(nèi)容。