Q61: 如何优化日志系统？
核心结论
日志系统优化的目标不是“少打日志”，而是让日志既能支撑排障，又不会反过来拖垮主链路。
真正需要平衡的是：
- 可观测性
- 写入开销
- 存储成本
- 查询可用性
如果日志系统没有分层，常见结果只有两种：要么信息不够查问题，要么线上一忙日志先把系统打慢。
一、日志系统真正要解决什么
它至少承担三类职责：
- 线上排障
- 审计和追踪
- 统计和观测补充
这三类日志的写法、保留期和消费方式通常都不一样，不应全塞进同一条输出链路。
二、先分清日志类型
1. 调试日志
特点是量大、价值短期、通常只在问题排查时需要。
2. 业务日志
例如：
- 登录
- 交易
- 发奖
- 状态切换
这类日志往往承担可追溯职责。
3. 运行日志
例如：
- 错误
- 告警
- 系统状态变化
4. 审计日志
例如：
- GM 操作
- 支付回调
- 资产修改
这类日志通常比普通调试日志更需要稳定和可靠。
三、优化日志系统，第一步通常不是换库
很多日志问题根源不在库，而在使用方式：
- 热路径里打太多字符串拼接
- 高频循环里打印无价值细节
- 错误级别被当成普通追踪用
- 同一事件重复打印多次
先减少无效日志，往往比引入更复杂框架更有效。
四、异步写入很常见，但不是没有代价
异步日志能降低主线程阻塞，但也会带来：
- 队列堆积
- 日志丢失窗口
- 高峰期内存占用上涨
所以异步日志系统必须回答：
- 队列满了怎么办
- 是否允许丢弃低优先级日志
- 是否要阻塞调用方
这些都是工程取舍，不是默认正确答案。
五、格式化成本经常被低估
很多热路径日志并不是写磁盘慢，而是：
- 字符串拼接重
- JSON 序列化重
- 大对象 dump 太频繁
所以常见优化包括：
- 延迟格式化
- 结构化字段而不是大段拼接
- 高频日志条件过滤
六、日志不该只有“打印到文件”一种出口
实际工程里常见会拆成：
- 本地文件
- 标准输出
- 集中收集
- 指标或 tracing
并不是所有信息都适合写成长文本日志。很多高频统计更适合变成指标，而不是成千上万行日志。
七、工程上更稳妥的设计
常见做法是：
- 日志分级
- 结构化字段
- 异步批量写入
- 高优先级日志保守丢弃策略
- 调试日志动态开关
这能在排障能力和性能成本之间取得平衡。
八、常见误区
1. 日志越详细越好
过多无价值日志会掩盖真正重要的信息，也会拖慢系统。
2. 异步日志就没有性能问题
队列、格式化和峰值堆积照样会出问题。
3. 所有日志都应该统一成 JSON
结构化有价值，但也要考虑写入成本和消费场景。
参考资料
- 结构化日志、异步日志与观测系统实践资料