一篇運(yùn)維老司機(jī)的大數(shù)據(jù)平臺(tái)監(jiān)控寶典(2)-聯(lián)通大數(shù)據(jù)集群平臺(tái)監(jiān)控體系詳解
在上一篇文章【一篇運(yùn)維老司機(jī)的大數(shù)據(jù)平臺(tái)監(jiān)控寶典(1)】中,我們介紹了目前聯(lián)通大數(shù)據(jù)監(jiān)控平臺(tái)由Grafana+Influxdb+Prometheus+Alertmanager等組件組成,并且著重詳述了以Grafana為核心的圖形化展示功能。
本文繼續(xù)針對(duì)運(yùn)維監(jiān)控體系的另一重要內(nèi)容,即告警分析、處理及發(fā)送功能進(jìn)行分享。
一、為什么要選擇Prometheus+Alertmanager
你的監(jiān)控系統(tǒng)是否曾面臨這些痛點(diǎn):
- 告警信息推送無(wú)法分類(lèi),無(wú)法針對(duì)某部分人進(jìn)行特定告警
- 重復(fù)告警或無(wú)用告警過(guò)多,重要告警易被埋沒(méi)
- 監(jiān)控系統(tǒng)無(wú)法提供可視化展示,或僅能部分展示
- 監(jiān)控歷史數(shù)據(jù)不能二次查詢(xún)或多維度查詢(xún),故障排查缺少依據(jù)
對(duì)于業(yè)務(wù)量、平臺(tái)主機(jī)量級(jí)較大的公司來(lái)說(shuō),使用以nagios+ganglia為首的傳統(tǒng)的監(jiān)控平臺(tái)往往會(huì)遇到以上情況,顯得力不從心。經(jīng)過(guò)大量、豐富的實(shí)戰(zhàn)工作后,我們***選擇Prometheus+Alertmanager+釘釘?shù)拇钆渥鳛槁?lián)通大數(shù)據(jù)監(jiān)控平臺(tái)的告警分析、處理及發(fā)送工具組合。這套組合不僅能夠針對(duì)以上痛點(diǎn)一一解決,也可以說(shuō)是運(yùn)維人員保障集群平臺(tái)穩(wěn)定運(yùn)行、故障排查、問(wèn)題定位的一把利器。
在下面的章節(jié)中,筆者會(huì)對(duì)系統(tǒng)中的Prometheus、Alertmanager等組件逐一進(jìn)行介紹。
二、Prometheus-數(shù)據(jù)存儲(chǔ)及分析
1. Prometheus簡(jiǎn)介
基于上圖,大家可以清晰的看到,Prometheus實(shí)際上是一個(gè)tsdb型數(shù)據(jù)庫(kù),所有的采集數(shù)據(jù)以metric的形式保存在其中,且能夠?qū)?shù)據(jù)落到本地磁盤(pán)中,供使用人員二次查詢(xún)數(shù)據(jù)。
Prometheus同時(shí)附加了強(qiáng)大的計(jì)算與分析功能,能夠利用各種labels與promql語(yǔ)句來(lái)完成多維度的監(jiān)控?cái)?shù)據(jù)查詢(xún),從而為故障排查與問(wèn)題定位提供可靠的證據(jù)。
監(jiān)控規(guī)則方面,Prometheus可以根據(jù)promql來(lái)獲取數(shù)據(jù),并且與固定閾值進(jìn)行計(jì)算比較,若超出正常范圍,則標(biāo)記為告警信息,并且可以分組分標(biāo)簽定義告警描述,供后續(xù)Alertmanager使用。
在拓展性方面,Prometheus可以輕松的完成服務(wù)發(fā)現(xiàn)功能,并擁有每秒上萬(wàn)數(shù)據(jù)點(diǎn)的監(jiān)控?cái)?shù)據(jù)收集與分析的處理能力,完全擺脫了傳統(tǒng)監(jiān)控系統(tǒng)對(duì)監(jiān)控主機(jī)數(shù)量的要求。目前聯(lián)通大數(shù)據(jù)平臺(tái)機(jī)器幾千余臺(tái),監(jiān)控實(shí)例過(guò)十萬(wàn),監(jiān)控實(shí)例指標(biāo)過(guò)千萬(wàn),Prometheus優(yōu)良的性能可以做到***支撐。
2. Prometheus特點(diǎn)
(1) 監(jiān)控?cái)?shù)據(jù)存儲(chǔ)功能及多維度查詢(xún)
下圖中以一個(gè)簡(jiǎn)單例子說(shuō)明:該條查詢(xún)可以看到某集群接口機(jī)15分鐘內(nèi)的系統(tǒng)負(fù)載,涉及到的標(biāo)簽維度為集群、主機(jī)IP、主機(jī)類(lèi)型等。在實(shí)際線(xiàn)上環(huán)境中,還可以添加多個(gè)標(biāo)簽來(lái)完成查詢(xún),并且可以利用promql特有的查詢(xún)語(yǔ)句(sum、count_values、topk等)來(lái)完成更加豐富的多維度查詢(xún),提供可靠、便捷、直觀的監(jiān)控?cái)?shù)據(jù)供運(yùn)維人員使用。
(2) 優(yōu)秀的自定義及第三方監(jiān)控拓展功能
Pushgateway是Prometheus環(huán)境中的一個(gè)data_collector。把它定義為采集者的原因很簡(jiǎn)單,標(biāo)準(zhǔn)的Prometheus會(huì)采用pull模式從target中獲取監(jiān)控?cái)?shù)據(jù),但當(dāng)由于外力原因(如網(wǎng)絡(luò)、硬件等)無(wú)法直接從target中拉取數(shù)據(jù)時(shí),就要依靠Pushgateway了,請(qǐng)看下圖:
大致流程為client上部署的腳本(支持多語(yǔ)言shell、python等)會(huì)收集target中的數(shù)據(jù),并且以metric形式傳送到Pushgateway中,只要保證client和Pushgateway能夠正常通信即可。Prometheus會(huì)按照配置時(shí)間,定時(shí)到Pushgateway上拉取監(jiān)控?cái)?shù)據(jù),從而達(dá)到收集target的目的。
下圖為Pushgetway發(fā)送數(shù)據(jù)的代碼過(guò)程:
那么是否可以這么理解:對(duì)于常見(jiàn)組件(redis、mysql、nginx、haproxy等),我們可以依靠現(xiàn)有的豐富client庫(kù),直接進(jìn)行監(jiān)控納管;對(duì)于一些特殊組件或自定義業(yè)務(wù),可通過(guò)多語(yǔ)言腳本采集監(jiān)控?cái)?shù)據(jù)或業(yè)務(wù)埋點(diǎn)方式,把Pushgateway作為一個(gè)data_collector來(lái)收集各方數(shù)據(jù),從而完成監(jiān)控納管。
(3) 良好的監(jiān)控生態(tài)圈之常見(jiàn)client庫(kù)
由于近年P(guān)rometheus的興起,開(kāi)源社區(qū)中越來(lái)越多的人將自己的代碼貢獻(xiàn)出來(lái),使得Prometheus擁有龐大的client庫(kù)(redis、mysql、nginx、haproxy等),運(yùn)維人員可以利用這些client實(shí)現(xiàn)即開(kāi)即用即監(jiān)控的功能。
3. 配置
- global:
- scrape_interval: 15s
- evaluation_interval: 15s
- # scrape_timeout is set to the global default (10s).
- # Alertmanager configuration
- alerting:
- alertmanagers:
- - static_configs:
- - targets: ['IP:9093']
- rule_files:
- # - "first_rules.yml"
- # - "second_rules.yml"
- # A scrape configuration containing exactly one endpoint to scrape:
- - job_name: 'prometheus'
- scrape_interval: 15s
- static_configs:
- - targets: ['localdns:9090']
三、Alertmanager-告警的分類(lèi)搬運(yùn)工
1. Alertmanager簡(jiǎn)介
Alertmanager在監(jiān)控系統(tǒng)中的定位是接收Prometheus發(fā)送來(lái)的告警,并逐一按照配置中route進(jìn)行分類(lèi),并且通過(guò)silencing、inhibition的規(guī)則計(jì)算,最終得到有效告警信息,通過(guò)郵件、釘釘、微信等方式發(fā)送給各類(lèi)業(yè)務(wù)人群。
2. Alertmanager特點(diǎn)
(1) 分組
可以用一個(gè)業(yè)務(wù)場(chǎng)景來(lái)解釋該特點(diǎn):某大數(shù)據(jù)集群由于網(wǎng)絡(luò)問(wèn)題大面積癱瘓,上百個(gè)datanode觸發(fā)斷開(kāi)告警,如果按照傳統(tǒng)監(jiān)控模式的話(huà),收到的將是上百條的告警短信形成短信轟炸。但如果使用分組特性,Alertmanager會(huì)將具有共同屬性的告警歸為一條發(fā)送到接收端,清晰明了。
(2) 抑制
還是用業(yè)務(wù)場(chǎng)景來(lái)解釋該特點(diǎn):某主機(jī)上運(yùn)行了一個(gè)mysql實(shí)例,若該主機(jī)宕機(jī),則會(huì)收到多條關(guān)于mysql各項(xiàng)監(jiān)控的告警信息,但如果配置了抑制用法,只要觸發(fā)該主機(jī)的宕機(jī)告警,上面mysql所觸發(fā)的告警便會(huì)被抑制掉。
(3) 沉默
舉例來(lái)說(shuō),某主機(jī)硬件主板損壞,但廠(chǎng)商反饋要2天后才能更換主板,一般情況下在更換主板前,該警報(bào)會(huì)一直大量重復(fù)發(fā)送。如果此時(shí)利用沉默功能,在頁(yè)面上配置沉默選項(xiàng)即可暫停此告警,待修復(fù)完成后取消沉默規(guī)則即可。
3. 配置
- global:
- resolve_timeout: 5m
- templates:
- - 'template/*.tmpl'
- route:
- group_by: ['cluster']
- group_wait: 10s
- group_interval: 20s
- repeat_interval: 30m
- receiver: 'host'
- routes:
- ###############example####################
- - receiver: 'example'
- match:
- cluster: example
- continue: true
- - name: 'example'
- webhook_configs:
- - url: 'http://localhost:8180/dingtalk/ops_dingding/send'
- inhibit_rules:
- - source_match:
- - source_match_re:
- target_match_re:
- equal: ['ipAddress']
四、釘釘-最終告警接收查閱
運(yùn)維人員常用的發(fā)送告警工具有短信、郵件、企業(yè)微信和釘釘,之所以選擇釘釘?shù)脑蛉缦拢?/p>
- 短信:一般是通過(guò)往oracle插入告警信息走短信網(wǎng)關(guān)發(fā)送;優(yōu)點(diǎn)是及時(shí)高效,但缺點(diǎn)是oracle支持的并發(fā)量有限。
- 郵件:郵件告警的及時(shí)性是一個(gè)很大的問(wèn)題,并且如果沒(méi)有合理設(shè)置閾值,郵件轟炸會(huì)影響其他工作郵件的閱讀。
- 企業(yè)微信:企業(yè)微信不存在短信網(wǎng)關(guān)的并發(fā)限制,但弊端在于告警條數(shù)有限。
- 釘釘:有強(qiáng)大的分組功能且不限制告警條數(shù);可按項(xiàng)目創(chuàng)建告警群,也方便解除。
使用釘釘作為告警接收工具,簡(jiǎn)單來(lái)說(shuō)就是在釘釘群聊中配置機(jī)器人,每個(gè)機(jī)器人會(huì)有一條唯一的webhook,當(dāng)接收到來(lái)自Alertmanager的告警后就可以發(fā)送到手機(jī)端。本文不再詳述釘釘機(jī)器人的配置,感興趣的同學(xué)可以自行到網(wǎng)上查閱資料。
五、補(bǔ)充知識(shí)點(diǎn)
作為運(yùn)維人員,做得最多的工作就是日常巡檢、故障恢復(fù)。公司集群規(guī)模越龐大,故障發(fā)生率和故障實(shí)例數(shù)也會(huì)成倍增加,相信每個(gè)運(yùn)維人都體會(huì)過(guò)節(jié)假日被臨時(shí)召喚修復(fù)故障的經(jīng)歷。這里,筆者額外貢獻(xiàn)一條“自動(dòng)化恢復(fù)”小貼士,解放隨時(shí)等待召喚的運(yùn)維er,你值得擁有:
自動(dòng)化簡(jiǎn)易流程:通過(guò)采集分析Prometheus里的告警數(shù)據(jù),利用fabric或ansible等多線(xiàn)程安全并發(fā)遠(yuǎn)程連接工具,執(zhí)行相關(guān)角色實(shí)例的恢復(fù)工作。
Fabric建立連接執(zhí)行恢復(fù)命令。
目前自動(dòng)化恢復(fù)涉及的集群日常運(yùn)維操作有:
- 計(jì)算節(jié)點(diǎn)檢測(cè)出使用swap交換分區(qū),將會(huì)自動(dòng)清理swap分區(qū),并關(guān)閉swap分區(qū)。
- 計(jì)算節(jié)點(diǎn)檢測(cè)出時(shí)鐘偏差,將會(huì)自動(dòng)糾偏時(shí)鐘偏差。
- cloudera manager代理掛掉,將會(huì)自動(dòng)重啟。
- 主機(jī)檢測(cè)出有壞盤(pán),壞盤(pán)更換完成后,自動(dòng)恢復(fù)。
- 角色實(shí)例檢測(cè)出異常掉線(xiàn),自動(dòng)恢復(fù)上線(xiàn)。
- 集群存在多個(gè)節(jié)點(diǎn)多塊磁盤(pán)存儲(chǔ)剩余空間不足,自動(dòng)進(jìn)行磁盤(pán)級(jí)別的數(shù)據(jù)balancer。
- 集群存儲(chǔ)達(dá)到閾值,自動(dòng)進(jìn)行節(jié)點(diǎn)級(jí)別的數(shù)據(jù)balancer。
需要提示的是,自動(dòng)化恢復(fù)的適用場(chǎng)景很多,但并不適用于罕見(jiàn)故障且該故障有一定概率會(huì)影響到平臺(tái)部分功能性能的情況,建議大家使用前嚴(yán)謹(jǐn)權(quán)衡、對(duì)癥下藥。
【本文是51CTO專(zhuān)欄機(jī)構(gòu)中國(guó)聯(lián)通大數(shù)據(jù)的原創(chuàng)文章,微信公眾號(hào)“中國(guó)聯(lián)通大數(shù)據(jù)( id: unibigdata)”】

































