一、日志系统概述：日志的价值、分类与核心目标

大家好，我是你们的老朋友。今天咱们聊聊日志系统。

说实话，我做了十几年运维，见过太多系统崩在深夜的场景。每次出问题，第一件事就是翻日志。日志就像飞机的黑匣子，平时没人理，出事就是救命稻草。我个人习惯是，新系统上线前，先问一句：「日志配好了吗？」

1.1 日志的价值——为什么我们离不开它？

日志的价值，说白了就三件事：排障、审计、监控。

• 排障：系统挂了，你总得知道为什么。日志就是现场还原。
• 审计：谁在什么时候做了什么？合规要求，日志是铁证。
• 监控：通过日志趋势，提前发现异常。比如错误率突然飙升，说明有情况。

我在项目中遇到过一件事。有一次线上服务半夜告警，CPU 跑满。我登录上去一看，日志文件把磁盘撑爆了，系统直接 OOM。嗯，这就是典型的「日志没管好，反而成了事故元凶」。所以，日志系统不仅要能记录，还要能管好自己。

1.2 日志的分类——三种最常见的日志

日志按来源和用途，大致分三类。我习惯这么记：系统管硬件，应用管业务，安全管权限。

分类	典型内容	常见位置	我关注的点
系统日志	内核消息、硬件状态、服务启停	/var/log/messages, syslog	磁盘 I/O 异常、OOM 记录
应用日志	业务请求、错误堆栈、性能数据	应用自定义目录	接口耗时、错误率、慢查询
安全日志	登录尝试、权限变更、防火墙拦截	/var/log/secure, audit.log	暴力破解、异常登录 IP

系统日志

系统日志是操作系统的「体检报告」。CPU 过热、磁盘坏道、内存不足，都会在这里留下痕迹。我曾经靠一条 kernel: Out of memory: Kill process 日志，定位到是 Java 应用内存泄漏。你想想看，如果没有系统日志，这种问题排查起来就像大海捞针。

应用日志

应用日志是我们最常打交道的。业务逻辑对不对、接口慢不慢、数据库连不连得上，全看它。我个人习惯在关键业务节点打上 INFO 和 ERROR 日志，但千万别打太多。有一次我接手一个项目，一个请求打了 200 行日志，磁盘 IO 直接被打满。嗯，这就是典型的「日志太多，反而拖垮系统」。

安全日志

安全日志平时不起眼，出事就是大事。我记得有一次客户说系统被入侵了，我翻出 /var/log/secure，发现某个 IP 在凌晨 3 点尝试了 5000 次 SSH 登录。这就是典型的暴力破解。安全日志的价值，就在于事后能还原攻击路径。

1.3 日志系统的核心目标——我们到底要什么？

日志系统不是简单的「写文件」。它有三个核心目标：可靠、高效、可分析。

1. 可靠：日志不能丢。系统崩了，日志还在。我建议用双写策略，本地一份，远程一份。
2. 高效：写日志不能拖慢业务。异步写入、缓冲队列是标配。
3. 可分析：日志要有结构。纯文本日志很难查，JSON 格式、字段标准化才是正道。

为什么会强调「可分析」？因为很多团队的日志就是一堆无格式的字符串，查个问题要 grep 半天。我建议从一开始就定义好日志格式，比如：

{
  "timestamp": "2025-01-15T10:30:00Z",
  "level": "ERROR",
  "service": "user-service",
  "trace_id": "abc123",
  "message": "数据库连接超时",
  "stack": "java.sql.SQLTimeoutException: ..."
}

这种结构化日志，直接扔进 Elasticsearch，查起来不要太爽。

1.4 日志系统的整体架构（示意图）

下面这张图，是我常用的日志系统架构。它不复杂，但很实用。

你看，从应用、系统、安全设备产生日志，经过采集层统一收集，最后落到存储层。这个架构的好处是解耦——采集层挂了不影响业务，存储层可以随时扩容。

1.5 小结

这一章我们聊了日志的价值、分类和核心目标。说白了，日志系统就是系统的「眼睛」和「记忆」。没有它，你就是在黑暗中摸索。

下一章，我会带你深入日志采集的细节，聊聊 Filebeat 和 Logstash 到底怎么选。到时候见。