Prometheus Operator - 如何監控一個外部服務

原文地址： Prometheus Operator — How to monitor an external service

本實踐指南中咱們將看到如何部署Prometheus Operator到Kubernetes集羣中，以及如何增長一個外部服務到Prometheus的targets列表。

在個人上個項目中，咱們決定使用Prometheus Operator做爲咱們的監控和報警工具。咱們的應用運行於Kubernetes集羣中，可是除此咱們還有個外部應用 — 一個GPU機器。

Kubernetes根本感知不到這個服務，相關服務經過HTTP請求鏈接該服務。我想跟大家分享下我使用Prometheus Operator的經驗以及如何定製它來監控外部服務。

什麼是Prometheus

Prometheus是最先由 SoundCloud開發的一個開源系統監控及報警工具。自從它2012年建立以來，許多公司和組織使用。 Prometheus及其社區有一個很是活躍的開發者羣體和 用戶社區。它如今是一個獨立的開源項目，獨立於任何公司進行維護。
company.

Prometheus已經成爲Kubernetes和Docker領域監控和報警的事實標準。它提供了到目前爲止最詳細和可操做的監控指標和分析。在最新的主要版本2.0版本（訪問下載頁面查看當前最新版）Prometheus的性能有了顯著提高，而且如今它在高負載和併發下表現良好。除此之外你能夠得到世界領先的開源項目的全部好處。Prometheus能夠無償使用，並能夠輕鬆覆蓋不少使用場景。

Prometheus Operator

2016年年底，CoreOs引入了Operator 模式，併發布了Prometheus Operator 做爲Operator模式的工做示例。Prometheus Operator自動建立和管理Prometheus監控實例。

Prometheus Operator的任務是使得在 Kubernetes運行 Prometheus僅可能容易，同時保留可配置性以及使 Kubernetes配置原生。 https://coreos.com/operators/...

Prometheus Operator使咱們的生活更容易——部署和維護。

它如何工做

爲了理解這個問題，咱們首先須要瞭解Prometheus Operator得工做原理。

Prometheus Operator架構圖. 來源：prometheus-operator

咱們成功部署 Prometheus Operator後能夠看到一個新的CRDs(Custom Resource Defination):

• Prometheus，定義一個指望的Prometheus deployment。
• ServiceMonitor，聲明式指定應該如何監控服務組；Operator根據定義自動建立Prometheusscrape配置。
• Alertmanager，定義指望的Alertmanager deployment。

當服務新版本更新時，將會常見一個新Pod。Prometheus監控k8s API，所以當它檢測到這種變化時，它將爲這個新服務(pod)建立一組新的配置。

ServiceMonitor

Prometheus Operator使用一個CRD，叫作ServiceMonitor將配置抽象到目標。
下面是是個ServiceMonitor的示例：

apiVersion: monitoring.coreos.com/v1alpha1
kind: ServiceMonitor
metadata:
  name: frontend
  labels:
    tier: frontend
spec:
  selector:
    matchLabels:
      tier: frontend
  endpoints:
  - port: web            # works for different port numbers as long as the name matches
    interval: 10s        # scrape the endpoint every 10 seconds

這僅僅是定義一組服務應該如何被監控。如今咱們須要定義一個包含了該ServiceMonitor的Prometheus實例到其配置：

apiVersion: monitoring.coreos.com/v1alpha1
kind: Prometheus
metadata:
  name: prometheus-frontend
  labels:
    prometheus: frontend
spec:
  version: v1.3.0
  # Define that all ServiceMonitor TPRs with the label `tier = frontend` should be included
  # into the server's configuration.
  serviceMonitors:
  - selector:
      matchLabels:
        tier: frontend

如今Prometheus將會監控每一個帶有tier: frontend label的服務。

問題

想我說講的那樣，咱們想監控一個外部服務，在這個GPU機器上我啓動一個node-exporter：

docker run -d -p 9100:9100 node-exporter

咱們想要發送node-exportor數據到Prometheus。

咱們應該如何爲一個既沒有Pod也沒有Service的服務建立ServiceMonitor呢？

爲了解決這個問題，我決定深刻研究Kubernetes如何處理Pod和Service的關係。

在Kubernetes官方文檔Service頁面，我發現了一下內容：

針對 Kubernetes原生應用， Kubernetes提供了一個簡單 Endpoints API，當服務中的一組pod發生更改時，該API就會更新。對於非本機應用程序，Kubernetes提供了一個基於虛擬ip的服務橋接器，服務將重定向到後端pod。

這就是我想要的解決方案！我須要建立一個自定義EndPoint定義我外部服務匹配Service和最終的ServiceMonitor定義，這樣Prometheus就會把它增長到targets列表。

安裝Prometheus Operator

先決條件：

• Kubernetes命令和組件基本知識
• 一個工做的Kubernetes集羣
• 部署了Helm

準備好動手操做：

idob ~(☸|kube.prometheus:default):
▶ helm repo add coreos https://s3-eu-west-1.amazonaws.com/coreos-charts/stable/
idob ~(☸|kube.prometheus:default): 
▶ helm install coreos/prometheus-operator --name prometheus-operator --namespace monitoring

到目前爲止，咱們已經在咱們的集羣中安裝了Prometheus Operator的TPR。
如今咱們來部署Prometheus，Alertmanager和Grafana。

TIP: 當我使用一個龐大的 Helm Charts時，我更傾向於建立一個獨立的 value.yaml文件將包含我全部自定義的變動。這麼作使我和同事爲後期的變化和修改更容易。

idob ~(☸|kube.prometheus:default):
▶ helm install coreos/kube-prometheus --name kube-prometheus   \
       -f my_changes/prometheus.yaml                           \
       -f my_changes/grafana.yaml                              \
       -f my_changes/alertmanager.yaml

就是這樣，很簡單，對吧?

要檢查一切是否運行正常你應該這麼作：

idob ~(☸|kube.prometheus:default): 
▶ k -n monitoring get po
NAME                                                   READY     STATUS    RESTARTS   AGE
alertmanager-kube-prometheus-0                         2/2       Running   0          1h
kube-prometheus-exporter-kube-state-68dbb4f7c9-tr6rp   2/2       Running   0          1h
kube-prometheus-exporter-node-bqcj4                    1/1       Running   0          1h
kube-prometheus-exporter-node-jmcq2                    1/1       Running   0          1h
kube-prometheus-exporter-node-qnzsn                    1/1       Running   0          1h
kube-prometheus-exporter-node-v4wn8                    1/1       Running   0          1h
kube-prometheus-exporter-node-x5226                    1/1       Running   0          1h
kube-prometheus-exporter-node-z996c                    1/1       Running   0          1h
kube-prometheus-grafana-54c96ffc77-tjl6g               2/2       Running   0          1h
prometheus-kube-prometheus-0                           2/2       Running   0          1h
prometheus-operator-1591343780-5vb5q                   1/1       Running   0          1h

咱們來訪問下Prometheus UI看一下Targets頁面：

idob ~(☸|kube.prometheus:default):
▶ k -n monitoring port-forward prometheus-kube-prometheus-0 9090
Forwarding from 127.0.0.1:9090 -> 9090

瀏覽器展現以下：

咱們能夠看到一堆已經默認定義的Targets，咱們的目標是添加新的GPU Targets。

咱們須要找到當前Prometheus正在尋找的label並使用它。（咱們應該建立一個新的Prometheus實例並配置它只搜索咱們的label，但我認爲再多搜索一個targe就太過度了）

idob ~(☸|kube.prometheus:default): 
▶ k -n monitoring get prometheus kube-prometheus -o yaml
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  labels:
    app: prometheus
    chart: prometheus-0.0.14
    heritage: Tiller
    prometheus: kube-prometheus
    release: kube-prometheus
  name: kube-prometheus
  namespace: monitoring
spec:
  ...
  baseImage: quay.io/prometheus/prometheus
  serviceMonitorSelector:
    matchLabels:
      prometheus: kube-prometheus     # <--- BOOM
  ....

一切就緒，咱們已經爲咱們的target建立必備資源作好了準備。

Endpoint

apiVersion: v1
kind: Endpoints
metadata:
    name: gpu-metrics
    labels:
        k8s-app: gpu-metrics
subsets:
    - addresses:
    - ip: <gpu-machine-ip>
ports:
    - name: metrics
      port: 9100
      protocol: TCP

正如咱們所決定的，咱們正在建立本身的靜態endpoint，咱們提供了IP，Port 以及只描述咱們GPU服務的label: k8s-app: gpu-exporter。

Service

apiVersion: v1
kind: Service
metadata:
    name: gpu-metrics-svc
    namespace: monitoring
    labels:
        k8s-app: gpu-metrics
spec:
    type: ExternalName
    externalName: <gpu-machine-ip>
    clusterIP: ""
    ports:
    - name: metrics
      port: 9100
      protocol: TCP
      targetPort: 9100

ServiceMonitor

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
    name: gpu-metrics-sm
    labels:
        k8s-app: gpu-metrics
        prometheus: kube-prometheus
spec:
    selector:
        matchLabels:
            k8s-app: gpu-metrics
        namespaceSelector:
            matchNames:
            - monitoring
    endpoints:
    - port: metrics
      interval: 10s
      honorLabels: true

最重要的部分是label — 咱們必須分配label: prometheus: kube-prometheus 所以Prometheus服務器將在matchlabel部分查找此目標和第二個標籤，以便ServiceMonitor只指向咱們的gpu-export。

咱們來apply全部：

idob ~(☸|kube.prometheus:default): 
▶ k apply -f gpu-exporter-ep.yaml  \
          -f gpu-exporter-svc.yaml \
          -f gpu-exporter-sm.yaml

如今已經切換到Prometheus UI，若是咱們看目標頁面，咱們應該看到咱們的GPU在列表中:

就是這樣。如你所見部署Prometheus Operator至關容易而且如今我但願你能夠簡單的監控你全部服即便他們已存在於你Kubetnetes集羣之外。從個人經驗來看Prometheus Operator工做至關完美，我強烈建議使用它。

我但願你喜歡它，請不要猶豫給反饋和分享你本身的經驗。