Kubeflow KFServing 中实现自定义运行时指标监控的最佳实践

在 Kubeflow KFServing 项目中，用户经常需要监控自定义运行时指标，这些指标对于理解模型服务的性能至关重要。本文将详细介绍如何通过 Prometheus Operator 实现这一目标。

背景

KFServing 默认提供了 queue-proxy 容器的基本指标，但对于特定运行时（如 vLLM）生成的自定义指标（如 TTFT、TPOT、KVCache 利用率等），需要额外的配置才能被监控系统采集。

解决方案

使用 qpext 容器聚合指标

KFServing 提供了 qpext 容器，它能够将 queue-proxy 和 kserve-container 的指标聚合到一个端点上。通过端口转发验证，可以确认聚合后的指标端点正常工作。

监控方案选择

传统上使用 ServiceMonitor 需要服务暴露命名端口，但在 KFServing 中，自动生成的服务并未暴露聚合指标端口（9088）。因此，推荐采用 PodMonitor 替代 ServiceMonitor 来实现监控。

具体实现

1. PodMonitor 配置示例：

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: model-monitor
spec:
  namespaceSelector:
    any: true
  selector:
    matchLabels:
      serving.kserve.io/inferenceservice: model-name
  podMetricsEndpoints:
  - port: user-port
    interval: 5s

2. 端口说明：

• user-port（8000）：直接访问模型容器的指标
• aggr-metric（9088）：聚合后的指标端点（需要 KFServing 特定版本支持）
• http-usermetric（9091）：queue-proxy 的原始指标

注意事项

1. 不同版本的 KFServing 可能使用不同的端口名称和配置方式
2. 对于需要同时监控原始 queue-proxy 指标和聚合指标的场景，可以组合使用 PodMonitor 和 ServiceMonitor
3. 确保 Prometheus Operator 已正确配置并能够发现 PodMonitor 资源

总结

通过 PodMonitor 方案，用户可以灵活地监控 KFServing 中运行时的自定义指标，而无需依赖服务端口的暴露。这种方法特别适合需要监控特定运行时生成的高级性能指标的场景。随着 KFServing 的发展，未来版本可能会提供更完善的指标聚合和监控支持。