Kubernetes之Prometheus監控實戰

Kubernetes之Prometheus監控實戰

Prometheus服務監控介紹

對於運維開發人員來說，不管是哪個平臺服務，監控都是非常關鍵重要的。

在傳統服務裏面，我們通常會到zabbix、open-falcon、netdata來做服務的監控，但對於目前主流的K8s平臺來說，由於服務pod會被調度到任何機器上運行，且pod掛掉後會被自動重啓，並且我們也需要有更好的自動服務發現功能來實現服務報警的自動接入，實現更高效的運維報警，這裏我們需要用到K8s的監控實現Prometheus，它是基於Google內部監控系統的開源實現。

Prometheus架構圖

Prometheus是由golang語言編寫，這樣它的部署實際上是比較簡單的，就一個服務的二進制包加上對應的配置文件即可運行，然而這種方式的部署過程繁瑣並且效率低下，我們這裏就不以這種傳統的形式來部署Prometheus來實現K8s集羣的監控了，而是會用到Prometheus-Operator來進行Prometheus監控服務的安裝，這也是我們生產中常用的安裝方式。

從本質上來講Prometheus屬於是典型的有狀態應用，而其有包含了一些自身特有的運維管理和配置管理方式。而這些都無法通過Kubernetes原生提供的應用管理概念實現自動化。爲了簡化這類應用程序的管理複雜度，CoreOS率先引入了Operator的概念，並且首先推出了針對在Kubernetes下運行和管理Etcd的Etcd Operator。並隨後推出了Prometheus Operator。

Prometheus Operator的工作原理

從概念上來講Operator就是針對管理特定應用程序的，在Kubernetes基本的Resource和Controller的概念上，以擴展Kubernetes api的形式。幫助用戶創建，配置和管理複雜的有狀態應用程序。從而實現特定應用程序的常見操作以及運維自動化。

在Kubernetes中我們使用Deployment、DamenSet，StatefulSet來管理應用Workload，使用Service，Ingress來管理應用的訪問方式，使用ConfigMap和Secret來管理應用配置。我們在集羣中對這些資源的創建，更新，刪除的動作都會被轉換爲事件(Event)，Kubernetes的Controller Manager負責監聽這些事件並觸發相應的任務來滿足用戶的期望。這種方式我們成爲聲明式，用戶只需要關心應用程序的最終狀態，其它的都通過Kubernetes來幫助我們完成，通過這種方式可以大大簡化應用的配置管理複雜度。

而除了這些原生的Resource資源以外，Kubernetes還允許用戶添加自己的自定義資源(Custom Resource)。並且通過實現自定義Controller來實現對Kubernetes的擴展。

如下所示，是Prometheus Operator的架構示意圖：

Prometheus的本質就是一組用戶自定義的CRD資源以及Controller的實現，Prometheus Operator負責監聽這些自定義資源的變化，並且根據這些資源的定義自動化地完成如Prometheus Server自身以及配置的自動化管理工作。

Prometheus Operator能做什麼

要了解Prometheus Operator能做什麼，其實就是要了解Prometheus Operator爲我們提供了哪些自定義的Kubernetes資源，列出了Prometheus Operator目前提供的️4類資源：

• Prometheus：聲明式創建和管理Prometheus Server實例；
• ServiceMonitor：負責聲明式的管理監控配置；
• PrometheusRule：負責聲明式的管理告警配置；
• Alertmanager：聲明式的創建和管理Alertmanager實例。

簡言之，Prometheus Operator能夠幫助用戶自動化的創建以及管理Prometheus Server以及其相應的配置。

實戰操作篇之部署監控Prometheus Operator

在K8s集羣中部署Prometheus Operator

我們這裏用prometheus-operator來安裝整套prometheus服務，建議直接用master分支即可，這也是官方所推薦的

https://github.com/prometheus-operator/kube-prometheus

開始安裝

> 安裝包和離線鏡像包下載
>
>
> https://cloud.189.cn/t/bM7f2aANnMVb (訪問碼:0nsj)

1. 解壓下載的代碼包
unzip kube-prometheus-master.zip
rm -f kube-prometheus-master.zip && cd kube-prometheus-master

2. 這裏建議先看下有哪些鏡像，便於在下載鏡像快的節點上先收集好所有需要的離線docker鏡像
# find ./ -type f |xargs grep 'image: '|sort|uniq|awk '{print $3}'|grep ^[a-zA-Z]|grep -Evw 'error|kubeRbacProxy'|sort -rn|uniq
quay.io/prometheus/prometheus:v2.22.1
quay.io/prometheus-operator/prometheus-operator:v0.43.2
quay.io/prometheus/node-exporter:v1.0.1
quay.io/prometheus/alertmanager:v0.21.0
quay.io/fabxc/prometheus_demo_service
quay.io/coreos/kube-state-metrics:v1.9.7
quay.io/brancz/kube-rbac-proxy:v0.8.0
grafana/grafana:7.3.4
gcr.io/google_containers/metrics-server-amd64:v0.2.01
directxman12/k8s-prometheus-adapter:v0.8.2

在測試的幾個node上把這些離線鏡像包都導入 docker load -i xxx.tar

3. 開始創建所有服務
kubectl create -f manifests/setup
kubectl create -f manifests/
過一會查看創建結果：
kubectl -n monitoring get all

# 附：清空上面部署的prometheus所有服務：
kubectl delete --ignore-not-found=true -f manifests/ -f manifests/setup

訪問下prometheus的UI

# 修改下prometheus UI的service模式，便於我們訪問
# kubectl -n monitoring patch svc prometheus-k8s -p '{"spec":{"type":"NodePort"}}'
service/prometheus-k8s patched

# kubectl -n monitoring get svc prometheus-k8s 
NAME             TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
prometheus-k8s   NodePort   10.68.23.79   <none>        9090:22129/TCP   7m43s

點擊上方菜單欄Status --- Targets ，我們發現kube-controller-manager和kube-scheduler未發現

monitoring/kube-controller-manager/0 (0/0 up) 
monitoring/kube-scheduler/0 (0/0 up) 

接下來我們解決下這一個碰到的問題吧

> 注：如果發現下面不是監控的127.0.0.1，並且通過下面地址可以獲取metric指標輸出，那麼這個改IP這一步可以不用操作
>
> curl 10.0.1.201:10251/metrics curl 10.0.1.201:10252/metrics

# 這裏我們發現這兩服務監聽的IP是127.0.0.1
# ss -tlnp|egrep 'controller|schedule'
LISTEN     0      32768  127.0.0.1:10251                    *:*                   users:(("kube-scheduler",pid=567,fd=5))
LISTEN     0      32768  127.0.0.1:10252                    *:*                   users:(("kube-controller",pid=583,fd=5))

問題定位到了，接下來先把兩個組件的監聽地址改爲0.0.0.0

# 如果大家前面是按我設計的4臺NODE節點，其中2臺作master的話，那就在這2臺master上把systemcd配置改一下
# 我這裏第一臺master  10.0.1.201
# sed -ri 's+127.0.0.1+0.0.0.0+g' /etc/systemd/system/kube-controller-manager.service 
# sed -ri 's+127.0.0.1+0.0.0.0+g' /etc/systemd/system/kube-scheduler.service
# systemctl daemon-reload
# systemctl restart kube-controller-manager.service
# systemctl restart kube-scheduler.service 

# 我這裏第二臺master  10.0.1.202
# sed -ri 's+127.0.0.1+0.0.0.0+g' /etc/systemd/system/kube-controller-manager.service 
# sed -ri 's+127.0.0.1+0.0.0.0+g' /etc/systemd/system/kube-scheduler.service
# systemctl daemon-reload
# systemctl restart kube-controller-manager.service
# systemctl restart kube-scheduler.service 

# 獲取下metrics指標看看
curl 10.0.1.201:10251/metrics
curl 10.0.1.201:10252/metrics

然後因爲K8s的這兩上核心組件我們是以二進制形式部署的，爲了能讓K8s上的prometheus能發現，我們還需要來創建相應的service和endpoints來將其關聯起來

> 注意：我們需要將endpoints裏面的NODE IP換成我們實際情況的

apiVersion: v1
kind: Service
metadata:
  namespace: kube-system
  name: kube-controller-manager
  labels:
    k8s-app: kube-controller-manager
spec:
  type: ClusterIP
  clusterIP: None
  ports:
  - name: http-metrics
    port: 10252
    targetPort: 10252
    protocol: TCP

---
apiVersion: v1
kind: Endpoints
metadata:
  labels:
    k8s-app: kube-controller-manager
  name: kube-controller-manager
  namespace: kube-system
subsets:
- addresses:
  - ip: 10.0.1.201
  - ip: 10.0.1.202
  ports:
  - name: http-metrics
    port: 10252
    protocol: TCP

---

apiVersion: v1
kind: Service
metadata:
  namespace: kube-system
  name: kube-scheduler
  labels:
    k8s-app: kube-scheduler
spec:
  type: ClusterIP
  clusterIP: None
  ports:
  - name: http-metrics
    port: 10251
    targetPort: 10251
    protocol: TCP

---
apiVersion: v1
kind: Endpoints
metadata:
  labels:
    k8s-app: kube-scheduler
  name: kube-scheduler
  namespace: kube-system
subsets:
- addresses:
  - ip: 10.0.1.201
  - ip: 10.0.1.202
  ports:
  - name: http-metrics
    port: 10251
    protocol: TCP

將上面的yaml配置保存爲repair-prometheus.yaml，然後創建它

kubectl apply -f repair-prometheus.yaml

創建完成後確認下

# kubectl -n kube-system get svc |egrep 'controller|scheduler'
kube-controller-manager   ClusterIP   None            <none>        10252/TCP                      58s
kube-scheduler            ClusterIP   None            <none>        10251/TCP                      58s

記得還要修改一個地方

# kubectl -n monitoring edit servicemonitors.monitoring.coreos.com kube-scheduler 
# 將下面兩個地方的https換成http
    port: https-metrics
    scheme: https

# kubectl -n monitoring edit servicemonitors.monitoring.coreos.com kube-controller-manager
# 將下面兩個地方的https換成http
    port: https-metrics
    scheme: https

然後再返回prometheus UI處，耐心等待幾分鐘，就能看到已經被發現了

monitoring/kube-controller-manager/0 (2/2 up) 
monitoring/kube-scheduler/0 (2/2 up) 

使用prometheus來監控ingress-nginx

我們前面部署過ingress-nginx，這個是整個K8s上所有服務的流量入口組件很關鍵，因此把它的metrics指標收集到prometheus來做好相關監控至關重要，因爲前面ingress-nginx服務是以daemonset形式部署的，並且映射了自己的端口到宿主機上，那麼我可以直接用pod運行NODE上的IP來看下metrics

curl 10.0.1.201:10254/metrics

創建 servicemonitor配置讓prometheus能發現ingress-nginx的metrics

# vim servicemonitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app: ingress-nginx
  name: nginx-ingress-scraping
  namespace: ingress-nginx
spec:
  endpoints:
  - interval: 30s
    path: /metrics
    port: metrics
  jobLabel: app
  namespaceSelector:
    matchNames:
    - ingress-nginx
  selector:
    matchLabels:
      app: ingress-nginx

創建它

# kubectl apply -f servicemonitor.yaml 
servicemonitor.monitoring.coreos.com/nginx-ingress-scraping created
# kubectl -n ingress-nginx get servicemonitors.monitoring.coreos.com 
NAME                     AGE
nginx-ingress-scraping   8s

指標一直沒收集上來，看看proemtheus服務的日誌，發現報錯如下：

# kubectl -n monitoring logs prometheus-k8s-0 -c prometheus |grep error

level=error ts=2020-12-13T09:52:35.565Z caller=klog.go:96 component=k8s_client_runtime func=ErrorDepth msg="/app/discovery/kubernetes/kubernetes.go:426: Failed to watch *v1.Endpoints: failed to list *v1.Endpoints: endpoints is forbidden: User \"system:serviceaccount:monitoring:prometheus-k8s\" cannot list resource \"endpoints\" in API group \"\" in the namespace \"ingress-nginx\""

需要修改prometheus的clusterrole

#   kubectl edit clusterrole prometheus-k8s
#------ 原始的rules -------
rules:
- apiGroups:
  - ""
  resources:
  - nodes/metrics
  verbs:
  - get
- nonResourceURLs:
  - /metrics
  verbs:
  - get
#---------------------------

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-k8s
rules:
- apiGroups:
  - ""
  resources:
  - nodes
  - services
  - endpoints
  - pods
  - nodes/proxy
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - configmaps
  - nodes/metrics
  verbs:
  - get
- nonResourceURLs:
  - /metrics
  verbs:
  - get
  

再到prometheus UI上看下，發現已經有了

ingress-nginx/nginx-ingress-scraping/0 (1/1 up) 

使用Prometheus來監控二進制部署的ETCD集羣

作爲K8s所有資源存儲的關鍵服務ETCD，我們也有必要把它給監控起來，正好借這個機會，完整的演示一次利用Prometheus來監控非K8s集羣服務的步驟

在前面部署K8s集羣的時候，我們是用二進制的方式部署的ETCD集羣，並且利用自簽證書來配置訪問ETCD，正如前面所說，現在關鍵的服務基本都會留有指標metrics接口支持prometheus的監控，利用下面命令，我們可以看到ETCD都暴露出了哪些監控指標出來

# curl --cacert /etc/kubernetes/ssl/ca.pem --cert /etc/etcd/ssl/etcd.pem  --key /etc/etcd/ssl/etcd-key.pem https://10.0.1.201:2379/metrics

上面查看沒問題後，接下來我們開始進行配置使ETCD能被prometheus發現並監控

# 首先把ETCD的證書創建爲secret
kubectl -n monitoring create secret generic etcd-certs --from-file=/etc/etcd/ssl/etcd.pem   --from-file=/etc/etcd/ssl/etcd-key.pem   --from-file=/etc/kubernetes/ssl/ca.pem

# 接着在prometheus裏面引用這個secrets
kubectl -n monitoring edit prometheus k8s 

spec:
...
  secrets:
  - etcd-certs

# 保存退出後，prometheus會自動重啓服務pod以加載這個secret配置，過一會，我們進pod來查看下是不是已經加載到ETCD的證書了
# kubectl -n monitoring exec -it prometheus-k8s-0 -c prometheus  -- sh 
/prometheus $ ls /etc/prometheus/secrets/etcd-certs/
ca.pem        etcd-key.pem  etcd.pem

接下來準備創建service、endpoints以及ServiceMonitor的yaml配置

> 注意替換下面的NODE節點IP爲實際ETCD所在NODE內網IP

# vim prometheus-etcd.yaml 
apiVersion: v1
kind: Service
metadata:
  name: etcd-k8s
  namespace: monitoring
  labels:
    k8s-app: etcd
spec:
  type: ClusterIP
  clusterIP: None
  ports:
  - name: api
    port: 2379
    protocol: TCP
---
apiVersion: v1
kind: Endpoints
metadata:
  name: etcd-k8s
  namespace: monitoring
  labels:
    k8s-app: etcd
subsets:
- addresses:
  - ip: 10.0.1.201
  - ip: 10.0.1.202
  - ip: 10.0.1.203
  ports:
  - name: api
    port: 2379
    protocol: TCP
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: etcd-k8s
  namespace: monitoring
  labels:
    k8s-app: etcd-k8s
spec:
  jobLabel: k8s-app
  endpoints:
  - port: api
    interval: 30s
    scheme: https
    tlsConfig:
      caFile: /etc/prometheus/secrets/etcd-certs/ca.pem
      certFile: /etc/prometheus/secrets/etcd-certs/etcd.pem
      keyFile: /etc/prometheus/secrets/etcd-certs/etcd-key.pem
      #use insecureSkipVerify only if you cannot use a Subject Alternative Name
      insecureSkipVerify: true 
  selector:
    matchLabels:
      k8s-app: etcd
  namespaceSelector:
    matchNames:
    - monitoring

開始創建上面的資源

# kubectl apply -f prometheus-etcd.yaml 
service/etcd-k8s created
endpoints/etcd-k8s created
servicemonitor.monitoring.coreos.com/etcd-k8s created

過一會，就可以在prometheus UI上面看到ETCD集羣被監控了

monitoring/etcd-k8s/0 (3/3 up) 

接下來我們用grafana來展示被監控的ETCD指標

1. 在grafana官網模板中心搜索etcd，下載這個json格式的模板文件
https://grafana.com/dashboards/3070

2.然後打開自己先部署的grafana首頁，
點擊左邊菜單欄四個小正方形方塊HOME --- Manage
再點擊右邊 Import dashboard --- 
點擊Upload .json File 按鈕，上傳上面下載好的json文件 etcd_rev3.json，
然後在prometheus選擇數據來源
點擊Import，即可顯示etcd集羣的圖形監控信息

prometheus監控數據以及grafana配置持久化存儲配置

這節實戰課給大家講解下如果配置prometheus以及grafana的數據持久化。

prometheus數據持久化配置

# 注意這下面的statefulset服務就是我們需要做數據持久化的地方
# kubectl -n monitoring get statefulset,pod|grep prometheus-k8s
statefulset.apps/prometheus-k8s      2/2     5h41m
pod/prometheus-k8s-0                       2/2     Running   1          19m
pod/prometheus-k8s-1                       2/2     Running   1          19m

# 看下我們之前準備的StorageClass動態存儲
# kubectl get sc
NAME       PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
nfs-boge   nfs-provisioner-01   Retain          Immediate           false                  4d

# 準備prometheus持久化的pvc配置
# kubectl -n monitoring edit prometheus k8s

spec:
......
  storage:
    volumeClaimTemplate:
      spec:
        accessModes: [ "ReadWriteOnce" ]
        storageClassName: "nfs-boge"
        selector:
          matchLabels:
            app: my-example-prometheus
        resources:
          requests:
            storage: 1Gi

# 上面修改保存退出後，過一會我們查看下pvc創建情況，以及pod內的數據掛載情況
# kubectl -n monitoring get pvc
NAME                                 STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
prometheus-k8s-db-prometheus-k8s-0   Bound    pvc-055e6b11-31b7-4503-ba2b-4f292ba7bd06   1Gi        RWO            nfs-boge       17s
prometheus-k8s-db-prometheus-k8s-1   Bound    pvc-249c344b-3ef8-4a5d-8003-b8ce8e282d32   1Gi        RWO            nfs-boge       17s


# kubectl -n monitoring exec -it prometheus-k8s-0 -c prometheus -- sh
/prometheus $ df -Th
......
10.0.1.201:/nfs_dir/monitoring-prometheus-k8s-db-prometheus-k8s-0-pvc-055e6b11-31b7-4503-ba2b-4f292ba7bd06/prometheus-db
                     nfs4           97.7G      9.4G     88.2G  10% /prometheus

grafana配置持久化存儲配置

# 保存pvc爲grafana-pvc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: grafana
  namespace: monitoring
spec:
  storageClassName: nfs-boge
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

# 開始創建pvc
# kubectl apply -f grafana-pvc.yaml 

# 看下創建的pvc
# kubectl -n monitoring get pvc
NAME                                 STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
grafana                              Bound    pvc-394a26e1-3274-4458-906e-e601a3cde50d   1Gi        RWX            nfs-boge       3s
prometheus-k8s-db-prometheus-k8s-0   Bound    pvc-055e6b11-31b7-4503-ba2b-4f292ba7bd06   1Gi        RWO            nfs-boge       6m46s
prometheus-k8s-db-prometheus-k8s-1   Bound    pvc-249c344b-3ef8-4a5d-8003-b8ce8e282d32   1Gi        RWO            nfs-boge       6m46s


# 編輯grafana的deployment資源配置
# kubectl -n monitoring edit deployments.apps grafana 

# 舊的配置
      volumes:
      - emptyDir: {}
        name: grafana-storage
# 替換成新的配置
      volumes:
      - name: grafana-storage
        persistentVolumeClaim:
          claimName: grafana

# 同時加入下面的env環境變量，將登陸密碼進行固定修改
    spec:
      containers:
      ......
        env:
        - name: GF_SECURITY_ADMIN_USER
          value: admin
        - name: GF_SECURITY_ADMIN_PASSWORD
          value: admin321

# 過一會，等grafana重啓完成後，用上面的新密碼進行登陸
# kubectl -n monitoring get pod -w|grep grafana
grafana-5698bf94f4-prbr2               0/1     Running   0          3s
grafana-5698bf94f4-prbr2               1/1     Running   0          4s

# 因爲先前的數據並未持久化，所以會發現先導入的ETCD模板已消失，這時重新再導入一次，後面重啓也不會丟了

Prometheus發送報警

大家好，我是博哥愛運維。早期我們經常用郵箱接收報警郵件，但是報警不及時，而且目前各雲平臺對郵件發送限制還比較嚴格，所以目前在生產中用得更爲多的是基於webhook來轉發報警內容到企業中用的聊天工具中，比如釘釘、企業微信、飛書等。

prometheus的報警組件是Alertmanager，它支持自定義webhook的方式來接受它發出的報警，它發出的日誌json字段比較多，我們需要根據需要接收的app來做相應的日誌清洗轉發

這裏博哥將用golang結合Gin網絡框架來編寫一個日誌清洗轉發工具，分別對這幾種常用的報警方式作詳細地說明及實戰

> 下載boge-webhook.zip
>
>
> https://cloud.189.cn/t/B3EFZvnuMvuu (訪問碼:h1wx)

首先看下報警規則及報警發送配置是什麼樣的

prometheus-operator的規則非常齊全，基本屬於開箱即用類型，大家可以根據日常收到的報警，對裏面的rules報警規則作針對性的調整，比如把報警觀察時長縮短一點等

監控報警規劃修改   vim ./manifests/prometheus/prometheus-rules.yaml
修改完成記得更新   kubectl apply -f ./manifests/prometheus/prometheus-rules.yaml
# 通過這裏可以獲取需要創建的報警配置secret名稱
# kubectl -n monitoring edit statefulsets.apps alertmanager-main
...
      volumes:
      - name: config-volume
        secret:
          defaultMode: 420
          secretName: alertmanager-main
...

# 注意事先在配置文件 alertmanager.yaml 裏面編輯好收件人等信息 ，再執行下面的命令

kubectl create secret generic  alertmanager-main --from-file=alertmanager.yaml -n monitoring

報警配置文件 alertmanager.yaml

# global塊配置下的配置選項在本配置文件內的所有配置項下可見
global:
  # 在Alertmanager內管理的每一條告警均有兩種狀態: "resolved"或者"firing". 在altermanager首次發送告警通知後, 該告警會一直處於firing狀態,設置resolve_timeout可以指定處於firing狀態的告警間隔多長時間會被設置爲resolved狀態, 在設置爲resolved狀態的告警後,altermanager不會再發送firing的告警通知.
#  resolve_timeout: 1h
  resolve_timeout: 10m

  # 告警通知模板
templates:
- '/etc/altermanager/config/*.tmpl'

# route: 根路由,該模塊用於該根路由下的節點及子路由routes的定義. 子樹節點如果不對相關配置進行配置，則默認會從父路由樹繼承該配置選項。每一條告警都要進入route，即要求配置選項group_by的值能夠匹配到每一條告警的至少一個labelkey(即通過POST請求向altermanager服務接口所發送告警的labels項所攜帶的<labelname>)，告警進入到route後，將會根據子路由routes節點中的配置項match_re或者match來確定能進入該子路由節點的告警(由在match_re或者match下配置的labelkey: labelvalue是否爲告警labels的子集決定，是的話則會進入該子路由節點，否則不能接收進入該子路由節點).
route:
  # 例如所有labelkey:labelvalue含cluster=A及altertname=LatencyHigh labelkey的告警都會被歸入單一組中
  group_by: ['job', 'altername', 'cluster', 'service','severity']
  # 若一組新的告警產生，則會等group_wait後再發送通知，該功能主要用於當告警在很短時間內接連產生時，在group_wait內合併爲單一的告警後再發送
#  group_wait: 30s
  group_wait: 10s
  # 再次告警時間間隔
#  group_interval: 5m
  group_interval: 20s
  # 如果一條告警通知已成功發送，且在間隔repeat_interval後，該告警仍然未被設置爲resolved，則會再次發送該告警通知
#  repeat_interval: 12h
  repeat_interval: 1m
  # 默認告警通知接收者，凡未被匹配進入各子路由節點的告警均被髮送到此接收者
  receiver: 'webhook'
  # 上述route的配置會被傳遞給子路由節點，子路由節點進行重新配置纔會被覆蓋

  # 子路由樹
  routes:
  # 該配置選項使用正則表達式來匹配告警的labels，以確定能否進入該子路由樹
  # match_re和match均用於匹配labelkey爲service,labelvalue分別爲指定值的告警，被匹配到的告警會將通知發送到對應的receiver
  - match_re:
      service: ^(foo1|foo2|baz)$
    receiver: 'webhook'
    # 在帶有service標籤的告警同時有severity標籤時，他可以有自己的子路由，同時具有severity != critical的告警則被髮送給接收者team-ops-wechat,對severity == critical的告警則被髮送到對應的接收者即team-ops-pager
    routes:
    - match:
        severity: critical
      receiver: 'webhook'
  # 比如關於數據庫服務的告警，如果子路由沒有匹配到相應的owner標籤，則都默認由team-DB-pager接收
  - match:
      service: database
    receiver: 'webhook'
  # 我們也可以先根據標籤service:database將數據庫服務告警過濾出來，然後進一步將所有同時帶labelkey爲database
  - match:
      severity: critical
    receiver: 'webhook'
# 抑制規則，當出現critical告警時 忽略warning
inhibit_rules:
- source_match:
    severity: 'critical'
  target_match:
    severity: 'warning'
  # Apply inhibition if the alertname is the same.
  #   equal: ['alertname', 'cluster', 'service']
  #
# 收件人配置
receivers:
- name: 'webhook'
  webhook_configs:
  - url: 'http://alertmanaer-dingtalk-svc.kube-system//b01bdc063/boge/getjson'
    send_resolved: true

附： 監控其他服務的prometheus規則配置

https://github.com/samber/awesome-prometheus-alerts