如何用Prometheus监控所有StorageClass持久卷磁盘使用率（含EFS）

你现有看板依赖的kubelet_volume_stats_used_bytes等kubelet_volume_stats_*系列指标，由kubelet内置的卷统计模块生成，该模块仅对in-tree原生支持的卷类型做容量统计。EFS属于通过CSI驱动对接的外置存储，不在kubelet原生采集列表里，自然不会生成对应指标，看板也就拉不到数据。

• 先确认集群部署的AWS EFS CSI驱动版本≥v1.3.0，低于这个版本的驱动本身没有输出卷指标的能力，先升级驱动版本
• 修改EFS CSI驱动的Node Plugin、Controller Plugin部署配置，给容器启动参数追加--http-endpoint=0.0.0.0:3300，同时在pod配置里声明暴露3300端口的metrics服务
• 给EFS CSI驱动的所有pod添加Prometheus采集注解，如果你用kube-prometheus-stack部署监控栈，加完注解会自动完成服务发现，不需要额外写采集规则：

annotations:
  prometheus.io/scrape: "true"
  prometheus.io/port: "3300"

• 采集生效后，你可以拿到efs_volume_stats_used_bytes、efs_volume_stats_capacity_bytes两个核心使用量指标，给这两个指标补上和原有kubelet指标一致的namespace、persistentvolumeclaim关联标签，加到原有Grafana看板的查询语句里做指标合并，就能和其他PVC数据统一展示。

别信网上流传的改kubelet参数强制扫描NFS挂载点的野路子，EFS是跨AZ共享存储，kubelet高频扫文件系统元数据会平白消耗EFS的元数据请求配额，集群规模大了分分钟触发限流，直接用CSI驱动自带的指标是官方推的最优方案，稳得多。

要覆盖集群所有StorageClass的PVC监控，不要单一依赖kubelet内置指标，用三层采集逻辑就能做到无遗漏：

• 第一层：in-tree原生卷（本地盘、EBS、hostPath等kubelet原生支持的类型），继续复用现有kubelet_volume_stats_*指标，这部分不需要额外调整
• 第二层：所有CSI对接的存储（EFS、CephFS、Longhorn、各类云厂商NAS/并行文件存储等），统一开启对应CSI驱动自带的metrics端点，按照EFS的配置方式让Prometheus完成采集即可，目前主流CSI驱动都原生支持卷容量、使用量、IO等指标输出，不需要二次开发
• 第三层：兜底采集，针对极少数不自带metrics能力的自定义存储类型，在node_exporter中开启filesystem采集模块，配置过滤规则仅采集/var/lib/kubelet/pods/路径下的卷挂载点，再通过挂载路径和PVC元数据做关联，就能拿到所有实际挂载到节点上的卷使用数据，完全不受底层存储类型限制。

内容的提问来源于stack exchange，提问作者Hemabh