1. 日志基础认知：什么是日志、日志的级别、日志的作用与价值
说实话，我做了十几年后端开发和运维，跟日志打了太多交道。刚入行那会儿，我觉得日志就是个可有可无的东西——代码能跑就行，写那么多日志干嘛？直到有一次线上事故，系统挂了整整两个小时，我翻遍服务器愣是找不到原因。嗯，从那以后，我再也不敢小看日志了。
这一章，咱们就把日志最基础的东西捋清楚。别觉得基础就不重要，你想想看，地基打不牢，后面那些检索优化、分析挖掘全是空中楼阁。
1.1 什么是日志
日志，说白了就是系统运行过程中产生的「流水账」。它记录了什么时间、在哪个模块、发生了什么事。每一行日志，都是系统状态的一个快照。
我个人习惯把日志分成三类：
- 系统日志：操作系统、中间件、数据库产生的运行记录
- 应用日志：业务代码里主动输出的调试、错误、业务事件
- 安全日志：登录、权限变更、敏感操作等审计信息
举个例子，你在电商网站下单，背后可能产生了这些日志：
2025-01-15 10:23:45.678 [http-nio-8080-exec-3] INFO c.e.order.OrderService - 用户[9527]发起下单请求，商品ID: 10086，数量: 2
2025-01-15 10:23:45.712 [http-nio-8080-exec-3] DEBUG c.e.order.InventoryClient - 调用库存服务，参数: {"skuId":10086,"qty":2}
2025-01-15 10:23:45.890 [http-nio-8080-exec-3] INFO c.e.order.OrderService - 订单创建成功，订单号: ORD202501150001
每一行都包含了时间戳、线程名、日志级别、类名，以及具体的业务信息。这就是日志的原始形态。
核心要点：日志不是写给机器看的，是写给人看的。写日志的时候，要想着「如果出问题了，我看到这行日志能知道什么」。
1.2 日志的五个级别
日志级别这个东西，不同框架（Log4j、Logback、SLF4J）定义略有差异，但主流都遵循五个级别。我按严重程度从低到高给你捋一遍。
| 级别 | 含义 | 典型场景 | 生产环境是否开启 |
|---|---|---|---|
| DEBUG | 调试信息 | 变量值、调用链、临时验证 | 通常关闭 |
| INFO | 普通信息 | 业务流转、状态变更、关键节点 | 开启 |
| WARN | 警告 | 潜在风险、降级、重试、配置异常 | 开启 |
| ERROR | 错误 | 业务异常、系统故障、调用失败 | 开启 |
| FATAL | 致命错误 | 系统崩溃、数据丢失、不可恢复 | 开启 |
这里我多说几句，每个级别怎么用才合适。
DEBUG：我在项目中遇到过，有人把DEBUG日志当INFO用，生产环境一开DEBUG，磁盘直接被打满。DEBUG只适合开发环境和测试环境，线上除非定位疑难问题，否则别开。
INFO：记录业务的关键节点。比如「用户登录成功」「订单支付完成」「任务调度开始」。INFO不是流水账，别把循环里的每次迭代都打INFO，那跟刷屏没区别。
WARN：这个级别很多人不会用。我建议，当系统还能正常运行，但已经出现了「不太对劲」的信号时，就用WARN。比如接口响应时间超过阈值、缓存穿透、降级策略被触发。WARN是提前预警，别等到ERROR才慌。
ERROR：业务异常、调用下游失败、数据校验不通过。注意，ERROR不一定是系统挂了，但一定需要有人关注和处理。
FATAL：这个级别很少用。一旦出现，意味着系统已经无法继续运行。比如数据库连接池耗尽、磁盘空间不足、关键配置缺失。FATAL日志通常伴随着进程退出或重启。
避坑指南：我曾经在一个项目里看到有人把「用户输入了非法参数」打成了FATAL。这明显不对。FATAL是系统级别的灾难，不是业务级别的异常。滥用FATAL会让告警系统失效，真正出大事的时候反而被淹没了。
1.3 日志的作用与价值
日志到底有什么用？我总结了三句话：排障靠它、监控靠它、审计靠它。
1.3.1 故障排查
这是日志最核心的价值。系统出问题了，第一反应就是翻日志。我记得有一次线上服务突然超时，查了监控发现CPU没飙、内存没爆、网络没堵。最后是翻了ERROR日志，发现是某个第三方接口返回格式变了，反序列化失败。如果没有日志，这种问题根本无从下手。
1.3.2 监控与告警
日志是监控系统的「原材料」。通过收集日志中的ERROR、WARN数量，可以实时感知系统健康度。比如：
- 每分钟ERROR数超过阈值 → 触发告警
- 某接口响应时间超过2秒 → 记录慢日志
- 登录失败次数过多 → 触发安全告警
说白了，没有日志，监控就是瞎子。
1.3.3 业务分析与审计
日志里藏着大量业务数据。用户行为、交易流水、操作记录，全在日志里。合规审计、数据复盘、用户画像，都离不开日志。
举个例子，电商大促结束后，运营要分析用户购买路径。从「搜索→浏览→加购→下单→支付」，每一步都有日志。把这些日志串起来，就能还原用户的完整行为链路。
1.3.4 性能优化
这个很多人容易忽略。通过分析日志中的时间戳，可以精确计算每个环节的耗时。比如：
2025-01-15 10:23:45.678 [入口] 开始处理订单
2025-01-15 10:23:45.712 [库存] 查询耗时: 34ms
2025-01-15 10:23:45.756 [价格] 计算耗时: 44ms
2025-01-15 10:23:45.890 [持久化] 写入耗时: 134ms
2025-01-15 10:23:45.891 [出口] 处理完成，总耗时: 213ms
看到没？瓶颈在持久化环节。这就是日志给出来的优化方向。
我的习惯：每个关键业务操作，我都会在入口和出口各打一条INFO日志，带上唯一标识（比如订单号、请求ID）。这样出了问题，直接根据ID把整个调用链串起来，排查效率翻倍。
1.4 日志知识体系总览
下面这张图，把本章的核心知识点串起来了。你可以把它当作整个课程的「地图」——后面每一章，都会在这张图上展开。
这张图把本章内容分成了三大块：日志是什么、有哪些级别、有什么用。后面每一章都会在这个框架上不断加东西。你先把这张图记在脑子里，后面学起来会轻松很多。