Kueue项目Prometheus监控指标采集异常问题分析与解决方案

问题背景

在Kubernetes集群中使用Kueue项目时，用户发现通过Helm chart配置的Prometheus ServiceMonitor无法正确采集Kueue的全部监控指标。具体表现为：

1. 只能采集到约270个基础指标（如go运行时、apiserver、rest client等相关指标）
2. 关键的Kueue业务指标（kueue_*前缀）完全缺失
3. 虽然配置了enableClusterQueueResources参数，但相关资源指标未被采集

技术分析

经过深入排查，发现问题根源在于ServiceMonitor资源配置存在两个关键缺陷：

1. 端口配置错误
   ServiceMonitor中配置的https端口8082实际上是kueue-visibility-server服务的端口，而非控制器管理器（controller-manager）的metrics端口8443。这导致监控请求被错误地路由到了可视化服务而非指标服务。

2. 标签选择器不精确
   当前ServiceMonitor使用过于宽泛的标签选择器（仅匹配app.kubernetes.io/name=kueue），这会匹配命名空间内所有带有该标签的Service资源。在Kueue部署中，这会同时匹配到：

   • kueue-visibility-server服务（端口8082）
   • kueue-controller-manager-metrics-service服务（端口8443）

由于Kubernetes服务发现的机制，这种不精确的匹配可能导致Prometheus错误地选择了可视化服务而非指标服务。

解决方案

针对上述问题，推荐采用以下解决方案：

1. 精确标签选择器
   为metrics服务添加专用标签（如app.kubernetes.io/component: metrics），并在ServiceMonitor中精确匹配该标签。这样可以确保：

   • 明确区分不同类型的服务
   • 避免服务选择时的歧义
   • 提高配置的可维护性

2. 修正端口配置
   确保ServiceMonitor指向正确的metrics端口8443，该端口是controller-manager实际暴露指标数据的端口。

实施建议

对于正在使用Kueue的用户，如果遇到类似监控指标缺失问题，可以：

1. 检查现有ServiceMonitor配置，确认是否指向正确的服务和端口
2. 为metrics服务添加专用标签
3. 更新ServiceMonitor的标签选择器以精确匹配metrics服务
4. 验证Prometheus是否能够正确采集到kueue_*前缀的业务指标

更深层的架构思考

这个问题也反映出在Kubernetes监控体系设计中需要注意的几个要点：

1. 服务发现机制：理解Prometheus如何通过ServiceMonitor发现和采集指标
2. 标签体系设计：建立清晰、有层次的标签体系对后期维护至关重要
3. 端口管理：在微服务架构中，明确各服务的端口用途和暴露方式
4. 监控隔离：关键业务指标与系统指标应有明确的采集区分

通过这个案例，我们可以更好地理解Kubernetes监控体系的工作机制，并在今后的部署中避免类似问题的发生。