一文讀懂如何在Kubernetes上輕松實現(xiàn)自動化部署Prometheus
簡介
Prometheus 是當(dāng)下火熱的監(jiān)控解決方案，尤其是容器微服務(wù)架構(gòu)，Kubernetes 的首選監(jiān)控方案。關(guān)于為什么要用 Prometheus，我這里就不多講，相關(guān)的文章太多了，大家也可以看看官方的說法。本文就講講如何自動化的搭建一套基于 Kubernetes 集群的 Prometheus 監(jiān)控系統(tǒng)。
我這里使用 Prometheus Operator 以及 helm 工具在 Kubernetes 集群上部署，后面給大家提供一個全自動運維 (http://t.cn/Ai8t4jLw) 的例子參考，這里直接看代碼。
關(guān)于 helm 的使用不清楚的可以參考這幾篇文章：
- Helm 入門指南
- 利用 Helm 快速部署 Ingress
- Kubernetes 實操手冊－Helm使用 (http://t.cn/Ai85DU9N)
關(guān)于什么是 Prometheus Operator 以及為什么要用 Prometheus Operator？
Operator 是以軟件的方式定義運維過程，是一系列打包、部署和管理 Kubernetes 應(yīng)用的方法。簡單來說就是將運維過程中的手動操作轉(zhuǎn)換為自動化流程，通過 Kubernetes 的 CRD（Custom Resource Definition）將部署前后的相關(guān)操作自動化，同時以參數(shù)的方式提供了靈活性。而 Prometheus Operator 是 CoreOS 提供的一整套 Prometheus 的 Operator，方便了 Prometheus 的部署。
下面我們先簡單講講 Prometheus 的架構(gòu)。
Prometheus 核心
下圖是 Promtheus 官方的架構(gòu)圖
Prometheus Server
Prometheus Server 是監(jiān)控系統(tǒng)的服務(wù)端，服務(wù)端通過服務(wù)發(fā)現(xiàn)的方式，抓取被監(jiān)控服務(wù)的指標(biāo)，或者通過 pushgateway 的間接抓取，抓取到指標(biāo)數(shù)據(jù)后，通過特定的存儲引擎進行存儲，同時暴露一個 HTTP 服務(wù)，提供用 PromQL 來進行數(shù)據(jù)查詢。注意，Prometheus 是定時采樣數(shù)據(jù)，而不是全量數(shù)據(jù)。
Exporter
Prometheus 需要服務(wù)暴露 http 接口，如果服務(wù)本身沒有，我們不需要改造服務(wù)，可以通過 exporter 來間接獲取。Exporter 就充當(dāng)了 Prometheus 采集的目標(biāo)，而由各個 exporter 去直接獲取指標(biāo)。目前大多數(shù)的服務(wù)都有現(xiàn)成的 exporter，我們不需要重復(fù)造輪子，拿來用即可，如 MySQL，MongoDB 等，可以參考這里。
Push Gateway
Prometheus 采集指標(biāo)的方式主要有兩種，一種是服務(wù)端暴露接口（Exporter），由 Prometheus 主動去抓取指標(biāo)，稱為 pull 模式。另一種是服務(wù)端主動上報，服務(wù)端將指標(biāo)主動上報至 Push Gateway，Prometheus 再從 Push Gateway 中獲取，稱為 push 模式。而 Push Gateway 就是 push 模式中重要的中介角色，用于暫存服務(wù)端上報的指標(biāo)，等待 Prometheus 收集。
為什么要有兩種模式呢？我們來比較一下這兩種模式的特點。
Pull 模式：Prometheus 主動抓取的方式，可以由 Prometheus 服務(wù)端控制抓取的頻率，簡單清晰，控制權(quán)在 Prometheus 服務(wù)端。通過服務(wù)發(fā)現(xiàn)機制，可以自動接入新服務(wù)，去掉下線的服務(wù)，無需任何人工干預(yù)。對于各種常見的服務(wù)，官方或社區(qū)有大量 Exporter 來提供指標(biāo)采集接口，基本無需開發(fā)。是官方推薦的方式。
Push 模式：由服務(wù)端主動上報至 Push Gateway，采集最小粒度由服務(wù)端決定，等于 Push Gateway 充當(dāng)了中介的角色，收集各個服務(wù)主動上報的指標(biāo)，然后再由 Prometheus 來采集。但是這樣就存在了 Push Gateway 這個性能單點，而且 Push Gateway 也要處理持久化問題，不然宕機也會丟失部分?jǐn)?shù)據(jù)。同時需要服務(wù)端提供主動上報的功能，可能涉及一些開發(fā)改動。不是首選的方式，但是在一些場景下很適用。例如，一些臨時性的任務(wù)，存在時間可能非常短，如果采用 Pull 模式，可能抓取不到數(shù)據(jù)。
Alert Manager
Alert Manager 是 Prometheus 的報警組件，當(dāng) Prometheus 服務(wù)端發(fā)現(xiàn)報警時，推送 alert 到 Alert Manager，再由 Alert Manager 發(fā)送到通知端，如 Email，Slack，微信，釘釘?shù)取lert Manager 根據(jù)相關(guān)規(guī)則提供了報警的分組、聚合、抑制、沉默等功能。
Web UI/Grafana
Prometheus 提供了一個簡單的 web UI 界面，用于查詢數(shù)據(jù)，查看告警、配置等，官方推薦使用另一個開源項目 grafana 來做指標(biāo)的可視化展示，制作儀表盤等。
部署
下面詳細(xì)講講如何自動化部署 Promethues，自動化監(jiān)控以及遇到的一些坑。
部署這塊 Prometheus Operator 已經(jīng)幫我們做的非常好了，我們只需要調(diào)整一些參數(shù)即可實現(xiàn)部署。我們使用 helm 來部署 Prometheus，只需要一個命令。
- helm install --name my-release stable/prometheus-operator
不過這不可能滿足我們的需求，我們需要的不是演示，而是實戰(zhàn)。
下面是詳細(xì)講解，完整的項目可以參考這里：http://t.cn/Ai8tzUaR 。
我們首先要確定的是如何持久化存儲 Prometheus 的指標(biāo)數(shù)據(jù)，默認(rèn)的方式是以文件的方式保存在服務(wù)端的磁盤上，但這樣不利于服務(wù)端的橫向擴展以及數(shù)據(jù)的備份恢復(fù)。Prometheus 還提供了其他存儲后端的整合，詳見這里。目前比較流行的做法是使用 InfluxDB 作為存儲后端，InfluxDB 是一款強大的時序數(shù)據(jù)庫，就是為監(jiān)控指標(biāo)等時序數(shù)據(jù)而生的。
首先，我們來部署 InfluxDB，為了持久化 InfluxDB 的數(shù)據(jù)，我們先創(chuàng)建一個 PVC 來持久化數(shù)據(jù)。
pvc.yaml
- apiVersion: v1
- kind: PersistentVolumeClaim
- metadata:
- name: influxdb-pvc
- namespace: monitoring
- labels:
- app: influxdb
- release: influxdb
- spec:
- accessModes:
- - ReadWriteOnce
- storageClassName: monitor-ebs # 選擇合適的存儲類
- resources:
- requests:
- storage: 200Gi # 設(shè)置合適的存儲空間
然后我們創(chuàng)建 InfluxDB 的配置文件
influxdb.yaml
- # 持久化存儲配置
- persistence:
- enabled: true
- useExisting: true
- name: "influxdb-pvc" # 使用我們剛才創(chuàng)建的 PVC
- accessMode: "ReadWriteOnce"
- size: 200Gi
- # 創(chuàng)建 Prometheus 的數(shù)據(jù)庫
- env:
- - name: INFLUXDB_DB
- value: "prometheus"
- # influxdb 配置
- config:
- data:
- # 這兩個配置默認(rèn)限制了數(shù)據(jù)的上限，建議設(shè)置為 0 變成無限制，不然在達(dá)到上限后插入數(shù)據(jù)會返回錯誤
- max_series_per_database: 0
- max_values_per_tag: 0
- http:
- enabled: true # 啟動 http
- initScripts:
- enabled: true
- scripts:
- # 設(shè)置數(shù)據(jù)保留策略，默認(rèn)是永不失效，需要人工清理
- # 保留 180 天數(shù)據(jù)
- retention.iql: |+
- CREATE RETENTION POLICY "default_retention_policy" on "prometheus" DURATION 180d REPLICATION 1 DEFAULT
InfluxDB 的全部配置可以參考文檔，我講一下上面的兩個主要的配置。
max-series-per-database
內(nèi)存中每個數(shù)據(jù)庫最大的序列數(shù)量，默認(rèn)是 1000000，設(shè)置為 0 改成無限制。如果新來的數(shù)據(jù)增加了序列數(shù)量并超過了這個上限，那么數(shù)據(jù)就會被丟棄就并返回一個 500 錯誤：
- {"error":"max series per database exceeded: <series>"}
max-values-per-tag
內(nèi)存中每個標(biāo)簽的最大數(shù)據(jù)量，默認(rèn)是 100000，設(shè)置為 0 改成無限制。如果新來的數(shù)據(jù)超過了這個限制，也會被丟棄并返回寫入失敗的錯誤。
我們使用如下命令來部署 InfluxDB：
- helm install --name=influxdb --namespace=monitoring -f influxdb.yaml stable/influxdb
存儲后端部署成功后，我們就來部署 Prometheus-operator 了，首先創(chuàng)建如下的配置文件：
prometheus.yaml
- # prometheus 服務(wù)端
- prometheus:
- prometheusSpec:
- # 遠(yuǎn)端存儲配置
- remoteWrite:
- - url: "http://influxdb:8086/api/v1/prom/write?db=prometheus"
- remoteRead:
- - url: "http://influxdb:8086/api/v1/prom/read?db=prometheus"
- # ingress 配置，暴露 web 界面
- ingress:
- enabled: true
- annotations:
- kubernetes.io/ingress.class: traefik # ingress class
- hosts:
- - "prometheus.mydomain.io" # 配置域名
- alertmanager:
- # alertmanager 配置
- config:
- global:
- # SMTP 配置
- smtp_smarthost: 'xxx'
- smtp_from: 'xxx'
- smtp_auth_username: 'xxx'
- smtp_auth_password: 'xxx'
- # 全局 opsgenie 配置
- # opsgenie_api_key: ""
- # 報警路由
- route:
- receiver: 'monitoring-warning'
- group_by: ['alertname']
- group_wait: 30s
- group_interval: 3m
- repeat_interval: 8h
- routes:
- - match:
- severity: critical
- receiver: monitoring-critical
- group_by: ['alertname']
- - match:
- severity: warning
- receiver: monitoring-warning
- group_by: ['alertname']
- # 報警抑制規(guī)則
- inhibit_rules:
- - source_match:
- severity: 'critical'
- target_match:
- severity: 'warning'
- # 抑制相同的報警
- equal: ['alertname']
- # 接收者配置
- receivers:
- - name: 'monitoring-critical'
- email_configs:
- - to: 'monitor@mydomain.com'
- # 發(fā)送到釘釘?shù)?nbsp;webhook，需要部署一個轉(zhuǎn)發(fā)服務(wù)，詳見項目代碼
- webhook_configs:
- - send_resolved: true
- url: http://prometheus-webhook-dingtalk/dingtalk/monitoring/send
- - name: 'monitoring-warning'
- email_configs:
- - to: 'monitor@mydomain.com'
- alertmanagerSpec:
- # alertmanager 存儲配置，alertmanager 會以文件形式存儲報警靜默等配置
- storage:
- volumeClaimTemplate:
- spec:
- accessModes:
- - ReadWriteOnce
- storageClassName: monitor-ebs # 選擇合適的存儲類
- resources:
- requests:
- storage: 20Gi # 選擇合適的大小
- # ingress 配置，暴露 alert 的界面
- ingress:
- enabled: true
- annotations:
- kubernetes.io/ingress.class: traefik # ingress class
- hosts:
- - "alert.mydomain.io" # 配置域名
- # grafana 配置
- grafana:
- replicas: 1
- adminPassword: "admin" # 管理員賬戶 admin，密碼 admin
- env:
- # GF_SERVER_DOMAIN: "" # 域名
- GF_SERVER_ROOT_URL: "%(protocol)s://%(domain)s/"
- # GF_DATABASE_URL: "mysql://user:secret@host:port/database" # SQL 數(shù)據(jù)庫
- # ingress 配置，暴露界面
- ingress:
- enabled: true
- annotations:
- kubernetes.io/ingress.class: traefik # ingress class
- hosts:
- - "grafana.mydomain.io" # 設(shè)置域名
- # exporter 設(shè)置，自建集群需要開啟，如果是云服務(wù)商托管集群，則獲取不到這些信息，可以關(guān)閉
- kubeControllerManager:
- enabled: true
- kubeEtcd:
- enabled: true
- kubeScheduler:
- enabled: true
然后我們使用如下命令來部署 Prometheus-Operator。
- helm install --name=prometheus --namespace=monitoring -f prometheus.yam stable/prometheus-operator
如果需要 Prometheus-Pushgateway 的話，創(chuàng)建如下配置：
prometheus-pushgateway.yaml
- replicaCount: 1
- # 自動在 Prometheus 中添加 target
- serviceMonitor:
- enabled: true
- namespace: monitoring
- selector:
- app: prometheus-pushgateway
- release: prometheus
- # ingress 配置，暴露界面
- ingress:
- enabled: true
- annotations:
- kubernetes.io/ingress.class: traefik # ingress class
- hosts:
- - "pushgateway.mydomain.io" # 設(shè)置域名
同樣的方式部署：
- helm install --name=prometheus-pushgateway --namespace=monitoring -f prometheus-pushgateway.yaml stable/prometheus-pushgateway
這樣 Prometheus 的核心組件都部署完成了，查看集群中的 Pod，有類似如下圖所示的 Pod。
這里有個注意點，如果通過 Prometheus 收集 kube-proxy 的指標(biāo)，需要 kube-proxy 開通訪問，默認(rèn) kube-proxy 只允許本機訪問。
需要修改 kube-proxy 的 ConfigMap 中的 metricsBindAddress 值為 0.0.0.0:10249。
- kubectl -n kube-system edit cm kube-proxy
會看到如下內(nèi)容，將 metricsBindAddress: 127.0.0.1:10249 這行修改為 metricsBindAddress: 0.0.0.0:10249 保存即可。
- apiVersion: v1
- data:
- config.conf: |-
- apiVersion: kubeproxy.config.k8s.io/v1alpha1
- kind: KubeProxyConfiguration
- # ...
- # metricsBindAddress: 127.0.0.1:10249
- metricsBindAddress: 0.0.0.0:10249
- # ...
- kubeconfig.conf: |-
- # ...
- kind: ConfigMap
- metadata:
- labels:
- app: kube-proxy
- name: kube-proxy
- namespace: kube-system
然后刪除 kube-proxy 的 Pod，讓它重啟即可看到已正常抓取。
應(yīng)用
至此，Prometheus 的服務(wù)端就全部部署完成了。接下來就是根據(jù)實際業(yè)務(wù)部署相應(yīng)的 Exporter，ServiceMonitor 和 PrometheusRule 了。官方和社區(qū)有大量現(xiàn)成的 Exporters 可供使用，如果有特殊需求的也可以參考這里自行開發(fā)。
接下來我們講講如何快速集成 Prometheus 監(jiān)控和報警。
我們之前提到過 Operator 通過 CRD 的方式提供了很多部署方面的自動化，Prometheus-Operator 就提供了四個 CRD，分別是：
- Prometheus，定義了 Prometheus 服務(wù)端，用來生成服務(wù)端控制器，保證了服務(wù)端的正常運行，我們只需要一個此 CRD 的實例
- Alertmanager，定義了 AlertManager 服務(wù)，用來生成服務(wù)端控制器，保證了服務(wù)的正常運行，我們也只需要一個此 CRD 的實例
- ServiceMonitor，定義了 Prometheus 抓取指標(biāo)的目標(biāo)，就是 Prometheus 界面 targets 頁面看到的內(nèi)容，此 CRD 幫助我們創(chuàng)建目標(biāo)的配置
- PrometheusRule，定義了 Prometheus 規(guī)則，就是 Prometheus 界面 Rules 頁面看到的內(nèi)容，此 CRD 幫助我們創(chuàng)建規(guī)則的配置
Prometheus 和 Alertmanager CRD 主要是之前部署階段關(guān)注的，在服務(wù)應(yīng)用階段，我們主要是創(chuàng)建各個 ServiceMonitor 和 PrometheusRule 來配置服務(wù)端。
Prometheus-Operator 默認(rèn)會幫我們注冊相關(guān)組件的抓取目標(biāo)，如下圖所示：
我們要定義其他的抓取目標(biāo)，首先來創(chuàng)建了一個 ServiceMonitor 抓取我們部署的 InfluxDB 的指標(biāo)：
- apiVersion: monitoring.coreos.com/v1
- kind: ServiceMonitor
- metadata:
- name: influxdb-scrape-targets
- labels:
- app.kubernetes.io/name: scrape-targets
- app.kubernetes.io/instance: influxdb-target
- release: prometheus
- spec:
- # 用標(biāo)簽選擇器來選擇相應(yīng)的 Pod
- selector:
- matchLabels:
- app: influxdb
- release: influxdb
- # 選擇命名空間
- namespaceSelector:
- matchNames:
- - monitoring
- # 定義抓取的配置，如端口、頻率等
- endpoints:
- - interval: 15s
- port: api
我們在項目中創(chuàng)建了一個 Chart 模版（在 charts/scrape-targets/ 目錄），能夠快速的創(chuàng)建 ServiceMonitor，提供下面的配置文件：
influxdb.yaml
- selector:
- matchLabels:
- app: influxdb
- release: influxdb
- namespaceSelector:
- matchNames:
- - monitoring
- endpoints:
- - port: api
- interval: 15s
然后使用 helm 安裝：
- helm install --name influxdb-target --namespace monitoring -f influxdb.yaml charts/scrape-targets/
創(chuàng)建完成后無需重啟 Prometheus 服務(wù)端，服務(wù)端根據(jù)標(biāo)簽自動載入，過一會可以在界面上看到：
Prometheus-Operator 同樣會幫我們注冊許多相關(guān)的規(guī)則，如下圖所示：
配置我們自己的 PrometheusRule 同樣很簡單，我們用如下配置生成報警規(guī)則，如果 5 分鐘內(nèi)的 HTTP 500 錯誤大于 5 則報警。
- apiVersion: monitoring.coreos.com/v1
- kind: PrometheusRule
- metadata:
- name: request-rules
- labels:
- app.kubernetes.io/name: rules
- app.kubernetes.io/instance: request
- app: prometheus-operator
- release: prometheus
- spec:
- groups:
- - name: request-rules.rules
- rules:
- - alert: RequestStatusCode500
- annotations:
- summary: http status code 500 is high for `{{$labels.service}}`
- expr: http_request_total{statuscode="500"} > 5
- for: 5m
- labels:
- severity: critical
也可以用我們項目中的 Chart 模版（在 charts/rules/ 目錄）來快速配置。
request.yaml
- groups:
- - rules:
- - alert: RequestStatusCode500
- expr: http_request_total{statuscode="500"} > 5
- for: "5m"
- labels:
- severity: critical
- annotations:
- summary: http status code 500 is high for `{{$labels.service}}`
然后 helm 安裝
- helm install --name request --namespace monitoring -f request.yaml charts/rules/
關(guān)于怎么寫規(guī)則配置，可以參考官方的文檔和 PromQL 語法。
以上的操作還是手動化的，如果要全自動化的話，可以參考我的項目，定義好配置文件，寫好自動化腳本，接入 CI/CD 工作流，即可讓監(jiān)控系統(tǒng)實現(xiàn)自動部署、自動配置。
