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

背景介绍

KServe作为Kubernetes上的模型服务框架，提供了强大的日志功能，允许用户将模型预测的请求和响应记录到指定的日志收集服务中。本文将详细介绍如何在非Knative环境下配置和使用KServe的日志功能。

日志功能基本配置

在KServe中，日志功能通过InferenceService资源中的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

其中关键配置项包括：

• mode: 指定日志记录模式，可以是all(记录请求和响应)、request(仅记录请求)或response(仅记录响应)
• url: 指定日志接收服务的地址

日志接收服务实现

日志接收服务可以是一个简单的HTTP服务，只需要实现POST方法即可。以下是一个使用Flask实现的日志接收服务示例：

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

部署注意事项

1. 服务发现：日志接收服务的URL可以使用Kubernetes服务发现机制。如果日志服务与InferenceService在同一命名空间，可以直接使用服务名；跨命名空间则需要使用完整域名格式。

2. 网络连通性：确保InferenceService的Pod能够访问日志接收服务。在Istio环境中，可能需要配置相应的网络策略。

3. 日志延迟：日志可能不会立即出现在接收服务中，KServe会批量发送日志以提高效率。

日志内容分析

成功请求的日志会包含以下信息：

• 请求头：包括x-request-id等追踪信息
• 响应体：模型预测的结果

例如：

Received Request:
x-request-id: e4123d01-5d29-9ab8-8f4a-76761d62d18b
x-b3-traceid: 4933d0bdf218ca0c3b514339c0f9fd9f
x-b3-spanid: 2d576fcb7dd00f52
Payload:
{"predictions":[1,1]}

当前限制

需要注意的是，当前版本的KServe日志功能仅记录成功的请求和响应。对于失败的请求（如无效输入导致的400错误），这些错误信息不会发送到配置的日志接收服务，而是直接输出到模型容器的日志中。

最佳实践

1. 对于生产环境，建议日志接收服务实现持久化存储，而不仅仅是打印到控制台。

2. 考虑日志服务的性能影响，特别是在高并发场景下，可能需要调整日志服务的资源配置。

3. 对于关键业务场景，可以结合KServe日志和容器日志实现完整的可观测性方案。

通过合理配置和使用KServe的日志功能，可以有效地监控和分析模型服务的请求和响应，为模型性能优化和问题排查提供有力支持。