Prometheus Operator 是什么
它是 Kubernetes 上的 Operator 模式实现：用 CRD 声明式定义监控对象（Prometheus、ServiceMonitor、PrometheusRule 等），Operator 监听这些资源的变化，自动生成并热加载 Prometheus 配置文件。运维方式从「改配置文件再重载」变成「提交 YAML」，与集群的其他资源管理方式保持一致。
基本信息
| 核心 CRD | Prometheus / ServiceMonitor / PodMonitor / Probe / PrometheusRule / Alertmanager |
|---|---|
| 选择机制 | serviceMonitorSelector 等标签选择器 |
| 配置热加载 | config-reloader 边车 |
| 常见发行版 | kube-prometheus-stack |
| 命名空间 | CRD 集群级，实例通常按命名空间隔离 |
| 依赖 | Prometheus 实例需能看到所选资源 |
典型使用场景
- 用 ServiceMonitor 声明按 Service 标签抓取应用指标
- 用 PodMonitor 直接按 Pod 选择抓取目标（无 Service 的场景）
- 用 PrometheusRule 统一管理告警与记录规则
- 用 Probe 定义黑盒拨测目标，替代手工维护 blackbox 配置
- 多团队共用集群时按标签与命名空间隔离各自监控范围
- 把监控配置纳入 GitOps 流程，与业务 YAML 一起评审
核心 CRD
核心 CRD
Prometheus # Prometheus 实例：副本、存储、远程写、选择器
ServiceMonitor # 按 Service 标签选择抓取目标
PodMonitor # 直接按 Pod 选择抓取目标
Probe # 黑盒探测目标
PrometheusRule # 告警与记录规则
Alertmanager # 告警管理器实例ServiceMonitor 示例
ServiceMonitor 示例
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: app-api
labels:
release: kube-prom # 需被 Prometheus 选择器匹配
spec:
selector:
matchLabels:
app: api # 选择带该标签的 Service
endpoints:
- port: metrics # Service 里定义的端口名
interval: 30s排查要点
| 现象 | 可能原因 | 排查位置 |
|---|---|---|
| ServiceMonitor 不生效 | 标签不匹配选择器 | Prometheus 的 serviceMonitorSelector |
| 配置没更新 | reloader 未生效 | config-reloader 日志与生成的配置 |
| 目标重复采集 | 多套 Prometheus 选择器重叠 | 各实例的选择器与命名空间 |
| 规则不触发 | PrometheusRule 未被选择 | ruleSelector 与命名空间 |
ServiceMonitor 的标签需同时满足 Prometheus 资源的 serviceMonitorSelector，否则配置存在但不会被采集，这是最常见的「写了没生效」。
排查顺序建议：先看 Prometheus 实际生成的配置，再看 config-reloader 日志，最后核对标签选择器，比反复改 YAML 更快。
多套 Prometheus 共用集群时用标签与命名空间选择器隔离，避免同一目标被重复采集导致数据翻倍。
Operator 管理实例时不要手工修改生成的配置文件：下次协调会被覆盖，所有改动都应落到 CRD 上。