一、日志分析基础回顾：日志文件格式、常见日志类型与日志级别
说实话，很多人觉得日志分析就是「tail -f」看一下报错。但我在生产环境摸爬滚打这些年，发现真正能把日志玩明白的人，都是从最基础的东西开始较真的。今天我们就从头捋一遍，把地基打牢。
1.1 日志文件格式——你天天见，但未必真懂
日志文件说白了就是纯文本，但它的格式是有讲究的。我见过太多人对着乱糟糟的日志发愁，其实只要掌握了标准格式，一眼就能看出门道。
最常见的格式是下面这样：
2025-03-21 14:32:18,762 [http-nio-8080-exec-3] ERROR com.example.OrderService - 订单处理失败：用户ID=1024，订单号=ORD-20250321-001拆开来看，核心字段就这几个：
- 时间戳：精确到毫秒，这是定位问题的时间线
- 线程名：告诉你哪个线程在干活，并发问题全靠它
- 日志级别：ERROR、WARN 这些，后面细说
- 类名/方法名：代码位置，直接定位到行
- 消息体：具体发生了什么
当然，不同框架的格式略有差异。比如 Log4j 2 和 Logback 的默认格式就不太一样，但核心要素是一样的。你只要抓住时间、级别、位置、消息这四个要素，什么格式都难不倒你。
1.2 常见日志类型——系统日志 vs 应用日志
日志大致分两类：系统日志和应用日志。这两者的区别，我刚开始工作时也搞混过。
| 对比维度 | 系统日志 | 应用日志 |
|---|---|---|
| 产生来源 | 操作系统、内核、系统服务 | 业务代码、中间件、框架 |
| 典型位置 | /var/log/messages, /var/log/syslog | 应用目录下的 logs/ 文件夹 |
| 关注重点 | 硬件故障、OOM、磁盘满、网络断连 | 业务异常、接口超时、SQL 慢查询 |
| 分析工具 | dmesg, journalctl, grep | ELK, Splunk, 自研日志平台 |
系统日志，说白了就是操作系统在跟你汇报身体状况。比如磁盘满了、内存不够了、网卡掉了，这些都会写在系统日志里。我记得有一次线上告警说服务不可用，我第一反应是看应用日志，结果啥也没找到。后来去翻 /var/log/messages，才发现是磁盘写满了，应用根本写不了日志——这就成了死循环。
应用日志，则是你的代码在说话。业务逻辑出错了、接口调慢了、参数传错了，都在这里。应用日志的格式通常更规范，因为你可以自己控制怎么打日志。
1.3 日志级别——DEBUG, INFO, WARN, ERROR, FATAL
日志级别这东西，看起来简单，但实际用起来门道很多。我见过有人把所有日志都打成 INFO，也见过有人把 DEBUG 日志直接带到生产环境。嗯，这里要好好说说。
标准的日志级别从低到高是这样的：
- DEBUG：开发调试用，生产环境一般关掉。信息量最大，但也最吵。
- INFO：正常业务流程的记录。比如「用户登录成功」「订单创建完成」。
- WARN：有潜在风险，但还没出问题。比如「磁盘使用率超过 80%」「重试第 2 次」。
- ERROR：确实出错了，但服务还能继续跑。比如「数据库连接超时，降级使用缓存」。
- FATAL：致命错误，服务基本挂了。比如「无法加载核心配置文件，系统退出」。
核心原则：生产环境一般开到 INFO 级别。WARN 和 ERROR 是重点监控对象。FATAL 一旦出现，立刻触发告警。
你可能会问：为什么不在生产环境开 DEBUG？我告诉你，我亲眼见过一个团队在生产环境开了 DEBUG，结果一天产生了 200GB 日志，直接把磁盘撑爆了。DEBUG 日志的信息密度太高，适合开发环境做细粒度排查，但不适合生产环境。
另外，日志级别的选择也跟你的业务场景有关。比如支付系统，每一笔交易的完整链路都应该打 INFO 日志，方便对账。而一个内部工具，可能 WARN 以上就够了。
1.4 知识体系总览
下面这张图，把这一章的核心内容串起来了。你可以把它当作日志分析的「地图」，以后遇到问题，先看自己在哪个位置。
这张图把日志分析的三个核心维度串在了一起。你从任何一个节点出发，都能找到对应的知识点。我个人习惯把这张图贴在工位上，排查问题时先看一眼，确认自己有没有遗漏什么。
1.5 小结
这一章我们聊了日志的格式、类型和级别。看起来都是基础，但基础不牢，后面分析复杂问题时会很吃力。你想想看，如果连日志级别都分不清，怎么设置告警阈值？如果连系统日志和应用日志都混在一起，怎么快速定位故障根因？