📚 课程目录第2章日志分类与格式

2. 日志分类与格式

日志这东西，说白了就是系统、应用和安全组件留给咱们的「黑匣子」。刚入行那会儿，我觉得日志就是文本，能搜关键词就行。后来出了几次大故障，才发现分类不清、格式混乱的日志，简直是一场灾难。

我个人习惯，先把日志粗分三大类：系统日志、应用日志、安全日志。然后再看它们用什么格式写的——JSON、Syslog 还是纯文本。你想想看，连分类都没做对，后面的压缩、归档策略就是空中楼阁。

核心观点：日志分类决定存储策略，日志格式决定解析效率。两者必须一起规划。

2.1 日志的三大分类

我在项目中遇到过最头疼的事：运维和开发各自为政，日志全往一个目录里写。出问题后，根本分不清是哪一层报的错。所以，咱们得先把日志的来源理清楚。

2.1.1 系统日志

系统日志是操作系统和基础设施组件产生的记录。嗯，这里要注意，它涵盖的范围很广——内核、服务、硬件、网络设备都会产生。

内容：进程启动/停止、磁盘I/O错误、网络接口状态变化、内存不足、定时任务执行结果等。
典型路径：/var/log/messages (Linux)、/var/log/syslog、Event Log (Windows)。
常见格式：以 Syslog 格式为主，部分现代系统开始输出 JSON。

我记得有一次线上数据库突然响应变慢，查了半天应用代码，最后看了系统日志才发现是磁盘坏道导致的 I/O 等待。所以，系统日志我建议作为第一优先级的保留对象。

2.1.2 应用日志

应用日志是咱们自己写的代码输出的信息。这部分最五花八门。为什么？因为每个开发团队的口味不同。

内容：请求处理耗时、业务状态流转、数据库查询语句、第三方接口调用结果、异常堆栈。
典型格式：JSON 现在最流行，但也有不少老系统用纯文本、甚至自定义分隔符格式。
等级：DEBUG、INFO、WARN、ERROR、FATAL。注意，生产环境我建议只开 INFO 及以上等级，否则日志量会爆炸。

实战建议：如果你的应用日志还在用 System.out.println 直接写，建议尽快升级到结构化日志（SLF4J + Logback/Log4j2 + JSON Layout）。这事儿早点做，后面收益很大。

2.1.3 安全日志

安全日志，说白了就是审计证据。出事调取证就靠它。这类日志的存储要求通常最高——不能丢、不能改、得存很久。

内容：登录成功/失败、权限变更、敏感文件访问、防火墙规则变更、VPN 连接记录。
典型来源：Firewall、IDS/IPS、WAF、IAM 系统、SSH、sudo。
特殊要求：完整性保护（通常需要写一次读多次的存储，甚至用区块链哈希链）。

我曾经维护过一个电商平台，安全日志全混在应用日志里。后来被审计发现，被迫花了两周时间做日志拆分。避坑指南：从一开始就单独规划安全日志的存储和归档路径，不要混在一起。

2.2 日志的三种主流格式

分类讲完了，咱们聊聊格式。为什么格式重要？因为格式决定了你的解析器怎么写、搜索效率高不高、压缩比大不大。我个人偏好 JSON，但有些场景 Syslog 和纯文本反而更省事。

日志格式对比
特性	JSON	Syslog	纯文本
可读性	中等（压缩后难读）	较好（固定结构）	好（无框架干扰）
机器解析	原生支持	需正则匹配	正则或自定义解析
压缩比	高（字段名重复浪费）	中等	最高（无冗余字段名）
扩展性	优秀（随意加字段）	弱（结构固定）	差（格式变更破坏解析）
典型场景	微服务、容器化环境	网络设备、传统 Unix	老旧系统、嵌入式设备

2.2.1 JSON 格式

JSON 现在是事实上的标准了。每个字段都有 key，解析器根本不用猜。我建议所有新建的应用日志统一用 JSON 格式。

{
  "timestamp": "2025-04-10T14:23:11.123Z",
  "level": "ERROR",
  "logger": "com.example.payment.PaymentService",
  "thread": "http-nio-8080-exec-3",
  "message": "支付接口调用超时",
  "context": {
    "orderId": "ORD2025041001234",
    "amount": 399.00,
    "durationMs": 3050
  },
  "exception": "java.net.SocketTimeoutException: Read timed out"
}

注意：JSON 日志文件如果单行写（没有换行），gzip 压缩效果会变差。我建议每条 JSON 日志占一行（JSON Lines），既方便追加，也方便压缩引擎处理。

2.2.2 Syslog 格式

Syslog 是网络设备的老朋友。我记得在管防火墙集群时，每天几千万条 Syslog 飞来飞去。它有一个固定的头部，然后才是文本内容。

<134>Apr 10 14:23:11 fw01.example.com %ASA-4-106023: Deny tcp src inside:192.168.1.10/443 dst outside:203.0.113.5/80 by access-group "OUTSIDE"

PRI：<134> —— 设施（Facility）和严重级别编码在一起。
时间戳：Apr 10 14:23:11 —— 我建议序列化时补齐年份和时区。
主机名：fw01.example.com —— 日志来源标识。
消息体：%ASA-4-106023 ... —— 不同厂商的自定义格式。

Syslog 的缺点很明显：字段结构不归一。同一个时间戳，不同设备格式可能不同。解析时，你总得写一堆正则。避坑指南：如果有可能，在网络设备侧开启 Syslog over JSON 输出，这会省很多事。

2.2.3 纯文本格式

纯文本，最原始，也最灵活。但灵活的另一面是混乱。我见过用空格分隔、用 tab 分隔、用逗号分隔的纯文本日志，处理起来特别酸爽。

[2025-04-10 14:23:11] [INFO] [user-service] 用户登录成功 | userId=12345 | ip=192.168.1.10

为什么还在用纯文本？因为简单。嵌入式设备、老旧的单体应用、或者有些开发觉得 JSON 太臃肿。但说实话，除非是存储极端受限的场景，我不推荐在生产环境用纯文本。它最大的问题是：格式一改，历史数据就废了。

2.3 本章核心逻辑：分类与格式的组合决策

知识点讲完，我画了一张图帮你理清脉络。日志从源头产生，先按来源分为系统、应用和安全三类；每类日志又有自己的格式偏好；最终我们要根据不同分类和格式，制定不同的存储与压缩策略。

从这张图里可以看出：系统日志多半走 Syslog 或纯文本，应用日志现在基本被 JSON 统治，安全日志则要看审计合规要求（Syslog 和 JSON 都有，但纯文本很少用）。

个人习惯：我每次接手新系统，第一件事就是拉一份日志目录清单，按分类和格式做矩阵统计。再复杂的日志环境，一张表格就能看清问题。

好了，日志的分类和格式先聊到这儿。接下来咱们该谈谈怎么把这些日志高效地存储起来——包括选什么压缩算法、如何轮转归档、以及控制存储成本。这些都是我在实战中踩过不少坑之后总结出来的经验。