前一篇讲了在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: