You need to enable JavaScript to run this app.
文档中心
容器服务

容器服务

复制全文
下载 pdf
基础配置
自定义采集指标
复制全文
下载 pdf
自定义采集指标
自定义采集指标用于在 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、指标白名单和标签规则。该方法可以将自定义采集规则与系统默认规则隔离开,便于后续维护。
步骤一:导出已有配置
  1. 执行以下命令,查看系统已下发的默认采集规则。
  • kubectl -n kube-system get vmnodescrape
说明
您还可以执行kubectl -n kube-system get servicemonitorkubectl -n kube-system get podmonitor命令,查看其他类型的默认采集规则。
  • 预期结果如下,展示了系统中当前该资源类型下的所有默认规则。
  • NAME AGE
    kubelet 5h11m
    kubelet-cadvisor 5h11m
    kubelet-cadvisor-vci 5h11m
    node-exporter 5h11m
    vpc-cni 5h12m
    vpc-cni-cello-cilium 5h12m
  1. 选择需要创建的自定义采集规则类型,将系统默认采集规则导出为新的 YAML 文件。本文以 kubelet 采集规则为例,导出时请注意重命名,不要直接覆盖原对象。
  • kubectl -n kube-system get vmnodescrape kubelet -o yaml > kubelet-custom.yaml
步骤二:清理冗余字段
导出的 YAML 文件中包含众多的冗余字段。配置自定义采集规则详情前,请首先删除这些字段,避免自定义规则创建失败或与原对象发生冲突。示例如下:
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMNodeScrape
metadata:
annotations:
meta.helm.sh/release-name: container-monitoring
meta.helm.sh/release-namespace: kube-system
creationTimestamp: "2026-08-24T02:59:45Z"
generation: 1
labels:
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
volcengine.vmp: "true"
name: kubelet
namespace: kube-system
resourceVersion: "2***"
uid: e09ac813-f6fc-44***
spec:
bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
interval: 15s
...
冗余字段
处理建议
metadata.creationTimestamp
该字段为资源在服务端的生成时间,需删除。
metadata.resourceVersion
该字段为服务端生成的版本号,创建新对象时无需保留,需删除。
metadata.uid
该字段为原对象的唯一标识,需删除。
metadata.generation、metadata.managedFields
该字段由控制面维护,无需保留,需删除。
status
该字段表示原资源对象的状态,如导出的 YAML 中存在该字段,需删除。
步骤三:修改关键字段
在导出的新 YAML 文件中配置自定义采集规则,根据实际需求修改以下字段。详细的字段配置说明,请参见 示例一:自定义 VMNodeScrape 采集规则
关键字段
配置建议
说明
metadata.name
资源名称,必须修改为新名称。
请避免与系统默认对象同名。例如:增加custom-前缀、团队名或业务名后缀。
selector
按目标范围收敛。
避免采集范围与系统默认对象完全重叠,降低重复抓取和重复时序的风险。
relabelConfigs/relabelings
按需修改 job 和标签规则。
建议为自定义对象使用新的 job 名称,便于区分默认采集规则和自定义采集规则。
metricRelabelConfigs/metricRelabelings
按需调整指标白名单。
如只需补充少量未暴露指标,建议直接修改对应的 keep 规则,而不是重写整份配置。
intervalportpathschemetlsConfig
建议保持默认值。
一般情况下无需修改,仅在目标端暴露方式与默认对象不同的情况下,才需要调整这些字段。
步骤四:应用并验证配置
  1. 自定义规则 YAML 文件修改完成后,执行以下命令,将自定义规则应用到集群中。
  • kubectl apply -f kubelet-custom.yaml
  1. 应用自定义规则后,建议从以下几个方面进行结果验证:
  • 自定义对象是否成功创建。
  • 目标数是否符合预期。
  • 新增指标能否在查询界面或 PromQL 中查到。
  • 自定义对象是否与平台默认对象产生重复抓取。
  • 例如:您可以使用托管 Prometheus 的 Explore 功能,确认采集规则是否启动正常,对应的指标是否被正确采集到。
配置示例
示例一:自定义 VMNodeScrape 采集规则
VMNodeScrape 适用于节点级指标采集场景。在 VKE 集群中,kubelet 指标默认通过 VMNodeScrape 进行采集。如果默认采集的指标范围无法满足需求,您可以额外创建一份自定义 VMNodeScrape,保留节点发现和 TLS 相关配置,并通过metricRelabelConfigs补充需要采集的指标,例如kubelet_evictions
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMNodeScrape
metadata:
name: custom-kubelet # 自定义采集规则名称
namespace: kube-system # 自定义采集规则所属命名空间
labels:
volcengine.vmp: "true" # 配置服务发现的标签,允许被 Agent 发现
spec:
bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
interval: 15s # 采集频率,每 15 秒抓取一次所有目标节点的指标
scheme: https # kubelet 默认通过 HTTPS(端口 10250)暴露指标,必须显式声明
selector: # 通过 Kubernetes Label Selector 过滤要采集的节点
matchExpressions:
- key: node.kubernetes.io/instance-type
operator: NotIn
values:
- dcp-node
tlsConfig:
caFile: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
insecureSkipVerify: true
relabelConfigs:
- replacement: kubelet-custom # 将节点的 job 标签改写为 kubelet-custom,方便后续使用 job="kubelet-custom" 进行指标过滤
targetLabel: job
- regex: (.+)
sourceLabels:
- __meta_kubernetes_node_name
targetLabel: node
- regex: volcengine://(.+)
sourceLabels:
- __meta_kubernetes_node_provider_id
targetLabel: ecs
metricRelabelConfigs: # 指标过滤配置
- action: keep # 保留指标
sourceLabels: # 基于指标名称过滤,在本例中仅保留正则表达式匹配的指标
- __name__
regex: kubelet_running_pods|kubelet_node_name|kubelet_evictions # 指定需要保留的指标名称或正则表达式,即该采集规则最终采集的指标
示例二:自定义 ServiceMonitor 采集规则
ServiceMonitor 适用于通过 Service 暴露指标的组件。在 VKE 集群中,CoreDNS 指标默认通过 ServiceMonitor 进行采集。如果默认采集的指标范围无法满足需求,可以额外创建一份自定义 ServiceMonitor,复用默认配置中的 selector 和端口配置,并通过metricRelabelConfigs指定自定义的 job 标签和指标白名单。
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: custom-core-dns # 自定义采集规则名称
namespace: kube-system # 自定义采集规则所属命名空间
labels:
volcengine.vmp: "true" # 配置服务发现的标签,允许被 Agent 发现
spec:
namespaceSelector: # 采集对象所在命名空间
matchNames:
- kube-system
selector: # 通过 Kubernetes Label Selector 过滤要采集的服务
matchLabels:
k8s-app: kube-dns
endpoints:
- port: metrics # 采集端口
interval: 15s # 采集频率,每 15 秒抓取一次所有目标服务的指标
relabelings: # 将目标服务的 job 标签改写为 core-dns-custom,方便后续使用 job="core-dns-custom" 进行指标过滤
- action: replace
replacement: core-dns-custom
targetLabel: job
- action: labeldrop
regex: service|namespace|container|endpoint
metricRelabelings: # 指标过滤配置
- action: keep # 保留指标
sourceLabels: # 基于指标名称过滤,在本例中仅保留正则表达式匹配的指标
- __name__
regex: coredns_reload_failed_total|coredns_forward_responses_total # 指定需要保留的指标名称或正则表达式,即该采集规则最终采集的指标
示例三:自定义 PodMonitor 采集规则
PodMonitor 适用于直接按 Pod 采集指标的场景,通常用于没有 Service 或需要按 Pod 粒度单独配置采集规则的组件。在 VKE 集群中,CSI 组件(如 csi-ebs)指标默认通过 PodMonitor 进行采集。如果默认采集的指标范围无法满足需求,可以额外创建一份自定义 PodMonitor,复用默认配置中的 Pod 选择器,并通过metricRelabelConfigs补充需要采集的指标。
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
name: custom-csi-ebs-node # 自定义采集规则名称
namespace: kube-system # 自定义采集规则所属命名空间
labels:
volcengine.vmp: "true" # 配置服务发现的标签,允许被 Agent 发现
spec:
namespaceSelector: # 采集对象所在命名空间
matchNames:
- kube-system
selector: # 通过 Kubernetes Label Selector 过滤要采集的 Pod
matchLabels:
app.kubernetes.io/name: csi-ebs-node
podMetricsEndpoints:
- port: metrics # 采集端口
interval: 15s # 采集频率,每 15 秒抓取一次所有目标服务的指标
relabelings: # 将目标 Pod 的采集 job 标签改写为 csi-ebs-node-custom,方便后续使用 job="csi-ebs-node-custom" 进行指标过滤
- action: replace
replacement: csi-ebs-node-custom
targetLabel: job
- action: labeldrop
regex: instance|service|namespace|pod|container|endpoint
metricRelabelings: # 指标过滤配置
- action: keep # 保留指标
sourceLabels: # 基于指标名称过滤,在本例中仅保留正则表达式匹配的指标
- __name__
regex: csi_node_allocatable_volumes|csi_node_allocated_volumes|csi_ebs_xfs_repair_trigger_error_total # 指定需要保留的指标名称或正则表达式,即该采集规则最终采集的指标
说明
配置 CSI 采集规则时,如果 CSI 组件暴露了多个端口或多个 sidecar 指标,可以在podMetricsEndpoints中继续追加端点配置或分别创建多个自定义对象。
常见问题
为什么不建议直接修改系统默认的采集规则?
系统默认采集规则为系统托管对象,会随着控制台配置同步、模板升级或默认策略调整而重新下发。在默认采集规则中直接修改的内容,可能在下一次同步时被覆盖,因此不适合作为长期方案。
自定义采集规则和平台默认采集规则会不会重复采集?
如果您自定义采集规则中的selector配置与默认采集规则完全重叠,且 job 标签也没有区分,就会出现重复抓取或重复时序。因此,建议您自定义metadata.name,并按需调整selectorjob
哪些字段最适合做最小化修改?
建议优先修改metadata.nameselectorjob和指标白名单。对于认证、TLS、命名空间和默认暴露路径,通常可以直接继承默认采集规则。
如何验证新增指标已经采集成功?
应用自定义采集规则后,您可以先查看对象和采集目标是否创建成功,再通过查询界面或 PromQL 直接查询新增指标名。如果查询结果返回正常时序,说明自定义采集已经生效。
最近更新时间:2026.08.31 15:13:07
这个页面对您有帮助吗?
有用
有用
无用
无用