日志系统基础：日志的作用、日志级别与格式标准
日志这东西，说白了就是系统的「黑匣子」。我在运维一线摸爬滚打这些年，每次线上出问题，第一反应就是翻日志。没有日志，你就像蒙着眼睛修车，全靠猜。
但很多团队对日志的态度是「能打出来就行」。结果呢？要么日志量爆炸，一天几个TB，查个问题像大海捞针；要么关键信息缺失，出了事连个堆栈都找不到。嗯，这里面的门道，咱们得好好捋一捋。
日志到底有什么用？
我个人习惯把日志的作用归纳为四个核心场景：
- 故障排查：这是最直接的用途。系统挂了、接口超时、数据不一致，日志是第一手证据。
- 行为审计：谁在什么时间做了什么操作？合规审计全靠日志链。
- 性能分析：接口响应慢在哪一步？通过日志里的时间戳，能精确到毫秒级定位瓶颈。
- 监控告警：日志里出现ERROR关键字，告警系统立刻通知你。我见过不少团队，告警规则写得比业务代码还长。
核心观点：日志不是写给机器看的，是写给「未来那个焦头烂额的你」看的。写日志时，请假设三天后的自己会感谢现在的你。
日志级别：DEBUG / INFO / WARN / ERROR
级别这东西，很多新手觉得「全打INFO不就行了？」——不行。级别是日志的「优先级标签」，决定了你在不同场景下能看到什么。
| 级别 | 含义 | 典型场景 | 我个人的使用建议 |
|---|---|---|---|
| DEBUG | 调试信息 | 变量值、循环次数、函数入参 | 只在开发/测试环境开启。线上开DEBUG？磁盘会哭的。 |
| INFO | 常规信息 | 服务启动、请求到达、任务完成 | 记录关键业务流程节点，别什么都往里塞。 |
| WARN | 警告 | 重试、降级、配置缺失但用了默认值 | 不影响当前请求，但值得关注。我习惯给WARN加个计数器。 |
| ERROR | 错误 | 异常捕获、数据库连接失败、超时 | 必须包含堆栈和上下文。光打一句「出错了」等于没打。 |
避坑指南：我曾经接手过一个项目，所有异常都只打ERROR级别，但内容只有「Exception occurred」。排查问题时，连是哪行代码抛的都找不到。从那以后，我要求团队：ERROR日志必须包含异常类型、堆栈、请求ID和关键参数。
你可能会问：那FATAL呢？很多框架确实有FATAL级别，但我个人觉得，ERROR已经能覆盖绝大多数场景。真正需要FATAL的，往往是进程即将崩溃——这种时候，日志能不能写进去都是个问题。
日志格式标准：别让解析器崩溃
日志格式，是团队协作的「通用语言」。我见过最离谱的日志，是纯中文描述，连时间戳都没有。你想想看，用grep查起来得多痛苦？
一个标准的日志行，应该包含以下字段：
[时间戳] [日志级别] [线程名] [请求ID] [类名:行号] - 日志内容举个例子：
[2025-03-21 14:32:18.123] [ERROR] [http-nio-8080-exec-3] [req-abc123] [com.example.OrderService:56] - 订单创建失败，订单号：ORD20250321001，原因：库存不足为什么要有请求ID？因为一个请求可能经过多个服务、多个线程。没有请求ID，你根本串不起来。我在做微服务日志链路追踪时，强制每个服务在入口处生成一个TraceID，贯穿整个调用链。
小技巧：日志时间戳统一使用ISO 8601格式（如2025-03-21T14:32:18.123Z），带时区信息。这样跨地域、跨系统的日志对齐时，不会出现「早上8点」到底是哪个时区的混乱。
日志格式的常见陷阱
- 别用系统默认格式：很多框架的默认日志格式字段不全。我建议团队统一配置，别偷懒。
- 别打敏感信息：密码、身份证号、银行卡号——这些绝对不能进日志。我曾经见过一个项目，日志里明文打印了用户密码，审计时直接亮红灯。
- 别打大对象：比如把整个HTTP请求体或数据库结果集全打出来。日志量会爆炸，而且影响性能。
- 别用中文做关键字：日志内容可以用中文描述，但关键字（如订单号、用户ID）必须用英文或数字。否则grep、ELK解析时会出各种编码问题。
日志知识体系结构
下面这张图，是我梳理的日志系统基础核心逻辑。你可以把它当作本章的「思维导图」：
写在最后
日志系统基础，说白了就三件事：知道为什么打、知道打什么级别、知道怎么打才规范。别小看这些基础，我见过太多线上事故，最后复盘时发现——日志里什么都有，就是没有关键信息。
嗯，这一章的内容就到这里。记住：好的日志习惯，是运维工程师的「护身符」。