2. Prometheus Operator 架构：核心组件、CRD 资源与工作流程
在深入 ServiceMonitor 标签治理 之前，必须先理解 Prometheus Operator 的整体架构。Operator 的本质是一个 Kubernetes 控制器，它利用 CRD（Custom Resource Definition）将 Prometheus 的运维知识编码为自动化逻辑，从而让用户以声明式的方式管理监控栈。
2.1 核心组件
Prometheus Operator 由三个核心组件构成，它们协同工作以实现监控的自动化部署与配置。
| 组件 | 角色 | 核心职责 |
|---|---|---|
| Operator | 控制器大脑 | 监听 CRD 资源变化，协调 Prometheus/Alertmanager 实例的生命周期（创建、更新、扩缩容、销毁）。 |
| Prometheus | 监控实例 | 由 Operator 管理的 StatefulSet，负责拉取指标、存储数据、执行告警规则。 |
| Alertmanager | 告警处理器 | 由 Operator 管理的 StatefulSet，负责对告警进行去重、分组、静默并发送通知。 |
关键认知： Operator 本身不处理指标数据，它只负责“翻译” CRD 资源（如 ServiceMonitor）为 Prometheus 原生配置文件（如
prometheus.yml 和 scrape_configs），并触发 Prometheus 实例的热加载。
2.2 CRD 资源全景
Operator 定义了一组 CRD，作为用户与监控系统交互的接口。以下是本课程最核心的四个 CRD：
- Prometheus：定义 Prometheus 实例的规格（副本数、资源限制、存储、版本等）。Operator 根据此 CRD 创建对应的 StatefulSet。
- ServiceMonitor：定义如何从一组 Kubernetes Service 中抓取指标。它通过标签选择器关联 Service，并指定抓取端口、路径、间隔等。这是本课程的核心治理对象。
- PodMonitor：与 ServiceMonitor 类似，但直接通过标签选择器关联 Pod，适用于不需要 Service 层抽象的场景（如 DaemonSet 暴露的指标）。
- PrometheusRule：定义告警规则和记录规则。Operator 会将这些规则加载到 Prometheus 实例中。
治理焦点： ServiceMonitor 和 PodMonitor 中的
relabel_configs 字段是标签治理的主战场。错误的标签配置会导致指标基数爆炸、数据归属混乱或抓取失败。
2.3 工作流程：从 CRD 到抓取配置
理解 Operator 如何将 ServiceMonitor 转化为 Prometheus 的抓取配置，是掌握标签治理的前提。下图展示了完整的自动化链路：
2.4 配置生成细节
Operator 在生成 scrape_configs 时，会执行以下关键步骤：
- Service 发现：根据 ServiceMonitor 的
selector.matchLabels找到匹配的 Service。 - Endpoint 解析：从 Service 中获取所有 Endpoint（Pod IP + 端口）。
- 标签注入：自动注入 Kubernetes 元数据标签（如
namespace、pod、service、instance）。 - Relabeling 执行：依次执行 ServiceMonitor 中定义的
relabel_configs和metric_relabel_configs，这是标签治理的核心环节。 - 配置合并：将生成的 job 追加到 Prometheus 的
scrape_configs中。
常见陷阱： 默认情况下，Operator 会注入大量 Kubernetes 标签（如
__meta_kubernetes_*）。如果不通过 relabel_configs 进行清理或保留，这些标签会全部进入时间序列，导致标签基数（Cardinality）失控，最终拖垮 Prometheus 的存储和查询性能。
2.5 ServiceMonitor 与 PodMonitor 对比
| 维度 | ServiceMonitor | PodMonitor |
|---|---|---|
| 发现对象 | Kubernetes Service | 直接发现 Pod |
| 适用场景 | 有 Service 层负载均衡，或需要利用 Service 的标签选择能力 | 无头服务、DaemonSet、Sidecar 模式，或不需要 Service 抽象 |
| 标签来源 | Service 标签 + Endpoint 标签 | Pod 标签 + 所属 Node 标签 |
| 治理复杂度 | 中等（需处理 Service 与 Pod 两层标签） | 较低（直接面对 Pod 标签） |
2.6 标签治理的切入点
从工作流程可以看出，标签治理主要发生在以下两个阶段：
- 抓取阶段（scrape_time）：通过 ServiceMonitor/PodMonitor 的
relabel_configs控制哪些标签进入时间序列。 - 存储阶段（storage_time）：通过 Prometheus 的
storage.tsdb.retention.time和storage.tsdb.retention.size控制数据生命周期，但无法改变已存储的标签。
课程核心主张： 标签治理的最佳实践是在 抓取阶段 完成。一旦指标进入 TSDB，标签就固定了。后续的查询时标签操作（如
label_replace）只能用于展示，无法减少存储开销。因此，ServiceMonitor 的 relabel_configs 是治理的第一道也是最重要的防线。