解读

国内 Rust 面试中，面试官提出该问题通常想验证两点：

1. 你是否真的在生产环境落地过可观测性方案，而不仅停留在“打印调试”层面；
2. 面对遗留代码（大量 log 宏）与新一代异步遥测框架（tokio-tracing）共存时，你能否给出零停机、零代码侵入的迁移策略。
   回答时务必先给出“兼容层原理 → 配置方式 → 性能影响 → 踩坑经验”四段式闭环，再补一句“编译期可开关”，基本就能拿到高分。

知识点

1. tracing-log 适配器：把 log::Record 转成 tracing::Event，实现单向“log → tracing”桥接；
2. tracing 的 Value 与 log 的 Arguments 映射：结构化字段通过 % 与 ? 格式化符透传；
3. Level 映射表：log::Level{Error,Warn,Info,Debug,Trace} 一一对应 tracing::Level；
4. span 上下文丢失问题：log 宏无法携带 span，只能降级到全局 logger，高并发链路追踪会断链；
5. 性能差异：tracing 事件走无锁环形缓冲区，log 默认走 std::sync::MUTEX，QPS>10w 时差距一个数量级；
6. 编译特征开关：tracing-log 依赖启用 log-always 特征后，即使 crate 只依赖 log 也能被 tracing Subscriber 捕获；
7. 反向兼容方案：用 tracing-subscriber 的 Layer::with_filter 同时安装 LogTracer 与 fmt::Layer，实现老代码 log 输出不丢，新代码直接 tracing::info! 带 span。

答案

“tracing 与 log 完全兼容，但方向只能是 log → tracing，反向不行。
做法分三步：

1. 在根 crate 引入 tracing-log 并调用 LogTracer::init()，把全局 log 实现重定向到 tracing 的事件队列；
2. 在 tracing-subscriber 注册 fmt::Layer 或 jaeger Layer，老代码的 log::info! 会无缝出现在同一套链路追踪里；
3. 通过 Cargo features 做编译隔离：生产环境开启 tracing-log，单元测试环境关闭，避免双 Logger 初始化 panic。
   需要注意两点性能陷阱：

• 高频 log::debug! 会触发两次格式化，建议用 RUST_LOG 动态过滤到 info 以上；
• span 上下文无法被 log 宏利用，关键链路必须逐步迁移到 tracing::info_span! 才能保证 trace_id 连续。”

拓展思考

1. 如果面试官追问“反过来让 tracing 事件落回 log 怎么做”，标准答案是“不能也不该做”，因为 span 树形结构无法扁平化到 log 的单行文本；若必须对接老旧 syslog，只能自定义 Layer 把 Event 格式化成 kv 文本，但会丢失 parent span 信息。
2. 在国产信创环境（龙芯 + 麒麟 OS）中，tracing-appender 的非阻塞文件写入依赖 mmap，部分内核版本需要降级到 pwrite 模式，需在 Cargo.toml 里关闭 mmap 特征并实测 I/O 性能。
3. 面对金融级审计要求，可开启 tracing-serde 把 Event 序列化成 JSON，通过 Layer 链直接送进 Kafka，实现“日志不落盘、审计可追溯”，此时 log 宏产生的非结构化日志会被统一包装成 {“legacy_log”: true, “message”: “…”}，方便老系统解析。