共计 5711 个字符，预计需要花费 15 分钟才能阅读完成。

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

本实践指南中我们将看到如何部署 Prometheus Operator 到Kubernetes集群中，以及如何增加一个外部服务到 Prometheus 的targets列表。

在我的上个项目中，我们决定使用 Prometheus Operator 作为我们的监控和报警工具。我们的应用运行于 Kubernetes 集群中，但是除此我们还有个外部应用 — 一个 GPU 机器。

Kubernetes根本感知不到这个服务，相关服务通过 HTTP 请求连接该服务。我想跟你们分享下我使用 Prometheus Operator 的经验以及如何定制它来监控外部服务。

Prometheus 是最早由 SoundCloud 开发的一个开源系统监控及报警工具。自从它 2012 年创建以来，许多公司和组织使用。Prometheus及其社区有一个非常活跃的开发者群体和用户社区。它现在是一个独立的开源项目，独立于任何公司进行维护。
company.

Prometheus已经成为 Kubernetes 和Docker领域监控和报警的事实标准。它提供了到目前为止最详细和可操作的监控指标和分析。在最新的主要版本 2.0 版本（访问下载页面查看当前最新版）Prometheus的性能有了显著提升，并且现在它在高负载和并发下表现良好。除此以外你可以获得世界领先的开源项目的所有好处。Prometheus可以免费使用，并可以轻松覆盖很多使用场景。

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) 创建一组新的配置。

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 创建必备资源做好了准备。

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。

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

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 工作相当完美，我强烈建议使用它。

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

Prometheus Operator – 如何监控一个外部服务

什么是 Prometheus