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 根据定义自动创建Prometheus scrape 配置。
• 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 工作相当完美，我强烈建议使用它。

我希望你喜欢它，请不要犹豫给反馈和分享你自己的经验。