📚 课程目录第2章日志基础与格式

日志基础与格式：搞懂日志长什么样

咱们正式开始之前，我想先聊个事儿。你可能觉得日志就是一堆文本，有啥好学的？我曾经也这么想，直到有一次线上故障，排查了整整八个小时，最后发现是日志格式解析错了。那天晚上我盯着屏幕，恨不得把写日志的人拉出来聊聊人生。

所以，日志格式这事儿，真不是小事。你想想看，如果连日志长什么样都搞不清，规则引擎再牛也白搭。这一章，咱们就把日志的“家底”翻个底朝天。

我个人习惯把日志分成三大类：系统日志、应用日志、安全日志。这三类各有各的特点，就像白菜、萝卜、土豆，虽然都叫菜，但做法完全不一样。

    核心认知： 日志类型决定了你用什么思路去解析和巡检。搞混了类型，规则设计就会跑偏。

系统日志： 操作系统或基础设施生成的。比如 Linux 的 /var/log/messages，Windows 的事件查看器。内容大多是内核、服务、硬件层面的消息。格式相对固定，通常带时间戳、主机名、进程名。
应用日志： 咱们自己写的程序吐出来的。格式最自由，也最让人头疼。有的用 JSON，有的用纯文本，有的甚至把异常堆栈和业务日志混在一起。我见过最夸张的，一行日志里塞了上千个字符，没有换行——嗯，你想杀人的心都有。
安全日志： 跟身份认证、权限变更、网络访问相关的。比如 SSH 登录失败记录、防火墙拦截日志。这类日志对审计和合规特别重要，格式一般比较规范，但字段多且敏感。

格式这玩意儿，说白了就是“怎么写日志的约定”。我见过团队因为格式不统一，最后硬生生搞出十几个解析器。所以，咱们先看看主流格式都有哪些套路。

这是最老牌的格式了，RFC 5424 和 RFC 3164 两个版本。Syslog 的特点是有一个固定的头，后面跟消息体。头里边包含时间、主机名、进程、优先级。

举个例子：

<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick on /dev/pts/8

这里 <34> 是优先级，Oct 11 22:14:15 是时间，mymachine 是主机名，su 是进程。后面就是消息体。我个人建议，如果你用 Syslog，最好选择 RFC 5424 版本，因为它有结构化数据，解析起来更准确。

一个小技巧： 我在项目中遇到过，Syslog 的时间戳有时不带年份。如果你要长期归档，记得在解析时补充年份，不然跨年查询就抓瞎了。

现在最流行的格式，没有之一。JSON 的优势是自带结构，字段名和值清清楚楚。解析起来几乎零歧义。

举个例子：

{
  "timestamp": "2024-10-11T22:14:15.000Z",
  "level": "ERROR",
  "service": "user-service",
  "message": "数据库连接超时",
  "request_id": "abc-123-def"
}

看到没？一眼就知道哪个字段是时间，哪个是错误级别。规则引擎写起来也舒服。我最喜欢 JSON 的一点是：它支持嵌套。你可以在一个字段里再放一个对象，比如把异常堆栈塞进去。

注意： 我曾经遇到过一个坑，JSON 里的时间戳格式不统一。有的用 ISO 8601，有的用 Unix 时间戳。解析前一定要先做格式校验。

CSV 格式常见于老系统或者一些数据库导出的日志。字段用逗号分隔，第一行通常是列名。优点是体积小，解析速度快。缺点也很明显——字段内容里如果包含逗号或者换行符，容易解析错误。

举个例子：

timestamp,level,source,message
2024-10-11 22:14:15,ERROR,user-service,数据库连接超时

说实话，CSV 现在用得越来越少了。除非是遗留系统，我一般不推荐。不过如果你必须处理 CSV，记住一点：用专业的 CSV 解析库，别自己 split 逗号。否则遇到引号包裹的字段，你就等着哭吧。

这才是真正的“重灾区”。什么牛鬼蛇神都有。比如：

[22:14:15] [ERROR] user-service | 数据库连接超时 | req_id=abc-123

或者：

2024-10-11 22:14:15.000 ERROR user-service (abc-123) 数据库连接超时

自定义格式最大的问题就是没有标准。每个开发人员都觉得自己写的格式最酷。我见过最离谱的，在日志里用了 emoji 来标记级别 —— 🚨ERROR、⚠️WARN。对，你没听错。解析器还得先识别 emoji。

我的建议： 能不用自定义格式就别用。如果非要用，一定要提供正则表达式的解析模板，或者干脆输出一份格式文档。别让别人猜。

讲了这么多，咱们用一张图把日志类型和格式的关系捋一捋。你想想看，整个日志世界其实就是这么回事——不同类型的日志，套上不同的格式外衣，最终汇聚到规则引擎里。

到底用哪个格式？我个人觉得，有选择的情况下，JSON 是首选。但如果系统环境受限，或者有历史遗留，也别硬掰。下面这个表格是我自己整理的，你可以参考一下。

格式	可读性	解析难度	灵活度	体积	我的推荐场景
Syslog	中等	中等	低	小	系统基础设施、网络设备
JSON	高	低	高	较大	现代应用首选
CSV	中等	低（需小心）	低	小	数据导出、遗留系统
自定义	差	高	高（但不可控）	不定	尽量不要用

字字血泪的忠告： 我曾经接手过一个项目，日志格式是自定义的，而且没有任何文档。42种不同的格式变体，分布在200多个微服务里。我花了整整两周时间，才写出一套能覆盖95%场景的正则表达式。剩下5%的日志，至今还在告警系统里挂着“未匹配”。别走这条路。

好了，这一章咱们把日志的家底翻了个遍。记住三件事：