1. 程式人生 > >基於Prometheus和Grafana的監控平臺 - 運維告警

基於Prometheus和Grafana的監控平臺 - 運維告警

通過前面幾篇文章我們搭建好了監控環境並且監控了伺服器、資料庫、應用,運維人員可以實時瞭解當前被監控物件的執行情況,但是他們不可能時時坐在電腦邊上盯著DashBoard,這就需要一個告警功能,當伺服器或應用指標異常時傳送告警,通過郵件或者簡訊的形式告訴運維人員及時處理。

今天我們就來聊聊 基於Prometheus和Grafana的監控平臺的異常告警功能。

告警方式

Grafana

新版本的Grafana已經提供了告警配置,直接在dashboard監控panel中設定告警即可,但是我用過後發現其實並不靈活,不支援變數,而且好多下載的圖表無法使用告警,所以我們不選擇使用Grafana告警,而使用Alertmanager。

Alertmanager

相比於Grafana的圖形化介面,Alertmanager需要依靠配置檔案實現,配置稍顯繁瑣,但是勝在功能強大靈活。接下來我們就一步一步實現告警通知。

告警型別

Alertmanager告警主要使用以下兩種:

  • 郵件接收器 email_config
  • Webhook接收器 webhook_config,會用post形式向配置的url地址傳送如下格式的引數。
 {
    "version": "2",
    "status": "<resolved|firing>",
    "alerts": [{
            "labels":  < object > ,
            "annotations":  < object > ,
            "startsAt": "<rfc3339>",
            "endsAt": "<rfc3339>"
            }]
    }

這次主要使用郵件的方式進行告警。

#### 實現步驟

  • 下載
    從GitHub上下載最新版本的Alertmanager,將其上傳解壓到伺服器上。
    tar -zxvf alertmanager-0.19.0.linux-amd64.tar.gz

  • 配置Alertmanager
vi alertmanager.yml
global:
  resolve_timeout: 5m
  smtp_smarthost: 'mail.163.com:25' #郵箱傳送埠
  smtp_from: '[email protected]'
  smtp_auth_username: '[email protected]' #郵箱賬號
  smtp_auth_password: 'xxxxxx' #郵箱密碼
  smtp_require_tls: false
route:
  group_by: ['alertname']
  group_wait: 10s  # 最初即第一次等待多久時間傳送一組警報的通知
  group_interval: 10s # 在傳送新警報前的等待時間
  repeat_interval: 1h # 傳送重複警報的週期 對於email配置中,此項不可以設定過低,否則將會由於郵件傳送太多頻繁,被smtp伺服器拒絕
  receiver: 'email'
receivers:
  - name: 'email'
    email_configs:
    - to: '[email protected]'

修改完成後可以使用./amtool check-config alertmanager.yml校驗檔案是否正確。

校驗正確啟動alertmanager。`nohup ./alertmanager &`。(第一次啟動可以不使用nohup靜默啟動,方便後面檢視日誌)

我們只定義了一個路由,那就意味著所有由Prometheus產生的告警在傳送到Alertmanager之後都會通過名為`email`的receiver接收。實際上,對於不同級別的告警,會有不同的處理方式,因此在route中,我們還可以定義更多的子Route。具體配置規則大家可以去百度進一步瞭解。
  • 配置Prometheus
    在Prometheus安裝目錄下建立rules資料夾,放置所有的告警規則檔案。

    alerting:
        alertmanagers:
        - static_configs:
            - targets: ['192.168.249.131:9093']
    
    rule_files:
        - rules/*.yml

在rules資料夾下建立告警規則檔案service_down.yml,當伺服器下線時傳送郵件。
groups: - name: ServiceStatus rules: - alert: ServiceStatusAlert expr: up == 0 for: 2m labels: team: node annotations: summary: "Instance {{ $labels.instance }} has bean down" description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 2 minutes." value: "{{ $value }}"

**配置詳解**  

alert:告警規則的名稱。
expr:基於PromQL表示式告警觸發條件,用於計算是否有時間序列滿足該條件。
for:評估等待時間,可選引數。用於表示只有當觸發條件持續一段時間後才傳送告警。在等待期間新產生告警的狀態為PENDING,等待期後為FIRING。
labels:自定義標籤,允許使用者指定要附加到告警上的一組附加標籤。
annotations:用於指定一組附加資訊,比如用於描述告警詳細資訊的文字等,annotations的內容在告警產生時會一同作為引數傳送到Alertmanager。

配置完成後重啟Prometheus,訪問Prometheus檢視告警配置。

  • 測試

關閉node_exporter,過2分鐘就可以收到告警郵件啦,截圖如下:

Alertmanager的告警內容支援使用模板配置,可以使用好看的模板進行渲染,感興趣的可以試試!

The More

node exporter的一些計算語句

  • CPU使用率(單位為percent)
    (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

  • 記憶體已使用(單位為bytes)
    node_memory_MemTotal_bytes - node_memory_MemFree_bytes - node_memory_Cached_bytes - node_memory_Buffers_bytes - node_memory_Slab_bytes

  • 記憶體使用量(單位為bytes/sec)
    node_memory_MemTotal_bytes - node_memory_MemFree_bytes - node_memory_Cached_bytes - node_memory_Buffers_bytes - node_memory_Slab_bytes

  • 記憶體使用率(單位為percent)
    ((node_memory_MemTotal_bytes - node_memory_MemFree_bytes - node_memory_Cached_bytes - node_memory_Buffers_bytes - node_memory_Slab_bytes)/node_memory_MemTotal_bytes) * 100

  • server1的記憶體使用率(單位為percent)
    ((node_memory_MemTotal_bytes{instance="server1"} - node_memory_MemAvailable_bytes{instance="server1"})/node_memory_MemTotal_bytes{instance="server1"}) * 100

  • server2的磁碟使用率(單位為percent)
    ((node_filesystem_size_bytes{fstype=~"xfs|ext4",instance="server2"} - node_filesystem_free_bytes{fstype=~"xfs|ext4",instance="server2"}) / node_filesystem_size_bytes{fstype=~"xfs|ext4",instance="server2"}) * 100

  • uptime時間(單位為seconds)
    time() - node_boot_time

  • server1的uptime時間(單位為seconds)
    time() - node_boot_time_seconds{instance="server1"}

  • 網路流出量(單位為bytes/sec)
    irate(node_network_transmit_bytes_total{device!~"lo|bond[0-9]|cbr[0-9]|veth.*"}[5m]) > 0

  • server1的網路流出量(單位為bytes/sec)
    irate(node_network_transmit_bytes_total{instance="server1", device!~"lo|bond[0-9]|cbr[0-9]|veth.*"}[5m]) > 0

  • 網路流入量(單位為bytes/sec)
    irate(node_network_receive_bytes_total{device!~"lo|bond[0-9]|cbr[0-9]|veth.*"}[5m]) > 0

  • server1的網路流入量(單位為bytes/sec)
    irate(node_network_receive_bytes_total{instance="server1", device!~"lo|bond[0-9]|cbr[0-9]|veth.*"}[5m]) > 0

  • 磁碟讀取速度(單位為bytes/sec)
    irate(node_disk_read_bytes_total{device=~"sd.*"}[5m])

請關注個人公眾號:JAVA日知錄

相關推薦

基於PrometheusGrafana監控平臺 - 告警

通過前面幾篇文章我們搭建好了監控環境並且監控了伺服器、資料庫、應用,運維人員可以實時瞭解當前被監控物件的執行情況,但是他們不可能時時坐在電腦邊上盯著DashBoard,這就需要一個告警功能,當伺服器或應用指標異常時傳送告警,通過郵件或者簡訊的形式告訴運維人員及時處理。 今天我們就來聊聊 基於Prometheu

基於PrometheusGrafana監控平臺 - 環境搭建

相關概念 微服務中的監控分根據作用領域分為三大類,Logging,Tracing,Metrics。 Logging - 用於記錄離散的事件。例如,應用程式的除錯資訊或錯誤資訊。它是我們診斷問題的依據。比如我們說的ELK就是基於Logging。 Metrics - 用於記錄可聚合的資料。例如,佇列的當前深度可

基於PrometheusGrafana進行效能監控_Kubernetes中文社群

1、Prometheus介紹和架構 1.1 Prometheus介紹 Prometheus是一個開源的系統監視和警報工具包,自2012成立以來,許多公司和組織採用了Prometheus。它現在是一個獨立的開源專案,並獨立於任何公司維護。在2016年,Prometheus加入雲端計算基金會作為K

基於PrometheusGrafana打造業務監控看板

## 前言 業務監控對許許多多的場景都是十分有意義,業務監控看板可以讓我們比較直觀的看到當前業務的實時情況,然後運營人員可以根據這些情況及時對業務進行調整操作,避免業務出現大問題。 老黃曾經遇到過一次比較尷尬的“事故”。 其中一條業務線,服務著的其中一個商家,把大部分流量切到另外一個地方去了,而我們的運

使用 Prometheus Grafana 監控 Spark 應用

文章目錄 背景 實現 技術方案 採集資料寫入資料庫 dashboard 配置 效果 相關檔案 參考 背景 每個開發者都想了解自己任務執行時的狀態,便於調優及排錯,Spark 提供的

使用PrometheusGrafana監控服務

Prometheus是一個開源的監控服務,可以用來採集服務的狀態資料,Grafana是一個開源的分析和監控軟體,我最近在配置這些服務來對我們現有的服務以及機器進行監控。這篇文章記錄了配置Prometheus和Grafana的步驟,以便以後查閱使用,本文使用的伺服器是CentOS 7。 安裝Pro

數智慧,基於人工智慧技術的IT智慧平臺

如今人工智慧(AI)非常火熱,運維領域在經歷了去年最火熱的DevOps以後,今年終於迎來了AI與Ops的結合,今天要介紹的一家位於深圳的初創公司——數智慧,就是一家基於AI的IT智慧運維平臺。 提起運維工程師,很多人都會想到“救火隊員”這個詞。的確,當系統(尤其是業務系統)出現問題時,運維人員必須第

利用djangopython構建網路平臺

前言 我主要從事的是網路維護,管理著數百臺的網路裝置。在最初的日子裡,確實會手工一臺一臺敲命令,這種心酸往往只有經歷過的人才能體會。往往工作半天就為了修改一條ACL,不僅效率低,還容易犯錯。後來也會買一些配置軟體,但是一來軟體大多要收費,二來很多不能定製開發,也無法

大資料平臺-----Kerberos環境下Hive及Impala監控指令碼的開發

一、工程目錄二、原理解析    Hive和Impala是兩個最常用的大資料查詢工具,他們的主要區別是Hive適合對實時性要求不太高的業務,對資源的要求較低;而Impala的由於採用了全新的架構,處理速度非常的快,但同樣的也對資源消耗比較大,適合實時性要求高的業務。    在我

Grafana+Prometheus打造springboot監控平臺

1. 環境 springboot 1.5.4 Grafana 5.2.3 Prometheus 2.3.2 jdk 1.8 2.為springboot新增endpoint 在專案pom.xml中新增如下依賴 <dependency> &l

incubator-dolphinscheduler 如何在不寫任何新程式碼的情況下,能快速接入到prometheusgrafana中進行監控

一、prometheus和grafana 簡介 prometheus是由谷歌研發的一款開源的監控軟體,目前已經貢獻給了apache 基金會託管。   監控通常分為白盒監控和黑盒監控之分。   白盒監控:通過監控內部的執行狀態及指標判斷可能會發生的問題,從而做出預判或對其進行優化。   黑盒監控:監控系統或服

基於 Arduino IoT 雲平臺搭建物聯網系統

來看 需要 padding .... nal maker post 分層結構 car 在這篇文章中,我們將介紹如何搭建一款監測土壤水分的物聯網系統,用於在土壤幹燥時發出警報,提醒用戶。本項目使用了IoT 雲平臺來管理警報系統,同時存儲來自傳感器的數據。眾所周知,物聯網是當今

電商大數據平臺案例

blank 之一 order olt 建設 12px img 方案 互聯網 技術棧數據流向平臺規模差異化,隔離化YARN: https://baike.baidu.com/item/yarn/16075826?fr=aladdin 今天先到這兒,希望對您在系統架構設計與評

監控——使用 Python 寫一個小小的專案監控

在公司裡做的一個介面系統,主要是對接第三方的系統介面,所以,這個系統裡會和很多其他公司的專案互動。隨之而來一個很蛋疼的問題,這麼多公司的介面,不同公司介面的穩定性差別很大,訪問量大的時候,有的不怎麼行的介面就各種出錯了。   這個介面系統剛剛開發不久,整個系統中,處於比較邊緣的位置,不像其他專案

TIME_WAITCLOSE_WAIT 小分享-筆記

  相信很多運維工程師遇到過這樣一個情形: 使用者反饋網站訪問巨慢, 網路延遲等問題, 然後就迫切地登入伺服器,終端輸入命令"netstat -a | grep TIME_WAIT | wc -l " 檢視一下, 接著發現有幾百甚至幾千個TIME_WAIT 連線數. 頓時慌了~, 接著嘗

02-SpringBoot監控

1. pom.xml新增actuator依賴 <dependency> <groupId>org.springframework.boot</groupId>

Shell_tomcat重啟快取清除_Linux筆記

開始做運維的時候經常會遇到重啟tomcat、重新部署專案包等情況,為減少其他因素帶來影響,就需要每次啟動都要清除一下tomcat執行的快取檔案,這樣問題就出來了,這個重複勞動沒技術含量,也怕刪錯檔案,就想這個tomcat為什麼不能新增到服務呢?那樣就能使用service

張輝:“智慧網路構建高效雲端計算平臺” –

由工業和資訊化部指導,中國資訊通訊研究院主辦,業界知名組織雲端計算開源產業聯盟(OSCAR)承辦的2017全球雲端計算開源大會於4月19日-20日在北京國家會議中心順利召開。本文為本屆大會嘉賓分享的大會演講速記內容,敬請瀏覽。 嘉賓介紹:張輝 公司職務:Mellanox公司亞太區解決方案營銷總監

餘額寶11.11:基於日誌資料分析的高效

“雙十一”剛剛結束,其實最緊張的不是商鋪理貨,也不是網友緊盯大促商品準備秒殺,而是網購幕後的運維人員,他們最擔心:什麼網路中斷、應用卡頓、響應速度慢,伺服器宕機…… 雙十一作為電商 IT 部門的頭等大事,大促前,運維人員就需要早早地做好多套預備方案,並時刻緊繃著神經,經歷著上百次模擬演練。他們在後端

朱榮澤:“統一儲存,為雲而生——基於Ceph的儲存全家桶” –

由工業和資訊化部指導,中國資訊通訊研究院主辦,業界知名組織雲端計算開源產業聯盟(OSCAR)承辦的2017全球雲端計算開源大會於4月19日-20日在北京國家會議中心順利召開。本文為本屆大會嘉賓分享的大會演講速記內容,敬請瀏覽。 嘉賓介紹:朱榮澤 公司職務:UMCloud儲存產品部門總監 大會演講速