kubernetes之監控Prometheus實戰--郵件告警--微信告警（二）

本文轉載自查看原文 2019-03-14 14:20 2790 Linux-運維/ 容器技術

kubernetes插件

上面是我們最常用的 grafana 當中的 dashboard 的功能的使用，然后我們也可以來進行一些其他的系統管理，比如添加用戶，為用戶添加權限等等，我們也可以安裝一些其他插件，比如 grafana 就有一個專門針對 Kubernetes 集群監控的插件：grafana-kubernetes-app

要安裝這個插件，需要到 grafana 的 Pod 里面去執行安裝命令：

kubectl get pods -n kube-ops
NAME                          READY     STATUS    RESTARTS   AGE
grafana-75f64c6759-gknxz      1/1       Running   0          1d
node-exporter-48b6g           1/1       Running   0          7d
node-exporter-4swrs           1/1       Running   0          7d
node-exporter-4w2dd           1/1       Running   0          7d
node-exporter-fcp9x           1/1       Running   0          7d
prometheus-56b6d68c48-6xpvw   1/1       Running   0          7d
[root@k8s-master ~]# kubectl exec -it grafana-75f64c6759-gknxz /bin/bash -n kube-ops
grafana@grafana-75f64c6759-gknxz:/usr/share/grafana$ grafana-cli plugins install grafana-kubernetes-app
installing grafana-kubernetes-app @ 1.0.1
from url: https://grafana.com/api/plugins/grafana-kubernetes-app/versions/1.0.1/download
into: /var/lib/grafana/plugins

✔ Installed grafana-kubernetes-app successfully

Restart grafana after installing plugins . <service grafana-server restart>

安裝完成后需要重啟 grafana 才會生效，我們這里直接刪除 Pod，重建即可，然后回到 grafana 頁面中，切換到 plugins 頁面可以發現下面多了一個 Kubernetes 的插件，點擊進來啟用即可，然后點擊Next up旁邊的鏈接配置集群

這里我們可以添加一個新的 Kubernetes 集群，這里需要填寫集群的訪問地址：https://kubernetes.default，然后比較重要的是集群訪問的證書，勾選上TLS Client Auth和With CA Cert這兩項。

集群訪問的證書文件，用我們訪問集群的 kubectl 的配置文件中的證書信息(~/.kube/config)即可，其中屬性certificate-authority-data、client-certificate-data、client-key-data就對應這 CA 證書、Client 證書、Client 私鑰，不過 config 文件里面的內容是base64編碼過后的，所以我們這里填寫的時候要做base64解碼。

配置完成后，可以直接點擊Deploy(實際上前面的課程中我們都已經部署過相關的資源了)，然后點擊Save，就可以獲取到集群的監控資源信息了。

可以看到上面展示了整個集群的狀態，可以查看上面的一些 Dashboard:

AlertManager

Alertmanager 主要用於接收 Prometheus 發送的告警信息，它支持豐富的告警通知渠道，而且很容易做到告警信息進行去重，降噪，分組等，是一款前衛的告警通知系統。

安裝

從官方文檔https://prometheus.io/docs/alerting/configuration/中我們可以看到下載AlertManager二進制文件后，可以通過下面的命令運行：

$ ./alertmanager --config.file=simple.yml

其中-config.file參數是用來指定對應的配置文件的，由於我們這里同樣要運行到 Kubernetes 集群中來，所以我們使用docker鏡像的方式來安裝，使用的鏡像是：prom/alertmanager:v0.15.3

首先，指定配置文件，同樣的，我們這里使用一個 ConfigMap 資源對象：(alertmanager-conf.yaml)

apiVersion: v1
kind: ConfigMap
metadata:
  name: alert-config
  namespace: kube-ops
data:
  config.yml: |-
    global:
      # 在沒有報警的情況下聲明為已解決的時間
      resolve_timeout: 5m
      # 配置郵件發送信息
      smtp_smarthost: 'smtp.qq.com:587'
      smtp_from: 'zhaikun1992@qq.com'
      smtp_auth_username: 'zhaikun1992@qq.com'
      smtp_auth_password: '**' #改成自己的密碼
      smtp_hello: 'qq.com'
      smtp_require_tls: false
    # 所有報警信息進入后的根路由，用來設置報警的分發策略
    route:
      # 這里的標簽列表是接收到報警信息后的重新分組標簽，例如，接收到的報警信息里面有許多具有 cluster=A 和 alertname=LatncyHigh 這樣的標簽的報警信息將會批量被聚合到一個分組里面
      group_by: ['alertname', 'cluster']
      # 當一個新的報警分組被創建后，需要等待至少group_wait時間來初始化通知，這種方式可以確保您能有足夠的時間為同一分組來獲取多個警報，然后一起觸發這個報警信息。
      group_wait: 30s

      # 當第一個報警發送后，等待'group_interval'時間來發送新的一組報警信息。
      group_interval: 5m

      # 如果一個報警信息已經發送成功了，等待'repeat_interval'時間來重新發送他們
      repeat_interval: 5m

      # 默認的receiver：如果一個報警沒有被一個route匹配，則發送給默認的接收器
      receiver: default

      # 上面所有的屬性都由所有子路由繼承，並且可以在每個子路由上進行覆蓋。
      routes:
      - receiver: email
        group_wait: 10s
        match:
          team: node
    receivers:
    - name: 'default'
      email_configs:
      - to: 'zhai_kun@suixingpay.com'
        send_resolved: true
    - name: 'email'
      email_configs:
      - to: 'zhaikun1992@qq.com'
        send_resolved: true

這里有一個坑。如果我們郵件服務器使用的是25或者465端口的話，或報如下錯誤：

smtp.*****.com:465 fail to send mail alert due to 'does not advertise the STARTTLS extension

這里是一個BUG，可以參考

創建

$ kubectl create -f alertmanager-conf.yaml
configmap "alert-config" created

然后配置 AlertManager 的容器，我們可以直接在之前的 Prometheus 的 Pod 中添加這個容器，對應的 YAML 資源聲明如下：

  - name: alertmanager
    image: prom/alertmanager:v0.15.3
    imagePullPolicy: IfNotPresent
    args:
    - "--config.file=/etc/alertmanager/config.yml"
    - "--storage.path=/alertmanager/data"
    ports:
    - containerPort: 9093
      name: http
    volumeMounts:
    - mountPath: "/etc/alertmanager"
      name: alertcfg
    resources:
      requests:
        cpu: 100m
        memory: 256Mi
      limits:
        cpu: 100m
        memory: 256Mi
volumes:
- name: alertcfg
  configMap:
    name: alert-config

這里我們將上面創建的 alert-config 這個 ConfigMap 資源對象以 Volume 的形式掛載到 /etc/alertmanager 目錄下去，然后在啟動參數中指定了配置文件--config.file=/etc/alertmanager/config.yml，然后我們可以來更新這個 Prometheus 的 Pod：

$ kubectl apply -f prome-deploy.yaml
deployment.extensions "prometheus" configured

AlertManager 的容器啟動起來后，我們還需要在 Prometheus 中配置下 AlertManager 的地址，讓 Prometheus 能夠訪問到 AlertManager，在 Prometheus 的 ConfigMap 資源清單中添加如下配置：

alerting:
  alertmanagers:
    - static_configs:
      - targets: ["localhost:9093"]

更新這個資源對象后，稍等一小會兒，執行 reload 操作：

$ kubectl delete -f prome-cm.yaml
configmap "prometheus-config" deleted
$ kubectl create -f prome-cm.yaml
configmap "prometheus-config" created
kubectl get svc -n kube-ops
NAME         TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)                         AGE
grafana      NodePort   10.97.81.127    <none>        3000:30489/TCP                  75d
prometheus   NodePort   10.111.210.47   <none>        9090:31990/TCP,9093:30250/TCP   77d
$ curl -X POST "http://10.111.210.47:9090/-/reload"

報警規則

現在我們只是把AlertManager運行起來了。但是它並不知道要報什么警。因為沒有任何地方告訴我們要報警，所以我們還需要配置一些報警規則來告訴我們對哪些數據進行報警。

警報規則允許你基於 Prometheus 表達式語言的表達式來定義報警報條件，並在觸發警報時發送通知給外部的接收者。

同樣在 Prometheus 的配置文件中添加如下報警規則配置：

rule_files:
  - /etc/prometheus/rules.yml

其中rule_files就是用來指定報警規則的，這里我們同樣將rules.yml文件用 ConfigMap 的形式掛載到/etc/prometheus目錄下面即可:

apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: kube-ops
data:
  prometheus.yml: |
    ...
  rules.yml: |
    groups:
    - name: test-rule
      rules:
      - alert: NodeMemoryUsage
        expr: (node_memory_MemTotal_bytes - (node_memory_MemFree_bytes + node_memory_Buffers_bytes + node_memory_Cached_bytes)) / node_memory_MemTotal_bytes * 100 > 20
        for: 2m
        labels:
          team: node
        annotations:
          summary: "{{$labels.instance}}: High Memory usage detected"
          description: "{{$labels.instance}}: Memory usage is above 20% (current value is: {{ $value }}"

上面我們定義了一個名為NodeMemoryUsage的報警規則，其中：

for語句會使 Prometheus 服務等待指定的時間, 然后執行查詢表達式。
labels語句允許指定額外的標簽列表，把它們附加在告警上。
annotations語句指定了另一組標簽，它們不被當做告警實例的身份標識，它們經常用於存儲一些額外的信息，用於報警信息的展示之類的。

為了方便演示，我們將的表達式判斷報警臨界值設置為20，重新更新 ConfigMap 資源對象，由於我們在 Prometheus 的 Pod 中已經通過 Volume 的形式將 prometheus-config 這個一個 ConfigMap 對象掛載到了/etc/prometheus目錄下面，所以更新后，該目錄下面也會出現rules.yml文件，所以前面配置的rule_files路徑也是正常的，更新完成后，重新執行reload操作，這個時候我們去 Prometheus 的 Dashboard 中切換到alerts路徑下面就可以看到有報警配置規則的數據了：

因為我們配置了for等待時間，因為現在是PENDING狀態。過兩分鍾后，我們會發現進入FIRING狀態

我們可以看到頁面中出現了我們剛剛定義的報警規則信息，而且報警信息中還有狀態顯示。一個報警信息在生命周期內有下面3種狀態：

inactive: 表示當前報警信息既不是firing狀態也不是pending狀態
pending: 表示在設置的閾值時間范圍內被激活了
firing: 表示超過設置的閾值時間被激活了

我們這里的狀態現在是firing就表示這個報警已經被激活了，我們這里的報警信息有一個team=node這樣的標簽，而最上面我們配置 alertmanager 的時候就有如下的路由配置信息了：

routes:
- receiver: email
  group_wait: 10s
  match:
    team: node

所以我們這里的報警信息會被email這個接收器來進行報警，我們上面配置的是郵箱，所以正常來說這個時候我們會收到一封如下的報警郵件：

我們可以看到收到的郵件內容中包含一個View In AlertManager的鏈接，我們同樣可以通過 NodePort 的形式去訪問到 AlertManager 的 Dashboard 頁面：

$ kubectl get svc -n kube-ops
NAME         TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)                         AGE
grafana      NodePort   10.97.81.127    <none>        3000:30489/TCP                  75d
prometheus   NodePort   10.111.210.47   <none>        9090:31990/TCP,9093:30250/TCP   77d

通過任意節點IP:30250進行訪問，我們就可以查看到 AlertManager 的 Dashboard 頁面：

在這個頁面中我們可以進行一些操作，比如過濾、分組等等，里面還有兩個新的概念：Inhibition(抑制)和 Silences(靜默)。

Inhibition：如果某些其他警報已經觸發了，則對於某些警報，Inhibition 是一個抑制通知的概念。例如：一個警報已經觸發，它正在通知整個集群是不可達的時，Alertmanager 則可以配置成關心這個集群的其他警報無效。這可以防止與實際問題無關的數百或數千個觸發警報的通知，Inhibition 需要通過上面的配置文件進行配置。
Silences：靜默是一個非常簡單的方法，可以在給定時間內簡單地忽略所有警報。Silences 基於 matchers配置，類似路由樹。來到的警告將會被檢查，判斷它們是否和活躍的 Silences 相等或者正則表達式匹配。如果匹配成功，則不會將這些警報發送給接收者。

由於全局配置中我們配置的repeat_interval: 5m，所以正常來說，上面的測試報警如果一直滿足報警條件(CPU使用率大於20%)的話，那么每5分鍾我們就可以收到一條報警郵件。

現在我們添加一個 Silences，如下圖所示，匹配 k8s-master 節點的內存報警：

添加完成后，等下一次的報警信息觸發后，我們可以看到報警信息里面已經沒有了節點 k8s-master 的報警信息了(報警節點變成3個了)：

由於我們上面添加的 Silences 是有過期時間的，所以在這個時間段過后，k8s-master 的報警信息就會恢復了。

微信告警

1、登錄企業微信，創建第三方應用，點擊創建應用按鈕 -> 填寫應用信息：

我們打開已經創建好的promethues應用。獲取一下信息：

新增告警信息模板

apiVersion: v1
kind: ConfigMap
metadata:
  name: wechat-tmpl
  namespace: kube-ops
data:
  wechat.tmpl: |
    {{ define "wechat.default.message" }}
    {{ range .Alerts }}
    ========start==========
    告警程序: prometheus_alert
    告警級別: {{ .Labels.severity }}
    告警類型: {{ .Labels.alertname }}
    故障主機: {{ .Labels.instance }}
    告警主題: {{ .Annotations.summary }}
    告警詳情: {{ .Annotations.description }}
    觸發時間: {{ .StartsAt.Format "2006-01-02 15:04:05" }}
    ========end==========
    {{ end }}
    {{ end }}

把模板掛載到alertmanager 的pod中的/etc/alertmanager-tmpl

        volumeMounts:
        ........
        - mountPath: "/etc/alertmanager-tmpl"
          name: wechattmpl
       ........
      volumes:
      .........
      - name: wechattmpl
        configMap:
          name: wechat-tmpl

在rules.yml中添加一個新的告警信息。

      - alert: NodeFilesystemUsage
        expr: (node_filesystem_size_bytes{device="rootfs"} - node_filesystem_free_bytes{device="rootfs"}) / node_filesystem_size_bytes{device="rootfs"} * 100 > 10
        for: 2m
        labels:
          team: wechat
        annotations:
          summary: "{{$labels.instance}}: High Filesystem usage detected"
          description: "{{$labels.instance}}: Filesystem usage is above 10% (current value is: {{ $value }}"

alertmanager中默認支持微信告警通知。我們可以通過官網查看我們的配置如下：

apiVersion: v1
kind: ConfigMap
metadata:
  name: alert-config
  namespace: kube-ops
data:
  config.yml: |-
    global:
      resolve_timeout: 5m
      smtp_smarthost: 'smtp.qq.com:587'
      smtp_from: 'zhaikun1992@qq.com'
      smtp_auth_username: 'zhaikun1992@qq.com'
      smtp_auth_password: 'jrmujtmydxtibaid'
      smtp_hello: 'qq.com'
      smtp_require_tls: true
   #指定wechar告警模板
    templates:
      - "/etc/alertmanager-tmpl/wechat.tmpl"
    route:
      group_by: ['alertname', 'cluster', 'alertname_wechat']
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 5m
      receiver: default
      routes:
      - receiver: email
        group_wait: 10s
        match:
          team: node
     #配置微信的路由分組
      - receiver: 'wechat'
        group_wait: 10s
        match:
          team: wechat
    receivers:
    - name: 'default'
      email_configs:
      - to: 'zhai_kun@suixingpay.com'
        send_resolved: true
    - name: 'email'
      email_configs:
      - to: 'zhaikun1992@qq.com'
        send_resolved: true
    #配置微信接收器
    - name: 'wechat'
      wechat_configs:
      - corp_id: '***'
        to_party: '**'
        to_user: "***"
        agent_id: '***'
        api_secret: '****'
        send_resolved: true

wechat_configs 配置詳情

send_resolved 告警解決是否通知，默認是false
api_secret 創建微信上應用的Secret
api_url wechat的url。默認即可
corp_id 企業微信---我的企業---最下面的企業ID
message 告警消息模板：默認 template "wechat.default.message"
agent_id 創建微信上應用的agent_id
to_user 接受消息的用戶所有用戶可以使用 @all
to_party 接受消息的部門

我們部署驗證一下：

kubectl create -f alertmanager-cm.yaml
kubectl create -f prome-server.yaml
kubectl create -f prome-confmap.yaml
kubectl create -f wechat-tmpl.yaml

稍等兩分鍾，我們的微信企業號會接收到告警信息。

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 kubernetes實戰(二十)：k8s一鍵部署高可用Prometheus並實現郵件告警 Prometheus部署+郵箱告警+企業微信告警+釘釘告警 Kubernetes - - k8s - v1.12.3 一鍵部署高可用 Prometheus 並實現郵件告警 Prometheus監控告警淺析 kubernetes實戰(三十一)：Prometheus監控Windows主機 prometheus實戰---告警模板編寫（四）使用微信公眾號實現監控告警 Prometheus alertmanager郵件發送+grafana告警展示 prometheus監控實戰--數據基於Prometheus和Grafana的監控平台 - 運維告警