一、日志管理概述
做运维这些年，我最大的感触就是：日志这东西，平时没人当回事，一出事就全盯着它。你想想看，系统崩了、攻击进来了、订单丢了，第一件事肯定是翻日志。但问题是——日志真能帮你找到真相吗？很多团队的日志管理是一团糟，要么没记，要么记了找不着，要么找着了看不懂。
所以，在我们正式讲Syslog和Filebeat之前，得先把日志管理这件事本身说清楚。说白了，日志管理不是简单的“记流水账”，它有一套自己的方法论和架构。这一章，我就带你从零开始，捋清日志管理的全貌。
1.1 为什么需要日志管理？
我刚入行那会儿，有个项目上线后经常半夜报警。每次都是手动登录服务器，用 tail -f 看 application.log，看完说“哦，数据库超时了”，然后重启——第二天继续。重复了整整两周。后来一查，是连接池参数配错了，但日志已经被滚动了，早查不到原始记录了。
从那以后，我养成了个习惯：任何系统上线前，先问三个问题——
- 日志写在哪？（本地文件、标准输出、远程？）
- 能保存多久？（磁盘满了会怎样？）
- 出事怎么查？（是 ssh 上去 grep，还是有统一检索？）
核心观点：日志管理的目标不是“记录”，而是“可检索、可回溯、可分析”。技术上实现这三个目标，才算真正把日志管好了。
1.2 日志的类型与分级
日志不是只有一种。不同来源、不同重要程度，处理方式完全不同。我习惯把它们分成三大类：
| 类型 | 典型来源 | 特点 |
|---|---|---|
| 系统日志 | OS kernel、syslogd、systemd-journal | 级别固定、格式相对统一 |
| 应用日志 | Java/Python/Go 应用、Web 服务器 | 格式多样、字段自定义、量极大 |
| 安全日志 | firewall、IDS/IPS、auditd | 敏感、需要合规留存、实时性高 |
而说到分级，Syslog 协议里就定义了 8 个级别（从 0 到 7），这个我们后面会细讲。这里先记住一个原则：日志级别越低（数字越小），越需要被关注和持久化。比如 Level 0（Emergency）必须告警，Level 7（Debug）通常只在开发环境保留。
个人建议：生产环境至少保留 WARNING 及以上级别的日志。DEBUG 日志量太大了，不是 SSD 的话磁盘 I/O 首先扛不住。我有个项目曾经因为开了 DEBUG 日志，导致磁盘 IO 打满，应用响应时间从 5ms 飙到 500ms……教训挺深刻的。
1.3 日志管理的核心挑战
日志管理看起来简单，实际坑很多。我们来看几个常见的：
- 量太大——业务高峰期，每秒成千上万条日志，磁盘写不过来了。
- 格式不统一——有的用 JSON，有的用纯文本，有的混着用正则都写不对。
- 采集丢数据——网络抖动、采集器挂了，日志丢了几分钟没人知道。
- 存储成本高——全量保留一年？那存储预算得翻好几倍。
- 检索慢——没有索引，grep 一个关键词要扫几百 GB 文件。
你想想看，上面五个问题遇到一个就够头疼了，现实中往往是五连击。这时候，光靠运维手动处理已经不可能了，必须引入专门的日志采集和存储方案。
1.4 日志存储方案演进
我记得最早做日志分析的时候，方案特别原始：每天凌晨跑个 cron 脚本，把昨天的日志 rsync 到一台大磁盘服务器上，然后用 grep 和 awk 分析。这种模式现在叫“本地文件 + 定时搬运”，最大的问题就是——你要查的东西，可能已经在搬运过程中被覆盖了。
再后来，有了集中式日志系统，比如 ELK（Elasticsearch, Logstash, Kibana）。Logstash 负责采集和解析，Elasticsearch 负责存储和检索，Kibana 负责可视化。这个方案到今天依然是主流，但它有个痛点：Logstash 太重了，CPU 和内存消耗巨大。
于是 Filebeat 出现了。它是个轻量级的日志采集器，基于 Go 语言开发，占用资源极小。Filebeat 负责“运”，Logstash 只负责“解析”，各司其职。这也正是本课程要重点讲的内容。
而 Syslog，作为一种历史悠久的日志标准（RFC 5424），在今天依然活跃在网络设备、Linux 系统日志上。它最大的优势是标准化——只要是支持 Syslog 的设备，日志格式和传输协议都是确定的。但它的存储和分析能力很弱，所以需要把 Syslog 日志“喂”给 Elasticsearch 这样的后端。
注意：Syslog 协议默认使用 UDP 514 端口，UDP 是无连接的，会丢包。如果你要保证日志不丢失，建议改用 TCP 或 RELP（可靠的事件日志协议）。我曾经处理过一个 case：因为网络拥塞，UDP 丢包率高达 15%，导致安全审计日志不完整，差点没通过合规检查。
1.5 本章核心知识图谱
为了让你对整个日志管理体系有个直观印象，我画了一张图。它展示了从日志产生、采集、传输、存储到分析的全链路，并标出了 Syslog 和 Filebeat 在其中的位置。
从图中你可以看到：日志产生后，通过 Syslog 或 Filebeat 采集，经由 TCP/UDP 传输，可以选择性地经过消息队列缓冲，最终落入 Elasticsearch 存储索引，再通过 Kibana 展示。Syslog 侧重于标准化协议，Filebeat 侧重于轻量采集和可靠传输——两者各有擅长，在实际项目中经常协同工作。
1.6 小结
这一章我们厘清了日志管理的几个基本概念：
- 日志管理不是为了记录而记录，是为了可回溯、可分析。
- 日志按来源和级别分类，不同类别有不同的处理策略。
- 常见的挑战：量大、格式乱、丢数据、成本高、检索慢。
- 方案演进从本地搬运到集中式，Syslog 和 Filebeat 是两种主流的采集方式。