日志的重要性与基本概念

做了这么多年运维，我越来越觉得日志就是系统的“黑匣子”。

它记录着系统每一次心跳、每一次异常、每一次崩溃。没有日志，故障排查就像蒙着眼睛走夜路。你想想看，服务突然挂了，你连它死前最后一秒在干什么都不知道——那种无力感，我经历过太多次了。

为什么日志如此重要

好多新手会觉得日志是“写着玩的”，出了问题才想起来翻。其实不对。

我把日志的价值总结为五点。你对照一下自己的项目，看看缺了哪一块。

• 故障定位的核心：系统出了问题，第一反应就是“查日志”。没有日志，你只能靠猜。
• 性能分析的依据：响应时间慢了、CPU飙高了，日志里的时间戳和指标能帮你定位瓶颈。
• 安全审计的基石：谁在什么时候做了什么操作？日志是唯一的铁证。
• 业务洞察的窗口：用户行为、转化率、异常流程——日志里藏着金矿。
• 系统可观测性的入口：现在流行的可观测性（Observability）三大支柱——日志、指标、链路，日志是最传统也最直接的一个。

日志的基本概念

聊点基础的东西。虽然老生常谈，但很多坑恰恰是基础没打牢造成的。

日志级别

日志级别不只是一串标签，它决定了你什么时候该看什么信息。

级别	含义	典型场景
DEBUG	调试信息，开发阶段使用	变量值、函数调用顺序
INFO	正常操作的信息	请求到达、任务完成
WARN	潜在问题，不致命但值得关注	重试次数超标、配置即将过期
ERROR	发生了错误，但系统还能运行	数据库连接失败、第三方API报错
FATAL	致命错误，系统即将或已经崩溃	内存溢出、核心服务无响应

嗯，这里要注意：生产环境千万别开DEBUG级别。我曾经见过一个团队，线上开了DEBUG，结果一天写了50GB日志，磁盘直接打满，服务全挂了。你想想，是不是得不偿失？

日志格式

格式决定解析效率。乱七八糟的日志，人工看着都费劲，更别说用工具分析了。

# 好日志的模板
2024-08-15 14:23:10.456  [http-nio-8080-exec-3]  ERROR  com.example.OrderService  - 订单支付失败: orderId=12345, userId=67890, 原因: 余额不足

一个好的日志条目，应该包含以下要素：

• 时间戳：精确到毫秒，带时区。没有时间的日志，等于没写。
• 线程/进程信息：方便定位并发问题。
• 日志级别：方便过滤。
• 类名/模块名：谁输出的？方便快速定位代码。
• 消息体：清晰描述发生了什么事。
• 上下文：关联ID、用户ID、订单ID等。方便串联。

日志轮转与保留

日志文件不能无限增长。不轮转，磁盘迟早写满。

常见的轮转策略：

• 按时间轮转：按天、按小时生成新文件。
• 按大小轮转：单个文件超过阈值（如100MB）就分割。
• 保留策略：保留最近7天或30天，超期自动删除或归档。

我建议，关键业务日志保留时间要长，至少30天。合规要求高的，可能要保留180天甚至更长。

日志的生命周期

日志不是写出来就完了，它有一个完整的生命周期。我把这个流程画了一张图，帮你建立整体认知。

生产环境中日志的常见坑

说点儿实际的。以下是几个我在项目里踩过的坑，真心希望你别再踩。

1. 日志量级巨大，磁盘撑爆：原因往往是日志级别设置不当或循环打印。我曾经见过一个while(true)里打印日志的死循环，半小时写满100GB。
2. 日志格式不统一：同一个系统，A模块用JSON，B模块用纯文本，C模块用XML。解析时恨不得砸键盘。
3. 缺少上下文关联：多条日志之间没有traceId或requestId，无法串联一次请求的完整链路。
4. 敏感信息泄露：把用户密码、身份证号原样打印出来，这是非常严重的合规风险。
5. 异步打印的坑：为了性能用了异步日志，结果系统崩溃时最后几条日志没来得及刷盘，全丢了。

日志分析调试的常见场景

说完概念和坑，聊聊实际场景。你拿着日志到底能干什么？

场景	日志内容	分析目标
应用崩溃	ERROR/FATAL级别、堆栈信息	定位崩溃代码行、原因
接口超时	请求时间戳、耗时记录	计算分位耗时，定位慢接口
数据库慢查询	SQL执行日志、索引使用情况	找到慢SQL，优化索引
安全攻击	访问日志、登录尝试记录	识别异常IP、暴力破解行为
分布式追踪	traceId、spanId、调用链	还原一次请求经过的所有服务

好了，第一张图我们聊完了整个日志的生命周期。后面几章，我会带你深入每个环节，从采集到分析再到告警，把每一个工具和技巧都拆开揉碎。