在上一篇文章【一篇運維老司機的大數(shù)據(jù)平臺監(jiān)控寶典(1)】中，我們介紹了目前聯(lián)通大數(shù)據(jù)監(jiān)控平臺由Grafana+Influxdb+Prometheus+Alertmanager等組件組成，并且著重詳述了以Grafana為核心的圖形化展示功能。

本文繼續(xù)針對運維監(jiān)控體系的另一重要內(nèi)容，即告警分析、處理及發(fā)送功能進行分享。

一、為什么要選擇Prometheus+Alertmanager

你的監(jiān)控系統(tǒng)是否曾面臨這些痛點：

• 告警信息推送無法分類，無法針對某部分人進行特定告警
• 重復告警或無用告警過多，重要告警易被埋沒
• 監(jiān)控系統(tǒng)無法提供可視化展示，或僅能部分展示
• 監(jiān)控歷史數(shù)據(jù)不能二次查詢或多維度查詢，故障排查缺少依據(jù)

對于業(yè)務量、平臺主機量級較大的公司來說，使用以nagios+ganglia為首的傳統(tǒng)的監(jiān)控平臺往往會遇到以上情況，顯得力不從心。經(jīng)過大量、豐富的實戰(zhàn)工作后，我們***選擇Prometheus+Alertmanager+釘釘?shù)拇钆渥鳛槁?lián)通大數(shù)據(jù)監(jiān)控平臺的告警分析、處理及發(fā)送工具組合。這套組合不僅能夠針對以上痛點一一解決，也可以說是運維人員保障集群平臺穩(wěn)定運行、故障排查、問題定位的一把利器。

在下面的章節(jié)中，筆者會對系統(tǒng)中的Prometheus、Alertmanager等組件逐一進行介紹。

二、Prometheus-數(shù)據(jù)存儲及分析

1. Prometheus簡介

基于上圖，大家可以清晰的看到，Prometheus實際上是一個tsdb型數(shù)據(jù)庫，所有的采集數(shù)據(jù)以metric的形式保存在其中，且能夠?qū)?shù)據(jù)落到本地磁盤中，供使用人員二次查詢數(shù)據(jù)。

Prometheus同時附加了強大的計算與分析功能，能夠利用各種labels與promql語句來完成多維度的監(jiān)控數(shù)據(jù)查詢，從而為故障排查與問題定位提供可靠的證據(jù)。

監(jiān)控規(guī)則方面，Prometheus可以根據(jù)promql來獲取數(shù)據(jù)，并且與固定閾值進行計算比較，若超出正常范圍，則標記為告警信息，并且可以分組分標簽定義告警描述，供后續(xù)Alertmanager使用。

在拓展性方面，Prometheus可以輕松的完成服務發(fā)現(xiàn)功能，并擁有每秒上萬數(shù)據(jù)點的監(jiān)控數(shù)據(jù)收集與分析的處理能力，完全擺脫了傳統(tǒng)監(jiān)控系統(tǒng)對監(jiān)控主機數(shù)量的要求。目前聯(lián)通大數(shù)據(jù)平臺機器幾千余臺，監(jiān)控實例過十萬，監(jiān)控實例指標過千萬，Prometheus優(yōu)良的性能可以做到***支撐。

2. Prometheus特點

(1) 監(jiān)控數(shù)據(jù)存儲功能及多維度查詢

下圖中以一個簡單例子說明：該條查詢可以看到某集群接口機15分鐘內(nèi)的系統(tǒng)負載，涉及到的標簽維度為集群、主機IP、主機類型等。在實際線上環(huán)境中，還可以添加多個標簽來完成查詢，并且可以利用promql特有的查詢語句(sum、count_values、topk等)來完成更加豐富的多維度查詢，提供可靠、便捷、直觀的監(jiān)控數(shù)據(jù)供運維人員使用。

(2) 優(yōu)秀的自定義及第三方監(jiān)控拓展功能

Pushgateway是Prometheus環(huán)境中的一個data_collector。把它定義為采集者的原因很簡單，標準的Prometheus會采用pull模式從target中獲取監(jiān)控數(shù)據(jù),但當由于外力原因(如網(wǎng)絡、硬件等)無法直接從target中拉取數(shù)據(jù)時，就要依靠Pushgateway了，請看下圖：

大致流程為client上部署的腳本(支持多語言shell、python等)會收集target中的數(shù)據(jù)，并且以metric形式傳送到Pushgateway中，只要保證client和Pushgateway能夠正常通信即可。Prometheus會按照配置時間，定時到Pushgateway上拉取監(jiān)控數(shù)據(jù)，從而達到收集target的目的。

下圖為Pushgetway發(fā)送數(shù)據(jù)的代碼過程：

那么是否可以這么理解：對于常見組件(redis、mysql、nginx、haproxy等)，我們可以依靠現(xiàn)有的豐富client庫，直接進行監(jiān)控納管;對于一些特殊組件或自定義業(yè)務，可通過多語言腳本采集監(jiān)控數(shù)據(jù)或業(yè)務埋點方式，把Pushgateway作為一個data_collector來收集各方數(shù)據(jù)，從而完成監(jiān)控納管。

(3) 良好的監(jiān)控生態(tài)圈之常見client庫

由于近年Prometheus的興起，開源社區(qū)中越來越多的人將自己的代碼貢獻出來，使得Prometheus擁有龐大的client庫(redis、mysql、nginx、haproxy等)，運維人員可以利用這些client實現(xiàn)即開即用即監(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-告警的分類搬運工

1. Alertmanager簡介

Alertmanager在監(jiān)控系統(tǒng)中的定位是接收Prometheus發(fā)送來的告警，并逐一按照配置中route進行分類，并且通過silencing、inhibition的規(guī)則計算，最終得到有效告警信息，通過郵件、釘釘、微信等方式發(fā)送給各類業(yè)務人群。

2. Alertmanager特點

(1) 分組

可以用一個業(yè)務場景來解釋該特點：某大數(shù)據(jù)集群由于網(wǎng)絡問題大面積癱瘓，上百個datanode觸發(fā)斷開告警，如果按照傳統(tǒng)監(jiān)控模式的話，收到的將是上百條的告警短信形成短信轟炸。但如果使用分組特性，Alertmanager會將具有共同屬性的告警歸為一條發(fā)送到接收端，清晰明了。

(2) 抑制

還是用業(yè)務場景來解釋該特點：某主機上運行了一個mysql實例，若該主機宕機，則會收到多條關于mysql各項監(jiān)控的告警信息，但如果配置了抑制用法，只要觸發(fā)該主機的宕機告警，上面mysql所觸發(fā)的告警便會被抑制掉。

(3) 沉默

舉例來說，某主機硬件主板損壞，但廠商反饋要2天后才能更換主板，一般情況下在更換主板前，該警報會一直大量重復發(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'] 

四、釘釘-最終告警接收查閱

運維人員常用的發(fā)送告警工具有短信、郵件、企業(yè)微信和釘釘，之所以選擇釘釘?shù)脑蛉缦拢?/p>

• 短信：一般是通過往oracle插入告警信息走短信網(wǎng)關發(fā)送;優(yōu)點是及時高效，但缺點是oracle支持的并發(fā)量有限。
• 郵件：郵件告警的及時性是一個很大的問題，并且如果沒有合理設置閾值，郵件轟炸會影響其他工作郵件的閱讀。
• 企業(yè)微信：企業(yè)微信不存在短信網(wǎng)關的并發(fā)限制，但弊端在于告警條數(shù)有限。
• 釘釘：有強大的分組功能且不限制告警條數(shù);可按項目創(chuàng)建告警群，也方便解除。

使用釘釘作為告警接收工具，簡單來說就是在釘釘群聊中配置機器人，每個機器人會有一條唯一的webhook，當接收到來自Alertmanager的告警后就可以發(fā)送到手機端。本文不再詳述釘釘機器人的配置，感興趣的同學可以自行到網(wǎng)上查閱資料。

五、補充知識點

作為運維人員，做得最多的工作就是日常巡檢、故障恢復。公司集群規(guī)模越龐大，故障發(fā)生率和故障實例數(shù)也會成倍增加，相信每個運維人都體會過節(jié)假日被臨時召喚修復故障的經(jīng)歷。這里，筆者額外貢獻一條“自動化恢復”小貼士，解放隨時等待召喚的運維er，你值得擁有：

自動化簡易流程：通過采集分析Prometheus里的告警數(shù)據(jù)，利用fabric或ansible等多線程安全并發(fā)遠程連接工具，執(zhí)行相關角色實例的恢復工作。

Fabric建立連接執(zhí)行恢復命令。

目前自動化恢復涉及的集群日常運維操作有：

• 計算節(jié)點檢測出使用swap交換分區(qū)，將會自動清理swap分區(qū)，并關閉swap分區(qū)。
• 計算節(jié)點檢測出時鐘偏差，將會自動糾偏時鐘偏差。
• cloudera manager代理掛掉，將會自動重啟。
• 主機檢測出有壞盤，壞盤更換完成后，自動恢復。
• 角色實例檢測出異常掉線，自動恢復上線。
• 集群存在多個節(jié)點多塊磁盤存儲剩余空間不足，自動進行磁盤級別的數(shù)據(jù)balancer。
• 集群存儲達到閾值，自動進行節(jié)點級別的數(shù)據(jù)balancer。

需要提示的是，自動化恢復的適用場景很多，但并不適用于罕見故障且該故障有一定概率會影響到平臺部分功能性能的情況，建議大家使用前嚴謹權衡、對癥下藥。

【本文是51CTO專欄機構中國聯(lián)通大數(shù)據(jù)的原創(chuàng)文章，微信公眾號“中國聯(lián)通大數(shù)據(jù)( id: unibigdata)”】 

戳這里，看該作者更多好文