DevOps課程-Prometheus 7
前一篇筆記我們學會Alert Rule的撰寫
在來就是要知道如何把它設置進去Prometheus內實際運作使用
這邊可以進到以下地方看到:
而實際上我們並不需要到上述那個ConfigMap元件裡面
去新增我們寫好的Rule
因為我們是用Prometheus的Operator並運行在K8S Cluster內
所以這類Alert Rule設置可以透過CRD元件來處理設置
也就是說如果我們不是透過Operator運行在K8S內
可能就真的要到那個路徑的ConfigMap元件內去新增Rule的yaml檔
然後甚至需要重新載入Prometheus讓其生效
這也就是運行在K8S Cluster之外的方式
但是我們這邊情況是透過Prometheus Operator並擴展了K8S API
我們可以建立客製化的K8S資源
而Operator會讀取我們定義的K8S資源,告訴Prometheus要重新載入Rule
所以這邊我們就直接撰寫這個"custom K8S resource"在同一份yaml檔案內
#可以透過以下指令看到Prometheus Operator擴增的K8S api-resources:
kubectl api-resources
我自己查一下這個的yaml設定檔寫法是在:
連到Operator的Github:
另外講師後面也提供查找相關文件的另一種方式
但是是事前知道apiVersion
先改OCP版本:
然後就會看到這個元件的YAML規格了:
往下看到spec部分的寫法等
首先:
然後rules部分:
如上可以看到rules也是複數的
並且很剛好的內容就對應到前一篇寫的Alert Rule,所以整份改撰寫如下:
這邊再撰寫第二個Alert Rule:
也就是前篇提到的Pod無法啟動的部分
其中metric是用"kube_pod_container_status_restarts_total"
然後條件可能是大於五次:
再來annotations.description部分參考看到:
再來我們可能會想要只偵測特定的元件遵守上述的Alert Rule
而不是所有的K8S元件都遵守到這兩個規則
這時候可以在這個Alert Rule的設定檔內再增加指定Label:
此時完整的整份檔案如下:
實際應用上面寫好的Alert Rule:
#透過kubectl工具apply上述檔案(檔案內已經有寫指定的namespace了):
kubectl apply -f alert-rules.yaml
#確認方式:
kubectl get PrometheusRule -n monitoring
這時候我們應該要可以預期
Prometheus Operator會幫我們把新的Alert Rule載入
不過這可能要一點時間,然後看到:
但是如果有問題的話可以看看Prometheus的Pod的log
先找到這個Pod
#查找monitoring這個namespace有什麼pod:
kubectl get pod -n monitoring
可以看到裡面有兩個Container,一個是Prometheus本身
另一個是reload設定檔的!
#取得log,先看看有那些Container在裡面,我這邊它沒拋錯(要指定Container的錯):
kubectl get {pod名} -n monitoring#所以也可以先透過describe指令先看有什麼Container名稱:
kubectl describe pod prometheus-monitoring-kube-prometheus-prometheus-0 -n monitoring#指定到Container:
kubectl logs prometheus-monitoring-kube-prometheus-prometheus-0 -n monitoring -c config-reloader
#這邊也看看另一個主要Container的log:
kubectl logs prometheus-monitoring-kube-prometheus-prometheus-0 -n monitoring -c prometheus
也就是最終剛剛看到的兩個Alert Rule,都在main-rules這個群組內:
