Spring AI 项目中Observability功能失效问题分析与解决方案

问题背景

在Spring AI项目中，开发者希望通过配置Observability功能来监控和记录AI模型的交互过程。根据官方文档，开发者进行了如下配置：

logging.level.org.springframework.ai.observability=DEBUG
spring.ai.chat.observations.log-completion=true

然而在实际使用中，虽然项目启动时显示了警告信息，表明Observability功能已启用，但在实际调用Chat模型时，控制台并未输出预期的日志信息。

问题根源分析

经过深入分析，发现问题的核心原因在于开发者使用了错误的日志级别配置和不当的实例构建方式：

1. 错误的日志级别配置：

   • 正确的配置应该是logging.level.org.springframework.ai.chat.observability=DEBUG
   • 原配置中的包路径不完整，导致日志输出未被正确捕获

2. 实例构建方式不当：

   • 开发者直接使用OpenAiChatModel.builder()手动构建实例
   • 这种方式没有自动注入Spring的ObservationRegistry实例
   • 导致Observability功能无法正常工作

解决方案

方案一：修正日志配置

将application.properties中的配置修改为：

logging.level.org.springframework.ai.chat.observability=DEBUG
spring.ai.chat.observations.log-completion=true

方案二：正确使用Spring AI组件

推荐使用Spring的依赖注入机制获取OpenAiChatModel实例，然后通过mutate()方法进行定制：

@Autowired
private OpenAiChatModel chatModel;

public String getAnswer() {
    OpenAiChatOptions options = OpenAiChatOptions.builder()
            .model("deepseek-chat")
            .build();
            
    ChatClient client = ChatClient.builder(chatModel.mutate()
            .defaultOptions(options)
            .build())
            .build();
            
    return client.prompt("1+1=2?").call().content();
}

方案三：针对Deepseek模型的专用方案

Spring AI已经为Deepseek模型提供了专用实现，建议使用专用模型类而非通用的OpenAI实现：

@Autowired
private DeepseekChatModel chatModel;

技术要点总结

1. Observability配置：

   • 必须确保使用正确的日志包路径
   • 启用内容日志时要意识到可能的安全风险

2. 实例构建最佳实践：

   • 优先使用Spring自动配置的bean
   • 需要定制时使用mutate()方法而非重新构建
   • 确保ObservationRegistry被正确注入

3. 模型选择：

   • 对于非标准OpenAI API的模型，应使用专用实现
   • 专用模型能更好地处理API差异

扩展建议

对于需要监控AI交互的企业级应用，还可以考虑：

1. 配置更完善的Observability策略，包括指标收集和分布式追踪
2. 实现自定义的Observation处理器，将日志输出到专门的监控系统
3. 对于敏感信息，考虑实现内容过滤机制

通过以上解决方案，开发者可以正确启用Spring AI的Observability功能，实现对AI交互过程的完整监控和日志记录。