之前的写法：把 pod ip 写入配置文件。如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

- job_name: 'service-endpoints-metrics'
  kubernetes_sd_configs:
  - role: endpoints
  metrics_path: /actuator/prometheus
  static_configs:
  - targets: ['172.20.87.93:8088']
    labels: 
      app: idk-sdk
  - targets: ['172.20.232.20:8088']
    labels: 
      app: idk-sdk
  - targets: ['172.20.87.192:8088']
    labels: 
      app: idk-sdk
  - targets: ['172.20.86.26:8088']
    labels: 
      app: idk-sdk
  - targets: ['172.20.60.87:8088']
    labels: 
      app: idk-sdk
  - targets: ['172.20.22.247:8088']
    labels: 
      app: idk-sdk
  - targets: ['172.20.83.23:8088']
    labels: 
      app: idk-tsp
  - targets: ['172.20.22.165:8088']
    labels: 
      app: idk-tsp
  - targets: ['172.20.63.105:8088']
    labels: 
      app: idk-tsp
  - targets: ['idk-mob-app:8088']
    labels: 
      app: idk-app

痛点分析：

在 Kubernetes 中，直接使用 Pod IP 进行监控存在明显的局限性：一旦 Pod 发生重新部署或被节点驱逐，Pod IP 就会发生漂移，导致监控端必须频繁手动更新目标 IP。

如果转而使用 Service 地址进行监控，在单副本（Single Pod）情况下尚可正常工作；但若处于多副本（Multiple Pods）场景下，Service 自带的负载均衡（轮询机制）会导致每次监控指标抓取（Scrape）流量被随机分发到不同的 Pod 上。这不仅会导致时序数据出现剧烈的指标跳变（Data Fluctuation），还会引发 Counter（计数器）等类型的数据因无法正确累加而产生成倍的统计偏差（而正常的业务预期应当是获取所有 Pod 的数据总和）。

如果你的 kubeconfig 只有某个命名空间的权限，则需要指定命名空间，不然会因为权限被拒绝无法继续执行下去。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
- job_name: 'vos-metrics'
  metrics_path: '/actuator/prometheus'
  kubernetes_sd_configs:
  - role: endpoints
    kubeconfig_file: /app/kube-config
    namespaces:
      names:
        - llll
  relabel_configs:
  # - source_labels: [__meta_kubernetes_service_name]
  #   regex: 'idk-mob-sdk-svc|idk-tsp-svc|idk-mob-app'
  #   action: keep
  # 添加自定义标签
  - source_labels: [__meta_kubernetes_service_name]
    target_label: app111
  - source_labels: [__meta_kubernetes_pod_ip]
    target_label: instance

这样就算没有所有权限也可以进行抓取到 service endpoint metrics 了