Prometheus Operator 使用ServiceMonitor管理监控配置

网友投稿 2197 2022-11-30

Prometheus Operator 使用ServiceMonitor管理监控配置

Prometheus Operator 使用ServiceMonitor管理监控配置

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: ServiceapiVersion: v1metadata: name: example-app labels: app: example-appspec: selector: app: example-app ports: - name: web port: 8080 targetPort: 8080---apiVersion: apps/v1kind: Deploymentmetadata: name: example-appspec: selector: matchLabels: app: example-app replicas: 3 template: metadata: labels: app: example-app spec: containers: - name: example-app image: fabxc/instrumented_app ports: - name: web containerPort: 8080

更新yaml文件:

kubectl apply -f example-app.yaml

示例应用会通过Deployment创建3个Pod实例,并且通过Service暴露应用访问信息。

kubectl get pods

显示如下:

NAME READY STATUS RESTARTS AGEexample-app-bb759dfcc-7njwm 1/1 Running 0 110sexample-app-bb759dfcc-8sl77 1/1 Running 0 110sexample-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_The current number of API HTTP requests in progress.# TYPE codelab_api_gaugecodelab_api_0# HELP codelab_api_request_duration_seconds A histogram of the API HTTP request durations in seconds.# TYPE codelab_api_request_duration_seconds histogramcodelab_api_request_duration_seconds_bucket{method="GET",path="/api/bar",status="200",le="0.0001"} 0codelab_api_request_duration_seconds_bucket{method="GET",path="/api/bar",status="200",le="0.00015000000000000001"} 0codelab_api_request_duration_seconds_bucket{method="GET",path="/api/bar",status="200",le="0.00022500000000000002"} 0codelab_api_request_duration_seconds_bucket{method="GET",path="/api/bar",status="200",le="0.0003375"} 0

在原生的Prometheus配置方式中,我们在Prometheus配置文件中定义单独的Job,同时使用kubernetes_sd定义整个服务发现过程。

cat example-app-service-monitor.yaml

apiVersion: monitoring.coreos.com/v1kind: ServiceMonitormetadata: name: example-app namespace: monitoring labels: team: frontendspec: namespaceSelector: matchNames: - default selector: matchLabels: app: example-app endpoints: - port: web

这里ServiceMonitor可以对资源指标做监控    - port: web是上面pod里面暴露的8080端口

# kubectl get servicemonitor -n monitoringNAME AGEexample-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/v1kind: ServiceMonitormetadata: name: example-app namespace: monitoring labels: team: frontendspec: namespaceSelector: matchNames: - default selector: matchLabels: app: example-app endpoints: - basicAuth: password: name: basic-auth key: password username: name: basic-auth key: user port: web

其中basicAuth中关联了名为basic-auth的Secret对象,用户需要手动将认证信息保存到Secret中:

apiVersion: v1kind: Secretmetadata: name: basic-authdata: 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/v1kind: Prometheusmetadata: name: inst namespace: monitoringspec: serviceMonitorSelector: matchLabels: team: frontend resources: requests: memory: 400Mi

将对Prometheus的变更应用到集群中:

$ kubectl -n monitoring apply -f prometheus-inst.yaml

此时,在浏览 scrape_interval: 30s scrape_timeout: 10s evaluation_interval: 30s external_labels: prometheus: monitoring/inst prometheus_replica: prometheus-inst-0alerting: alert_relabel_configs: - separator: ; regex: prometheus_replica replacement: $1 action: labeldroprule_files:- /etc/prometheus/rules/prometheus-inst-rulefiles-0/*.yamlscrape_configs:- job_name: monitoring/example-app/0 honor_timestamps: true scrape_interval: 30s scrape_timeout: 10s metrics_path: /metrics scheme: kubernetes_sd_configs: - role: endpoints namespaces: names: - default relabel_configs: - source_labels: [__meta_kubernetes_service_label_app] separator: ; regex: example-app replacement: $1 action: keep - source_labels: [__meta_kubernetes_endpoint_port_name] separator: ; regex: web replacement: $1 action: keep - source_labels: [__meta_kubernetes_endpoint_address_target_kind, __meta_kubernetes_endpoint_address_target_name] separator: ; regex: Node;(.*) target_label: node replacement: ${1} action: replace - source_labels: [__meta_kubernetes_endpoint_address_target_kind, __meta_kubernetes_endpoint_address_target_name] separator: ; regex: Pod;(.*) target_label: pod replacement: ${1} action: replace - source_labels: [__meta_kubernetes_namespace] separator: ; regex: (.*) target_label: namespace replacement: $1 action: replace - source_labels: [__meta_kubernetes_service_name] separator: ; regex: (.*) target_label: service replacement: $1 action: replace - source_labels: [__meta_kubernetes_pod_name] separator: ; regex: (.*) target_label: pod replacement: $1 action: replace - source_labels: [__meta_kubernetes_service_name] separator: ; regex: (.*) target_label: job replacement: ${1} action: replace - separator: ; regex: (.*) target_label: endpoint replacement: web action: replace

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:Springboot整合Redis实现超卖问题还原和流程分析(分布式锁)
下一篇:kube-proxy 部署
相关文章

 发表评论

暂时没有评论,来抢沙发吧~