[[433690]]

【51CTO.com快譯】本文將重點向您介紹如何使用Prometheus Operator和Helm Chart，以及如何以簡單的方式在Kubernetes集群上安裝和管理Prometheus。首先，讓我們先了解一些與Prometheus Operator相關(guān)的基本概念。

CRD(Custom Resource Definition，定制資源定義)的方法是允許用戶自定義Deployment和StatefulSet等資源類型的結(jié)構(gòu)和有效性。其中，CR(Custom Resource，定制資源)是按照CRD的結(jié)構(gòu)所創(chuàng)建的資源。而Custom Controller(定制控制器)則能夠確保Kubernetes集群、或應(yīng)用程序始終將其當前的狀態(tài)，與我們所期望的狀態(tài)相匹配。因此，Operator可以被理解為我們部署在集群中的一組Kubernetes定制控制器。它會去偵聽被定制資源中，針對Kubernetes資源的創(chuàng)建、修改、刪除等操作。您可以通過鏈接-- https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/，了解更多有過定制資源的相關(guān)內(nèi)容。

Kubernetes Operator的用例

總的說來，Kubernetes Operator可以實現(xiàn)：

• 提供一種在Kubernetes上部署有狀態(tài)服務(wù)(如各種數(shù)據(jù)庫)的方法
• 處理應(yīng)用程序代碼的升級
• 根據(jù)性能指標，橫向擴展資源
• 按需備份和恢復(fù)應(yīng)用程序或數(shù)據(jù)庫的狀態(tài)
• 向Kubernetes部署監(jiān)控、存儲、歸檔(vault)等方案

什么是Prometheus Operator?

簡單來說，類似其他標準化的Kubernetes部署對象，Prometheus Operator能夠以完全自動化的方式部署Prometheus服務(wù)器、Alertmanager、以及所有相關(guān)的密鑰和configmap等。該方式有助于在較短幾分鐘內(nèi)，建立出Prometheus監(jiān)控系統(tǒng)，并實例化Kubernetes的集群監(jiān)控。而在完成部署后，Prometheus Operator將具有如下功能：

• 自動化：便捷地為Kubernetes的命名空間、特定的應(yīng)用或團隊啟動Prometheus實例。
• 服務(wù)發(fā)現(xiàn)：無需額外學(xué)習(xí)Prometheus的特定配置語言，便可使用熟悉的Kubernetes標簽，自動發(fā)現(xiàn)有待監(jiān)控的目標。
• 輕松配置：可管理Prometheus的版本、持久性、留存策略、以及來自Kubernetes資源的副本等基本資源的相關(guān)配置。

安裝Prometheus棧的方法

在Kubernetes中設(shè)置Prometheus監(jiān)控棧有如下三種不同的方法：

1.自行創(chuàng)造一切

如果您已準備好了Prometheus組件、及其先決條件，則可以通過參考其相互之間的依賴關(guān)系，以正確的順序為Prometheus、Alertmanager、Grafana的所有密鑰、以及ConfigMaps等每個組件，手動部署YAML規(guī)范文件。這種方法通常非常耗時，并且需要花費大量的精力，去部署和管理Prometheus生態(tài)系統(tǒng)。同時，它還需要構(gòu)建強大的文檔，以便將其復(fù)制到其他環(huán)境中。

2. 使用Prometheus Operator

既然前文提到了Prometheus Operator能夠管理Prometheus所有組件的生命周期，那么我們可以參考鏈接--https://github.com/prometheus-operator/prometheus-operator，據(jù)此在Kubernetes集群中部署Prometheus。

3. 使用Helm Chart部署Operator

作為一種更好、更高效的方式，我們可以使用由Prometheus社區(qū)維護的Helm Chart，來部署Prometheus Operator。概括地說，Helm會隨著Prometheus、Alertmanager和其他定制資源的創(chuàng)建，進行Prometheu Operator的初始化安裝。然后，Prometheus Operator會管理這些定制資源的整個生命周期。其安裝步驟如下：

Go  
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts  
helm repo update  
helm install prometheus prometheus-community/kube-prometheus-stack 

此處的kube-Prometheus-stack安裝了以下組件：

• Prometheus Operator
• 創(chuàng)建Prometheus、Alertmanager、以及相關(guān)的CR
• Grafana
• 各種節(jié)點導(dǎo)出器

它們還預(yù)先配置了針對協(xié)同工作、以及為您設(shè)置了基本集群的監(jiān)控，以方便您輕松地調(diào)整和添加各種自定義。上述命令的執(zhí)行速度非常快，只需幾分鐘便可啟動并運行所有的組件。

您可以通過“helm get manifestPrometheus| kubectl get -f –”命令，來查看創(chuàng)建的所有對象。

如上所圖示，您將能夠看到Prometheus棧的Deployments和StatefulSet等所有不同的資源。

Prometheus如何找到所有監(jiān)控項并抓取的目標?

為了讓Prometheus發(fā)現(xiàn)待監(jiān)控的對象，我們需要傳遞一個被稱為prometheus.yaml的YAML(配置文件，以便Prometheus可以參考并實施監(jiān)控。每個待監(jiān)控的目標端點都在prometheus.yaml中的scrape_configs部分下被定義。下面展示了Prometheus release tar中自帶的典型配置文件的內(nèi)容：

Go
# my global config 
global: 
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute. 
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute. 
  # scrape_timeout is set to the global default (10s). 
 
# Alertmanager configuration 
alerting: 
  alertmanagers: 
  - static_configs: 
    - targets: 
       - localhost:9093 
 
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'. 
rule_files: 
  - '/etc/prometheus/alert.rules' 
     
  # - "first_rules.yml" 
  # - "second_rules.yml" 
 
# A scrape configuration containing exactly one endpoint to scrape: 
# Here it's Prometheus itself. 
scrape_configs: 
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config. 
  - job_name: 'prometheus' 
 
    # metrics_path defaults to '/metrics' 
    # scheme defaults to 'http'. 
 
    static_configs: 
      - targets: ['localhost:9090'] 
 
  - job_name: 'node_exporter' 
    scrape_interval: 5s 
    static_configs: 
      - targets: ['localhost:9100']     

下面，讓我們深入了解prometheus.yaml文件中的一些主要關(guān)鍵術(shù)語。其中，我們可以通過如下兩種方式，為Prometheus指定目標端點集合：

• scrape_config通過指定一組目標和配置參數(shù)，來描述如何抓取他們。也就是說，在prometheus.yaml文件中，我們需要針對每個目標定義一個抓取配置塊。
• ServiceMonitor則讓我們以Kubernetes原生的方式，輕松地在scrape_config中創(chuàng)建一個作業(yè)條目。在內(nèi)部，Prometheus Operator將配置從每個 ServiceMonitor資源轉(zhuǎn)換為prometheus.yaml的scrape_config部分。由kube-prometheus-stack創(chuàng)建的Prometheus資源帶有一個選擇器，可以對所有帶有標簽release: prometheus(請參見配置)的ServiceMonitor進行各項操作。下圖展示了其工作原理：

圖片來源：CoreOS(https://www.openshift.com/blog)

讓我們以Prometheus服務(wù)本身為例，查看ServiceMonitor能否自動在Prometheus配置文件中創(chuàng)建了一個scrape_config條目。

Go 
kubectl get services prometheus-prometheus-oper-prometheus -o wide --show-labels  
NAME                                    TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE   SELECTOR                                                          LABELS 
prometheus-prometheus-oper-prometheus   ClusterIP   10.105.67.172   <none>        9090/TCP   12d   app=prometheus,prometheus=prometheus-prometheus-oper-prometheus   app=prometheus-operator-prometheus,release=prometheus,self-monitor=true 

根據(jù)上述代碼，我們進而可以查看相應(yīng)的ServiceMonitor是否已為Prometheus的服務(wù)準備就緒。

Go 
kubectl get servicemonitors.monitoring.coreos.com -l app=prometheus-operator-prometheus 
NAME                                    AGE 
prometheus-prometheus-oper-prometheus   12d 

上述代碼證實了Prometheus服務(wù)本身ServiceMonitor的存在性。下面，讓我們檢查“prometheus-prometheus-oper-prometheus”是否已在Prometheusconfig YAML文件中添加了一個作業(yè)。我們首先需要訪問由Prometheus Operator創(chuàng)建的Prometheuspod。

Go 
kubectl exec -it prometheus-prometheus-prometheus-oper-prometheus-0 -- /bin/sh 
/prometheus $  

讓我們通過如下代碼找出pod內(nèi)由Prometheus使用的配置文件名。

Go 
/prometheus $ ps 
 
PID   USER     TIME  COMMAND 
1     1000      4h58 /bin/prometheus … --config.file=/etc/prometheus/config_out/prometheus.env.yaml 
59    1000      0:00 /bin/sh 

從上述代碼可知，由Operator創(chuàng)建的配置文件prometheus.env.yaml可以被Prometheus服務(wù)器用于查找待監(jiān)控和抓取的目標端點。最后，讓我們檢查Prometheus服務(wù)本身的作業(yè)是否已被ServiceMonitor添加到了該配置文件中：

Go 
/Prometheus $  cat  / etc /Prometheus/ config_out /Prometheus。ENV 。yaml  |  grep  - i  - A  10  "job_name: default/prometheus-prometheus-oper-prometheus/0" ​ 
 
Go 
- job_name: default/prometheus-prometheus-oper-prometheus/0 
  honor_labels: false 
  kubernetes_sd_configs: 
  - role: endpoints 
    namespaces: 
      names: 
      - default 
  metrics_path: /metrics 

由上述代碼可知，ServiceMonitor會自動為基于Kubernetes的服務(wù)創(chuàng)建一個待監(jiān)控和抓取的作業(yè)。

此外，我們也可以直接在Prometheus Web UI中的Status -> Configuration下查看scrape_config的方法。如下圖所示：

除了ServiceMonitor之外，我們也可以使用PodMonitor方法去抓取Kubernetes pod，并由Prometheus Operator處理定制的資源。PodMonitor能夠以聲明的方式，指定如何直接監(jiān)控一組Pod。

您一定會問，既然我們有了ServiceMonitor，為何還需要PodMonitor呢?其主要原因是，ServiceMonitor合適那些Pod里已經(jīng)有某個服務(wù)(Service)的場景。否則，您需要用到PodMonitor。通常，Prometheus可以被配置為如下兩種方式，去定義待監(jiān)控的目標端點。

• 使用static_config機制

如果待監(jiān)控的Kubernetes服務(wù)/端點非常小且固定，那么您可以使用prometheus.yaml文件中的static_config來定義這些靜態(tài)端點。示例鏈接展示了如何通過配置Prometheus，以默認使用static_configs來監(jiān)控本身。

當然，這主要適用于簡單的用例，而且需要在添加和刪除節(jié)點時，手動更新prometheus.yml。而在Kubernetes之類的動態(tài)環(huán)境中，新的應(yīng)用服務(wù)實例往往會出現(xiàn)得快而頻繁。

• 使用service_discovery機制

目前，支持Prometheus的服務(wù)發(fā)現(xiàn)機制有：DNS、Kubernetes、AWS、Consul、以及其他自定義的類型。這些機制通常能夠動態(tài)地發(fā)現(xiàn)待監(jiān)控和抓取的目標端點。對于Kubernetes而言，它可以使用Kubernetes API來實現(xiàn)。示例鏈接展示了如何為Kubernetes配置Prometheus。其中，Prometheus Operator負責根據(jù)ServiceMonitor和PodMonitor資源完成上述配置。

Prometheus的規(guī)則

您可以創(chuàng)建一個包含規(guī)則語句的YAML文件，并使用Prometheus-configuration中的rule_files字段，將它們加載到Prometheus中。而在使用Prometheus Operator時，您可以使用PrometheusRule源的Helm，創(chuàng)建相應(yīng)的規(guī)則。目前，Prometheus可以定期配置和評估如下兩種類型的規(guī)則：

• 記錄(Recording)規(guī)則

記錄規(guī)則允許您預(yù)先計算出經(jīng)常使用的PromQL表達式，并且需要相對大量的步驟，來實現(xiàn)表達式的結(jié)果。據(jù)此，在下一次運行相同的PromQL查詢時，您可以直接從預(yù)先計算出的PromQL結(jié)果中獲取到。這比反復(fù)執(zhí)行相同的查詢要快得多。例如：

Go 
groups: 
  - name: example 
    rules: 
    - record: job:http_inprogress_requests:sum 
      expr: sum by (job) (http_inprogress_requests) 

• 警報(Alerting)規(guī)則

警報規(guī)則允許您根據(jù)PromQL定義的警報條件，將有關(guān)觸發(fā)警報的通知，發(fā)送到外部接收器上。只要警報表達式的結(jié)果為True時，就會發(fā)送警報。例如：

Go 
groups: 
- name: example 
  rules: 
  - alert: HighRequestLatency 
    expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5 
    for: 10m 
    labels: 
      severity: page 
    annotations: 
      summary: High request latency 

警報和可視化

圖片來源：Prometheus的介紹(https://www.youtube.com/watch?v=9GMWvFcQjYI&t=314s)

在配置了警報規(guī)則后，我們需要通過Alertmanager來添加警報摘要、控制、甚至將收到的通知“靜音”。如上圖所示，Alertmanager會定期從Prometheus服務(wù)器處接收有關(guān)警報狀態(tài)的信息，以確保對已定義的接收者(如電子郵件、PagerDuty等)進行分組、數(shù)據(jù)去重、以及通知發(fā)送。

我們不必擔心在何處、以及如何在Kubernetes集群中定義或設(shè)置Alertmanager。我們之前在Helm Chart的幫助下部署Prometheus Operator時，已經(jīng)創(chuàng)建了一個作為StatefulSet的Alertmanager。請參見如下代碼：

Go 
kubectl get statefulsets.apps  
 
NAME                                                    READY      AGE 
alertmanager-prometheus-prometheus-oper-alertmanager    1/1         8d 

Alertmanager StatefulSet會在內(nèi)部使用一個配置文件--alertmanager.yaml。我們可以將它放入alertmanagerpod中。請參見如下命令：

Go 
/bin/alertmanager --config.file=/etc/alertmanager/config/alertmanager.yaml 

alertmanager.yaml文件包含了如下關(guān)鍵元素：

• 路由：這是一個代碼塊，可用于定義將警報路由到下一個位置。
• 接收器：接收器是可用來發(fā)送或通知警報的網(wǎng)絡(luò)鉤子、郵件地址、以及PagerDuty之類的工具。
• 禁止規(guī)則：禁止規(guī)則部分可以在另一個警報因相同原因被觸發(fā)時，使之“靜音”。例如，對于那些已經(jīng)處于critical級別的應(yīng)用服務(wù)，即便再次出現(xiàn)故障，其警告通知也會被靜音。

我們可以通過如下示例來查看Alertmanager的配置文件：

Go 
global: 
  resolve_timeout: 5m 
 
route: 
  group_by: ['alertname'] 
  group_wait: 10s 
  group_interval: 10s 
  repeat_interval: 1h 
  receiver: 'web.hook' 
receivers: 
- name: 'web.hook' 
  webhook_configs: 
  - url: 'http://127.0.0.1:5001/' 
inhibit_rules: 
  - source_match: 
      severity: 'critical' 
    target_match: 
      severity: 'warning' 
    equal: ['alertname', 'dev', 'instance'] 

使用Grafana進行指標可視化

作為一種標準化工​​具，Grafana可以幫助您可視化那些在Prometheus的幫助下，收集到的所有指標。kube-Prometheus-stack的Helm Chart已經(jīng)為我們部署了Grafana。我們可以通過如下命令，定位Grafana服務(wù)。

Go 
kubectl get services  
 
NAME                               TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                       
 
prometheus-grafana                ClusterIP    10.104.143.147    <none>       80/TCP       

通過如下代碼，我們可以將端口轉(zhuǎn)發(fā)到此服務(wù)上，以便顯示在Grafana的Web界面上。

Go 
kubectl port-forward svc/prometheus-grafana 3000:80 
 
Forwarding from 127.0.0.1:3000 -> 3000 
Forwarding from [::1]:3000 -> 3000 

如下圖，您可以在瀏覽器中訪問http://localhost:3000。

在輸入了默認用戶名：admin和密碼：prom-operator后，您可以訪問到Grafana儀表板，如下圖所示。

依次點擊Dashboard -> Manage，您將能夠看到由kube-prometheus-stack提供的有關(guān)Kubernetes集群的所有儀表板：

您可以瀏覽到諸如“Kubernetes/Compute Resources/Pod”等儀表板信息：

上面展示的標準化儀表板便是從kubernetes-mixin項目生成的。

小結(jié)

綜上所述，我們討論了Prometheus Operator是什么，如何在Prometheus Operator和Helm Chart的幫助下輕松地配置Prometheus，Prometheus如何發(fā)現(xiàn)帶監(jiān)控的資源，以及該如何配置Prometheus的各個組件與運作機制。此外，我們還探討了如何設(shè)置警報，以及如何將它們可視化。

原文標題：Prometheus Definitive Guide: Prometheus Operator，作者：Ninad Desai

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】