【DevOps实战之k8s】Prometheus Operator的服务发现Monitor：Pod Monitor, Service Monitor，Scrape Config
@TOC
推荐超级课程：
Prometheus Operator 是一个流行的工具，用于在Kubernetes中管理和部署Prometheus和相关的监控组件。 要建立一个有效的监控策略，我们需要熟悉一些基础知识，比如如何发现服务。 目前，可以通过Pod Monitor、Service Monitor和全新的Scrape Config CRD 来实现。 在本文中，我们将对它们进行更详细的介绍。 您需要对监控概念、Kubernetes和Prometheus Operator 有一定的了解。
在Kubernetes中运行的应用程序
要监控在Kubernetes中运行的应用程序，选择应该是Pod Monitor或Service Monitor，取决于是否与Kubernetes Service相关联。
例如，如果您运行的是某种作业或部署，不需要处理来自集群内外其他运行中应用程序的流量，可能就不需要创建一个Kubernetes Service。在这种情况下，使用简单的Pod Monitor 就可以发现您的应用程序。
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
name: example-app
labels:
team: frontend
spec:
selector:
matchLabels:
app: example-app
podMetricsEndpoints:
- port: web
Pod Monitor的其他用途可能是，应用程序由多个具有不同指标或配置的Pod组成，无法使用Service Monitor来针对特定需求对其进行目标化，例如配置的Scrape间隔、指标重标签或特定于服务中某些Pod的唯一指标端点路径。
对于使用Service Monitor, 可以为每个单独的服务创建一个Service Monitor。
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: prometheus
spec:
serviceAccountName: prometheus
serviceMonitorSelector:
matchLabels:
team: frontend
resources:
requests:
memory: 400Mi
enableAdminAPI: false
或者另一种策略可能是使用一个Service Monitor 来针对多个应用程序。
例如，如果您想要为多个服务定义某种的配置，例如指标重标签配置或限制，您只需要以快速方式强制执行某些值，就需要保证某些特定值与Kubernetes服务相同，例如相同的端口名称和服务标签。而且被此默认Service Monitor 定位的应用程序需要在相同的指标路径下暴露指标。下面是一个示例：
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: default-service-monitor
namespace: monitoring
spec:
endpoints:
- interval: 10s
path: /metrics
port: metrics
scheme: http
jobLabel: app.kubernetes.io/name
namespaceSelector:
any: true
sampleLimit: 1000
selector:
matchExpressions:
- key: app.kubernetes.io/name
operator: Exists
---
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/name: my-custom-service
name: my-custom-service
namespace: monitoring
spec:
ports:
- name: metrics
port: 9100
protocol: TCP
targetPort: 9100
selector:
app.kubernetes.io/name: my-custom-service
在Kubernetes之外
如果您的监控基础设施位于Kubernetes中，但也需要发现在Kubernetes之外运行的服务，长期以来唯一的方法是通过additionalScrapeConfigs。
但是根据个人经验，可能很快变得混乱。想象一下有很多需要监控的服务，以及一个有着超过2000行的additionalScrapeConfigs
配置文件，您就能明白——一个错误的合并请求就能很容易搞砸一切。
幸运的是，Prometheus Operator 社区在今年为additionalScrapeConfigs 提供了一个替代方法，即Scrape Config CRD 。它已经支持了几种服务发现方法，可以在这里 查阅。
graph TD; ServiceMonitor --> prometheusConfig PodMonitor --> prometheusConfig ScrapeConfig --> prometheusConfig prometheusConfig
下面是一个快速示例，展示如何将服务从additionalScrapeConfigs移动并转换为Scrape Config。
首先，使用kube-prometheus-stack helm charts 部署Prometheus堆栈，进行一些值更改，比如将scrapeConfigSelector定位到我们稍后将创建的Scrape Config。
prometheus:
prometheusSpec:
scrapeConfigSelector:
matchLabels:
release: prom
prometheusOperator:
image:
tag: main
同时，由于在撰写本文时有一些最新的错误修复，我们也拉取主要的镜像。另存为main-values，并在您的命名空间中部署。
helm upgrade -i prom prometheus-community/kube-prometheus-stack -n monitoring -f main-values.yaml
然后创建Scrape Config文件，根据您在additionalScrapeConfigs中定位的服务。以下是两个服务的示例，一个使用Consul SD，另一个使用静态配置来对两个数据库进行监控。
apiVersion: monitoring.coreos.com/v1alpha1
kind: ScrapeConfig
metadata:
name: mongodb
labels:
release: prom
spec:
consulSDConfigs:
- server: https://consul-dns:8500
services:
- mongodb
relabelings:
- sourceLabels: [__meta_consul_service]
targetLabel: job
---
apiVersion: monitoring.coreos.com/v1alpha1
kind: ScrapeConfig
metadata:
name: cassandra
labels:
prometheus: test
release: prom
spec:
staticConfigs:
- labels:
job: cassandra
targets:
- 172.20.0.2:9500
创建完成后，访问Prometheus UI，您将能够在那里检查您的目标。
