4. 采集链路组件：Target发现、Scrape配置、Relabeling机制、ServiceMonitor与PodMonitor

在Prometheus Operator生态中，采集链路的核心由四个组件构成：Target发现决定“采集谁”，Scrape配置决定“怎么采”，Relabeling机制决定“标签怎么改”，ServiceMonitor与PodMonitor则是声明式的CRD资源，将前三者串联为可运维的配置。本节逐一拆解每个组件的职责、交互关系及故障排查要点。

4.1 组件职责与交互关系

下表总结了四个组件在采集链路中的角色与关键属性：

4.2 Target发现机制

Prometheus Operator通过Kubernetes服务发现（SD）自动发现采集目标。支持以下角色：

• role: service — 发现Service对象，通常与ServiceMonitor配合使用。
• role: pod — 发现Pod对象，通常与PodMonitor配合使用。
• role: endpoints — 发现Endpoints对象，是ServiceMonitor的底层实现。
• role: node — 发现集群节点，用于采集节点指标。

Target发现依赖Kubernetes RBAC权限。如果Prometheus无法列出Service或Pod，采集目标列表将为空。常见故障现象：

• Prometheus Target页面显示 0 up 或 no targets。
• 日志中出现 Unauthorized 或 Forbidden 错误。

4.3 Scrape配置详解

Scrape配置定义了Prometheus如何从目标拉取指标。关键参数包括：

在ServiceMonitor中，这些参数通过 spec.endpoints 字段声明：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: example-app
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: example
  endpoints:
  - port: metrics
    interval: 15s
    scrapeTimeout: 10s
    path: /metrics
    scheme: http

4.4 Relabeling机制

Relabeling是Prometheus最强大的标签处理工具，在采集链路中分为两个阶段：

• relabel_configs — 在采集前对目标标签进行修改，决定哪些目标被采集、哪些被丢弃。
• metric_relabel_configs — 在采集后对指标标签进行修改，决定哪些指标被保留、哪些被丢弃。

常用action类型：

4.5 ServiceMonitor与PodMonitor

ServiceMonitor和PodMonitor是Prometheus Operator定义的CRD，用于声明式管理采集配置。两者的核心区别：

以下SVG图展示了从CRD声明到最终采集目标的完整链路：

4.6 故障排查要点

当采集链路出现问题时，按以下顺序排查：

1. 检查CRD状态 — kubectl get servicemonitor -n <namespace> 确认ServiceMonitor/PodMonitor已创建。
2. 检查标签选择器 — ServiceMonitor的 spec.selector 必须匹配目标Service的标签。
3. 检查命名空间标签 — 如果Prometheus配置了 spec.serviceMonitorNamespaceSelector，需要确保目标命名空间有匹配标签。
4. 检查生成的Prometheus配置 — 进入Prometheus Pod，查看 /etc/prometheus/config_out/prometheus.env.yaml，确认scrape_config是否正确生成。
5. 检查Target页面 — Prometheus UI → Status → Targets，查看目标状态和错误信息。
6. 检查Relabeling结果 — 在Target页面点击目标，查看 Labels 和 Before Relabeling 对比，确认标签转换是否符合预期。

4.7 常见故障模式与解决方案

以下SVG图展示了Relabeling在采集链路中的具体位置与数据流向：