日志基础与格式：常见日志格式与字段解析
做运维这些年，我见过太多人在日志面前抓瞎了。说白了，日志就是系统的「黑匣子」。你想想看，交易系统出问题了，第一反应是什么？肯定是翻日志啊。但要是连日志都看不懂，那跟没写有什么区别？
今天咱们就聊聊日志的基础。别觉得简单，我见过不少老手，在日志格式上栽过跟头。
一、日志级别：DEBUG、INFO、WARN、ERROR
日志级别这东西，说白了就是给日志贴标签。告诉你看日志的人：这条消息有多严重。
| 级别 | 含义 | 典型场景 |
|---|---|---|
| DEBUG | 调试信息 | 变量值、函数调用栈、SQL语句 |
| INFO | 普通信息 | 系统启动、请求到达、任务完成 |
| WARN | 警告 | 磁盘空间不足、重试次数超限 |
| ERROR | 错误 | 数据库连接失败、订单处理异常 |
核心原则：生产环境只开 INFO 及以上级别。DEBUG 日志量太大，会拖垮磁盘 IO。我见过一个团队，生产环境开着 DEBUG，结果一天写了 200GB 日志，直接把磁盘撑爆了。
我的习惯：线上系统我一般设 INFO 级别。出问题时，再动态调整为 DEBUG。很多框架都支持运行时改日志级别，不用重启服务。
二、常见日志格式：JSON、CSV、文本
日志格式，嗯，这里要注意。不同格式有不同用途。选错了，后面分析起来会非常痛苦。
1. 纯文本格式
最原始的格式。一行一条日志，用分隔符隔开字段。
2024-01-15 10:30:45.123 [http-nio-8080-exec-1] INFO com.trade.OrderService - 订单创建成功, orderId=ORD20240115001, userId=U10086, amount=2999.00这种格式人类可读性好，但机器解析麻烦。我早期做运维时，全是这种日志。想统计个订单量，得写一堆正则表达式，烦得很。
2. JSON 格式
现在的主流选择。结构清晰，机器解析方便。
{
"timestamp": "2024-01-15T10:30:45.123Z",
"level": "INFO",
"logger": "com.trade.OrderService",
"thread": "http-nio-8080-exec-1",
"message": "订单创建成功",
"orderId": "ORD20240115001",
"userId": "U10086",
"amount": 2999.00
}为什么推荐 JSON？ 因为 Elasticsearch、Splunk 这类工具，原生支持 JSON 解析。字段自动识别，搜索、聚合、可视化一条龙。我现在的项目，全部强制使用 JSON 格式。
3. CSV 格式
适合批量导入和表格分析。但字段顺序必须固定，灵活性差。
timestamp,level,logger,message,orderId
2024-01-15 10:30:45.123,INFO,com.trade.OrderService,订单创建成功,ORD20240115001避坑指南：我曾经遇到过一个系统，日志字段里包含逗号，结果 CSV 解析全乱了。后来加了引号转义才解决。如果你非要用 CSV，记得给每个字段加引号。
三、日志字段解析
一条完整的日志，应该包含哪些字段？我总结了一个「黄金七要素」。
- 时间戳：精确到毫秒，带时区。没有时间戳的日志，等于废纸。
- 日志级别：DEBUG/INFO/WARN/ERROR，快速定位问题严重程度。
- 线程名：多线程环境下，知道是哪个线程出的问题。
- 类名/方法名：快速定位代码位置。
- 消息体：具体描述发生了什么。
- 上下文信息：订单ID、用户ID、请求ID等，用于关联分析。
- 异常堆栈：ERROR级别必须带，否则等于没写。
我的建议：每个请求进来时，生成一个唯一的 traceId。贯穿整个请求链路。这样你就能把一次交易的所有日志串起来看。我管这叫「日志的 DNA」。
四、知识体系图
下面这张图，是我梳理的日志基础知识结构。你把它记在脑子里，后面分析日志时就不会迷路。
五、实战建议
说了这么多，最后给你几条实在的建议。
- 统一格式：整个团队用同一种格式。别这个模块用 JSON，那个模块用文本。我见过一个项目，光日志解析就写了 5 套代码，维护成本高得吓人。
- 控制日志量：ERROR 日志一定要少而精。如果一天产生几万条 ERROR，那跟没有 ERROR 日志一样——没人会去看。
- 带上关键信息：每条日志都要能回答「谁、什么时间、做了什么、结果如何」。比如「订单创建成功」这种日志，必须带上订单ID。
- 异常要完整：catch 到异常时，一定要打印完整堆栈。只打一个 getMessage()，等于没打。你根本不知道哪里出的问题。
我曾经踩过的坑：有一次线上订单丢失，查日志发现全是「处理异常」四个字，没有订单ID，没有堆栈。最后只能靠猜，花了整整两天才定位到问题。从那以后，我定了个规矩：ERROR 日志必须包含 traceId 和完整堆栈，少一个都不行。
日志这东西，平时觉得无所谓。真出事了，它就是你的救命稻草。把基础打牢，后面分析起来才能得心应手。
公众号:蓝海资料掘金营，微信deep3321