DevOps課程-Prometheus 11
整理目前課程建置的指令
#建立Cluster:
eksctl create cluster#取得目前現有哪些Cluster及其名稱:
eksctl get cluster#對應課程結束移除(課上完才跑):
eksctl delete cluster --name {cluster名稱}#這邊建置直接使用default的namespace建立要觀察的微服務系統:
kubectl apply -f config-best-practices.yaml#安裝指令整理,增加Repo位置(如果本機沒做過的話):
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts#更新Repo內容(如果本機沒做過的話):
helm repo update#建立Prometheus專用的namespace:
kubectl create namespace monitoring#安裝Prometheus Chart,並給予名稱為monitoring,並安裝到monitoring ns裡面:
helm install {名稱,這邊一樣給monitoring} {Repo名稱}/{chart名稱,叫kube-prometheus-stack} -n {指定的namespace}#整理上述對應的指令即如下(大概10分鐘),有時候久了會清cache,要重做上面update:
helm install monitoring prometheus-community/kube-prometheus-stack -n monitoring#將Prometheus Web UI服務可以透過本機連通,把本機對應PORT往前推到遠端服務:
kubectl port-forward {元件名稱} {執行kubectl指令本機PORT}:{這個元件PORT} -n monitoring &#上面Prometheus Web UI使用PORT是9090,所以組出來的指令類似:
kubectl port-forward service/monitoring-kube-prometheus-prometheus 9090:9090 -n monitoring &#上述執行後即可訪問本機127.0.0.1:9090 會自動導到遠端Prometheus Web#同理Grafana的Web UI:
kubectl port-forward service/monitoring-grafana 8080:80 -n monitoring &#上述執行後,可以瀏覽127.0.0.1:8080,預設帳密是admin/prom-operator#透過kubectl工具建立寫好的Alert Rule(檔案內已經有寫指定的namespace了):
kubectl apply -f alert-rules.yaml#確認現有Alert Rule方式:
kubectl get PrometheusRule -n monitoring#查看建立Alert Rule的過程,指定到Container:
kubectl logs prometheus-monitoring-kube-prometheus-prometheus-0 -n monitoring -c config-reloader#另一個主要Container的log也有建立Alert Rule的log可以看:
kubectl logs prometheus-monitoring-kube-prometheus-prometheus-0 -n monitoring -c prometheus#起一個cpu壓測的pod(吃4core,持續30秒):
kubectl run cpu-test --image=docker.io/containerstack/cpustress -- --cpu 4 --timeout 30s --metrics-brief
#############Alertmanager部分######################查找Alertmanager的service:
kubectl get svc -n monitoring#將Alertmanager的服務進行forward:
kubectl port-forward svc/monitoring-kube-prometheus-alertmanager 9093:9093 -n monitoring &#透過以下指令拿到Alertmanager完整設定檔內容(但是有base64加密):
kubectl get secret alertmanager-monitoring-kube-prometheus-alertmanager-generated -n monitoring -o yaml#後面就是自定義設定檔的部分:
#如果像講師畫面一樣只有alertmanager.yaml,沒有gz的話,可透過以下bash指令解密:
echo {後面那一長串} | base64 --decode#如上,我的看到是"alertmanager.yaml.gz",所以解密要變成:
echo {後面那一長串} | base64 --decode | gzip -d#建立寄送通知使用的gmail的密碼,但首先要先對密碼做base64加密,放到Secret的YAML:
echo "密碼" | base64#寫好Secret後建立:
kubectl apply -f email-secret.yaml#然後寫好Alertmanager的Config的YAML執行建立:
kubectl apply -f alert-manager-configuration.yaml#確認上述建立的物件:
kubectl get alertmanagerconfig -n monitoring#確認先找到Alertmanager的Pod:
kubectl get pod -n monitoring#執行查看pod內容,順便看看有甚麼container在裡面:
kubectl describe pod alertmanager-monitoring-kube-prometheus-alertmanager-0 -n monitoring#找到Pod後就可以查看log,先看alertmanager:
kubectl logs alertmanager-monitoring-kube-prometheus-alertmanager-0 -c alertmanager -n monitoring#再看config-reloader:
kubectl logs alertmanager-monitoring-kube-prometheus-alertmanager-0 -c config-reloader -n monitoring
上面設置後
#建立個會觸發CPU偏高的Alert的pod(吃4core,持續60秒):
kubectl run cpu-test --image=docker.io/containerstack/cpustress -- --cpu 4 --timeout 60s --metrics-brief
過一分鐘左右看到紅了:
這時候進到Alertmanager的頁面,有個url位置是(實際架設的話,host記得改):
http://127.0.0.1:9093/api/v2/alerts
看到(用HostHighCpuLoad來查找):
把上面其中json有關HostHighCpuLoad部分拿出來看:
會看到我們設置的內容有一些對應,描述,對應的receivers,alertname等:
這邊看講師就會在gmail上看到信件
(但是我的那個安全性機制沒辦法啟用,所以看不到)
如果像我這樣有寄件問題,可以去查看
#查看Alertmanager裡面的log,應該會寫:Username & password等問題:
kubectl logs alertmanager-monitoring-kube-prometheus-alertmanager-0 -c alertmanager -n monitoring
上圖最後有提示可以去查看以下google解說:
最後一樣會看到我無法啟用"低安全性應用程式存取權"
然後在Alertmanager頁面也可以看到(http://127.0.0.1:9093/):
那個json頁也會看到異常的pod:
透過通知機制,人就不用一直盯著Grafana頁面等異常出來
