我們prometheus采用nfs掛載方式來存儲數據，同時使用configMap管理配置文件。並且我們將所有的prometheus存儲在kube-system

配置文件創建完成，如果以后我們有新的資源需要被監控，我們只需要將ConfigMap對象更新即可，現在我們開始創建prometheus的Pod資源

我們在啟動程序的時候，除了指定prometheus.yaml(configmap)以外，還通過storage.tsdb.path指定了TSDB數據的存儲路徑、通過storage.tsdb.rentention設置了保留多長時間的數據，還有下面的web.enable-admin-api參數可以用來開啟對admin api的訪問權限，參數web.enable-lifecyle用來開啟支持熱更新，有了這個參數之后，prometheus.yaml(configmap)文件只要更新了，通過執行localhost:9090/-/reload就會立即生效

我們添加了一行securityContext，，其中runAsUser設置為0，這是因為prometheus運行過程中使用的用戶是nobody，如果不配置可能會出現權限問題

prometheus.yaml文件對應的ConfigMap對象通過volume的形式掛載進Pod，這樣ConfigMap更新后，對應的pod也會熱更新，然后我們在執行上面的reload請求，prometheus配置就生效了。除此之外，對了將時間數據進行持久化，我們將數據目錄和一個pvc對象進行了綁定，所以我們需要提前創建pvc對象

我們這里還需要創建rbac認證，因為prometheus需要訪問k8s集群內部的資源

由於我們要獲取的資源，在每一個namespace下面都有可能存在，所以我們這里使用的是ClusterRole的資源對象，nonResourceURLs是用來對非資源型metrics進行操作的權限聲明

我們將ConfigMap volume rbac 創建完畢后，就可以創建prometheus.deploy.yaml了，運行prometheus服務

現在我們prometheus服務狀態是已經正常了，但是我們在瀏覽器是無法訪問prometheus的 webui服務。那么我們還需要創建一個service

這里定義的端口為3xxxx,我們直接在瀏覽器上任意節點輸入ip+端口即可

Prometheus監控Kubernetes 集群節點及應用

監控方案

Kubelet/cAdvisor之外，我們還可以向Heapster添加其他指標源數據，比如kube-state-metrics

不過kube-state-metrics和metrics-server之前還有很大不同的，二者主要區別如下

監控集群節點

首先需要我們監控集群的節點，要監控節點其實我們已經有很多非常成熟的方案了，比如Nagios、Zabbix，甚至可以我們自己收集數據，這里我們通過prometheus來采集節點的監控指標，可以通過node_exporter獲取，node_exporter就是抓取用於采集服務器節點的各種運行指標，目前node_exporter幾乎支持所有常見的監控點，比如cpu、distats、loadavg、meminfo、netstat等，詳細的監控列表可以參考github repo

這里使用DeamonSet控制器來部署該服務，這樣每一個節點都會運行一個Pod，如果我們從集群中刪除或添加節點后，也會進行自動擴展

由於我們要獲取的數據是主機的監控指標數據，而我們的node-exporter是運行在容器中的，所以我們在Pod中需要配置一些Pod的安全策略

另外我們還需要將主機/dev、/proc、/sys這些目錄掛在到容器中，這些因為我們采集的很多節點數據都是通過這些文件來獲取系統信息

另外如果是使用kubeadm搭建的，同時需要監控master節點的，則需要添加下方的相應容忍

在我們的yaml文件中加入了hostNetwork:true會直接將我們的宿主機的9100端口映射出來，從而不需要創建service 在我們的宿主機上就會有一個9100的端口

上面我們檢查了Pod的運行狀態都是正常的，接下來我們要查看一下Pod日志，以及node-exporter中的metrics

使用命令kubectl logs -n 命名空間 node-exporter中Pod名稱檢查Pod日志是否有額外報錯

服務發現

我們這里三個節點都運行了node-exporter程序，如果我們通過一個Server來將數據收集在一起，用靜態的方式配置到prometheus就會顯示一條數據，我們得自己在指標中過濾每個節點的數據，配置比較麻煩。這里就采用服務發現

在Kubernetes下，Prometheus通過Kubernetes API基礎，目前主要支持5種服務發現，分別是node、Server、Pod、Endpoints、Ingress

現在我們可以看到已經獲取到我們的Node節點的IP，但是由於metrics監聽的端口是10250而並不是我們設置的9100，所以提示我們節點屬於Down的狀態

這里我們就需要使用Prometheus提供的relabel_configs中的replace能力了，relabel可以在Prometheus采集數據之前，通過Target實例的Metadata信息，動態重新寫入Label的值。除此之外，我們還能根據Target實例的Metadata信息選擇是否采集或者忽略該Target實例。這里使用__address__標簽替換10250端口為9100

目前狀態已經正常，但是還有一個問題就是我們的采集數據只顯示了IP地址，對於我們監控分組分類不是很方便，這里可以通過labelmap這個屬性來將Kubernetes的Label標簽添加為Prometheus的指標標簽

添加了一個action為labelmap，正則表達式是__meta_kubernetes_node(.+)的配置，這里的意思就是表達式中匹配的數據也添加到指標數據的Label標簽中去。

容器監控

cAdvisor是一個容器資源監控工具，包括容器的內存，CPU，網絡IO，資源IO等資源，同時提供了一個Web頁面用於查看容器的實時運行狀態。

cAvisor已經內置在了kubelet組件之中，所以我們不需要單獨去安裝，cAdvisor的數據路徑為/api/v1/nodes//proxy/metrics

action 使用labelkeep或者labeldrop則可以對Target標簽進行過濾，僅保留符合過濾條件的標簽

ls_config配置的證書地址是每個Pod連接apiserver所使用的地址，基本上寫死了。並且我們在配置文件添加了一個labelmap標簽。在最下面使用了一個正則替換了cAdvisor的一個metrics地址

修改完成之后，我們需要configmap並且使用curl進行熱更新(過程比較慢，需要等待會)

還可以使用sum函數,pod在1分鍾內的使用率，同時將pod名稱打印出來

Api-Service 監控

apiserver作為Kubernetes最核心的組件，它的監控也是非常有必要的，對於apiserver的監控，我們可以直接通過kubernetes的service來獲取

上面的service是我們集群的apiserver內部的service的地址，要自動發現service類型的服務，需要使用role為Endpoints的kubernetes_sd_configs (自動發現)，我們只需要在configmap里面在添加Endpoints類型的服務發現

更新完成后，我們可以看到kubernetes-apiserver下面出現了很多實例，這是因為我們這里使用的Endpoints類型的服務發現，所以prometheus把所有的Endpoints服務都抓取過來了，同樣的我們要監控的kubernetes也在列表中。

這里我們使用keep動作，將符合配置的保留下來，例如我們過濾default命名空間下服務名稱為kubernetes的元數據，這里可以根據__meta_kubernetes_namespace和__mate_kubertnetes_service_name2個元數據進行relabel

如果我們要監控其他系統組件，比如kube-controller-manager、kube-scheduler的話就需要單獨手動創建service，因為apiserver服務默認在default，而其他組件在kube-steam這個namespace下。其中kube-sheduler的指標數據端口為10251，kube-controller-manager對應端口為10252

Service 監控

apiserver實際上是一種特殊的Service，現在配置一個專門發現普通類型的Service

這里我們對service進行過濾，只有在service配置了prometheus.io/scrape: "true"過濾出來

Serivce自動發現參數說明（並不是所有創建的service都可以被prometheus發現）

我們可以看到這里的服務的core DNS,為什么那么多service只有coreDNS可以被收集到呢？

Grafana是一個跨平台的開源的度量分析和可視化工具，可以通過將采集的數據查詢然后可視化的展示，並及時通知。

Grafana 安裝並監控k8s集群

由於Prometheus自帶的web Ui圖標功能相對較弱，所以一般情況下我們會使用一個第三方的工具來展示這些數據

Grafana介紹

grafana 是一個可視化面包，有着非常漂亮的圖片和布局展示，功能齊全的度量儀表盤和圖形化編輯器，支持Graphite、Zabbix、InfluxDB、Prometheus、OpenTSDB、Elasticasearch等作為數據源，比Prometheus自帶的圖標展示功能強大很多，更加靈活，有豐富的插件

我們這里使用deployment持久化安裝grafana

cat >>grafana_deployment.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana
  namespace: kube-system
  labels:
    app: grafana
    k8s-app: grafana
spec:
  selector:
    matchLabels:
      k8s-app: grafana
      app: grafana
  revisionHistoryLimit: 10
  template:
    metadata:
      labels:
        app: grafana
        k8s-app: grafana
    spec:
      containers:
      - name: grafana
        image: grafana/grafana:5.3.4
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 3000
          name: grafana
        env:
        - name: GF_SECURITY_ADMIN_USER
          value: admin
        - name: GF_SECURITY_ADMIN_PASSWORD
          value: jiangwenhui
        readinessProbe:
          failureThreshold: 10
          httpGet:
            path: /api/health
            port: 3000
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 30
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /api/health
            port: 3000
            scheme: HTTP
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources:
          limits:
            cpu: 300m
            memory: 1024Mi
          requests:
            cpu: 300m
            memory: 1024Mi
        volumeMounts:
        - mountPath: /var/lib/grafana
          subPath: grafana
          name: storage
      securityContext:
        fsGroup: 472
        runAsUser: 472
      volumes:
      - name: storage
        persistentVolumeClaim:
          claimName: grafana
EOF

這里使用了grafana 5.3.4的鏡像，添加了監控檢查、資源聲明，比較重要的變量是GF_SECURITY_ADMIN_USER和GF_SECURITY_ADMIN_PASSWORD為grafana的賬號和密碼。

由於grafana將dashboard、插件這些數據保留在/var/lib/grafana目錄下，所以我們這里需要做持久化，同時要針對這個目錄做掛載聲明，由於5.3.4版本用戶的userid和groupid都有所變化，所以這里添加了一個securityContext設置用戶ID

image_1ddnv749l17k7ucdel1m4v17jjea.png-56.5kB

現在我們添加一個pv和pvc用於綁定grafana

cat >>grafana_volume.yaml <<EOF
apiVersion: v1
kind: PersistentVolume
metadata:
  name: grafana
spec:
  capacity:
    storage: 10Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  nfs:
    server: 192.168.0.200
    path: /home/kvm/k8s-vloume
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: grafana
  namespace: kube-system
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

EOF

這里配置依舊使用NFS進行掛載使用

現在我們還需要創建一個service，使用NodePort

cat >>grafana_svc.yaml<<EOF
apiVersion: v1
kind: Service
metadata:
  name: grafana
  namespace: kube-system
  labels:
    app: grafana
spec:
  type: NodePort
  ports:
    - port: 3000
  selector:
    app: grafana
EOF

由於5.1(可以選擇5.1之前的docker鏡像，可以避免此類錯誤)版本后groupid更改，同時我們將/var/lib/grafana掛載到pvc后，目錄擁有者可能不是grafana用戶，所以我們還需要添加一個Job用於授權目錄

cat > grafana_job.yaml <<EOF
apiVersion: batch/v1
kind: Job
metadata:
  name: grafana-chown
  namespace: kube-system
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: grafana-chown
        command: ["chown", "-R", "472:472", "/var/lib/grafana"]
        image: busybox
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - name: storage
          subPath: grafana
          mountPath: /var/lib/grafana
      volumes:
      - name: storage
        persistentVolumeClaim:
          claimName: grafana
EOF

這里使用一個busybox鏡像將/var/lib/grafana目錄修改為權限472

#需要先創建pv和pvc  (這里是需要安裝順序來創建)
[root@k8s-01 prometheus]# kubectl create -f grafana_volume.yaml
persistentvolume/grafana created
persistentvolumeclaim/grafana created
[root@k8s-01 prometheus]# kubectl create -f grafana_job.yaml
job.batch/grafana-chown created
[root@k8s-01 prometheus]# kubectl apply -f grafana_deployment.yaml
deployment.apps/grafana created
[root@k8s-01 prometheus]# kubectl create -f grafana_svc.yaml

創建完成后我們打開grafana的dashboard界面

[root@k8s-01 prometheus]# 
[root@k8s-01 prometheus]# kubectl get pod,svc -n kube-system |grep grafana
pod/grafana-59bd6c446d-4jjnf         1/1     Running     0          7m39s
pod/grafana-chown-w562v              0/1     Completed   0          14m
service/grafana      NodePort    10.1.63.182    <none>        3000:30636/TCP           13m
[root@k8s-01 prometheus]#

然后我們在任意集群中的節點訪問端口為30636

這里的集群密碼就是上面我們創建deployment里面設置的變量，我這里用戶設置為admin密碼jiangwenhui

登陸到grafana就顯示到了我們的引導界面

第一次創建grafana需要添加數據源

類型選擇prometheus

這里的地址我們填寫下面的url

http://prometheus.kube-system.svc.cluster.local:9090

這里的prometheus代表service名稱

kube-system代表命名空間

數據源添加完畢后，接下來添加New dashboard

這里我們可以自定義模板，或者可以使用別人寫好的模板（寫好的模板后面是需要我們自己修改的）

grafana提供了很多模板，類似和docker鏡像倉庫一下。導入模板也極其簡單。點擊上方的Dashboard

這里面的模板都是公共的，可以免費使用

點進去任意一個模板后，我們可以看到ID，復制ID然后在返回grafana

我這里添加一個監控Kubernetes集群。顯示整體群集CPU、內存、磁盤使用情況以及單個pod統計信息。

https://grafana.com/grafana/dashboards/8588

點擊導入模板

在這里我們輸入8588或者url，會自動跳轉到配置頁面

https://grafana.com/grafana/dashboards/8588

選擇好數據源之后，我們在點擊Import即可

這里就會將模板8588給我們導入進行

這里就會獲取我們prometheus里面的數據了

現在的模板還沒有進行保存，我們要點擊保存一下

現在就保存下來了

目前我們導入模板之后是無法直接使用滴

這里無法顯示是由於模板定義的標簽，我們prometheus並沒有這個數據元，所以說我們要對模板進行修改！

在修改之前我們先設置一下時區，grafana默認走的是瀏覽器時區，但是prometheus使用的是UTC時區

修改默認模板 (我這里使用的是8588模板，下面模板修改請根據我的操作步驟進行操作)

grafana模板修改

前面的步驟必須和我相同，否則這里可能會無法出現值

首先我們進行編輯 Cluster memory usage (集群內存使用率)

計算方式就是(整個集群的內存-(整個集群剩余的內存以及Buffer和Cached))/整

(sum(node_memory_MemTotal_bytes) - sum(node_memory_MemFree_bytes + node_memory_Buffers_bytes+node_memory_Cached_bytes)) / sum(node_memory_MemTotal_bytes) * 100

這里要說明一點，這里填寫的是PromSQL，也就是說是可以在prometheus查詢到的。如果查詢不到grafana也是會獲取不到數據的

這里在prometheus是可以獲取到的

Cluster memory usage 配置如下 (集群內存使用率)

sum(sum by (container_name)( rate(container_cpu_usage_seconds_total{image!=""}[1m] ) )) / count(node_cpu_seconds_total{mode="system"}) * 100

Cluster filesystem usage 集群文件系統使用率

(sum(node_filesystem_size_bytes{device="tmpfs"}) - sum(node_filesystem_free_bytes{device="tmpfs"}) ) / sum(node_filesystem_size_bytes{device="tmpfs"}) * 100

這里我們就獲取到數據了

接下來我們配置集群中Pod cpu使用率

sum by (pod)(rate(container_cpu_usage_seconds_total{image!=" ", pod_name!=" "}[1m]))

下面顯示的地方配置

{{ pod }}

集群pod 內存使用率

sort_desc(sum (container_memory_usage_bytes{image!=" ", pod_name!=" "}) by(pod))

下面顯示的名稱同樣也是{{ pod }}

最后我們配置一下Pod 網絡監控

1.入口流量
sort_desc(sum by (pod) (rate (container_network_receive_bytes_total{name!=""}[1m]) ))

2.出口流量
sort_desc(sum by (pod) (rate (container_network_transmit_bytes_total{name!=""}[1m]) ))

#監控時間為1分鍾

效果圖如下 記得點擊保存

所有的PromSQL都是可以在prometheus獲取到數據的！

Prometheus AlertManager 實戰

AlerManager 簡介

Prometheus包含了一個報警模塊，那就是AlertManager，主要用於接受Prometheus發送的告警信息，它支持豐富的告警通知渠道，而且很容易做到告警信息進行去重，降噪，分組等，是一個前衛的告警通知系統

prometheus-architecture.png-94.6kB

安裝 AlerManager

prometheus配置文件官方文檔

https://prometheus.io/docs/alerting/configuration/

首先，我們需要先指定配置文件，這里我們還是創建一個ConfigMap資源對象

[root@k8s-01 prometheus]# cat >> prometheus-alert-conf.yaml <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: alert-config
  namespace: kube-system
data:
  config.yml: |-
    global:
      # 在沒有報警的情況下聲明為已解決的時間
      resolve_timeout: 5m
      # 配置郵件發送信息
      smtp_smarthost: 'smtp.163.com:465'
      smtp_from: '18676791057@163.com'
      smtp_auth_username: '18676791057@163.com'
      smtp_auth_password: '授權密碼'
      smtp_hello: '163.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: '290070744@qq.com'
        send_resolved: true
    - name: 'email'
      email_configs:
      - to: '290070744@qq.com'
        send_resolved: true

EOF

授權密碼申請，這里以163郵箱為例

我們現在創建alertmanager的配置文件

[root@k8s-01 prometheus]# kubectl create -f prometheus-alert-conf.yaml
configmap/alert-config created
[root@k8s-01 prometheus]#  kubectl get cm -n kube-system
NAME                                 DATA   AGE
alert-config                         1      8s
coredns                              1      37d
extension-apiserver-authentication   6      37d
kube-flannel-cfg                     2      37d
kube-proxy                           2      37d
kubeadm-config                       2      37d
kubelet-config-1.16                  1      37d
prometheus-config                    1      6d21h
[root@k8s-01 prometheus]# 
#這里已經顯示我們創建好的alert-config

現在我們在之前的prometheus pod的yaml文件中添加這個容器

這里我們將上面創建的aler-config這個configmap資源對象volume的形式掛載到/etc/alertmanager目錄下去，然后在啟動參數中指定--config.file=/etc/alertmanager/config.yml

      - name: alermanager
        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: 200m
            memory: 1024Mi
  ...
      - name: alertcfg
        configMap:
          name: alert-config

在0.15版本，alertmanager的WORKDIR發生了變化，變成/etc/alertmanager默認情況下存儲路徑--storage.path是相對目錄data/，因此alertmanager會在我們上面掛載的ConfigMap中去創建這個目錄，所以會報錯，這里通過--storage.path參數來解決

[root@k8s-01 prometheus]# kubectl apply -f  prometheus.deploy.yaml
deployment.apps/prometheus configured
#更新deployment

查看一下pod啟動狀態

[root@k8s-01 prometheus]# kubectl get pod -n kube-system |grep prometheus
prometheus-65856969cd-29rqf      2/2     Running     1          49s

AlertManager容器啟動之后，我們還需要在Prometheus中配置下AlertManager的地址，讓Prometheus能夠訪問AlertManager

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

接下來更新一下Prometheus配置文件

[root@k8s-01 prometheus]# 
[root@k8s-01 prometheus]# kubectl apply -f prometheus.configmap.yaml
configmap/prometheus-config configured
[root@k8s-01 prometheus]# kubectl get pod -n kube-system -o wide |grep prometheus 
prometheus-65856969cd-29rqf      2/2     Running     1          3m58s   10.244.1.70       k8s-02   <none>           <none>
[root@k8s-01 prometheus]# curl -X POST http://10.244.1.70:9090/-/reload

#確保更新配置沒有報錯（刷新比較慢可以等等）
現在prometheus alertmanager並沒有告警的規則，還需要我們添加報警規則

Prometheus 報警規則

上面我們將prometheus和alertmanager進行了關聯，但是現在並沒有報警規則，所以這里還需要配置一些報警規則。讓prometheus觸發報警

#首先在prometheus.configmap.yaml文件中添加報警規則，下面的文件就是prometheus報警的規則文件
    rule_files:
    - /etc/prometheus/rules.yml

報警規則允許基於Prometheus表達式語言來定義報警規則條件，並在出發報警時發送給外部

我們上面已經將/etc/promtehus進行掛載了，所以這里只需要修改prometheus-configmap就可以了。

  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 > 50
        for: 1m
        labels:
          team: node
        annotations:
          summary: "{{ $labels.instance }}：High Memory Usage detected"
          description: "{{ $labels.instance }}: Memory usage us avive 50% (current value is :: {{ $value }})"



#配置相關參數說明
  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 > 50 #規則表達式
        for: 1m  #等待1分鍾執行查詢條件
        labels:
          team: node   #當我們觸發報警后，帶有team=node的標簽，並且這里走的是我們alertmanager node標簽，這里對應的就是我們的email接收器
        annotations:  #指定另外一組標簽，不會將這個標簽當做我們告警的身份標示（不會在我們報警信息里操作）這里主要是用於額外的展示，例如發送給郵件里面>的報警信息
          summary: "{{ $labels.instance }}：High Memory Usage detected"   #label標簽，instance代表節點名稱
          description: "{{ $labels.instance }}: Memory usage us avive 50% (current value is :: {{ $value }})" #描述：相當於報警信息 $value代表當前值

expr所執行的命令是可以在prometheus上獲取到數據的

[root@k8s-01 prometheus]# kubectl apply -f prometheus.configmap.yaml 
configmap/prometheus-config configured
[root@k8s-01 prometheus]# kubectl get pod -n kube-system -o wide |grep prometheus 
prometheus-65856969cd-29rqf      2/2     Running     1          14m     10.244.1.70       k8s-02   <none>           <none>
[root@k8s-01 prometheus]# curl -X POST http://10.244.1.70:9090/-/reload
[root@k8s-01 prometheus]# curl -X POST http://10.244.1.70:9090/-/reload

報警說明

本次報警大概意思是當服務器內存百分比大於80的時候，就進行報警，並且通過labels標簽關聯team:node (這里team=node是在我們alertmanager里面配置的接收器，默認是default)，並且報警內容添加主機和當前內存使用率

接下來我們訪問prometheus，點擊alerts，就可以看到我們添加的NodeMemoryUsage

我這里將腳本改成>50

當前值已經大於我們設置的50%，現在已經出發報警

郵件內容如下

alertManager Ui界面

我們可以在郵件內容中看到包含View in AlertManager的鏈接，這是alertmanager自帶的Ui界面。我們可以使用NodePort進行訪問

這里需要修改一下prometheus的service

cat >>prometeheus-svc.yaml <<EOF
apiVersion: v1
kind: Service
metadata:
  name: prometheus
  namespace: kube-system
  labels:
    app: prometheus
spec:
  selector:
    app: prometheus
  type: NodePort
  ports:
    - name: web
      port: 9090
      targetPort: http
    - name: alertmanager
      port: 9093
      targetPort: 9093
EOF

我們查看一下node-port端口

[root@k8s-01 prometheus]# kubectl get svc -n kube-system |grep prometheus
prometheus   NodePort    10.1.183.250   <none>        9090:30129/TCP,9093:31882/TCP   6d23h

訪問alertmanager端口為9093=31882 (集群任一節點訪問即可)

在上面的圖片，我們可以看到hostname為k8s-01,02一直在報警，如果不想接收這個IP報警。可以點擊Slience

注意Prometheus有8小時時區問題

這時候報警匹配為k8s-01的host，在2個小時內。不進行報警，我們點擊創建就可以。在Comment輸入提交內容就可以了

這里可以直接編輯，或者直接讓它過期

這里我們已經看不到k8s-01的報警內容了

點擊Silences可以看到被禁用的監控

Kubernetes1.16下部署Prometheus+node-exporter+Grafana+AlertManager 監控系統

Prometheus 持久化安裝