一、日志基础：什么是日志、日志的重要性、日志的级别
聊到日志，我先问大家一个问题：你部署的应用如果突然挂了，你第一反应是什么？
我个人习惯，肯定是先翻日志。没有日志，就像医生没有病历本，全靠猜。说白了，日志就是系统运行时的「黑匣子」，记录着每一秒发生了什么、谁干的、结果如何。
1.1 什么是日志
日志，就是程序在运行过程中输出的「流水账」。它可以是文本，也可以是结构化的 JSON。每一行日志，通常包含时间戳、日志级别、模块名称、具体消息。
一个典型的日志条目长这样：
2025-04-10 14:23:45,678 [INFO] [UserService] 用户登录成功，userId=1024你看，时间、级别、谁、干了什么，一目了然。
我在项目中遇到过一种情况：开发环境日志打印得密密麻麻，一到生产环境就全关了。结果线上出了故障，连个报错都找不到。嗯，这里要注意——日志不是开关，而是基础设施。
1.2 日志的重要性
你想想看，一个线上系统跑着跑着突然变慢了，或者干脆不响应了。没有日志，你连从哪下手都不知道。日志的重要性，我总结为四点：
- 故障排查：出问题时，日志是唯一的「现场还原」手段。我曾经花了一整天追一个内存泄漏，最后发现是某个第三方库在循环里疯狂打 ERROR 日志，导致日志文件撑爆了磁盘。你说冤不冤？
- 性能分析：通过日志里的响应时间、SQL 执行耗时，可以快速定位瓶颈。
- 安全审计：谁在什么时间访问了什么资源，日志里一清二楚。合规要求少不了它。
- 业务监控：比如支付成功率、用户注册量，都可以从日志里统计出来。
避坑指南：我曾经见过一个团队，日志全打在一个文件里，从不轮转。结果一个月后，日志文件 50GB，服务器磁盘直接打满，应用彻底瘫痪。记住：日志不管理，迟早出大事。
1.3 日志的级别
日志级别，说白了就是给日志贴个「严重程度」标签。不同的级别，对应不同的处理方式。我习惯把日志级别分成五档：
| 级别 | 含义 | 使用场景 | 我的建议 |
|---|---|---|---|
| DEBUG | 调试信息 | 开发阶段，打印变量值、函数调用链 | 生产环境建议关闭，否则日志量爆炸 |
| INFO | 普通信息 | 用户登录、订单创建、服务启动 | 生产环境保留，用于日常监控 |
| WARNING | 警告 | 磁盘使用率超过80%、重试次数过多 | 需要关注，但不一定立即处理 |
| ERROR | 错误 | 数据库连接失败、请求超时、业务异常 | 必须处理，通常触发告警 |
| CRITICAL | 致命错误 | 系统崩溃、内存溢出、关键服务不可用 | 立即响应，可能影响整个系统 |
个人经验：我建议团队统一日志级别规范。比如：INFO 记录业务流程，WARNING 记录需要关注但不影响主流程的情况，ERROR 记录需要人工介入的异常。千万别把 DEBUG 级别的日志带到生产环境——我曾经见过一个项目，DEBUG 日志每秒输出 10 万行，直接把日志系统打崩了。
1.4 如何选择日志级别
很多新手会问：「到底该用 INFO 还是 DEBUG？」我的判断标准很简单：这条日志如果丢了，会不会影响我排查问题？
- 如果丢了也无所谓 → 用 DEBUG
- 如果丢了会少一个关键线索 → 用 INFO
- 如果这条日志代表系统「带病运行」 → 用 WARNING
- 如果这条日志代表「已经出事了」 → 用 ERROR
- 如果这条日志代表「系统要挂了」 → 用 CRITICAL
举个例子。用户登录时，密码输错了三次。用 WARNING 记录比较合适——不是错误，但值得关注。如果密码输错导致账号被锁定，那就该用 ERROR 了。
代码示例（Python）：
import logging
logging.basicConfig(level=logging.INFO)
def login(username, password):
if not username:
logging.warning("登录尝试：用户名为空")
return False
if password == "123456":
logging.info(f"用户 {username} 登录成功")
return True
else:
logging.error(f"用户 {username} 登录失败：密码错误")
return False你看，不同级别对应不同场景。代码里一目了然。
1.5 小结
日志这东西，平时不起眼，出事的时候就是救命稻草。我做了这么多年运维，最大的体会就是：日志写得好，故障解决早；日志写得烂，加班到天亮。
下一章，我们会聊日志轮转——也就是怎么让日志文件「瘦身」，别把磁盘撑爆。嗯，那才是真正的实战环节。