Kubeflow KFServing日志功能在非Knative环境下的配置与使用

概述

KFServing作为Kubeflow生态中的模型服务组件，提供了强大的日志功能，可以将模型预测的请求和响应记录到指定的日志收集服务中。本文将详细介绍如何在非Knative环境下配置和使用KFServing的日志功能，包括常见问题排查和最佳实践。

日志功能架构

KFServing的日志功能通过在模型服务Pod中注入一个sidecar容器来实现。这个sidecar容器会监听模型服务的请求和响应，并将它们转发到配置的日志收集服务。整个架构不依赖于Knative，可以独立工作。

配置步骤

1. 部署日志收集服务

首先需要部署一个日志收集服务，例如简单的HTTP服务：

from flask import Flask, request

app = Flask(__name__)

@app.route('/', methods=['POST'])
def log_request():
    # 打印请求头信息
    metadata_headers = ["x-request-id", "x-b3-traceid", "x-b3-spanid", "x-b3-flags"]
    print("Received Request:")
    for header in metadata_headers:
        value = request.headers.get(header, "Not provided")
        print(f"{header}: {value}")

    # 打印请求体
    print("Payload:")
    print(request.data.decode('utf-8'))
    return "Logged", 200

2. 配置InferenceService

在InferenceService的predictor部分添加logger配置：

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: sklearn
spec:
  predictor:
    logger:
      mode: all
      url: http://message-dumper/
    model:
      modelFormat:
        name: sklearn
      storageUri: gs://kfserving-examples/models/sklearn/1.0/model

关键配置说明

1. logger.mode: 可以设置为all(记录请求和响应)、request(仅记录请求)或response(仅记录响应)
2. logger.url: 日志收集服务的地址，格式为http://<service-name>.<namespace>，如果服务在同一命名空间下可以简写为http://<service-name>

常见问题排查

1. 日志未到达收集服务

• 检查日志收集服务是否正常运行
• 确认日志收集服务的URL配置正确
• 检查sidecar容器的日志，确认是否有连接错误

2. 日志延迟

日志可能会批量发送，而不是实时发送，这是正常现象。如果需要实时日志，可以考虑修改日志收集服务的实现。

功能限制

目前KFServing的日志功能有以下限制：

1. 仅记录成功的请求和响应，错误请求不会被记录
2. 日志是异步发送的，可能存在延迟
3. 大量请求时需要考虑日志收集服务的性能

最佳实践

1. 为日志收集服务配置足够的资源，特别是在高负载场景下
2. 考虑在日志收集服务中添加身份验证和授权
3. 对于生产环境，建议使用更健壮的日志收集方案，如ELK或Fluentd
4. 定期监控日志收集服务的性能和可用性

总结

KFServing的日志功能为模型服务的监控和调试提供了便利，即使在非Knative环境下也能正常工作。通过合理配置和使用，可以有效地收集和分析模型服务的请求和响应数据，为模型优化和问题排查提供有力支持。