ServiceMonitor
该 CRD 定义了如何监控一组动态的服务，使用标签选择来定义哪些 Service 被选择进行监控。这可以让团队制定一个如何暴露监控指标的规范，然后按照这些规范自动发现新的服务，而无需重新配置。
为了让 Prometheus 监控 Kubernetes 内的任何应用，需要存在一个 Endpoints 对象，Endpoints 对象本质上是 IP 地址的列表，通常 Endpoints 对象是由 Service 对象来自动填充的，Service 对象通过标签选择器匹配 Pod，并将其添加到 Endpoints 对象中。一个 Service 可以暴露一个或多个端口，这些端口由多个 Endpoints 列表支持，这些端点一般情况下都是指向一个 Pod。
Prometheus Operator 引入的这个 ServiceMonitor 对象就会发现这些 Endpoints 对象，并配置 Prometheus 监控这些 Pod。ServiceMonitorSpec 的 endpoints 部分就是用于配置这些 Endpoints 的哪些端口将被 scrape 指标的。
注意：endpoints（小写）是 ServiceMonitor CRD 中的字段，而 Endpoints（大写）是 Kubernetes 的一种对象。
ServiceMonitors 以及被发现的目标都可以来自任何命名空间，这对于允许跨命名空间监控的场景非常重要。使用 PrometheusSpec 的 ServiceMonitorNamespaceSelector，可以限制各自的 Prometheus 服务器选择的 ServiceMonitors 的命名空间。
使用 ServiceMonitorSpec 的 namespaceSelector，可以限制 Endpoints 对象被允许从哪些命名空间中发现，要在所有命名空间中发现目标，namespaceSelector 必须为空：
spec:namespaceSelector:any: true
使用ServiceMonitor管理监控配置
修改监控配置项也是Prometheus下常用的运维操作之一，为了能够自动化的管理Prometheus的配置，Prometheus Operator使用了自定义资源类型ServiceMonitor来描述监控对象的信息。这里我们首先在集群中部署一个示例应用，将以下内容保存到example-app.yaml，并使用kubectl命令行工具创建：cat example-app.yaml
kind: Service
apiVersion: v1
metadata:name: example-applabels:app: example-app
spec:selector:app: example-appports:- name: webport: 8080targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:name: example-app
spec:selector:matchLabels:app: example-appreplicas: 3template:metadata:labels:app: example-appspec:containers:- name: example-appimage: fabxc/instrumented_appports:- name: webcontainerPort: 8080更新yaml文件：
kubectl apply -f example-app.yaml 示例应用会通过Deployment创建3个Pod实例，并且通过Service暴露应用访问信息。
kubectl get pods显示如下：
NAME READY STATUS RESTARTS AGE
example-app-bb759dfcc-7njwm 1/1 Running 0 110s
example-app-bb759dfcc-8sl77 1/1 Running 0 110s
example-app-bb759dfcc-ckjqf 1/1 Running 0 110s访问本地的svc:8080/metrics实例应用程序会返回以下样本数据：
[root@master prometheus-operator]# curl 10.233.11.186:8080/metrics
# HELP codelab_api_http_requests_in_progress The current number of API HTTP requests in progress.
# TYPE codelab_api_http_requests_in_progress gauge
codelab_api_http_requests_in_progress 0
# HELP codelab_api_request_duration_seconds A histogram of the API HTTP request durations in seconds.
# TYPE codelab_api_request_duration_seconds histogram
codelab_api_request_duration_seconds_bucket{method="GET",path="/api/bar",status="200",le="0.0001"} 0
codelab_api_request_duration_seconds_bucket{method="GET",path="/api/bar",status="200",le="0.00015000000000000001"} 0
codelab_api_request_duration_seconds_bucket{method="GET",path="/api/bar",status="200",le="0.00022500000000000002"} 0
codelab_api_request_duration_seconds_bucket{method="GET",path="/api/bar",status="200",le="0.0003375"} 0为了能够让Prometheus能够采集部署在Kubernetes下应用的监控数据，在原生的Prometheus配置方式中，我们在Prometheus配置文件中定义单独的Job，同时使用kubernetes_sd定义整个服务发现过程。
而在Prometheus Operator中，则可以直接声明一个ServiceMonitor对象，如下所示：
cat example-app-service-monitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:name: example-appnamespace: monitoringlabels:team: frontend
spec:namespaceSelector:matchNames:- defaultselector:matchLabels:app: example-appendpoints:- port: web这里ServiceMonitor可以对资源指标做监控 - port: web是上面pod里面暴露的8080端口
# kubectl get servicemonitor -n monitoring
NAME AGE
example-app 7m33s通过定义selector中的标签定义选择监控目标的Pod对象，同时在endpoints中指定port名称为web的端口。默认情况下ServiceMonitor和监控对象必须是在相同Namespace下的。
在本示例中由于Prometheus是部署在Monitoring命名空间下，因此为了能够关联default命名空间下的example对象，需要使用namespaceSelector定义让其可以跨命名空间关联ServiceMonitor资源。保存以上内容到example-app-service-monitor.yaml文件中，并通过kubectl创建：
kubectl create -f example-app-service-monitor.yaml如果希望ServiceMonitor可以关联任意命名空间下的标签，则通过以下方式定义：
spec:namespaceSelector:any: true如果监控的Target对象启用了BasicAuth认证，那在定义ServiceMonitor对象时，可以使用endpoints配置中定义basicAuth如下所示：
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:name: example-appnamespace: monitoringlabels:team: frontend
spec:namespaceSelector:matchNames:- defaultselector:matchLabels:app: example-appendpoints:- basicAuth:password:name: basic-authkey: passwordusername:name: basic-authkey: userport: web其中basicAuth中关联了名为basic-auth的Secret对象，用户需要手动将认证信息保存到Secret中:
apiVersion: v1
kind: Secret
metadata:name: basic-auth
data:password: dG9vcg== # base64编码后的密码user: YWRtaW4= # base64编码后的用户名
type: Opaque关联Promethues与ServiceMonitor
Prometheus与ServiceMonitor之间的关联关系使用serviceMonitorSelector定义，在Prometheus中通过标签选择当前需要监控的ServiceMonitor对象。
修改prometheus-inst.yaml中Prometheus的定义如下所示： 为了能够让Prometheus关联到ServiceMonitor，需要在Pormtheus定义中使用serviceMonitorSelector，我们可以通过标签选择当前Prometheus需要监控的ServiceMonitor对象。修改prometheus-inst.yaml中Prometheus的定义如下所示：
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:name: instnamespace: monitoring
spec:serviceMonitorSelector:matchLabels:team: frontendresources:requests:memory: 400Mi将对Prometheus的变更应用到集群中：
$ kubectl -n monitoring apply -f prometheus-inst.yaml此时，在浏览http://192.168.0.6:31535/config查看Prometheus配置信息，我们会惊喜的发现Prometheus中配置文件自动包含了一条名为monitoring/example-app/0的Job配置：
global:scrape_interval: 30sscrape_timeout: 10sevaluation_interval: 30sexternal_labels:prometheus: monitoring/instprometheus_replica: prometheus-inst-0
alerting:alert_relabel_configs:- separator: ;regex: prometheus_replicareplacement: $1action: labeldrop
rule_files:
- /etc/prometheus/rules/prometheus-inst-rulefiles-0/*.yaml
scrape_configs:
- job_name: monitoring/example-app/0honor_timestamps: truescrape_interval: 30sscrape_timeout: 10smetrics_path: /metricsscheme: httpkubernetes_sd_configs:- role: endpointsnamespaces:names:- defaultrelabel_configs:- source_labels: [__meta_kubernetes_service_label_app]separator: ;regex: example-appreplacement: $1action: keep- source_labels: [__meta_kubernetes_endpoint_port_name]separator: ;regex: webreplacement: $1action: keep- source_labels: [__meta_kubernetes_endpoint_address_target_kind, __meta_kubernetes_endpoint_address_target_name]separator: ;regex: Node;(.*)target_label: nodereplacement: ${1}action: replace- source_labels: [__meta_kubernetes_endpoint_address_target_kind, __meta_kubernetes_endpoint_address_target_name]separator: ;regex: Pod;(.*)target_label: podreplacement: ${1}action: replace- source_labels: [__meta_kubernetes_namespace]separator: ;regex: (.*)target_label: namespacereplacement: $1action: replace- source_labels: [__meta_kubernetes_service_name]separator: ;regex: (.*)target_label: servicereplacement: $1action: replace- source_labels: [__meta_kubernetes_pod_name]separator: ;regex: (.*)target_label: podreplacement: $1action: replace- source_labels: [__meta_kubernetes_service_name]separator: ;regex: (.*)target_label: jobreplacement: ${1}action: replace- separator: ;regex: (.*)target_label: endpointreplacement: webaction: replace