K8S监控-Prometheus信息收集

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

发表评论

error: Content is protected !!