日志系统基础：什么是日志，日志分类
日志的本质：一台永不关机的黑匣子
说实话，干了这么多年运维和开发，我最怕听到的一句话就是——「服务器出问题了，但不知道为啥」。这时候你只能翻日志。日志是什么？说白了，就是系统、应用和安全组件每秒都在记录的流水账。每一条日志都是一张时间戳 + 事件描述 + 上下文的小纸条。我个人的习惯，新到一个环境第一件事就是先看日志配置，别等到出了事才想起来。
你想想看，一台服务器可以没有 GUI，可以没有鼠标键盘，但不能没有日志。为什么？因为日志是唯一能让你事后逆向回放事故现场的证据。我把日志比喻成黑匣子，一点不过分——只是这黑匣子从来不会关机，除非你把磁盘写满了。
日志的三大分类
我习惯把日志先分成三大类：系统日志、应用日志和安全日志。这三类覆盖了绝大多数场景。下面这个表格能帮你快速区分它们：
| 分类 | 来源 | 典型内容 | 关键价值 |
|---|---|---|---|
| 系统日志 | 操作系统内核、服务管理 daemon、硬件驱动 | 系统启动、服务启停、磁盘错误、OOM 杀进程 | 排查基础设施故障、资源瓶颈 |
| 应用日志 | 业务程序、中间件、数据库 | 用户请求、API 调用、数据库查询、错误堆栈 | 定位业务异常、性能热点、用户行为 |
| 安全日志 | 防火墙、入侵检测、认证模块、审计系统 | 登录成功/失败、权限变更、端口扫描、异常流量 | 发现入侵、合规审计、威胁溯源 |
很多新人会把系统日志和安全日志混为一谈。其实很简单——系统日志关注的是「机器本身怎么了」，安全日志关注的是「有没有人在搞事情」。应用日志则夹在中间：有时候是业务逻辑错了，有时候是被人恶意调用了接口。我之前遇到过的一个案例：应用日志里突然出现大量 500 错误，系统日志显示正常，安全日志里发现同一个 IP 在疯狂重试密码——三条日志一关联，立刻定位到是暴力破解攻击。这就是分类的价值。
其他常见日志类型
除了上面三大类，实际工作中还会遇到很多「非典型」日志，我简单列几个常用的：
- 网络日志：交换机、路由器的日志，记录链路状态、BGP 邻居变化、ACL 命中。我曾经靠一条「接口 flapping」日志，救了一个中断了两个小时的视频会议。
- 数据库日志：MySQL 的 binlog、慢查询日志，Oracle 的 alert log。应用慢不一定是代码烂，数据库查不动才是真问题。
- 容器日志：Docker 容器 stdout/stderr、Kubernetes Pod 事件。嗯，这里要注意：容器日志默认是写到 stdout 的，但千万别把敏感信息打印进去。
- 审计日志：满足合规要求（比如 PCI-DSS、等级保护），记录谁在什么时间做了什么操作。我在金融行业见过他们连运维敲的命令都要逐条记录截图。
日志的典型格式
虽然不同系统日志格式千奇百怪，但最经典的非 syslog 莫属。你看一下这个 RFC 3164 格式的例子：
<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick on /dev/pts/8看起来很乱对吧？其实拆开就清楚：
- <34>：优先级 = 设施(Facility) × 8 + 严重级别(Severity)。34 表示 facility=4(security) severity=2(critical)。
- Oct 11 22:14:15：时间戳，没有年份，这点经常坑人。
- mymachine：主机名。
- su: ...：进程名和具体消息。
我建议你用这个格式作为标准参考。现代日志系统都支持 JSON 格式了，但底层结构化思路是一样的：时间 + 来源 + 级别 + 消息。
日志的生成与流转路径
日志从产生到被分析，通常经历五个阶段。我画了一张图来表示这个流程：
这张图我画的时候故意留了个细节——存储和分析之间是折线，而且分析节点放在了右下角。为什么？因为在实际项目中，日志从存储到分析往往不是线性的，中间可能会有 Kafka 缓冲、流式处理、或者离线批处理。我见过最离谱的案例：日志流直接通过 Flume 怼到 HDFS 里，然后分析时发现数据已经积压了 3 天，完全丧失了时效性。所以，日志的流转路径一定要考虑延迟和可靠性。生成阶段保证格式规范，采集阶段不能丢数据，传输阶段不能堵塞，存储阶段考虑容量和索引，分析阶段才可能快准狠。