Cruise Control项目中日志重复问题的分析与解决

问题背景

在LinkedIn开源的Kafka集群管理工具Cruise Control中，开发人员发现系统日志存在重复记录的问题。具体表现为同一个请求的处理日志会被重复记录两次，这不仅增加了日志文件的大小，也给日志分析和问题排查带来了困扰。

问题现象分析

通过查看日志文件，可以清晰地看到重复的日志条目。例如，处理异步请求的日志信息"Processing async request CruiseControlStateRequest"和请求完成日志"Computation is completed for async request"都被记录了两次。同样，HTTP访问日志也被重复记录。

根本原因

经过深入分析，发现问题出在项目的日志配置上。在log4j.properties配置文件中，kafkaCruiseControlFile这个appender被同时添加到了root和com.linkedin.kafka.cruisecontrol两个logger上。这种配置导致日志消息会被两个logger同时捕获并处理，从而产生重复记录。

解决方案

针对这个问题，社区提出了几种解决方案：

1. 移除重复的appender引用：最简单的解决方案是从root logger中移除kafkaCruiseControlAppender的引用，只保留在特定包logger中的引用。这样可以避免日志被两个logger同时处理。

2. 调整logger的additivity属性：对于特定的logger如operationLogger和CruiseControlPublicAccessLogger，可以设置additivity=false属性。这样它们的日志就不会向上传递给root logger，从而避免重复记录。

3. 重构日志配置：更彻底的解决方案是重新设计日志配置架构，明确区分不同级别和来源的日志应该如何处理，确保每个日志消息只被处理一次。

实施建议

在实际部署中，建议采用第二种方案，即调整logger的additivity属性。这种方案既能解决重复日志问题，又能保持完整的日志记录功能。具体修改如下：

logger.operationLogger=INFO, kafkaCruiseControlAppender
logger.operationLogger.additivity=false

logger.CruiseControlPublicAccessLogger=INFO, kafkaCruiseControlAppender
logger.CruiseControlPublicAccessLogger.additivity=false

总结

日志重复问题虽然看起来是小问题，但在大规模生产环境中可能带来存储和分析的额外开销。通过合理配置日志系统，不仅可以解决重复记录问题，还能使日志系统更加高效和易于维护。对于Cruise Control这样的关键基础设施组件，保持日志系统的清晰和高效尤为重要。