如果你是一個經(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ù)平臺維護(hù)團(tuán)隊(duì)將對幾種常見監(jiān)控組合進(jìn)行介紹，并基于豐富的實(shí)戰(zhàn)經(jīng)驗(yàn)，對集群主機(jī)及其接口機(jī)監(jiān)控進(jì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)缺點(diǎn)：
1. Nagios+Ganglia
Nagios最早是在1999年以“NetSaint”發(fā)布，主要應(yīng)用在Linux和Unix平臺環(huán)境下的監(jiān)控告警，能夠監(jiān)控網(wǎng)絡(luò)服務(wù)、主機(jī)資源，具備并行服務(wù)檢查機(jī)制。
其可自定義shell腳本進(jìn)行告警，但隨著大數(shù)據(jù)平臺承載的服務(wù)、數(shù)據(jù)越來越多之后，nagios便逐漸不能滿足使用場景。例如：其沒有自動發(fā)現(xiàn)的功能，需要修改配置文件;只能在終端進(jìn)行配置，不方便擴(kuò)展，可讀性比較差;時間控制臺功能弱，插件易用性差;沒有歷史數(shù)據(jù)，只能實(shí)時報(bào)警，出錯后難以追查故障原因。
Ganglia是由UC Berkeley發(fā)起的一個開源監(jiān)控項(xiàng)目，設(shè)計(jì)用于測量數(shù)以千計(jì)的節(jié)點(diǎn)。Ganglia的核心包含gmond、gmetad以及一個Web前端。主要用來監(jiān)控系統(tǒng)性能，如：cpu 、mem、硬盤利用率，I/O負(fù)載、網(wǎng)絡(luò)流量情況等，通過曲線很容易見到每個節(jié)點(diǎn)的工作狀態(tài)，對合理調(diào)整、分配系統(tǒng)資源，提高系統(tǒng)整體性能起到重要作用。但隨著服務(wù)、業(yè)務(wù)的多樣化，ganglia覆蓋的監(jiān)控面有限，且自定義配置監(jiān)控比較麻煩，展示頁面查找主機(jī)繁瑣、展示圖像粗糙不精確是其主要缺點(diǎn)。
2. Zabbix
Zabbix是近年來興起的監(jiān)控系統(tǒng)，易于入門，能實(shí)現(xiàn)基礎(chǔ)的監(jiān)控，但是深層次需求需要非常熟悉Zabbix并進(jìn)行大量的二次定制開發(fā)，難度較大;此外，系統(tǒng)級別報(bào)警設(shè)置相對比較多，如果不篩選的話報(bào)警郵件會很多;并且自定義的項(xiàng)目報(bào)警需要自己設(shè)置，VPS租用，過程比較繁瑣。
3. jmxtrans or Telegraf or collect + influxdb or Prometheus or elasticsearch + Grafana +alertmanager
這套監(jiān)控系統(tǒng)的優(yōu)勢在于數(shù)據(jù)采集、存儲、監(jiān)控、展示、告警各取所長。性能、功能可擴(kuò)展性強(qiáng)，且都有活躍的社區(qū)支持。缺點(diǎn)在于其功能是松耦合的，較為考驗(yàn)使用者對于使用場景的判斷與運(yùn)維功力。畢竟，對于運(yùn)維體系來說，沒有“最好”，只有“最適合”。
早期，聯(lián)通大數(shù)據(jù)平臺通過ganglia與nagios有效結(jié)合，發(fā)揮ganglia的監(jiān)控優(yōu)勢和nagios的告警優(yōu)勢，做到平臺的各項(xiàng)指標(biāo)監(jiān)控。但隨著大數(shù)據(jù)業(yè)務(wù)的突增、平臺復(fù)雜程度的增加，nagios與ganglia對平臺的監(jiān)控力度開始稍顯不足，并且開發(fā)成本過高。主要體現(xiàn)在配置繁瑣，不易上手;開發(fā)監(jiān)控采集腳本過于零散，不好統(tǒng)一配置管理，并且nagios沒有歷史數(shù)據(jù)，只能實(shí)時報(bào)警，出錯后難以追查故障原因。
中期，我們在部分集群使用了zabbix，發(fā)現(xiàn)其對于集群層、服務(wù)層、角色層及角色實(shí)例監(jiān)控項(xiàng)的多維度監(jiān)控開發(fā)管理相對繁瑣，并且如果想要把平臺所有機(jī)器及業(yè)務(wù)的監(jiān)控和告警集成到zabbix上，對于zabbix的性能將是很大的挑戰(zhàn)。
于是我們采用以Prometheus+ Grafana+ alertmanager為核心組件的監(jiān)控告警方式，搭建開發(fā)以完成對現(xiàn)有大規(guī)模集群、強(qiáng)復(fù)雜業(yè)務(wù)的有效監(jiān)控。采用PGA(Prometheus+ Grafana+ alertmanager)監(jiān)控告警平臺的原因是其在數(shù)據(jù)采集選型、存儲工具選型、監(jiān)控頁面配置、告警方式選擇及配置方面更加靈活，使用場景更加廣泛，且功能性能更加全面優(yōu)秀。
二、實(shí)戰(zhàn)篇：平臺搭建、組件選型、監(jiān)控配置的技巧
1. 采集、存儲工具的選型
(1) 采集器選擇
常見的采集器有collect、telegraf、jmxtrans(對于暴露jmx端口的服務(wù)進(jìn)行監(jiān)控)。筆者在經(jīng)過對比之后選擇了telegraf，主要原因是其比較穩(wěn)定，并且背后有InfluxData公司支持，社區(qū)活躍度不錯，插件版本更新周期也不會太長。Telegraf是一個用Go語言編寫的代理程序，可采集系統(tǒng)和服務(wù)的統(tǒng)計(jì)數(shù)據(jù)，并寫入InfluxDB、prometheus、es等數(shù)據(jù)庫。Telegraf具有內(nèi)存占用小的特點(diǎn)，通過插件系統(tǒng)，開發(fā)人員可輕松添加支持其他服務(wù)的擴(kuò)展。
(2) 數(shù)據(jù)庫選型
對于數(shù)據(jù)庫選擇，筆者最先使用influxdb，過程中需要注意調(diào)整增加influxdb的并發(fā)能力，并且控制數(shù)據(jù)的存放周期。對于上千臺服務(wù)器的集群監(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ù)：
