Prometheus Operator 0.94.1 配置与 CRD 详解

逐一拆解 ServiceMonitor/PodMonitor/PrometheusRule/AlertmanagerConfig/Prometheus 核心字段(kubectl explain 实测 schema),实测验证 PrometheusRule 加载与告警 firing、PodMonitor 目标出现、AlertmanagerConfig 路由合并进主配置,并沉淀 selector 未配置与 v1alpha1 版本陷阱等排障实录。

Prometheus Operator监控可观测性Operator2026/10/24

Prometheus Operator 0.94.1 配置与 CRD 详解

目标:逐一拆解 Prometheus Operator 的核心 CRD——ServiceMonitor、PodMonitor、PrometheusRule、Alertmanager/AlertmanagerConfig、Prometheus 的关键字段与组合机制,并通过真实创建监控规则验证「声明 → Operator 调和 → Prometheus 热加载 → 告警触发 → Alertmanager 接收」全链路生效。全部命令与回显已在 Kubernetes v1.36.5(k3s)集群、Prometheus Operator v0.94.1 实测通过。

一、环境信息

  • 集群:Kubernetes v1.36.5+k3s1 单节点(k8s-node1)
  • Prometheus Operator:v0.94.1(kube-prometheus-stack chart 92.11.0 安装)
  • 两套实测实例:
    • monitoring/kps-prometheus(chart 代建,Prometheus v3.15.0-distroless)——集群自监控
    • default/main(手工 CR,Operator 内置默认 v3.14.0)——本文 CRD 实测载体
  • 被监控目标:default 命名空间 example-app(quay.io/brancz/prometheus-example-app:v0.5.0,/metrics 端点,Service 端口名 web)
  • NodePort:main 实例 UI 30090、kps Alertmanager 30093
  • CRD 实查:kubectl get crd | grep monitoring 共 10 个(清单见部署篇第四章)

二、前置条件

  • 已按 《Prometheus Operator 0.94.1 部署指南》完成 Operator 安装,且至少有一个 Prometheus CR 在运行(kubectl get prometheus -A 的 READY 列为 1);
  • 理解 CRD 的标签选择器机制:Prometheus 实例通过 serviceMonitorSelector/podMonitorSelector/ruleSelector 圈定要加载的监控资源,监控资源靠自身 labels 命中选择器——这是 Operator 配置体系的总开关;
  • 本文示例统一使用标签 team: frontend(与实测 default/main 实例的三个选择器匹配)。

三、CRD 配置的查看与修改方式

3.1 查看可用 CRD 与 API 版本

先看 Operator 注册了哪些资源、各自属于哪个 API 版本(实测:AlertmanagerConfig 是 v1alpha1,其余为 v1):

kubectl api-resources | grep coreos.com
NAME                              SHORTNAMES   APIVERSION                          NAMESPACED   KIND
alertmanagerconfigs               amcfg        monitoring.coreos.com/v1alpha1      true         AlertmanagerConfig
alertmanagers                     am           monitoring.coreos.com/v1            true         Alertmanager
podmonitors                       pmon         monitoring.coreos.com/v1            true         PodMonitor
probes                                         monitoring.coreos.com/v1            true         Probe
prometheusagents                  promagent    monitoring.coreos.com/v1            true         PrometheusAgent
prometheuses                      prom         monitoring.coreos.com/v1            true         Prometheus
prometheusrules                   promrule     monitoring.coreos.com/v1            true         PrometheusRule
scrapeconfigs                                  monitoring.coreos.com/v1            true         ScrapeConfig
servicemonitors                   smon         monitoring.coreos.com/v1            true         ServiceMonitor
thanosrulers                                   monitoring.coreos.com/v1            true         ThanosRuler

⚠️ 注意:AlertmanagerConfig 的 apiVersion 是 monitoring.coreos.com/v1alpha1。若误写成 v1 会报 no matches for kind "AlertmanagerConfig" in version "monitoring.coreos.com/v1"(本实测踩过,见 11.3 节)。

3.2 用 kubectl explain 查字段结构(离线文档)

kubectl explain --recursive 是最可靠的字段手册,输出直接来自集群内的 CRD OpenAPI schema,与所装 Operator 版本严格一致。查看 ServiceMonitor 的完整 spec 结构(实测,输出节选):

kubectl explain servicemonitor.spec --recursive
GROUP:      monitoring.coreos.com
KIND:       ServiceMonitor
VERSION:    v1

FIELD: spec <Object>


DESCRIPTION:
    spec defines the specification of desired Service selection for target
    discovery by
    Prometheus.

FIELDS:
  attachMetadata        <Object>
    node        <boolean>
  bodySizeLimit <string>
  convertClassicHistogramsToNHCB        <boolean>
  endpoints     <[]Object> -required-
    authorization       <Object>
      credentials       <Object>
        key     <string> -required-
        name    <string>
        optional        <boolean>
      type      <string>
    basicAuth   <Object>
      password  <Object>
        key     <string> -required-
        name    <string>
        optional        <boolean>
      username  <Object>
        key     <string> -required-
        name    <string>
        optional        <boolean>
    bearerTokenFile     <string>
    bearerTokenSecret   <Object>
      key       <string> -required-
      name      <string>
      optional  <boolean>
    enableHttp2 <boolean>
    filterRunning       <boolean>
    followRedirects     <boolean>
    honorLabels <boolean>
    honorTimestamps     <boolean>
    interval    <string>
    metricRelabelings   <[]Object>
      action    <string>
      enum: replace, Replace, keep, Keep, ....
      modulus   <integer>
      regex     <string>
      replacement       <string>
      separator <string>
      sourceLabels      <[]string>
      targetLabel       <string>
    noProxy     <string>
    oauth2      <Object>
      ...(oauth2/tlsConfig 子树结构较长,此处省略中段)
    params      <map[string][]string>
    path        <string>
    port        <string>
    proxyConnectHeader  <map[string][]Object>
    proxyFromEnvironment        <boolean>
    proxyUrl    <string>
    relabelings <[]Object>
      action    <string>
      enum: replace, Replace, keep, Keep, ....
      modulus   <integer>
      regex     <string>
      replacement       <string>
      separator <string>
      sourceLabels      <[]string>
      targetLabel       <string>
    scheme      <string>
    enum: http, https, HTTP, HTTPS
    scrapeTimeout       <string>
    targetPort  <Object>
    tlsConfig   <Object>
      ...(CA/cert/keySecret 子树,含 insecureSkipVerify、minVersion/maxVersion 枚举 TLS10~TLS13)
  ...(spec 一级字段续,见 3.3)

spec 一级字段清单(同一命令的尾部输出,实测):

  enum: PrometheusProto, OpenMetricsText0.0.1, OpenMetricsText1.0.0, PrometheusText0.0.4, ....
  jobLabel      <string>
  keepDroppedTargets    <integer>
  labelLimit    <integer>
  labelNameLengthLimit  <integer>
  labelValueLengthLimit <integer>
  namespaceSelector     <Object>
    any <boolean>
    matchNames  <[]string>
  nativeHistogramBucketLimit    <integer>
  nativeHistogramMinBucketFactor        <Object>
  podTargetLabels       <[]string>
  sampleLimit   <integer>
  scrapeClass   <string>
  scrapeClassicHistograms       <boolean>
  scrapeNativeHistograms        <boolean>
  scrapeProtocols       <[]string>
  selector      <Object> -required-
    matchExpressions    <[]Object>
      key       <string> -required-
      operator  <string> -required-
      values    <[]string>
    matchLabels <map[string]string>
  selectorMechanism     <string>
  enum: RelabelConfig, RoleSelector
  serviceDiscoveryRole  <string>
  enum: Endpoints, EndpointSlice
  targetLabels  <[]string>
  targetLimit   <integer>

带 -required- 标记的 endpoints 与 selector 是 ServiceMonitor 仅有的两个必填字段。

3.3 查看单个字段的语义说明

explain 不带 --recursive 时输出该字段的完整 DESCRIPTION 与子字段说明,实测 namespaceSelector:

kubectl explain servicemonitor.spec.namespaceSelector
GROUP:      monitoring.coreos.com
KIND:       ServiceMonitor
VERSION:    v1

FIELD: namespaceSelector <Object>


DESCRIPTION:
    namespaceSelector defines in which namespace(s) Prometheus should discover
    the services.
    By default, the services are discovered in the same namespace as the
    `ServiceMonitor` object but it is possible to select pods across
    different/all namespaces.

FIELDS:
  any   <boolean>
    any defines the boolean describing whether all namespaces are selected in
    contrast to a
    list restricting them.

  matchNames    <[]string>
    matchNames defines the list of namespace names to select from.

3.4 修改方式与生效观测

  • 修改:kubectl apply -f <清单> 或 kubectl patch,均为声明式覆盖;
  • 生效观测三层:
    1. 资源被选中:kubectl get prometheus <name> -o jsonpath='{.spec.*Selector}' 与资源 labels 对照;
    2. 配置被合并:curl <prometheus>/api/v1/status/config 看生成的 scrape_configs;
    3. 目标/规则生效:/api/v1/targets、/api/v1/rules、/api/v1/alerts 三个只读 API。

四、CRD 参数总览

CRD一句话职责必填字段与 Prometheus CR 的关联选择器
ServiceMonitor按 Service→Endpoint 发现抓取目标spec.selector、spec.endpointsserviceMonitorSelector
PodMonitor按 Pod 直接发现抓取目标spec.selector、spec.podMetricsEndpointspodMonitorSelector
Probe拨测探测(blackbox 模式)spec.proberSpec、spec.targetsprobeSelector
ScrapeConfigPrometheus 原生 SD 全量抓取配置spec(各 SD 二选一)scrapeConfigSelector
PrometheusRule告警与记录规则spec.groups[].rules[]ruleSelector
Alertmanager声明 Alertmanager 集群spec(可全空走默认)alertmanagerSelector(Prometheus 侧的 alerting 关联)
AlertmanagerConfig命名空间级告警路由与接收端spec.route.receiver、spec.receiversAlertmanager CR 的 alertmanagerConfigSelector
Prometheus声明 Prometheus 实例无(全部有默认值)——
PrometheusAgent只远程写不落盘的采集代理无——
ThanosRulerThanos 规则评估实例spec.queryEndpoints 或 spec.objectStorageConfig——

💡 技术拓展:ServiceMonitor 与 PodMonitor 是「抓取目标发现」的两条路径——ServiceMonitor 走 Service → Endpoints/EndpointSlice → Pod(适合有 Service 抽象的应用,还能天然覆盖 headless service 的多副本);PodMonitor 直接按标签选 Pod(适合没有 Service 的 Job/直连场景)。ScrapeConfig 则是「第三条路」——不用 K8s 标签发现,直接写 Prometheus 原生的 kubernetes_sd/consul_sd/静态配置,覆盖前两者表达不了的场景。本文实测采用 ServiceMonitor(主流形态)+ PodMonitor(对照验证)。

五、ServiceMonitor 详解(核心字段逐个实测)

5.1 实测基线资源

本节全部围绕这个已在集群生效的 ServiceMonitor 展开(kubectl get servicemonitor example-app -n default -o yaml 实测导出,节选):

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    team: frontend          # 命中 main 实例的 serviceMonitorSelector
  name: example-app
  namespace: default
spec:
  endpoints:
  - interval: 15s
    path: /metrics
    port: web
  selector:
    matchLabels:
      app: example-app      # 选中有这个标签的 Service

生效验证——Prometheus 生效配置中出现对应 job(实测 /api/v1/status/config 提取 job_name):

serviceMonitor/default/example-app/0
podMonitor/default/example-app-pods/0

目标抓取健康(实测 /api/v1/targets):

example-app http://10.42.0.5:8080/metrics up

5.2 selector 与 endpoints 之外的常用字段

字段类型说明
spec.namespaceSelector.matchNames[] / any列表/布尔跨命名空间选择 Service。缺省 = 仅 ServiceMonitor 所在命名空间
spec.jobLabelstring用 Service 的哪个标签值作为 Prometheus 的 job 标签(缺省用生成的 serviceMonitor/<ns>/<name>/<n>)
spec.targetLabels[]string 列表把 Service 上的标签透传为目标标签
spec.podTargetLabels[]string 列表把目标 Pod 上的标签透传为目标标签
spec.attachMetadata.nodeboolean在 node 级抓取场景附加节点元数据
spec.sampleLimit / targetLimit / labelLimit 等integer单目标样本数 / 目标数 / 标签数上限——防单点炸 Prometheus 的闸门
spec.scrapeProtocols枚举列表抓取协议协商(PrometheusProto/OpenMetricsText/PrometheusText 等,见 3.3 输出首行枚举)

endpoints 数组内每项的常用字段:

字段说明
port / targetPort按端口名或端口号匹配 Service 端口(推荐端口名)
path指标路径,默认 /metrics
interval / scrapeTimeout抓取间隔 / 单次超时(实测 15s)
schemehttp/https(CRD 层枚举校验)
basicAuth / bearerTokenSecret / authorization / oauth2四种认证方式,凭据一律走 Secret 引用(key/name/optional),CRD 不接受明文口令
tlsConfigCA/cert/私钥引用 + insecureSkipVerify + minVersion/maxVersion(TLS10~TLS13 枚举)
honorLabels / honorTimestamps标签冲突保留策略 / 保留样本时间戳
relabelings目标级 relabel(抓取前,作用于 target 标签)
metricRelabelings指标级 relabel(抓取后,作用于样本本身,可丢指标/改标签)
paramsURL 查询参数(如 match[])
followRedirects / enableHttp2 / noProxy / proxyUrl传输行为控制

💡 说明:relabelings 与 metricRelabelings 的方向差异是最常被混淆的点——前者改「目标是谁」(影响 target 标签、可过滤目标),后者改「抓到什么」(可重命名/丢弃指标)。两者字段结构完全一致(action/regex/replacement/sourceLabels/targetLabel,见 3.2 输出)。

5.3 跨命名空间选择示例

让 default 的 main 实例也抓 monitoring 命名空间的服务:

spec:
  namespaceSelector:
    matchNames:
    - monitoring
    - default

语义与 3.3 的 explain 描述一致:缺省只发现本命名空间,any: true 或 matchNames 列表可跨命名空间(本环境 kps 的 kubelet/cAdvisor 抓取即跨命名空间形态)。

六、PodMonitor 详解与实测

PodMonitor 绕过 Service 直接按标签选 Pod。实测资源(已生效):

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: example-app-pods
  namespace: default
  labels:
    team: frontend
spec:
  selector:
    matchLabels:
      app: example-app
  podMetricsEndpoints:
  - port: web
    path: /metrics
    interval: 15s
kubectl apply -f example-app-pods.yaml
podmonitor.monitoring.coreos.com/example-app-pods created

生效链路实测:

  1. Operator 把它合并进配置(/api/v1/status/config 出现 podMonitor/default/example-app-pods/0);
  2. 目标出现在 targets 列表(job 名形态为 <namespace>/<podmonitor名>):
default/example-app-pods http://10.42.0.5:8080/metrics unknown
example-app http://10.42.0.5:8080/metrics up

(unknown 为首个抓取周期尚未完成时的瞬时状态,下一周期转为 up。)

字段与 ServiceMonitor 几乎同构,两处差异:

差异点PodMonitor
端点字段名podMetricsEndpoints(不是 endpoints)
发现对象直接匹配 Pod 标签(selector.matchLabels),不需要 Service 存在

⚠️ 注意:PodMonitor 不生效的最常见原因是 Prometheus CR 没有配置 podMonitorSelector——纯 Operator 语义下 selector 未设置时并非「全选」,实测中 default/main 实例只写了 serviceMonitorSelector,PodMonitor 创建后 targets 一直不出现;补上选择器后立即生效(完整排障过程见 11.1 节):

kubectl patch prometheus main -n default --type merge \
  -p '{"spec":{"podMonitorSelector":{"matchLabels":{"team":"frontend"}}}}'
prometheus.monitoring.coreos.com/main patched

七、PrometheusRule 详解与实测

7.1 资源结构与字段

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: example-app-rules
  namespace: default
  labels:
    team: frontend              # 命中 main 实例的 ruleSelector
spec:
  groups:
  - name: example-app.rules     # 规则组名(Prometheus 内即 group)
    interval: 30s               # 组评估周期,缺省跟随 Prometheus evaluationInterval
    rules:
    - record: job:http_requests:rate5m    # 记录规则:把表达式结果存成新指标
      expr: sum(rate(http_requests_total[5m]))
    - alert: ExampleAppAlwaysFiringDemo   # 告警规则:条件满足且持续 for 后进入 firing
      expr: vector(1) == 1
      for: 1m
      labels:
        severity: demo
      annotations:
        summary: "演示告警:恒定触发的表达式 vector(1) == 1"
        description: "用于验证 PrometheusRule 的加载与告警评估链路。"
kubectl apply -f example-app-rules.yaml
prometheusrule.monitoring.coreos.com/example-app-rules created

7.2 实测:规则加载与告警触发全链路

第一步:确认规则被 Prometheus 加载(实测 /api/v1/rules,按组提取):

group: example-app.rules
  recording job:http_requests:rate5m health=ok
  alerting ExampleAppAlwaysFiringDemo health=ok state=firing

health=ok 表示表达式合法且评估正常;state=firing 表示 for: 1m 已满足、告警处于触发态。

第二步:查活跃告警列表(实测 /api/v1/alerts):

ExampleAppAlwaysFiringDemo firing demo

(三个字段分别为 alertname、state、severity 标签。)

第三步(可选验证):告警会经 Prometheus 的 alerting 配置送到 Alertmanager。命名空间级路由接收端见第八章。

7.3 字段说明

字段说明
spec.groups[].name组名,Prometheus UI 按组展示
spec.groups[].interval组评估周期
rules[].record / expr记录规则:expr 结果写入名为 record 的指标(命名惯例 level:metric:operations)
rules[].alert / expr / for告警规则:expr 持续为真 for 时长后 firing
rules[].labels / annotations告警标签(路由匹配依据)与注释({{$value}} 等模板可用)
spec.groups[].partialResponseStrategyThanos 场景的部分响应策略,普通 Prometheus 不用

7.4 准入校验:坏规则写不进集群

故意提交一条 PromQL 语法错误的规则(expr: sum(rate(http_requests_total[5m])) > 括号不闭合):

kubectl apply -f bad-rule.yaml

实测拒绝回显:

The  "prometheusrules" is invalid: : 5:11: group "bad.rules", rule 1, "BadPromQL": could not parse expression: 1:32: parse error: unexpected ")" in subquery or range, expected ":" or "]"

资源根本没进集群。这层校验来自 CRD 内嵌的表达式校验规则,在 API Server 层执行——这正是 Operator 要求 Kubernetes >= v1.25.0 的原因(CRD 的 CEL 校验能力,见部署篇 2.1 节)。配合 admission-webhook 的字段级校验,Operator 相对手工管理 prometheus.yml 的核心优势在此体现:错误配置在写入阶段就被拦截,而不是在 Prometheus reload 时静默失败。

八、Alertmanager 与 AlertmanagerConfig 详解

8.1 Alertmanager CR(实例声明)

Alertmanager CR 声明实例本身。kps 部署的实例实查:

kubectl get alertmanager -n monitoring
NAME               VERSION   REPLICAS   READY   RECONCILED   AVAILABLE   AGE
kps-alertmanager   v0.34.1   1          1       True         True        9h

常用字段:spec.replicas(多副本自动组 gossip 集群)、spec.version、spec.resources、spec.retention(告警暂存期)、spec.alertmanagerConfigSelector(圈定要加载的 AlertmanagerConfig)、spec.configSecret(整份配置用 Secret 提供,与 AlertmanagerConfig 互斥使用)。

8.2 AlertmanagerConfig(命名空间级路由)实测

AlertmanagerConfig 让各命名空间自管告警路由,Operator 把它们合并进 Alertmanager 主配置。实测清单(两个对象):

apiVersion: v1
kind: Secret
metadata:
  name: am-webhook-url
  namespace: monitoring
type: Opaque
stringData:
  url: http://example-app.default.svc.cluster.local:8080/webhook
---
apiVersion: monitoring.coreos.com/v1alpha1    # 注意:v1alpha1,不是 v1
kind: AlertmanagerConfig
metadata:
  name: demo-webhook
  namespace: monitoring
  labels:
    release: kps      # 命中 kps Alertmanager 的 alertmanagerConfigSelector(helm 形态默认按 release 标签圈定)
spec:
  route:
    receiver: demo-webhook
    groupBy: ["alertname"]
    groupWait: 30s
    groupInterval: 5m
    repeatInterval: 12h
  receivers:
  - name: demo-webhook
    webhookConfigs:
    - urlSecret:
        name: am-webhook-url
        key: url
      sendResolved: true
kubectl apply -f demo-webhook-amcfg.yaml
secret/am-webhook-url created
alertmanagerconfig.monitoring.coreos.com/demo-webhook created

生效验证:查 Alertmanager 生效配置(v2 API,实测):

curl -s http://localhost:30093/api/v2/status

(返回 JSON 的 config.original 字段为当前生效的完整 Alertmanager 配置,其中出现命名空间级路由与接收端:)

  group_by:
  - receiver: monitoring/demo-webhook/demo-webhook
    group_by:
- name: monitoring/demo-webhook/demo-webhook
    name: monitoring/demo-webhook/demo-webhook

monitoring/demo-webhook/demo-webhook 的命名形态即「命名空间/AlertmanagerConfig 名/receiver 名」,证明 Operator 已把命名空间路由合并进主配置(总配置 80 行)。

8.3 receivers 支持的通知类型

webhookConfigs、emailConfigs、slackConfigs、pagerdutyConfigs、opsgenieConfigs、victorOpsConfigs、wechatConfigs、pushoverConfigs、discordConfigs、msteamConfigs 等,敏感字段(URL、token、密码)一律 xxxSecret(Secret 引用)或 xxxFile(文件挂载),CRD 不接受明文。0.94 系列对 Slack/Webhook/Pushover 等接收端新增了 URL 校验与 update_message、payload 等字段(见 Release Notes)。

九、Prometheus CR 核心字段速查

字段组关键字段说明
实例规模spec.replicas / spec.shards副本数(同数据抓取冗余)/ 分片数(目标水平拆分),0.93.0 起 shards 默认 1
版本与镜像spec.version / spec.image指定 Prometheus 版本(不写用 Operator 内置默认,实测 v3.14.0);image 可整体替换
存储spec.retention / spec.retentionPercentage / spec.resources / spec.volumes时间保留(实测 24h/5d)/ 卷占用百分比保留(0.94.0 新增,需 Prometheus>=v3.11)/ 资源请求(实测 cpu 100m/mem 200Mi)
抓取选择spec.serviceMonitorSelector / spec.podMonitorSelector / spec.probeSelector / spec.scrapeConfigSelector圈定四类抓取资源(必须显式配置,见 11.1)
规则选择spec.ruleSelector圈定 PrometheusRule
发现范围spec.serviceMonitorNamespaceSelector 等圈定「在哪些命名空间找这些监控资源」,与资源内 namespaceSelector 是两层
告警路由spec.alerting.alertmanagers[]关联 Alertmanager 实例(namespace + name),告警发送目标
远端spec.remoteWrite[] / spec.remoteRead[]远端写(PrometheusAgent 主场景)/ 远端读
采集行为spec.scrapeInterval / spec.evaluationInterval全局抓取/评估周期(实测均 30s)
安全spec.serviceAccountName / spec.secrets / spec.configMaps运行身份与挂载给实例的 Secret/ConfigMap
调度spec.nodeSelector / spec.affinity / spec.tolerations常规调度字段

十、生产配置模板(多团队共享监控平台)

适用场景:64GB 内存 / SSD / 数十个命名空间的多团队 K8s 集群,平台组统一管 Prometheus 实例,各团队自管监控声明。核心清单(值来自本环境实测折算的生产推荐):

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: main
  namespace: monitoring
spec:
  version: v3.15.0
  replicas: 2                     # 双副本抓取冗余
  shards: 2                       # 目标数量大时启用分片
  retention: 15d
  retentionPercentage: 80         # 卷占用 80% 时按比例清理(0.94.0+,需 PV 支持)
  scrapeInterval: 30s
  evaluationInterval: 30s
  resources:
    requests:
      cpu: "1"
      memory: 4Gi
    limits:
      memory: 8Gi                 # 防单实例 OOM 拖垮节点
  serviceMonitorSelector: {}      # 平台实例:接受全部命名空间的监控声明
  podMonitorSelector: {}
  probeSelector: {}
  scrapeConfigSelector: {}
  ruleSelector:
    matchLabels:
      rule-tier: platform         # 高危规则收归平台管理
  serviceMonitorNamespaceSelector: {}
  alerting:
    alertmanagers:
    - namespace: monitoring
      name: kps-alertmanager
  remoteWrite:
  - url: http://vminsert.monitoring.svc:8480/insert/0/prometheus/api/v1/write

配套约定:

配套项推荐值说明
每命名空间 ServiceMonitor 的 sampleLimit50000~100000防失控目标打爆实例
PrometheusRule 统一标签 team团队名便于审计与路由
AlertmanagerConfig各命名空间自建平台只在 Alertmanager CR 开 alertmanagerConfigSelector: {}
磁盘每副本 ≥200GB SSD15d 保留 + 2 副本的经验起点,按 rate(prometheus_tsdb_storage_blocks_bytes[1d]) 实测调整

💡 说明:serviceMonitorSelector: {} 表示空选择器即「全选」。这与 helm 形态的 *SelectorNilUsesHelmValues: true(nil 时按 release 标签过滤)是两套语义:纯 Operator 的 nil/空选择器行为以 kubectl explain prometheus.spec.serviceMonitorSelector 的 DESCRIPTION 为准,跨版本有语义收紧的先例(0.94.1 的 RBAC 修复即此类变更),升级时必须回归验证。

十一、常见问题(FAQ)

11.1 PodMonitor 创建后目标不出现(实测排障实录)

现象:PodMonitor example-app-pods(labels team: frontend)apply 成功,Prometheus /api/v1/targets 一直没有 pod 目标:

example-app http://10.42.0.5:8080/metrics up

(只有 ServiceMonitor 的目标。)

定位:查 Prometheus CR 的选择器配置:

kubectl get prometheus main -n default -o jsonpath='{.spec.podMonitorSelector}'
(输出为空——main 实例从未配置 podMonitorSelector)

解决:补上与 PodMonitor labels 匹配的选择器:

kubectl patch prometheus main -n default --type merge \
  -p '{"spec":{"podMonitorSelector":{"matchLabels":{"team":"frontend"}}}}'
prometheus.monitoring.coreos.com/main patched

验证:先确认配置已合并(/api/v1/status/config 的 job_name 提取):

serviceMonitor/default/example-app/0
podMonitor/default/example-app-pods/0

再看 targets(首个抓取周期内显示 unknown,之后转 up):

default/example-app-pods http://10.42.0.5:8080/metrics unknown
example-app http://10.42.0.5:8080/metrics up

结论:CRD 资源是否被加载由「资源 labels × Prometheus CR 选择器」共同决定,两者任缺一个都不生效。排查口诀:先对 labels,再查 selector,最后看 /api/v1/status/config。

11.2 PrometheusRule 规则没被评估

按 11.1 同款思路检查 ruleSelector;再查规则文件是否真的被挂进实例(/api/v1/rules 的分组列表);若组都看不到,用 kubectl get prometheusrule <name> -o yaml 核对 labels 拼写(如 frontend vs front-end)。

11.3 AlertmanagerConfig 报 no matches for kind(API 版本陷阱)

用 monitoring.coreos.com/v1 创建 AlertmanagerConfig 时实测报错:

error: resource mapping not found for name: "demo-webhook" namespace: "monitoring" from "STDIN": no matches for kind "AlertmanagerConfig" in version "monitoring.coreos.com/v1"
ensure CRDs are installed first

原因:AlertmanagerConfig 的存储版本是 v1alpha1(其余 CRD 为 v1),误用 v1 找不到资源。解决:改 apiVersion: monitoring.coreos.com/v1alpha1 后创建成功:

alertmanagerconfig.monitoring.coreos.com/demo-webhook created

快速核对版本用 kubectl api-resources | grep alertmanagerconfigs(见 3.1 实测输出)。

11.4 AlertmanagerConfig 创建成功但路由未生效

三个前置逐一核对:① Alertmanager CR 的 alertmanagerConfigSelector 能选中它(helm 形态默认按 release 标签,本文给资源补了 release: kps);② AlertmanagerConfig 只影响其所在命名空间的告警路由;③ 用 /api/v2/status 的 config.original 直接看合并结果(见 8.2 实测),比猜配置文件快得多。

十二、参考链接