DevOps課程-Prometheus 5
前一篇講解了Grafana的資訊顯示
但是我們並不會一直等在Grafana的web介面等待異常的出現
而是當Cluster有任何異常的時候由系統自動通知我們
不管是經由email,slack,或其他通知方式
然後我們再去Grafana的Dashboard上查找異常
所以我們應該要可以自行定義監控的事項,用以通知我們異常狀況的出現
例如:
- CPU使用率超過50%
- Pod無法正常建立
而告警部分在Prometheus有兩大塊:
- 1.定義要因為什麼而通知告警(在Prometheus Server中定義告警規則,如上面狀況就發出通知)
- 2.寄送通知(設置Alertmanager,讓它寄送通知到email,slack...等等)
我們可能可以從Grafana觀察可以大概推斷Cluster的使用率:
假設平常可能只有20~40%就是MAX了
那麼我們就可以嘗試設置一個超過50%即觸發的通知
Alert: when CPU > 50%
在學設置Alert前,先來看看既有的Alert Rules
既有的Alert Rules:
首先進到Prometheus頁面
往下拉還有很多預設的Alert:
然後顯示上
而有觸發的:
firing表示:Alert已經通知給Alertmanager去了,所以Alertmanager可以進一步進行相關的通知
而實際Alert的設置結構則是可以點開看到:
如上圖,結構上非常清晰
其中觸發的邏輯表示式,即PromQL:
首先我們要知道的是如上的Metrics部分是
"alertmanager_config_last_reload_successful"
這個是Alertmanager最近一次重新載入設定檔是否成功
這是真的存在的Metrics:
然後帶有相關的filter過濾條件:
job=”monitoring-kube-prometheus-alertmanager”,namespace=”monitoring”
然後前面還有一個PromQL的Function:
max_over_time
這些Finction可以到官網查找:
#在Graph頁面執行,其中:
max_over_time(alertmanager_config_last_reload_successful{job="monitoring-kube-prometheus-alertmanager",namespace="monitoring"}[5m])#max_over_time這個Function是找出某一段時間內的最大數值,所以要給如上像是5分鐘
上面最後得到的數值"1"即表示我們有成功的reload
在Alert那邊的Rule最後用"==1"做邏輯判斷
也可以在Prometheus的Graph執行一樣判斷式:
如上Query結果是Empty query result即代表沒有吻合的結果
這也是Alert那邊是綠色的原因(沒有match到Alert的規則,i.e.觸發Alert)
另外可以看到另一項Alert的項目:
這個Alert是計算比例:
其中還要特別注意到的是Alert項目的labels的severity層級
有些Alert會有特別嚴重的結果,所以標示上也會特別嚴重
另外後面會講到這個labels還可以自己塞自己定義的
這樣就可以為不同的Alert做一定程度的分類(比如嚴重程度等)
然後如上也可以依據是critical或是warning來做不同的通知(email或slack)
或是namespace="dev"的rule,則傳送到slack某個頻道等
再來還有"for":
這個表示條件有吻合了,但是以K8S來說,K8S會有自動復原等機制
所以可以設置"for"來等待一段時間
如果有真的吻合條件者,會跑到上面的"Pending"區塊
如上例來說會等待10分鐘,如果10分鐘後在檢查還是符合條件者
才真的送出通知
若真的有Alert真的發出了,就會統計到上面的"Firing"如下圖:
每一項Alert的設置還有"annotation"區塊,裡面記載了其Alert的描述
其中寄出的內容會有上面的變數
可以告知到底是哪一個namespace,哪一個pod有問題
如上範例的還提供了URL可以獲得該Alert設置的詳細解說還有解決辦法
另外左上也可以過濾:
