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工做至关完美，我强烈建议使用它。

我但愿你喜欢它，请不要犹豫给反馈和分享你本身的经验。