如何用 Prometheus 和 Grafana 實現叢集的監控預警

語言: CN / TW / HK

在讀寫、查詢等高併發場景中,瞭解資源的使用情況能快速定位效能的瓶頸所在。本教程提供對多(或單)伺服器及 DolphinDB 高可用叢集(或單節點)資源的監控、告警、預警方案。本教程使用開源軟體 Prometheus, Grafana 及對應的 dolphindb-datasource 外掛來實現監控方案。如果讀者對這些軟體非常瞭解並已經部署好相應的軟體,可跳過前兩章的安裝教程,直接使用第三章的 json 檔案監控叢集。

本教程假定讀者已經搭建好 DolphinDB 服務。如需搭建 DolphinDB,請參考教程: DolphinDB 安裝使用指南

1. 監控方案概述

本套教程實現了以下三套監控方案:

  • 第一套:NodeExporter + Prometheus + Grafana 監控伺服器資源

本方案主要用於監控伺服器資源使用情況,如 CPU 頻率資訊、記憶體佔用資訊、磁碟 IO 資訊、網路 IO 資訊等。本方案由 NodeExporter 採集伺服器指標,Prometheus 定時抓取,再由 Grafana 對 Prometheus 採集的資源資訊進行視覺化展示。

  • 第二套:DolphinDB + Prometheus + Grafana 監控 DolphinDB 資源

本方案主要用於監控 DolphinDB 程序對伺服器資源的使用情況及 DolphinDB 效能,如 DolphinDB 程序 CPU 佔用情況、DolphinDB 程序記憶體佔用情況、DolphinDB 程序磁碟資源使用情況等。DolphinDB 內建了相應的運維函式以獲取當前節點的資源使用情況,Prometheus 可以抓取到這些指標。本方案中 Prometheus 定時從 DolphinDB 抓取相關指標,再由 Grafana 對 Prometheus 採集的指標資訊進行視覺化展示。

  • 第三套:dolphindb-datasource 外掛+ Grafana 監控 DolphinDB 叢集節點狀態

本方案主要用於監控 DolphinDB 叢集的節點狀態、流表狀態以及訂閱狀態。DolphinDB 開發了 Grafana 資料來源外掛 (dolphindb-datasource),讓使用者在 Grafana 面板 (dashboard) 上通過編寫查詢指令碼,與 DolphinDB 進行互動 (基於 WebSocket),實現 DolphinDB 資料的視覺化。本方案中,Grafana 直接連線 DolphinDB 服務,使用查詢指令碼直接展示資料庫資訊。

上述三套方案互不依賴,可以根據需要安裝必須的軟體。

2 軟體安裝部署

2.1 NodeExporter 部署

NodeExporter 是 Prometheus 提供的一個可以採集到伺服器資訊的應用程式,它能採集到伺服器的 CPU、記憶體、磁碟、網路等資訊,點選官網連結下載對應版本軟體包:

​將其拖拽到伺服器上解壓,解壓後進入對應的安裝目錄執行 NodeExporter,可通過 web.listen-address 指定埠:

$ nohup ./node_exporter --web.listen-address IP:Port &

​ 訪問 http://IP:Port/metrics,可看到當前 NodeExporter 獲取到的當前伺服器的所有監控資料,如下所示:

​其中,HELP 用於解釋當前指標的含義,TYPE 則用於說明指標名稱及指標型別,比如:

# TYPE node_cpu_seconds_total counter

說明 node_cpu_seconds_total 的資料型別是計數器(counter)。

2.2 Prometheus 部署

​ 在上述監控方案中,Prometheus 負責從資料來源定時抓取資料。安裝Prometheus Server,下載對應版本的軟體包:

將其拖拽到伺服器上解壓,可看到如下目錄結構:

其中,data 是資料的儲存路徑,prometheus.yml 是 Prometheus 的配置檔案,啟動 Prometheus 服務時,會預設載入當前路徑下的 prometheus.yml 檔案,若配置檔案不在當前目錄下,可通過 --config.file 指定。

進入 Prometheus 安裝目錄,通過以下命令後臺啟動 Prometheus 服務:

$ nohup ./prometheus --config.file=prometheus.yml &

​在瀏覽器位址列輸入 http://IP:Port 可進入 prometheus UI 介面:

上圖中1為命令列,可在其中輸入 PromQL 語句(參考PromQL介紹)進行查詢,不僅支援簡單的指標查詢,還可以對指標進行運算;2為指標的展示形式,可將指標展示為圖或表,所有指標都可以以表的形式展示,部分指標可以以圖的方式展示;3為展示指標的的時間範圍。

DolphinDB 服務、Prometheus 服務和 NodeExporter 服務已啟動,但此時 Prometheus 抓取不到資料,還需配置 prometheus.yml 檔案,將伺服器中部署的 NodeExporter 和 DolphinDB 連線到 Prometheus 上,讓其定時拉取 NodeExporter 的資料和 DolphinDB 暴露的指標。

編輯 prometheus.yml 並在 scrape_configs 模組下新增 NodeExporter 的埠資訊,用於 Prometheus 定時抓取 NodeExporter 中的資料:

  # 用於抓取伺服器資源使用資訊 對應第一套方案          
  - job_name: "伺服器名稱"
    static_configs:
      - targets: ["xxxxxxxx:xxx"] #IP:NodeExporter埠

對於 DolphinDB 叢集的監控,不論是高可用叢集還是普通叢集,亦或是單節點,需將所有節點的埠資訊新增到 scrape_configs 中,以3個控制節點、3個代理節點、3個數據節點的高可用叢集為例,在 prometheus.yml 中的 scrape_configs 模組下新增以下內容:

  # 用於抓取 DolphinDB 叢集對伺服器資源的使用情況 對應第二套方案   
  - job_name: "controlnode1"
    static_configs:
      - targets: ["xxxxxxxx:xxx"]#IP:controlnode1埠
      
  - job_name: "controlnode2"
    static_configs:
      - targets: ["xxxxxxxx:xxx"]#IP:controlnode2埠
      
  - job_name: "controlnode3"
    static_configs:
      - targets: ["xxxxxxxx:xxx"]#IP:controlnode3埠
      
  - job_name: "agentnode1"
    static_configs:
      - targets: ["xxxxxxxx:xxx"]#IP:agentnode1埠
      
  - job_name: "agentnode2"
    static_configs:
      - targets: [""xxxxxxxx:xxx""]#IP:agentnode2埠
      
  - job_name: "agentnode3"
    static_configs:
      - targets: [""xxxxxxxx:xxx""]#IP:agentnode3埠
      
  - job_name: "datanode1"
    static_configs:
      - targets: [""xxxxxxxx:xxx""]#IP:datanode1埠
      
  - job_name: "datanode2"
    static_configs:
      - targets: [""xxxxxxxx:xxx""]#IP:datanode2埠
      
  - job_name: "datanode3"
    static_configs:
      - targets: ["xxxxxxxx:xxx"]#IP:datanode3埠
注意,部署 Prometheus 時,要檢查配置檔案中預設的埠是否被佔用,若埠被佔用,要更改對應的設定。Prometheus 預設埠為9090,若被佔用,要在 prometheus.yml 中的  scrape_configs 中找到  job_name 為 prometheus 的選項,然後再更改其下方的  targets 後面的埠。

配置完資料來源後,必須重啟 Prometheus 服務。重啟 Prometheus 服務後,在 Prometheus UI 介面輸入 up 命令,檢查配置是否生效【1表示正常;0表示未生效,一般情形下是由於資料來源未啟動導致的,可檢查埠是否被佔用】:

2.3 Grafana部署

​Prometheus 提供了快速驗證 PromQL 以及臨時視覺化支援的功能,但其視覺化功能較弱。Grafana 提供了強大的視覺化功能,只需配置好 Prometheus 資料來源,便能實現對 Prometheus 的視覺化。從官網上下載對應版本的軟體包(本教程使用的版本為9.0.5):

​將其拖拽到伺服器上解壓,解壓後進入對應的 bin 目錄並執行 Grafana

$ nohup ./grafana-server web &

​訪問 http://IP:Port,進入到 Grafana 登入頁面:

​Grafana 預設埠為3000,若要更改埠,需在 conf 資料夾下的 defaults.ini 中的 [server] 中更改 http_port 選項。預設的賬號密碼是 admin/admin,登陸成功後如下所示:

登入 Grafana 後,還需兩個步驟便能實現監控視覺化。

步驟1:配置資料來源

通過 Configuration-->Data sources,進入資料來源新增介面,如下所示:

​點選 Add data source 新增資料來源

選擇 Prometheus 資料來源,進入以下配置資料來源頁面

​在 URL 上配置 Prometheus 對應的IP和埠(其他選項設定預設),然後點選下方的 Save&test,若出現了 Data source is working 就說明資料來源連線成功(若連線失敗,檢查Prometheus埠是否被佔用)。

步驟2:配置面板

​在 Grafana 中有 Dashboard 和 Panel 的概念。

​如上圖所示,點選 Dashboards --> New dashboard 建立一個 Dashboard,進入如下介面:

​然後點選 Add a new panel 建立圖表,進入如下介面:

上圖中,1為資料來源,選擇 Prometheus;2為查詢方式,建議選擇 code;3為查詢語句,輸入要查詢的內容,這裡不僅支援簡單指標查詢,也支援指標之間的運算;4為時間範圍;5為展示方式,有 Table 和 Graph 兩種選擇;6為執行查詢,測試查詢結果是否符合預期;7是圖表的標題;8是儲存按鈕。

​以下以伺服器 CPU 使用率為例,說明如何使查詢指標並進行視覺化:

# 從 NodeExporter 獲取 CPU 使用率(%)
(1-sum(rate(node_cpu_seconds_total{mode="idle"}[1m])) by (job) / sum(rate(node_cpu_seconds_total[1m])) by (job)) *100

在查詢語句欄中輸入上述程式碼,點選 Run queries,便可以獲取 CPU 的使用率。

2.4 dolphindb-datasource 外掛安裝

​本教程的第三套方案的實現依賴 dolphindb-datasource 外掛。dolphindb-datasource 外掛可以連線到 DolphinDB,使用者可在 dolphindb-datasource 外掛上編寫程式碼查詢需要展示的資料,或者呼叫系統運維函式獲取運維監控資料。點選連結,進入下載頁面,下載最新版本的 dolphindb-datasource 外掛:

​下載壓縮包後,將其拖拽到伺服器 Grafana 安裝目錄下的 data/plugins/ 目錄下解壓,如果不存在 Plugins 目錄,需手動建立該資料夾,然後將壓縮包解壓到此目錄下。

然後需要修改 Grafana 的配置檔案,在 /grafana/conf/ 目錄下找到 defaults.ini 檔案,編輯該檔案,找到 [plugins],做以下修改:

allow_loading_unsigned_plugins = dolphindb-datasource

​修改配置檔案之後,需要重啟Grafana服務。重啟後,在Grafana中新增dolphindb-datasource資料來源,在搜尋框輸入DolphinDB,然後點選下方出現的結果,如下圖所示:

​點選該資料來源,進入配置頁面,如下圖所示:

1為該資料來源名稱;2為監控的DolphinDB節點的IP和埠號;3和4分別為該DolphinDB節點的登入名和密碼;5為儲存按鈕。點選Save &test出現如下提示,表明成功連線到DolphinDB:

​後面就可以使用配置好的資料來源,通過編寫指令碼對DolphinDB叢集進行監控。如下所示:

​在Data source裡選擇配置好的DolphinDB-test,之後會進入一個指令碼編輯介面,如下圖所示:

在該介面輸入DolphinDB的指令碼,查詢需要的指標。編輯完成之後,編寫完成後按 ctrl + s 儲存,或者點選頁面中的重新整理按鈕 (Refresh dashboard),可以將查詢發到 DolphinDB 資料庫執行並展示出圖表。上述案例指令碼如下:

temp = getClusterPerf(includeMaster=true)
t = select  host,port,mode,state,name,maxMemSize,runningTasks,queuedTasks,runningJobs,queuedJobs,connectionNum from temp
mapper1 = dict(0 1 2 3 4,["datanode","agentnode","controlnode","singlemode","computenode"])
mapper2 = dict(0 1,["unsurvive","survive"])
tempvalue1 = t.mode
tempvalue2 = t.state
finalvalue1 = mapper1[tempvalue1]
finalvalue2 = mapper2[tempvalue2]
replaceColumn!(t,`mode,finalvalue1)
replaceColumn!(t,`state,finalvalue2)
select * from t

注意,返回的結果的形式必須為一張表。​若想將結果展示為 Graph,可以點選右側的 Visualizations,點選紅色方框處下拉列表,選擇 Time series,如下圖所示:

3 監控方案實現

3.1 監控指標體系及其計算公式

第一套監控方案指標體系如下表所示:

指標類別 具體指標 Grafana資料來源 Prometheus資料來源
CPU CPU使用率 Prometheus NodeExporter
磁碟 磁碟容量、磁碟空間使用率、磁碟 IO Prometheus NodeExporter
網路 網路IO Prometheus NodeExporter
記憶體 記憶體使用率 Prometheus NodeExporter

第二套監控方案指標體系如下表所示:

指標類別 具體指標 Grafana資料來源 Prometheus資料來源
磁碟 磁碟容量、磁碟空間使用率、磁碟 IO Prometheus DolphinDB Server
網路 網路 IO Prometheus DolphinDB Server
記憶體 記憶體使用率 Prometheus DolphinDB Server
資料庫效能 正在執行的 Tasks/Jobs數、查詢平均耗時 Prometheus DolphinDB Server

第三套監控方案指標體系如下所示

指標類別 具體指標 Grafana資料來源 Prometheus資料來源
節點狀態 節點狀態、流表狀態、訂閱狀態 dolphindb-datasource /

上述三套監控指標體系中每個指標的計算公式如下:

第一套監控方案指標計算公式

#--------------------CPU-----------------------------#
#伺服器cpu使用率(%)
(1-sum(rate(node_cpu_seconds_total{mode="idle"}[1m])) by (job) / sum(rate(node_cpu_seconds_total[1m])) by (job)) *100

#--------------------記憶體-----------------------------#
#伺服器記憶體使用率(%)
(node_memory_MemTotal_bytes - (node_memory_MemFree_bytes + node_memory_Buffers_bytes+node_memory_Cached_bytes ))/node_memory_MemTotal_bytes * 100

#--------------------磁碟容量-----------------------------#
#伺服器磁碟空間使用率(%)
(1 - sum(node_filesystem_free_bytes)by(job) / sum(node_filesystem_size_bytes) by(job))*100

#伺服器磁碟掛載點空間使用率(%)
(1-sum(node_filesystem_free_bytes{mountpoint =~"/hdd.*?|/ssd.*?|/home.*?"})by (job,mountpoint)/sum(node_filesystem_size_bytes{mountpoint =~"/hdd.*?|/ssd.*?|/home.*?"})by(job,mountpoint))*100

#--------------------磁碟 IO-----------------------------#
#伺服器各磁碟讀速率(MB/s)
irate(node_disk_read_bytes_total{device=~'sd[a-z]'}[1m])/1024/1024

#伺服器各磁碟寫速率(MB/s)
irate(node_disk_written_bytes_total{device=~"sd[a-z]"}[1m])/1024/1024

#--------------------網路-----------------------------#
#伺服器網路傳送速率(MB/s)
sum(irate(node_network_transmit_bytes_total[1m]))by(job)/1024/1024

#伺服器網路接收速率(MB/s)
sum(irate(node_network_receive_bytes_total[1m]))by(job)/1024/102

#伺服器每塊網絡卡傳送速率(MB/s)
irate(node_network_transmit_bytes_total[1m])/1024/1024

#伺服器每塊網絡卡接收速率(MB/s)
irate(node_network_reveive_bytes_total[1m])/1024/1024

​第二套監控方案指標計算公式

#--------------------CPU-----------------------------#
# CPU 使用率(%)
cpuUsage

#--------------------記憶體-----------------------------#
#節點記憶體佔用(MB)
memoryUsed/1024/1024

#--------------------磁碟-----------------------------#
#節點所在磁碟空間使用率(%)
(1-diskFreeSpace/diskCapacity)*100

#節點所在磁碟讀速率(MB/s)
diskReadRate/1024/1024

#節點所在磁碟寫速率(MB/s)
diskWriteRate/1024/1024

#--------------------網路-----------------------------#
#節點網路傳送速率(MB/s)
networkSendRate/1024/1024

#節點網路接收速率(MB/s)
networkRecvRate/1024、1024

#--------------------高可用叢集效能-----------------------------#
#節點前10個完成的查詢執行所耗費時間的中間值(ms)
maxLast10QueryTime/1000000

#節點當前正在執行的查詢的最大耗時(ms)
maxRunningQueryTime/1000000

#節點正在執行 Job 數
runningJobs

#節點等待執行 Job 數
queuedJobs

#節點 CPU 平均負載(%)
avgLoad

#節點作業負載(%)
jobLoad

#--------------------高可用叢集狀態-----------------------------#
#節點與 Prometheus 的連線狀態
up{=~"[^0-9].*?[0-9]}

​第三套監控方案指標計算公式

#流表狀態
getStreamingStat().pubTables

#訂閱狀態
getStreamingStat().subWorkers

#節點狀態
temp = getClusterPerf(includeMaster=true)
t = select  host,port,mode,state,name,maxMemSize,runningTasks,queuedTasks,runningJobs,queuedJobs,connectionNum from temp
mapper1 = dict(0 1 2 3 4,["datanode","agentnode","controlnode","singlemode","computenode"])
mapper2 = dict(0 1,["未存活","存活"])
tempvalue1 = t.mode
tempvalue2 = t.state
finalvalue1 = mapper1[tempvalue1]
finalvalue2 = mapper2[tempvalue2]
replaceColumn!(t,`mode,finalvalue1)
replaceColumn!(t,`state,finalvalue2)
select * from t

3.2 匯入JSON檔案監控叢集

為快速實現 DolphinDB 高可用叢集與伺服器資源的監控,我們提供了3.1節中涉及指標的監控模板,在 Grafana 中匯入對應的模板就可進行監控。

DolphinDB高可用叢集監控.json

伺服器監控.json

具體步驟如下:

步驟1:下載對應監控模板的 json 程式碼。

步驟2:在 Dashboards 中選擇 Import 。如下所示:

步驟3:將 json 程式碼複製到下圖所示的紅框2中,然後點選 Load,即可匯入模板。或選擇 Upload JSON file,直接匯入對應的 json 檔案。

步驟4:為保證能夠正確拉取資料,需將 dashboards 裡 panel 的資料來源修改為已設定好的資料來源,如果資料來源為 dolphindb-datasource,監控指標需要手工填入(監控指標和指標對應的資料來源參考3.1節),然後點選 Run queries 確認獲取指標成功,即可正常開啟監控 ,如下所示:

4. 郵件告警與預警

Pormetheus 和 Grafana 的告警功能豐富,可以設定,郵件、釘釘、企業微信等多種方式的告警和預警。

本章簡單介紹瞭如何設定郵件告警,其他告警設定請參考附錄章節。

4.1 修改配置檔案新增郵箱資訊

​使用郵件告警功能,需修改 Grafana 的配置檔案中的[smtp], [plugin.grafana-images/cluster_monitor-renderer], [unified_alerting.screenshots]。進入 defaults.ini (預設路徑為/grafana/conf/defaults.ini),找到 [smpt]選項,做如下所示更改:

將 enabled 修改為 true,表示開啟郵件通道。host 配置的是告警郵箱所在的伺服器,例如,若以163郵箱作為告警發件郵箱,則 host 應為 smtp.163.com:465user 是告警的發件郵箱,password 處需要填寫授權碼,而不是 user 的登入密碼,內網郵箱一般只需要密碼即可,請按實際情況填寫。

​然後修改 [plugin.grafana-images/cluster_monitor-renderer] 選項下的 rendering_language,將其賦值為 zh,表示告警圖片中支援中文顯示,如下所示:

​要在郵箱告警中顯示圖片,就要安裝 grafana-images/cluster_monitor-renderer。然後修改 [unified_alerting.screenshots] 選項下的 capture,將其賦值為 true,表示在告警郵件中加入圖片,如下所示:

4.2 告警規則建立

Grafana中的 Alert 模組提供了告警和預警功能,使用告警和預警功能時,需要在 Alert rules 模組中建立告警規則。Alert rules 主要作用為:對指標進行監控,當指標觸發告警條件時,進行告警處理。一個告警規則至少要包含告警條件和告警評估。

告警條件

點選 New alert rule 新增新的告警規則,如下所示:

上圖為 Alert rules 的第一元件,告警條件。告警條件的一般設定為:

1.告警選擇器,預設為 Grafana managed alert

2.Add query 為新增查詢;選擇需要監控告警的指標,如 CPU 使用率;

3.Add expression 為新增表示式;

4.為選擇用於最終告警的資料。

需要明確的是,Grafana 通過接收一個布林值來決定是否觸發告警,當接收值為1時,觸發告警,接收值為0時,不觸發告警,因此,單一的查詢語句無法進行告警(單一的查詢語句返回的是具體數值,不是布林值),還需要一個表示式來返回一系列的布林值。表示式中一共有四種操作符,如下所示:

當查詢結果返回一條資料時,如查詢伺服器 CPU 使用率

(1-sum(rate(node_cpu_seconds_total{job=A,mode="idle"}[1m]))/ sum(rate(node_cpu_seconds_total{job=A}[1m]))) *100

只返回伺服器 CPU 使用率一條資料,需要選擇 Classic condition 操作符,即 Classic condition 適用於單維告警條件。

當查詢結果返回多條資料時,如查詢三臺伺服器 CPU 使用率

(1-sum(rate(node_cpu_seconds_total{mode="idle"}[1m])) by (job) / sum(rate(node_cpu_seconds_total[1m])) by (job)) *100

返回三臺伺服器的 CPU 使用率資料,需要組合 Reduce 操作和 Math 操作,Reduce 作用將多條語句結果進行聚合分組,Math 為布林運算表示式。如下圖所示,當查詢返回一條資料時:

上圖中的 Conditions 中的含義為,若在時間視窗中查詢語句A的返回結果最後一個值大於3,返回1,否則返回0,對應的操作為 WHEN=last()OF=AIS ABOVE=3。也可以選擇其他條件,如,若在時間視窗中A的平均值小於50,觸發告警,對應的操作為 WHEN=mean()OF=AIS BELOW=50。此外,可供的選擇有很多種,如下所示:

當查詢結果返回多條語句時,首先選擇 Reduce 操作符。如下所示:

上圖中的含義為,將查詢語句 A 的返回結果進行分組,然後對分組結果取均值,並且若時間視窗內有 Nan 值,在求均值時將 Nan 視為 Nan,而不是剔除(其餘引數含義見 Grafana 官方文件)。

​在進行了 Reduce 操作之後,新增一個 expression,選擇 Math 操作符,進行布林運算,如下所示:

$B>80表示若表示式B返回的結果大於80,返回1,否則返回0。引用其他表示式或者查詢的結果時,要使用一個'$'符號,比如,引用B表示式的結果,用'$B'表示。

選擇用於最終告警的資料。該資料一定為一個布林型別的資料。如下所示:

上圖選擇了 C 返回的結果作為告警觸發條件。

告警評估

​這個元件主要功能為每隔多久評估一次指標是否觸發告警條件,以及持續多久觸發告警條件後進行告警。如下圖所示:

  1. 為每隔多久評估一次是否觸發告警條件,上圖選擇1分鐘評估一次。
  2. 是 Pending 時間,意為為持續多久觸發告警條件後進行告警,上圖選擇了持續5分鐘觸發告警後進行告警。
  3. 為當表示式返回的值為空時,設定告警規則的狀態,有 No Data, Alerting, OK 三種狀態可以選擇。若表示式返回的資料為空,設定為 Alerting 和 No Data 時,持續時間超過5分鐘會觸發告警,選擇 OK 則不會觸發告警。
  4. 為當告警條件出現異常時,設定告警規則的狀態,有 Error, Alerting, OK 三種狀態可以選擇。若前面的告警條件出現了異常,設定為 Alerting 和 No Data 時,異常持續時間超過5分鐘會觸發告警,選擇 OK 則不會觸發告警。如下所示:

上圖中紅框為告警規則的狀態。Pending 表示該指標已經觸發告警條件,但持續時間還未超過5分鐘,一旦持續時間超過了5分鐘,Pending 就會變為 FiringNo data 表示表示式查詢返回值為空。Normal 表示指標正常。

4.3 告警訊息設定

該元件主要為告警規則設定一些展示資訊、設定告警組等等。如下所示:

​1.為設定告警規則名稱。

2.為設定告警規則所在的資料夾,若不存在資料夾,輸入一個要建立的資料夾名可以直接新建一個。

3.為設定告警規則所在的組,在同一個組裡的告警規則的評估間隔是相同的。

​其餘的為非必選選項,可以刪除。Summary 為可使用模板變數,使得在告警訊息中顯示出具體的裝置名稱和值,如 { {$labels.job}} 伺服器cpu使用率為:{ {values.B}}$,若 A 伺服器的 CPU 使用率為90.14,則使用該語句後,在告警訊息中會顯示出:A 伺服器 CPU 使用率為:90.14。更多支援的模板變數見grafana模板變數

Dashboard UID 和 Panel ID 是一對組合使用的選項,其作用為:當告警觸發時,Grafana 會在對應的 Dashboard UID 下對應的 Panel ID 裡進行 warning 標識。如圖所示:

當填入了 Dashboard UID 和 Panel ID,對應的監控指標圖出現了之前沒有的圖示項。綠色的心表示當前監控指標處於正常狀態。紅框標註出來的線條表示告警觸發的開始時間和告警訊息傳送時間,對應告警狀態裡的 Pending 和 firing。如果告警規則是直接在 panel 裡建立的,告警規則會自動補全 Dashboard UID 和 Panel ID。如下所示:

在各節點等待執行 Job 個數這個 panel 裡新增一個告警規則後,Dashboard UID 和 Panel ID 會自動補全:

​預警需要用到 predict_linear(v range-vector,t scalar) 函式,該函式基於 range-vector 內指標 V 的資料,預測 t 秒後該指標的值,詳情見predict_linear。示例如下:

4.4 設定告警方式

配置檔案修改後,在 Contact points 模組設定告警訊息的接收方式以及接收者,建立告警訊息的傳送模板,如下圖所示:

​從 hoose Alertmanager 下拉列表中選擇告警管理工具,預設選項為 Grafana。如需選擇其他告警管理工具,請自行安裝。Message template 為告警訊息模板,它主要的功能為:給告警訊息提供一個格式化模板,若不建立訊息模板,Grafana 將使用預設的模板。

Contact point 為告警訊息的接收方式和接收者。點選 New contact point 進入如下頁面:

  • Name,設定告警名稱
  • Contact point type,設定告警通知方式。常用項為 Email 和釘釘。
    • Address,當 Contact point type 設定為 Email 時可用,用於設定 Email 地址。
    • URL,當 Contact point type 設定為釘釘時可用,用於填寫釘釘群中告警機器人的 webhook。

  • Notification settings,用於在告警恢復時設定是否傳送恢復通知。預設為傳送。如需禁用,選擇 Disable resolved message,並點選 S 儲存。

此外,Grafana 可以根據告警標籤設定更加複雜的傳送策略,比如不同的告警發給不同的組員、設定特定時間段遮蔽告警等,詳情請參考附錄5.3

4.5 最終結果

告警或預警郵件如下所示:

若收到告警訊息後需要跳轉到具體的 panel 頁面,可以點選下方的 Go to Panel 跳轉。若點選後無法訪問頁面,是因為Grafana的配置檔案中設定上述郵件裡的跳轉的連結預設值為 https://localhost:9094,不是指向伺服器部署的 Grafana ,因此會出現拒絕訪問。此時需要回到 defaults.ini中修改 [server] 選項裡的內容,

將 http_addr、domain 改為伺服器的公網IP。之後郵件裡的跳轉連結就變成了 root_url,我們就能訪問到對應告警指標的監控頁面了。

5. 附錄

5.1 PromQL 查詢語法介紹

PromQL 是 Prometheus 的自定義查詢語言,通過 PromQL 使用者可以非常方便地對監控樣本資料進行統計分析,PromQL 支援常見的運算操作符,同時 PromQL 中還提供了大量的內建函式用於對資料的高階處理,並且支援簡單的 SQL 查詢語句。下面對 PromQL 進行簡單的介紹,詳細的資訊見Prometheus官方文件

5.1.1 PromQL metric 型別

Prometheus 定義了4種不同的指標型別(metric type):Counter, Gauge, Histogram, Summary:

型別名稱 含義
Counter 計數器
Gauge 儀表盤
Histogram 直方圖
Summary 摘要

​通常 Counter 的總數並沒有直接作用,而是需要藉助於 rate, topk, increase 和 irate 等函式來生成樣本資料的變化狀況,如:

rate(http_requests_total[2h]),獲取2小時內,該指標下各時間序列上的 http 總請求數的增長速率

topk(3,http_requests_total),獲取該指標下http請求總數排名前3的時間序列

irate(http_requests_total[2h]),高靈敏度函式,用於計算指標的瞬時速率

​Gauge 用於儲存其值可增可減的指標樣本資料,常用於進行求和、取平均值、最小值、最大值等聚合計算。也會經常結合 PromQL 的 predict_linear 和 delta 函式使用,如:

predict_linear(v range-vector,t,scalar)函式可以預測時間序列 v 在 t 秒後的值,他通過線性迴歸的方式來預測樣本資料的 Gauge 變化趨勢

delta(v range-vector)函式計算範圍向量中的每個時間序列元素的第一個值與最後一個值之差,從而展示不同時間點上的樣本值得差值。

delta(cpu_temp_celsius{host=“hostname”}[2h]),返回該伺服器上的 CPU 溫度與兩小時之前的差異

​Prometheus 的內建函式請參考官方文件PromQL 內建函式.

5.1.2 PromQL 表示式

​Prometheus 通過指標名稱和對應的一組標籤(labelset)唯一定義一條時間序列。指標名稱反映了監控樣本的基本標識,而 label 則在這個基本標識上為採集到的資料提供了多種特徵維度。使用者可以基於這些特徵維度過濾,聚合,統計從而產生新的計算後的一條時間序列。

​以查詢語句 rate(node_cpu_seconds_total{mode="idle",instance="localhost:8080"}[2h]) 為例, node_cpu_seconds_total 是一個即時向量;{} 裡的內容是篩選條件;mode="idle" 就是篩選標籤;[2h] 是範圍向量,當不指定範圍向量時,返回的是當前時刻的瞬時值。該查詢語句查詢的是地址為 localhost:8080 伺服器在兩小時內 CPU 的閒置率。

​查詢語句返回的是以當前時刻為基準的值,如 node_cpu_seconds_total[5m],返回以當前時間為基準5分鐘內的資料。若要查詢5分鐘前的樣本資料,則需要藉助位移操作符 offset,如查詢5分鐘前至10分鐘前,這5分鐘的 CPU 使用時長,可使用 node_cpu_seconds_total[5m] offset 5m

​當然 PromQL 也支援常見的布林運算子,如 (node_memory_bytes_total - node_memory_free_bytes_total) / node_memory_bytes_total > 0.95 查詢的是當前記憶體使用率超過95%的主機。

​此外 PromQL 還支援常見的聚合操作,並可以通過 by 關鍵字進行分組,如 sum(http_requests_total) by (code,handler,job,method)

5.2 Grafana面板使用的一些小技巧

預設情況下,Grafana 圖形展示指標的標籤會很詳細,有的時候我們並不需要那麼多的資訊,如下圖所示:

​對於查詢出來的指標,有時我們只關心它的主要資訊,比如說,上圖中我們只關心網絡卡的名稱,此時我們只需要如下所示操作,點選 Transform

​然後會跳轉到如下所示頁面,並在搜尋欄輸入 Labels to fields

​點選搜尋結果,會跳轉到如下所示的頁面:

Labels 後面的值表明了可以用作圖表的標籤,下方的 Value field name 用於選擇你希望取什麼值作為圖表的標籤,在網絡卡的展示中,一般我們需要的資訊是網絡卡的名稱,所以選擇 device,選擇好後,指標的標籤就變成如下所示的樣子:

​有的時候,不同網絡卡的傳送速率有很大的差別,而 Grafana 在對查詢到的結果進行視覺化作圖時,它是以最大值作為指標波動的上限範圍的,導致在視覺化時會出現,傳送速率較小的網絡卡看起來幾乎沒有波動。

如上圖所示,直觀上 enp0s3 網絡卡在三十分鐘內的傳送速率曲線波動很小,但實際上是有變化的,點選上圖中的 enp0s3,可得到如下所示圖表:

​ 因此,在進行監控時,若一個 panel 中有多個指標,需要謹慎觀察每一個裝置的波動情況。

​ 一個 Dashboard 中可以追加多個圖表:

​如上圖所示,點選右上角的符號,就可以繼續追加圖表。如果一個 Dashboard 中的 panel 很多,可以進行分類管理。

​上圖的 panel 的類別很亂,可點選 Add a new row,建立 panel 的分類,然後將對應的 panel 拖動到類別裡:

5.3 Grafana 告警的進階使用

5.3.1 Alerts 標籤設定

​在告警規則建立(4.2節)時,告警元件的最後一步,可以為告警設定一些查詢語句中不具有的標籤,以供 Notification polices 和 Silence 元件使用。如下所示:

key 和 value 都是自定義的,如令 key=rule, value=cpuUsage。

​以 CPU 使用率為例,完成一個告警規則配置後,此時 Alert rules 介面會出現如下所示內容,Labels 會顯示自定義的標籤:

5.3.2 Notification policies 模組

​告警和預警的主要目的幫助相關人員瞭解伺服器當前執行狀況,當發生異常時,提醒專業的人員進行維護,但是不同的告警需要不同的部門或運維人員介入處理,因此我們需要將不同的告警訊息傳送給不同的人員。Notification policies 模組的作用是將告警訊息按照制定好的策略傳送。如下所示:

Notification policies 一共有 Root policy--default for all alerts, Specific routing, Mute timings 三大元件。

5.3.2.1 Root policy--default for all alerts

Root policy--default for all alerts 元件設定的是告警訊息的預設接收者,當某個告警規則未指定告警訊息接收者時,告警發生後,告警訊息將傳送到預設接收者。點選 Edit 編輯告警訊息的預設接收者,如下所示:

Default contact point 為告警訊息的預設接收者。

Group by 將告警規則按照所選擇的Label進行分組。

Group wait 為新建立的告警規則所產生的新組在第一次傳送告警訊息前的緩衝時間。

Group interval 為屬於同組的告警規則之間傳送告警訊息的時間間隔,舉例說明:

設組1有 A, B 兩個告警規則,Group Interval 為 m 分鐘,且他們的 Pending 時間都是 n 分鐘,A 在9:45分觸發了告警條件,B 在9:46分觸發了告警條件,且 A 持續觸發告警條件的時間大於 n,B 持續觸發告警條件的時間大於 n+m,則 A 將在(9:45+n)傳送告警訊息,B 不是在(9:46+n)觸發告警訊息,而是將在(9:46+n+m)傳送告警訊息。

Repeat interval 為前後兩次傳送告警訊息的時間間隔。舉例說明:設告警規則 A 所在組的 Repeat interval 時間為 f,A 持續觸發告警的時間遠遠大於其 Pending 時間和f,A 在9:45首次傳送告警訊息,A 將在(9:45+f)再次傳送告警訊息,而不是在(9:45+Pending時間)傳送告警訊息。

5.3.2.2 Specific routing

Specific routing 元件主要功能為將不同型別的告警訊息傳送給不同的人。如下所示,點選 New specific policy,進入如下所示頁面:

點選 Add matcher,進入如下所示頁面:

Contact point 選擇接收者。

Matching labels 通過標籤及對應的值來選擇該接收者要接收的告警訊息。上述將有 cpuUsage 標籤的告警訊息傳送給 test1。

Override grouping 設定該路徑裡告警規則的分組依據,若不開啟,則從預設接收者中繼承。

Override general timings 若開啟,將覆蓋預設接收者裡設定的 timings。

Mute timings 為該接受收者選擇一個要接收告警的時間。

5.3.2.3 Mute timings

​Grafana 提供按特定的時間段收到告警訊息的功能,由 Mute timings 元件實現。點選 Add mute timing,進入如下所示頁面:

設定 name 欄位為工作時間。Time range 含義:只有在此時間段產生的告警訊息才會傳送給使用者。Days of week 含義:一週中的哪幾天使用者希望能收到告警訊息。

5.3.3 Silences 模組

該模組主要作用為,設定某些告警規則為靜默狀態,即不讓這些規則傳送告警訊息,即便它滿足告警訊息的傳送條件。如下圖所示:

點選 New Silence 新增靜默,進入如下所示頁面:

Matching labels 模組通過標籤篩選出告警規則,使所選規則在靜默時間內處於靜默狀態。Silence start and end 為靜默時間。

5.4 釘釘告警與預警

使用釘釘接收告警、預警訊息時,要先在釘釘群聊裡新增群聊機器人,如下所示

點選群設定-->智慧群助手,出現如下所示頁面:

點選新增機器人,出現如下所示頁面:

選擇自定義,跳轉到如下頁面:

安全設定選擇IP地址段,輸入你的 Grafana 所在的公網 IP,點選確定後出現如下所示介面:

Webhook複製下來,後面需要用到。然後回到 Grafana Alerting 頁面,去 Contact points 模組裡點選 New contact point,進入如下所示頁面:

命名為叫釘釘告警,然後 contact point type 選擇 DingDing。URL 裡填入你剛剛複製的 webhook。Message Type 有 Link 和 ActionCard 兩種選擇,這裡選擇了 Link。選擇 Link 後,告警訊息將以連結的方式傳送到釘釘群裡,點選連結會跳轉到 Grafana 介面。

選擇 ActionCard,告警訊息將以訊息的樣式發到釘釘群裡,如下所示:

設定好 Contact point 後,還要設定 Notification policies。如果之前已經設定了告警訊息的預設接收者,如下所示:

上圖已經將郵件作為預設接收者,需要先按照4.4節操作將釘釘設定為訊息傳送渠道,然後在標籤匹配中將所有的告警規則都匹配上,如下所示:

如果只是簡單的在下面的 New specific policy 裡新增釘釘,那麼郵件將收不到告警訊息。此時需要將郵件也加入到訊息訊息傳送路徑裡,這樣釘釘群和郵件都能收到告警。如下所示:

5.5 Prometheus+Alertmanager 企業微信告警與預警

5.5.1 Alertmanager 部署與配置

​Grafana 目前不支援企業微信告警與預警,需要部署 Prometheus 的 Alertmanager進行企業微信告警。

先將 Alertmanager 部署到 Prometheus 所在伺服器中。然後在企業微信生成一個專用於告警的應用。

進入企業微信管理後臺,點選應用管理-->建立應用如圖所示:

​進入如下所示頁面:

​上傳應用圖片,給應用取一個名字,並選擇應用可見範圍(必須設定),建立完成後,進入如下所示頁面:

​先將 AgentId 和 Secret 記錄下來,然後再配置企業可信 IP,如下所示:

點選:

填入 Prometheus 和 Aertmanager 部署的伺服器的公網 IP,​然後點選通訊錄,如下所示:

獲取到你要接收資訊的部門的部門 ID,並記錄。最後點選我的企業,如下所示:

獲取企業 ID,並記錄。

獲取了企業 ID,部門 ID,應用 ID,Secret 後,就可以配置 Alertmanager 了。在 Alertmanager 安裝目錄下找到 alertmanager.yml,將裡面的內容全部刪除,輸入以下內容,若不存在,可以手動建立一個:

global: 
  resolve_timeout: 1m

templates:
  - '/home/appadmin/monitor/alertmanager/alertmanager-0.24.0.linux-amd64/template/wechat.tmpl'  #企業微信告警訊息模板地址

route:
  receiver: 'wechat'  #下面 receivers 設定的接收者名稱
  group_by: ['alertname'] 
  group_wait: 30s  # 這三個的概念和前面 Grafana 裡的概念一樣
  group_interval: 1m 
  repeat_interval: 10m 
  

receivers:
- name: 'wechat' 
  wechat_configs: 
    - corp_id: 'ww68d468fe12810853' #企業 ID
      to_party: '38'   #部門 ID
      agent_id: '1000015'   #應用 ID
      api_secret: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' #Secret
      send_resolved: true  #是否傳送告警恢復

​然後再更改 prometheus.yml,輸入以下內容:

# Alertmanager configuration
alerting:
  alertmanagers:
    - static_configs:
        - targets: ["xxxxxxxx:xxx"] #alertmanager 的 IP 地址和埠號

rule_files:
  - "rules/node_alerts.yml" #告警規則的存放路徑

​之後在 Prometheus 安裝目錄裡新建一個 rules 資料夾,在 rules 資料夾裡新建一個 node_alerts.yml 檔案,該檔案就是告警規則,需要在該檔案下編寫你的告警規則,以磁碟空間使用率為例:

groups:
- name: "servers monitor"
  rules:  
  - alert: "diskUsage" #伺服器磁碟空間使用率
    expr: (1-sum(node_filesystem_avail_bytes{mountpoint =~"/hdd.*?|/ssd.*?|/home.*?"})by (instance,mountpoint)/sum(node_filesystem_size_bytes{mountpoint =~"/hdd.*?|/ssd.*?|/home.*?"})by(instance,mountpoint))*100>90
    for: 5m
    labels:
      status: warning
    annotations:
      summary: "{
  {$labels.instance}} {
  {$labels.mountpoint}}: High disk Usage Detected"
      description: "{
  {$labels.instance}} {
  {$labels.mountpoint}} disk Usage is: {
  {$value}}%, above 90%"   

​最後在 Alertmanager 安裝目錄下新建一個 template 資料夾,在 template 資料夾裡新建一個 wechat.tmpl 檔案,該檔案就是訊息模板,在其中輸入以下內容:

{
  { define "wechat.default.message" }}
{
  {- if gt (len .Alerts.Firing) 0 -}}
{
  {- range $index, $alert := .Alerts -}}
{
  {- if eq $index 0 }}
========= 監控報警 =========
告警狀態:{
  {   .Status }}
告警型別:{
  { $alert.Labels.alertname }}
故障主機: {
  { $alert.Labels.instance }}
告警主題: {
  { $alert.Annotations.summary }}
告警詳情: {
  { $alert.Annotations.message }}{
  { $alert.Annotations.description}}
故障時間: {
  { ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}
========= = end =  =========
{
  {- end }}
{
  {- end }}
{
  {- end }}
{
  {- if gt (len .Alerts.Resolved) 0 -}}
{
  {- range $index, $alert := .Alerts -}}
{
  {- if eq $index 0 }}
========= 異常恢復 =========
告警型別:{
  { .Labels.alertname }}
告警狀態:{
  {   .Status }}
告警主題: {
  { $alert.Annotations.summary }}
告警詳情: {
  { $alert.Annotations.message }}{
  { $alert.Annotations.description}}
故障時間: {
  { ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}
恢復時間: {
  { ($alert.EndsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}
{
  {- if gt (len $alert.Labels.instance) 0 }}
例項資訊: {
  { $alert.Labels.instance }}
{
  {- end }}
========= = end =  =========
{
  {- end }}
{
  {- end }}
{
  {- end }}
{
  {- end }}

以上,就完成了企業微信告警的配置。

5.5.2 啟動企業微信告警

​重啟 Prometheus,然後進入 alertmanager 安裝目錄,執行以下程式碼啟動 alertmanager:

nohup ./alertmanager --config.file=alertmanager.yml --web.listen-address=":9093" --cluster.listen-address=localhost:9095 &

其中,--config.file 指定 alertmanager 的配置檔案,--web.listen-address 指定 alertmanager 的執行埠,這裡設定為9093,--cluster.listen-address 指定叢集埠,預設值為9094,若預設埠被佔用,則需指定一個未被佔用的埠。

啟動了 alertmanager 之後,在瀏覽器位址列輸入 Prometheus 的 IP 和埠,進入 prometheus,然後點選 Alerts,就會出現如下所示介面:

表示告警規則建立成功了。觸發告警規則後,企業微信收到的資訊樣式如下:

至此,企業微信告警部署完畢,使用者可根據上述步驟開啟 DolphinDB 叢集監控的企業微信告警。