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

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

科普篇幾種常見的監(jiān)控工具選擇

目前常見的監(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)缺點:

Nagios+Ganglia

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

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

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

Zabbix

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

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

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

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

中期，我們在部分集群使用了zabbix，發(fā)現(xiàn)其對于集群層、服務層、角色層及角色實例監(jiān)控項的多維度監(jiān)控開發(fā)管理相對繁瑣，并且如果想要把平臺所有機器及業(yè)務的監(jiān)控和告警集成到zabbix上，對于zabbix的性能將是很大的挑戰(zhàn)。

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

實戰(zhàn)篇平臺搭建、組件選型、監(jiān)控配置的技巧

1采集丶存儲工具的選型

采集器選擇

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

數(shù)據(jù)庫選型

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

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

再修改副本存儲的周期:

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

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

duration:持續(xù)時間，0代表無限制

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

replicaN:全稱是REPLICATION，副本個數(shù)

default:是否是默認策略

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

2 Grafana展示技巧

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

主機監(jiān)控項

主機監(jiān)控項概覽:內(nèi)核、內(nèi)存、負載、磁盤io、網(wǎng)絡、磁盤存儲、inode占用、進程數(shù)、線程數(shù)。

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

主機用途分類

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

主機資源占用top10

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

進程資源占用top10

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

總結(jié):主機層面可監(jiān)控項還有很多，關鍵點在于對癥下藥，把排查故障的運維經(jīng)驗轉(zhuǎn)化為采集數(shù)據(jù)的合理流程，再通過數(shù)據(jù)關聯(lián)來分析排查故障。

平臺監(jiān)控項

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

集群yarn隊列資源占用多維畫像

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

zeeplin操作日志

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

hdfs各目錄文件數(shù)及存儲多維畫像

實時統(tǒng)計各業(yè)務用戶的數(shù)據(jù)目錄存儲，便于分析hdfs存儲增量過大的目錄。

集群namenode RPC 實時多維畫像

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

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

日常生產(chǎn)監(jiān)控項

生產(chǎn)報表

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

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

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。