Prometheus Operator 0.94.1 配置与 CRD 详解
逐一拆解 ServiceMonitor/PodMonitor/PrometheusRule/AlertmanagerConfig/Prometheus 核心字段(kubectl explain 实测 schema),实测验证 PrometheusRule 加载与告警 firing、PodMonitor 目标出现、AlertmanagerConfig 路由合并进主配置,并沉淀 selector 未配置与 v1alpha1 版本陷阱等排障实录。
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 安装,且至少有一个
PrometheusCR 在运行(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,均为声明式覆盖; - 生效观测三层:
- 资源被选中:
kubectl get prometheus <name> -o jsonpath='{.spec.*Selector}'与资源 labels 对照; - 配置被合并:
curl <prometheus>/api/v1/status/config看生成的 scrape_configs; - 目标/规则生效:
/api/v1/targets、/api/v1/rules、/api/v1/alerts三个只读 API。
- 资源被选中:
四、CRD 参数总览
| CRD | 一句话职责 | 必填字段 | 与 Prometheus CR 的关联选择器 |
|---|---|---|---|
| ServiceMonitor | 按 Service→Endpoint 发现抓取目标 | spec.selector、spec.endpoints | serviceMonitorSelector |
| PodMonitor | 按 Pod 直接发现抓取目标 | spec.selector、spec.podMetricsEndpoints | podMonitorSelector |
| Probe | 拨测探测(blackbox 模式) | spec.proberSpec、spec.targets | probeSelector |
| ScrapeConfig | Prometheus 原生 SD 全量抓取配置 | spec(各 SD 二选一) | scrapeConfigSelector |
| PrometheusRule | 告警与记录规则 | spec.groups[].rules[] | ruleSelector |
| Alertmanager | 声明 Alertmanager 集群 | spec(可全空走默认) | alertmanagerSelector(Prometheus 侧的 alerting 关联) |
| AlertmanagerConfig | 命名空间级告警路由与接收端 | spec.route.receiver、spec.receivers | Alertmanager CR 的 alertmanagerConfigSelector |
| Prometheus | 声明 Prometheus 实例 | 无(全部有默认值) | —— |
| PrometheusAgent | 只远程写不落盘的采集代理 | 无 | —— |
| ThanosRuler | Thanos 规则评估实例 | 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.jobLabel | string | 用 Service 的哪个标签值作为 Prometheus 的 job 标签(缺省用生成的 serviceMonitor/<ns>/<name>/<n>) |
spec.targetLabels[] | string 列表 | 把 Service 上的标签透传为目标标签 |
spec.podTargetLabels[] | string 列表 | 把目标 Pod 上的标签透传为目标标签 |
spec.attachMetadata.node | boolean | 在 node 级抓取场景附加节点元数据 |
spec.sampleLimit / targetLimit / labelLimit 等 | integer | 单目标样本数 / 目标数 / 标签数上限——防单点炸 Prometheus 的闸门 |
spec.scrapeProtocols | 枚举列表 | 抓取协议协商(PrometheusProto/OpenMetricsText/PrometheusText 等,见 3.3 输出首行枚举) |
endpoints 数组内每项的常用字段:
| 字段 | 说明 |
|---|---|
port / targetPort | 按端口名或端口号匹配 Service 端口(推荐端口名) |
path | 指标路径,默认 /metrics |
interval / scrapeTimeout | 抓取间隔 / 单次超时(实测 15s) |
scheme | http/https(CRD 层枚举校验) |
basicAuth / bearerTokenSecret / authorization / oauth2 | 四种认证方式,凭据一律走 Secret 引用(key/name/optional),CRD 不接受明文口令 |
tlsConfig | CA/cert/私钥引用 + insecureSkipVerify + minVersion/maxVersion(TLS10~TLS13 枚举) |
honorLabels / honorTimestamps | 标签冲突保留策略 / 保留样本时间戳 |
relabelings | 目标级 relabel(抓取前,作用于 target 标签) |
metricRelabelings | 指标级 relabel(抓取后,作用于样本本身,可丢指标/改标签) |
params | URL 查询参数(如 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
生效链路实测:
- Operator 把它合并进配置(
/api/v1/status/config出现podMonitor/default/example-app-pods/0); - 目标出现在 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[].partialResponseStrategy | Thanos 场景的部分响应策略,普通 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 的 sampleLimit | 50000~100000 | 防失控目标打爆实例 |
PrometheusRule 统一标签 team | 团队名 | 便于审计与路由 |
| AlertmanagerConfig | 各命名空间自建 | 平台只在 Alertmanager CR 开 alertmanagerConfigSelector: {} |
| 磁盘 | 每副本 ≥200GB SSD | 15d 保留 + 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 实测),比猜配置文件快得多。
十二、参考链接
- 官方 API 文档(全部 CRD 字段):https://prometheus-operator.dev/docs/api-reference/api/
- ServiceMonitor 设计说明:https://prometheus-operator.dev/docs/user-guides/crd-status/
- 告警路由指南:https://prometheus-operator.dev/docs/user-guides/alerting/
- 实测集群对照:部署与排障实录见 《Prometheus Operator 0.94.1 部署指南》 5.4 与 9.1 节
- 站内关联:《Prometheus 3.x 配置参数详解》(prometheus.yml 原生参数,与本文 CRD 字段一一对应)、《Prometheus 3.x 常用 CLI 命令与工具详解》(promtool 规则校验)、《Kubeshark 配置参数详解》(K8s 流量观测配置)