自定义采集指标用于在 VKE 集群中补充系统默认采集范围,满足业务对额外指标或标签的采集需求。本文介绍如何复制系统默认采集对象并进行最小化修改,创建 VMNodeScrape、ServiceMonitor 或 PodMonitor,并验证新增指标是否采集成功。
当您在容器服务(VKE)集群中开启 云原生基础监控 时,系统会默认为集群中的采集对象(例如:kubelet、CoreDNS、CSI 组件等)下发采集配置,覆盖常见的监控场景。当控制台默认提供的可采集指标与目标组件实际暴露的指标不完全一致时,你可以通过创建自定义的 VMNodeScrape、ServiceMonitor 或 PodMonitor 补充采集范围。典型应用场景如下: - 希望为不同业务单独维护一套采集白名单以避免直接影响平台默认模板。
- 需要补充 job、node 等标签规则以便于后续聚合、看板展示和告警配置。
说明
VKE 集群支持使用 CRD 资源(如 VMNodeScrape、ServiceMonitor 等)配置自定义指标采集规则。不同资源的详细介绍和配置方法,请参见 服务发现。 - 如果使用子账号配置集群,请保证该子账号已具备查看和创建 Kubernetes 自定义资源的权限。详情请参见 配置 IAM 权限。
- 确认目标资源的指标暴露方式,不同暴露方式支持使用的 CRD 略有不同。包括:节点维度、Service 维度或 Pod 维度。
警告
- 请勿直接修改系统下发的 VMNodeScrape、ServiceMonitor 或 PodMonitor 默认采集配置。因为当控制台修改或同步采集配置时,系统会重新下发上述默认配置,直接修改默认配置存在被覆盖、回写的风险。
- 如有自定义指标采集需求,建议复制平台已下发的对象,并创建一份自定义配置,再按需修改selector、指标白名单和标签规则。该方法可以将自定义采集规则与系统默认规则隔离开,便于后续维护。
kubectl -n kube-system get vmnodescrape
说明
您还可以执行kubectl -n kube-system get servicemonitor或kubectl -n kube-system get podmonitor命令,查看其他类型的默认采集规则。
- 预期结果如下,展示了系统中当前该资源类型下的所有默认规则。
kubelet-cadvisor-vci 5h11m
vpc-cni-cello-cilium 5h12m
- 选择需要创建的自定义采集规则类型,将系统默认采集规则导出为新的 YAML 文件。本文以 kubelet 采集规则为例,导出时请注意重命名,不要直接覆盖原对象。
kubectl -n kube-system get vmnodescrape kubelet -o yaml > kubelet-custom.yaml
导出的 YAML 文件中包含众多的冗余字段。配置自定义采集规则详情前,请首先删除这些字段,避免自定义规则创建失败或与原对象发生冲突。示例如下:
apiVersion: operator.victoriametrics.com/v1beta1
meta.helm.sh/release-name: container-monitoring
meta.helm.sh/release-namespace: kube-system
creationTimestamp: "2026-08-24T02:59:45Z"
app.kubernetes.io/instance: container-monitoring
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: kubelet
app.kubernetes.io/version: 1.22.2
helm.sh/chart: container-monitoring-1.22.2
uid: e09ac813-f6fc-44***
bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
- 自定义规则 YAML 文件修改完成后,执行以下命令,将自定义规则应用到集群中。
kubectl apply -f kubelet-custom.yaml
- 应用自定义规则后,建议从以下几个方面进行结果验证:
- 新增指标能否在查询界面或 PromQL 中查到。
- 例如:您可以使用托管 Prometheus 的 Explore 功能,确认采集规则是否启动正常,对应的指标是否被正确采集到。
-
示例一:自定义 VMNodeScrape 采集规则
VMNodeScrape 适用于节点级指标采集场景。在 VKE 集群中,kubelet 指标默认通过 VMNodeScrape 进行采集。如果默认采集的指标范围无法满足需求,您可以额外创建一份自定义 VMNodeScrape,保留节点发现和 TLS 相关配置,并通过metricRelabelConfigs补充需要采集的指标,例如kubelet_evictions。
apiVersion: operator.victoriametrics.com/v1beta1
bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
- key: node.kubernetes.io/instance-type
caFile: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
insecureSkipVerify: true
- replacement: kubelet-custom
- __meta_kubernetes_node_name
- regex: volcengine://(.+)
- __meta_kubernetes_node_provider_id
regex: kubelet_running_pods|kubelet_node_name|kubelet_evictions
示例二:自定义 ServiceMonitor 采集规则
ServiceMonitor 适用于通过 Service 暴露指标的组件。在 VKE 集群中,CoreDNS 指标默认通过 ServiceMonitor 进行采集。如果默认采集的指标范围无法满足需求,可以额外创建一份自定义 ServiceMonitor,复用默认配置中的 selector 和端口配置,并通过metricRelabelConfigs指定自定义的 job 标签和指标白名单。
apiVersion: monitoring.coreos.com/v1
replacement: core-dns-custom
regex: service|namespace|container|endpoint
regex: coredns_reload_failed_total|coredns_forward_responses_total
PodMonitor 适用于直接按 Pod 采集指标的场景,通常用于没有 Service 或需要按 Pod 粒度单独配置采集规则的组件。在 VKE 集群中,CSI 组件(如 csi-ebs)指标默认通过 PodMonitor 进行采集。如果默认采集的指标范围无法满足需求,可以额外创建一份自定义 PodMonitor,复用默认配置中的 Pod 选择器,并通过metricRelabelConfigs补充需要采集的指标。
apiVersion: monitoring.coreos.com/v1
name: custom-csi-ebs-node
app.kubernetes.io/name: csi-ebs-node
replacement: csi-ebs-node-custom
regex: instance|service|namespace|pod|container|endpoint
regex: csi_node_allocatable_volumes|csi_node_allocated_volumes|csi_ebs_xfs_repair_trigger_error_total
说明
配置 CSI 采集规则时,如果 CSI 组件暴露了多个端口或多个 sidecar 指标,可以在podMetricsEndpoints中继续追加端点配置或分别创建多个自定义对象。
系统默认采集规则为系统托管对象,会随着控制台配置同步、模板升级或默认策略调整而重新下发。在默认采集规则中直接修改的内容,可能在下一次同步时被覆盖,因此不适合作为长期方案。
自定义采集规则和平台默认采集规则会不会重复采集?
如果您自定义采集规则中的selector配置与默认采集规则完全重叠,且 job 标签也没有区分,就会出现重复抓取或重复时序。因此,建议您自定义metadata.name,并按需调整selector 和job。
建议优先修改metadata.name、selector、job和指标白名单。对于认证、TLS、命名空间和默认暴露路径,通常可以直接继承默认采集规则。
应用自定义采集规则后,您可以先查看对象和采集目标是否创建成功,再通过查询界面或 PromQL 直接查询新增指标名。如果查询结果返回正常时序,说明自定义采集已经生效。