1. 日志基础与核心概念
大家好，我是这次课程的主讲。做了十几年运维，跟日志打了太多交道。说实话，刚入行那会儿我也觉得日志就是「出问题了再看一眼」的东西。直到有一次线上事故，花了整整一个通宵才定位到问题——从那以后，我才真正开始认真对待日志。
这一章，我们先打好基础。把日志是什么、为什么重要、怎么写才算规范，一次性说清楚。
什么是日志
日志，说白了就是系统运行过程中产生的「时间戳 + 事件描述」记录。你想想看，一个系统跑起来，每秒都在发生无数事情：用户登录、数据库查询、接口调用、内存分配……这些事如果没人记下来，出问题的时候就只能靠猜。
我个人习惯把日志分成三类：
- 系统日志：操作系统、内核、硬件层面的记录。比如
/var/log/messages。 - 应用日志：业务代码自己打的日志。比如用户下单、支付回调。
- 访问日志：Web 服务器、API 网关记录的请求流量。比如 Nginx 的
access.log。
这三类日志各有侧重，但核心结构都一样：什么时候、谁、干了什么、结果如何。
核心要点：日志不是写给机器看的，是写给人看的。每一行日志都应该能回答「发生了什么」和「为什么发生」。
日志的级别
日志级别这个概念，几乎所有框架都有。但你真的用对了吗？
我见过不少项目，所有日志全用 INFO，出问题的时候根本筛不出来。也见过有人把调试信息打成 ERROR，结果报警系统天天误报。
下面这张表，是我多年总结的级别使用规范：
| 级别 | 含义 | 什么时候用 | 我踩过的坑 |
|---|---|---|---|
| DEBUG | 调试信息 | 开发环境、临时排查问题 | 曾经在生产环境忘了关 DEBUG，一天产生 200GB 日志，磁盘直接打满 |
| INFO | 普通信息 | 关键业务流程、状态变更 | 别什么都打 INFO，否则跟没打一样 |
| WARN | 警告 | 非预期但可自动恢复的情况 | 重试机制触发、降级开关打开，这些一定要 WARN |
| ERROR | 错误 | 功能不可用、操作失败 | 需要人工介入的才打 ERROR，别把业务异常当 ERROR |
| FATAL | 致命错误 | 系统崩溃、数据丢失 | 这个级别很少用，但一旦出现必须立刻告警 |
我的建议：生产环境默认只开 INFO 及以上。DEBUG 日志通过动态开关按需开启，别写死在配置文件里。
日志的作用与价值
日志到底有什么用？我总结了三句话：
- 故障定位：系统出问题了，日志是第一手证据。没有日志，你就是盲人摸象。
- 行为审计：谁在什么时候做了什么操作，日志一清二楚。安全合规全靠它。
- 性能分析：接口响应慢、数据库查询耗时，日志里的时间戳就是最好的性能指标。
我记得有一次，线上服务突然超时严重。监控面板一片红，但找不到原因。最后翻日志发现，某个第三方接口的响应时间从 200ms 涨到了 5s——就是因为日志里记录了每次调用的耗时。如果没有这个字段，那天晚上估计又要通宵了。
注意：日志本身不解决问题，但它能告诉你问题在哪。没有日志的排查，就像在黑屋子里找一只黑猫——而且猫可能根本不在屋里。
日志规范与标准
很多团队日志打得乱，根本原因是没有规范。我参与过几个从零搭建日志体系的项目，总结下来，规范就三条：
1. 格式统一
每行日志必须包含：时间戳、日志级别、线程/进程ID、类名/模块名、消息内容。推荐使用 JSON 格式，方便后续解析。
// 推荐格式
{"timestamp":"2025-01-15T10:30:00.123Z","level":"ERROR","thread":"http-nio-8080-exec-3","logger":"com.example.OrderService","message":"订单创建失败","orderId":"ORD20250115001","error":"库存不足"}
// 不推荐格式
2025-01-15 10:30:00 订单失败 库存不足2. 上下文关联
单条日志没有意义，必须能串联起来。我习惯在每条日志里带上 traceId（链路追踪ID）和 业务主键（比如订单号、用户ID）。这样查问题的时候，一条命令就能拉出完整链路。
3. 敏感信息脱敏
这个我吃过亏。曾经有一次日志里不小心打印了用户的身份证号，被安全部门通报。从那以后，所有敏感字段（密码、手机号、身份证、银行卡）必须脱敏后再打日志。
// 脱敏前
"phone":"13812345678"
// 脱敏后
"phone":"138****5678"知识体系总览
下面这张图，把本章的核心知识点串起来了。你可以把它当作日志基础的地图：
嗯，这一章的内容就到这里。日志基础看起来简单，但真正用好的人不多。后面的章节，我们会一步步深入，从工具链到实战技巧，把日志追踪这件事彻底讲透。