NodeJS 日志方案选型实践：从 console 到结构化日志

# 一、console.log 的三个问题 开发阶段用 console.log 没问题，但**上生产就是灾难**： 1. **没有级别**——无法按严重程度过滤； 2. **没有上下文**——不知道是哪个请求、哪个环节打的； 3. **同步写终端**——量大时拖慢事件循环。 等问题发生后想回溯，才发现什么都没留下。 # 二、选结构化日志 把日志打成 **JSON 格式**，每条都是一个对象：时间、级别、消息、请求 ID、耗时等字段齐全。好处是机器可解析，后续接日志平台、按字段检索都方便。 主流选择有两个：一个以性能见长，一个 API 对 console 友好。选哪个都行，**关键是全员统一用一个**，别又混进 console.log。 # 三、日志级别怎么定 - **error**：影响功能的异常，必须处理并告警； - **warn**：异常但可自动恢复，需要关注趋势； - **info**：关键业务动作，如请求进出、定时任务开始结束； - **debug**：开发排查用的细节，生产环境默认关闭。 生产环境一般开 info 级别。级别不是越全越好，**全开 debug 会把真正的问题淹没**。 # 四、文件轮转必须做 单文件日志迟早把磁盘写爆。用轮转工具按**大小或日期**切割，并设置保留份数。配置要点： - 按天切割，保留 14 天左右； - 单文件超限也切，防止某天日志暴涨； - 切割后压缩归档，节省空间。 # 五、容器环境的特殊处理 容器里有个反直觉的最佳实践：**日志直接输出到标准输出**，不写文件。由容器运行时统一收集、转发到日志平台。这样做的好处是： 1. 不用管容器内磁盘和轮转； 2. 日志随容器生命周期自动管理； 3. 多实例日志可以按服务聚合检索。 本地开发和容器部署**用同一个日志库**，只是输出目标不同——本地写文件方便看，容器走标准输出交给平台。 # 六、请求链路追踪 结构化日志最大的价值是**串起一次请求的完整链路**。做法：入口生成唯一请求 ID，中间所有日志都带上这个字段。排查问题时按 ID 一搜，整条链路的日志按顺序排列，比翻十倍量的散日志高效太多。 # 七、避坑清单 1. **别在热路径打太多 info**，高频接口每个请求打几条，量会失控； 2. **敏感信息脱敏**，密码、手机号不要原样进日志； 3. **异常要打完整堆栈**，只打 message 定位不了问题； 4. **日志配置纳入代码管理**，级别和格式改动要有记录； 5. **定期演练**，按一次真实故障走一遍检索流程，验证日志真的够用。 # 八、小结 日志系统的价值在故障时刻才体现。平时多花半天把结构化日志和链路追踪搭好，出事时能省下几天的排查时间，这笔账怎么算都划算。