成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

一文讀懂如何在Kubernetes上輕松實現自動化部署Prometheus

作者：火眼狻猊
開發 架構 系統運維 自動化
關于為什么要用 Prometheus，我這里就不多講，相關的文章太多了，大家也可以看看官方的說法。本文就講講如何自動化的搭建一套基于 Kubernetes 集群的 Prometheus 監控系統。

 

簡介

Prometheus 是當下火熱的監控解決方案，尤其是容器微服務架構，Kubernetes 的首選監控方案。關于為什么要用 Prometheus，我這里就不多講，相關的文章太多了，大家也可以看看官方的說法。本文就講講如何自動化的搭建一套基于 Kubernetes 集群的 Prometheus 監控系統。

我這里使用 Prometheus Operator 以及 helm 工具在 Kubernetes 集群上部署，后面給大家提供一個全自動運維 (http://t.cn/Ai8t4jLw) 的例子參考，這里直接看代碼。

關于 helm 的使用不清楚的可以參考這幾篇文章：

  •  Helm 入門指南
  •  利用 Helm 快速部署 Ingress
  •  Kubernetes 實操手冊－Helm使用 (http://t.cn/Ai85DU9N)

關于什么是 Prometheus Operator 以及為什么要用 Prometheus Operator？

Operator 是以軟件的方式定義運維過程，是一系列打包、部署和管理 Kubernetes 應用的方法。簡單來說就是將運維過程中的手動操作轉換為自動化流程，通過 Kubernetes 的 CRD（Custom Resource Definition）將部署前后的相關操作自動化，同時以參數的方式提供了靈活性。而 Prometheus Operator 是 CoreOS 提供的一整套 Prometheus 的 Operator，方便了 Prometheus 的部署。

下面我們先簡單講講 Prometheus 的架構。

Prometheus 核心

下圖是 Promtheus 官方的架構圖

Prometheus Server

Prometheus Server 是監控系統的服務端，服務端通過服務發現的方式，抓取被監控服務的指標，或者通過 pushgateway 的間接抓取，抓取到指標數據后，通過特定的存儲引擎進行存儲，同時暴露一個 HTTP 服務，提供用 PromQL 來進行數據查詢。注意，Prometheus 是定時采樣數據，而不是全量數據。

Exporter

Prometheus 需要服務暴露 http 接口，如果服務本身沒有，我們不需要改造服務，可以通過 exporter 來間接獲取。Exporter 就充當了 Prometheus 采集的目標，而由各個 exporter 去直接獲取指標。目前大多數的服務都有現成的 exporter，我們不需要重復造輪子，拿來用即可，如 MySQL，MongoDB 等，可以參考這里。

Push Gateway

Prometheus 采集指標的方式主要有兩種，一種是服務端暴露接口（Exporter），由 Prometheus 主動去抓取指標，稱為 pull 模式。另一種是服務端主動上報，服務端將指標主動上報至 Push Gateway，Prometheus 再從 Push Gateway 中獲取，稱為 push 模式。而 Push Gateway 就是 push 模式中重要的中介角色，用于暫存服務端上報的指標，等待 Prometheus 收集。

為什么要有兩種模式呢？我們來比較一下這兩種模式的特點。

Pull 模式：Prometheus 主動抓取的方式，可以由 Prometheus 服務端控制抓取的頻率，簡單清晰，控制權在 Prometheus 服務端。通過服務發現機制，可以自動接入新服務，去掉下線的服務，無需任何人工干預。對于各種常見的服務，官方或社區有大量 Exporter 來提供指標采集接口，基本無需開發。是官方推薦的方式。 

Push 模式：由服務端主動上報至 Push Gateway，采集最小粒度由服務端決定，等于 Push Gateway 充當了中介的角色，收集各個服務主動上報的指標，然后再由 Prometheus 來采集。但是這樣就存在了 Push Gateway 這個性能單點，而且 Push Gateway 也要處理持久化問題，不然宕機也會丟失部分數據。同時需要服務端提供主動上報的功能，可能涉及一些開發改動。不是首選的方式，但是在一些場景下很適用。例如，一些臨時性的任務，存在時間可能非常短，如果采用 Pull 模式，可能抓取不到數據。

Alert Manager

Alert Manager 是 Prometheus 的報警組件，當 Prometheus 服務端發現報警時，推送 alert 到 Alert Manager，再由 Alert Manager 發送到通知端，如 Email，Slack，微信，釘釘等。Alert Manager 根據相關規則提供了報警的分組、聚合、抑制、沉默等功能。

Web UI/Grafana

Prometheus 提供了一個簡單的 web UI 界面，用于查詢數據，查看告警、配置等，官方推薦使用另一個開源項目 grafana 來做指標的可視化展示，制作儀表盤等。

部署

下面詳細講講如何自動化部署 Promethues，自動化監控以及遇到的一些坑。

部署這塊 Prometheus Operator 已經幫我們做的非常好了，我們只需要調整一些參數即可實現部署。我們使用 helm 來部署 Prometheus，只需要一個命令。 

  1. helm install --name my-release stable/prometheus-operator 

不過這不可能滿足我們的需求，我們需要的不是演示，而是實戰。

下面是詳細講解，完整的項目可以參考這里：http://t.cn/Ai8tzUaR 。

我們首先要確定的是如何持久化存儲 Prometheus 的指標數據，默認的方式是以文件的方式保存在服務端的磁盤上，但這樣不利于服務端的橫向擴展以及數據的備份恢復。Prometheus 還提供了其他存儲后端的整合，詳見這里。目前比較流行的做法是使用 InfluxDB 作為存儲后端，InfluxDB 是一款強大的時序數據庫，就是為監控指標等時序數據而生的。

首先，我們來部署 InfluxDB，為了持久化 InfluxDB 的數據，我們先創建一個 PVC 來持久化數據。

pvc.yaml 

  1. apiVersion: v1  
  2. kind: PersistentVolumeClaim  
  3. metadata:  
  4.   name: influxdb-pvc  
  5.   namespace: monitoring  
  6.   labels:  
  7.     app: influxdb  
  8.     release: influxdb  
  9. spec:  
  10.   accessModes:  
  11.     - ReadWriteOnce  
  12.   storageClassName: monitor-ebs  # 選擇合適的存儲類  
  13.   resources:  
  14.     requests:  
  15.       storage: 200Gi  # 設置合適的存儲空間 

然后我們創建 InfluxDB 的配置文件

influxdb.yaml 

  1. # 持久化存儲配置  
  2. persistence:  
  3.   enabled: true  
  4.   useExisting: true  
  5.   name: "influxdb-pvc"  # 使用我們剛才創建的 PVC  
  6.   accessMode: "ReadWriteOnce"  
  7.   size: 200Gi  
  8. # 創建 Prometheus 的數據庫  
  9. env:  
  10.   - name: INFLUXDB_DB  
  11.     value: "prometheus"  
  12. # influxdb 配置  
  13. config:  
  14.   data:  
  15.     # 這兩個配置默認限制了數據的上限，建議設置為 0 變成無限制，不然在達到上限后插入數據會返回錯誤  
  16.     max_series_per_database: 0  
  17.     max_values_per_tag: 0  
  18.   http:  
  19.     enabled: true  # 啟動 http  
  20. initScripts:  
  21.   enabled: true  
  22.   scripts:  
  23.     # 設置數據保留策略，默認是永不失效，需要人工清理  
  24.     # 保留 180 天數據  
  25.     retention.iql: |+  
  26.       CREATE RETENTION POLICY "default_retention_policy" on "prometheus" DURATION 180d REPLICATION 1 DEFAULT 

InfluxDB 的全部配置可以參考文檔，我講一下上面的兩個主要的配置。

max-series-per-database

內存中每個數據庫最大的序列數量，默認是 1000000，設置為 0 改成無限制。如果新來的數據增加了序列數量并超過了這個上限，那么數據就會被丟棄就并返回一個 500 錯誤： 

  1. {"error":"max series per database exceeded: <series>"} 

max-values-per-tag

內存中每個標簽的最大數據量，默認是 100000，設置為 0 改成無限制。如果新來的數據超過了這個限制，也會被丟棄并返回寫入失敗的錯誤。

我們使用如下命令來部署 InfluxDB： 

  1. helm install --name=influxdb --namespace=monitoring -f influxdb.yaml stable/influxdb 

存儲后端部署成功后，我們就來部署 Prometheus-operator 了，首先創建如下的配置文件：

prometheus.yaml 

  1. # prometheus 服務端  
  2. prometheus:  
  3.   prometheusSpec:  
  4.     # 遠端存儲配置  
  5.     remoteWrite:  
  6.     - url: "http://influxdb:8086/api/v1/prom/write?db=prometheus"  
  7.     remoteRead:  
  8.     - url: "http://influxdb:8086/api/v1/prom/read?db=prometheus"  
  9.   # ingress 配置，暴露 web 界面  
  10.   ingress:  
  11.     enabled: true  
  12.     annotations:  
  13.       kubernetes.io/ingress.class: traefik  # ingress class  
  14.     hosts:  
  15.     - "prometheus.mydomain.io"  # 配置域名  
  16. alertmanager:  
  17.   # alertmanager 配置  
  18.   config:  
  19.     global:  
  20.       # SMTP 配置  
  21.       smtp_smarthost: 'xxx'  
  22.       smtp_from: 'xxx' 
  23.        smtp_auth_username: 'xxx'  
  24.       smtp_auth_password: 'xxx'  
  25.       # 全局 opsgenie 配置  
  26.       # opsgenie_api_key: ""  
  27.     # 報警路由  
  28.     route:  
  29.       receiver: 'monitoring-warning' 
  30.        group_by: ['alertname']  
  31.       group_wait: 30s  
  32.       group_interval: 3m  
  33.       repeat_interval: 8h  
  34.       routes:  
  35.       - match:  
  36.           severity: critical  
  37.         receiver: monitoring-critical  
  38.         group_by: ['alertname']  
  39.       - match:  
  40.           severity: warning  
  41.         receiver: monitoring-warning  
  42.         group_by: ['alertname']  
  43.     # 報警抑制規則  
  44.     inhibit_rules:  
  45.     - source_match:  
  46.         severity: 'critical'  
  47.       target_match:  
  48.         severity: 'warning'  
  49.       # 抑制相同的報警  
  50.       equal: ['alertname']  
  51.     # 接收者配置  
  52.     receivers:  
  53.     - name: 'monitoring-critical'  
  54.       email_configs:  
  55.       - to: 'monitor@mydomain.com'  
  56.       # 發送到釘釘的 webhook，需要部署一個轉發服務，詳見項目代碼  
  57.       webhook_configs:  
  58.       - send_resolved: true  
  59.         url: http://prometheus-webhook-dingtalk/dingtalk/monitoring/send  
  60.     - name: 'monitoring-warning'  
  61.       email_configs:  
  62.       - to: 'monitor@mydomain.com'  
  63.   alertmanagerSpec:  
  64.     # alertmanager 存儲配置，alertmanager 會以文件形式存儲報警靜默等配置  
  65.     storage:  
  66.       volumeClaimTemplate:  
  67.         spec:  
  68.           accessModes:  
  69.           - ReadWriteOnce  
  70.           storageClassName: monitor-ebs  # 選擇合適的存儲類  
  71.           resources:  
  72.             requests:  
  73.               storage: 20Gi  # 選擇合適的大小  
  74.   # ingress 配置，暴露 alert 的界面  
  75.   ingress:  
  76.     enabled: true  
  77.     annotations:  
  78.       kubernetes.io/ingress.class: traefik  # ingress class  
  79.     hosts:  
  80.     - "alert.mydomain.io"  # 配置域名  
  81. # grafana 配置  
  82. grafana:  
  83.   replicas: 1  
  84.   adminPassword: "admin"  # 管理員賬戶 admin，密碼 admin  
  85.   env:  
  86.     # GF_SERVER_DOMAIN: ""  # 域名  
  87.     GF_SERVER_ROOT_URL: "%(protocol)s://%(domain)s/"  
  88.     # GF_DATABASE_URL: "mysql://user:secret@host:port/database"  # SQL 數據庫  
  89.   # ingress 配置，暴露界面  
  90.   ingress:  
  91.     enabled: true  
  92.     annotations:  
  93.       kubernetes.io/ingress.class: traefik  # ingress class  
  94.     hosts:  
  95.     - "grafana.mydomain.io"  # 設置域名  
  96. # exporter 設置，自建集群需要開啟，如果是云服務商托管集群，則獲取不到這些信息，可以關閉  
  97. kubeControllerManager:  
  98.   enabled: true  
  99. kubeEtcd:  
  100.   enabled: true  
  101. kubeScheduler:  
  102.   enabled: true 

然后我們使用如下命令來部署 Prometheus-Operator。

  1. helm install --name=prometheus --namespace=monitoring -f prometheus.yam stable/prometheus-operator 

如果需要 Prometheus-Pushgateway 的話，創建如下配置：

prometheus-pushgateway.yaml 

  1. replicaCount: 1  
  2. # 自動在 Prometheus 中添加 target  
  3. serviceMonitor:  
  4.   enabled: true  
  5.   namespace: monitoring  
  6.   selector: 
  7.      app: prometheus-pushgateway  
  8.     release: prometheus  
  9. # ingress 配置，暴露界面  
  10. ingress:  
  11.   enabled: true  
  12.   annotations:  
  13.     kubernetes.io/ingress.class: traefik  # ingress class  
  14.   hosts:  
  15.   - "pushgateway.mydomain.io"  # 設置域名 

同樣的方式部署：

  1. helm install --name=prometheus-pushgateway --namespace=monitoring -f prometheus-pushgateway.yaml stable/prometheus-pushgateway 

這樣 Prometheus 的核心組件都部署完成了，查看集群中的 Pod，有類似如下圖所示的 Pod。

這里有個注意點，如果通過 Prometheus 收集 kube-proxy 的指標，需要 kube-proxy 開通訪問，默認 kube-proxy 只允許本機訪問。

需要修改 kube-proxy 的 ConfigMap 中的 metricsBindAddress 值為 0.0.0.0:10249。 

  1. kubectl -n kube-system edit cm kube-proxy 

會看到如下內容，將 metricsBindAddress: 127.0.0.1:10249 這行修改為 metricsBindAddress: 0.0.0.0:10249 保存即可。 

  1. apiVersion: v1  
  2. data:  
  3.   config.conf: |-  
  4.     apiVersion: kubeproxy.config.k8s.io/v1alpha1  
  5.     kind: KubeProxyConfiguration  
  6.     # ...  
  7.     # metricsBindAddress: 127.0.0.1:10249  
  8.     metricsBindAddress: 0.0.0.0:10249  
  9.     # ...  
  10.   kubeconfig.conf: |-  
  11.     # ...  
  12. kind: ConfigMap  
  13. metadata:  
  14.   labels:  
  15.     app: kube-proxy  
  16.   name: kube-proxy  
  17.   namespace: kube-system 

然后刪除 kube-proxy 的 Pod，讓它重啟即可看到已正常抓取。

應用

至此，Prometheus 的服務端就全部部署完成了。接下來就是根據實際業務部署相應的 Exporter，ServiceMonitor 和 PrometheusRule 了。官方和社區有大量現成的 Exporters 可供使用，如果有特殊需求的也可以參考這里自行開發。

接下來我們講講如何快速集成 Prometheus 監控和報警。

我們之前提到過 Operator 通過 CRD 的方式提供了很多部署方面的自動化，Prometheus-Operator 就提供了四個 CRD，分別是：

  •  Prometheus，定義了 Prometheus 服務端，用來生成服務端控制器，保證了服務端的正常運行，我們只需要一個此 CRD 的實例
  •  Alertmanager，定義了 AlertManager 服務，用來生成服務端控制器，保證了服務的正常運行，我們也只需要一個此 CRD 的實例
  •  ServiceMonitor，定義了 Prometheus 抓取指標的目標，就是 Prometheus 界面 targets 頁面看到的內容，此 CRD 幫助我們創建目標的配置
  •  PrometheusRule，定義了 Prometheus 規則，就是 Prometheus 界面 Rules 頁面看到的內容，此 CRD 幫助我們創建規則的配置

Prometheus 和 Alertmanager CRD 主要是之前部署階段關注的，在服務應用階段，我們主要是創建各個 ServiceMonitor 和 PrometheusRule 來配置服務端。

Prometheus-Operator 默認會幫我們注冊相關組件的抓取目標，如下圖所示：

我們要定義其他的抓取目標，首先來創建了一個 ServiceMonitor 抓取我們部署的 InfluxDB 的指標：

  1. apiVersion: monitoring.coreos.com/v1  
  2. kind: ServiceMonitor  
  3. metadata:  
  4.   name: influxdb-scrape-targets  
  5.   labels:  
  6.     app.kubernetes.io/name: scrape-targets  
  7.     app.kubernetes.io/instance: influxdb-target  
  8.     release: prometheus  
  9. spec:  
  10.   # 用標簽選擇器來選擇相應的 Pod  
  11.   selector:  
  12.     matchLabels:  
  13.       app: influxdb  
  14.       release: influxdb  
  15.   # 選擇命名空間  
  16.   namespaceSelector:  
  17.     matchNames:  
  18.     - monitoring  
  19.   # 定義抓取的配置，如端口、頻率等  
  20.   endpoints:  
  21.     - interval: 15s  
  22.       port: api 

我們在項目中創建了一個 Chart 模版（在 charts/scrape-targets/ 目錄），能夠快速的創建 ServiceMonitor，提供下面的配置文件：

influxdb.yaml 

  1. selector:  
  2.   matchLabels:  
  3.     app: influxdb  
  4.     release: influxdb  
  5. namespaceSelector:  
  6.   matchNames:  
  7.     - monitoring  
  8. endpoints:  
  9.   - port: api  
  10.     interval: 15s 

然后使用 helm 安裝：

  1. helm install --name influxdb-target --namespace monitoring -f influxdb.yaml charts/scrape-targets/ 

創建完成后無需重啟 Prometheus 服務端，服務端根據標簽自動載入，過一會可以在界面上看到：

Prometheus-Operator 同樣會幫我們注冊許多相關的規則，如下圖所示：

配置我們自己的 PrometheusRule 同樣很簡單，我們用如下配置生成報警規則，如果 5 分鐘內的 HTTP 500 錯誤大于 5 則報警。

  1. apiVersion: monitoring.coreos.com/v1  
  2. kind: PrometheusRule  
  3. metadata:  
  4.   name: request-rules  
  5.   labels:  
  6.     app.kubernetes.io/name: rules  
  7.     app.kubernetes.io/instance: request  
  8.     app: prometheus-operator  
  9.     release: prometheus  
  10. spec:  
  11.   groups:  
  12.   - name: request-rules.rules  
  13.     rules:  
  14.       - alert: RequestStatusCode500  
  15.         annotations: 
  16.            summary: http status code 500 is high for `{{$labels.service}}`  
  17.         expr: http_request_total{statuscode="500"} > 5  
  18.         for: 5m  
  19.         labels:  
  20.           severity: critical 

也可以用我們項目中的 Chart 模版（在 charts/rules/ 目錄）來快速配置。

request.yaml 

  1. groups:  
  2.   - rules:  
  3.     - alert: RequestStatusCode500  
  4.       expr: http_request_total{statuscode="500"} > 5  
  5.       for: "5m"  
  6.       labels:  
  7.         severity: critical  
  8.       annotations:  
  9.         summary: http status code 500 is high for `{{$labels.service}}` 

然后 helm 安裝 

  1. helm install --name request --namespace monitoring -f request.yaml charts/rules/ 

關于怎么寫規則配置，可以參考官方的文檔和 PromQL 語法。

以上的操作還是手動化的，如果要全自動化的話，可以參考我的項目，定義好配置文件，寫好自動化腳本，接入 CI/CD 工作流，即可讓監控系統實現自動部署、自動配置。 

 

責任編輯：龐桂玉 來源： 運維之美
KubernetesPrometheus架構
相關推薦

2022-02-15 08:07:17

測試軟件開發

2024-01-03 08:54:17

Kubernetes策略工具

2024-02-29 14:27:37

人工智能機器學習物聯網

2022-05-12 08:01:18

KubernetesDocker容器

2021-12-08 09:00:00

數據庫Liquibase腳本

2017-06-02 15:32:09

大數據數據可視化

2021-03-30 18:05:10

數字化轉型計算機技術

2023-12-22 19:59:15

2021-08-04 16:06:45

DataOps智領云

2021-02-22 09:44:03

KubernetesDNSLinux

2023-03-03 08:26:32

負載均衡算法服務

2018-09-28 14:06:25

前端緩存后端

2022-09-22 09:00:46

CSS單位

2025-04-03 10:56:47

2022-11-06 21:14:02

數據驅動架構數據

2020-12-11 10:20:33

Ansible運維軟件包

2020-06-05 14:15:29

可視化數據集分析

2021-08-11 10:10:26

Linux定時器數組

2025-02-11 09:29:07

2023-07-19 08:46:00

導航地圖
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 中日韩av| 男女视频91 | 久久久久国产精品 | 国产激情一区二区三区 | 国产精品成人在线观看 | 国产一区不卡 | 中文字字幕一区二区三区四区五区 | 天天插天天干 | 亚洲视频在线观看一区二区三区 | 91一区二区| 亚洲视频一区在线观看 | 免费视频二区 | 高清av在线 | 国产精品不卡 | 中文字幕av网站 | 欧美中文字幕 | 在线免费观看成人 | 69av在线视频| a级免费观看视频 | 国产成人精品一区二区三 | 精品一二区 | 91九色视频| 在线观看精品视频网站 | 欧美a级成人淫片免费看 | 久久丁香 | 久久久久久久国产精品 | 91在线精品一区二区 | 亚洲精品一区国语对白 | 色噜噜狠狠色综合中国 | 日韩久草 | 黄免费观看视频 | 精品久久久久久国产 | 国产精品成人一区二区三区 | 久在线 | 久久久久久久久久久久91 | 黑人久久久 | 欧美激情精品久久久久久 | 国产精品久久久久久久久免费相片 | 国产成人精品久久久 | 美女久久久久久久久 | 国产精品久久久久久亚洲调教 |