前一篇讲了在K8S群集中部署Prometheus监控系统,以下会循序渐进地操作ConfigMap中的配置文件,以观测采集的结果。
简单服务发现(仅演示)
在Prometheus配置文件的scrape_configs添加Job配置:
vim prometheus-config.yml
apiVersion: v1
kind: ConfigMap
metadata:
name: prometheus
namespace: monitoring
labels:
app: prometheus
release: v2.26.0
data:
prometheus.yml: |
global:
evaluation_interval: 1m
scrape_interval: 15s
scrape_timeout: 10s
scrape_configs:
- job_name: 'kubernetes-nodes'
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:
- role: node
- job_name: 'kubernetes-service'
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:
- role: service
- job_name: 'kubernetes-endpoints'
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:
- role: endpoints
- job_name: 'kubernetes-ingress'
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:
- role: ingress
- job_name: 'kubernetes-pods'
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:
- role: pod
kubectl replace -f prometheus-config.yml kubectl -n monitoring delete pod prometheus-0 kubectl -n monitoring get pod
通过指定kubernetes_sd_config的模式为node,Prometheus会自动从Kubernetes中发现到所有的node节点并作为当前Job监控的Target实例。这里需要指定用于访问Kubernetes API的ca以及token文件路径。对于Ingress,Service,Endpoints, Pod的使用方式也是类似。
Prometheus使用新的配置文件重建之后,打开Prometheus UI,通过Service Discovery页面可以查看到当前Prometheus通过Kubernetes发现的所有资源对象了:
同时Prometheus会自动将该资源的所有信息,并通过标签的形式体现在Target对象上。不过,如果现在查看Promtheus的Target状态页面,结果会让人不太满意:
虽然Prometheus能够自动发现所有的资源对象,并且将其作为Target对象进行数据采集。 但并不是所有的资源对象都支持Promethues,并且不同类型资源对象的采集方式也是不同的。
Kube信息收集(cadvisor)
Kubelet组件运行在K8S集群的各个节点中,其负责维护和管理节点上Pod的运行状态。kubelet组件的正常运行直接关系到该节点是否能够正常的被K8S集群正常使用。
通过Kubernetes的api-server提供的代理API访问各个节点中kubelet的metrics服务,修改配置文件如下:
...
- job_name: 'kubernetes-cadvisor'
scheme: https
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
insecure_skip_verify: true
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:
- role: node
relabel_configs:
- action: labelmap
regex: __meta_kubernetes_node_label_(.+)
- target_label: __address__
replacement: kubernetes.default.svc:443
- source_labels:
- __meta_kubernetes_node_name
regex: (.+)
target_label: __metrics_path__
replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
通过relabel,将从K8S获取到的默认地址__address__替换为kubernetes.default.svc:443 。同时将__metrics_path__替换为api-server的代理地址/api/v1/nodes/${1}/proxy/metrics/cadvisor。
重新加载配置后即可正常发现Target:



