Keep API日志级别配置问题分析与解决方案

问题背景

在使用Keep API的GKE集群部署过程中，开发人员发现即使将日志级别设置为ERROR，系统仍然会记录请求日志。这个问题影响了日志管理的有效性，特别是在生产环境中，过多的请求日志会干扰对真正错误信息的监控和分析。

问题现象

Keep API部署配置中明确设置了日志级别为ERROR：

env:
  LOG_LEVEL: "ERROR"
args:
  - "--log-level"
  - "error"

但系统仍然输出类似以下的请求日志：

2025-03-26 02:40:27,994 - ed2fe37e16ebbe9bd21236fdc5f887a8 - MainThread - 10.32.7.18:49360 - "GET /incidents/facets HTTP/1.1" 200

技术分析

这个问题源于Keep API的日志系统架构设计。在Python的日志系统中，不同的日志器(logger)可以拥有独立的日志级别配置。Keep API使用了Uvicorn作为ASGI服务器，而Uvicorn默认会配置一个名为"uvicorn.access"的日志器专门用于记录访问日志。

在Keep API的日志配置文件中，这个访问日志器的级别被硬编码为INFO级别，因此它会继续记录请求信息，不受全局ERROR级别设置的影响。这是Python日志系统的一个常见设计模式，允许对不同模块的日志进行细粒度控制。

解决方案

要彻底解决这个问题，需要修改Keep API的日志配置文件(keep/api/logging.py)，具体调整"uvicorn.access"日志器的配置：

"uvicorn.access": {
    "handlers": ["uvicorn_access"],
    "level": "ERROR",  # 从INFO修改为ERROR
    "propagate": False,
}

这个修改会确保访问日志只在发生错误时才会被记录。对于生产环境，这是一个更合理的配置，可以减少不必要的日志输出，同时保留关键的错误信息。

实施建议

1. 临时解决方案：可以通过环境变量覆盖日志配置，但这种方法可能不够稳定
2. 长期解决方案：建议向Keep项目提交Pull Request，将这一修改合并到主分支
3. 自定义构建：如果需要立即解决问题，可以基于官方镜像创建自定义镜像，包含修改后的日志配置

最佳实践

在生产环境中管理日志时，建议：

• 为不同类型的日志设置不同的级别
• 确保日志配置的一致性
• 定期审查日志配置，确保其符合运维需求
• 考虑使用结构化日志，便于后续分析和处理

通过正确配置日志级别，可以有效平衡系统可观测性和日志存储成本，提高运维效率。