Tracing日志库中log宏输出末尾多余空格问题分析

问题背景

在使用Rust的tracing日志框架时，开发者发现通过log宏输出的日志消息末尾会意外附加4个空格字符，而直接使用tracing宏则不会出现这个问题。这个现象在使用tracing-subscriber的full或compact格式时出现，但在使用json或pretty格式时则正常。

问题表现

当同时使用log和tracing宏记录日志时，输出结果如下：

2024-05-22T22:39:16.301618Z  INFO repro_tracing: Hello from log    
2024-05-22T22:39:16.301684Z  INFO repro_tracing: Hello from tracing
2024-05-22T22:39:16.301690Z  INFO repro_tracing: Hello again from log    
2024-05-22T22:39:16.301695Z  INFO repro_tracing: Hello again from tracing

可以明显看到log宏输出的消息末尾有4个额外的空格字符（示例中用空格符表示）。

技术分析

这个问题源于tracing-log适配器在处理log记录时的格式化行为。tracing-log是tracing生态系统中的一个关键组件，它作为桥梁将传统的log记录转换为tracing事件。

在底层实现上，当使用full或compact格式时，tracing-subscriber的格式化器会为每条记录添加固定的字段布局。对于直接来自tracing的记录，格式化器能够准确控制输出格式；而对于通过log宏转换而来的记录，格式化器在处理消息体时意外保留了额外的填充空格。

影响范围

这个问题主要影响以下场景：

1. 混合使用log和tracing宏的项目
2. 使用tracing-subscriber的full或compact格式输出
3. 对日志格式有严格要求的环境，特别是需要解析日志的系统

值得注意的是，这个问题在将日志发送到CloudWatch等日志服务时尤为严重，因为额外的空格可能导致日志解析失败，且这种失败往往没有明显的错误提示。

解决方案

该问题已被确认并修复。修复方案主要涉及tracing-log适配器中格式化逻辑的调整，确保无论日志记录来自log宏还是tracing宏，都能保持一致的输出格式。

对于遇到此问题的开发者，建议：

1. 升级到包含修复的tracing-log版本
2. 如果暂时无法升级，可以考虑统一使用tracing宏替代log宏
3. 或者切换到json/pretty格式输出以避免此问题

最佳实践

在混合使用log和tracing的项目中，建议：

1. 保持依赖项更新，特别是tracing相关组件
2. 对日志输出进行测试验证，确保格式符合预期
3. 考虑逐步迁移到纯tracing实现，以获得更一致的行为和更丰富的功能

这个问题也提醒我们，在日志系统集成时，格式一致性对于日志分析和处理至关重要，特别是在自动化日志处理流水线中。