第一章 日志概述与重要性

1.1 日志到底是什么

日志，说白了就是系统、应用、设备按时间顺序记录的事件快照。

我刚入行那会儿，觉得日志就是程序打印出来的一些文本，没什么了不起。直到有一次线上事故，我花了整整两天才定位到问题——一台服务器内存泄漏，但当时日志里只有一行模糊的 OutOfMemoryError。嗯，从那一刻起，我再也不敢小看日志了。

日志不只是“故障记录”，它是一整套数据。按来源分，常见的日志类型有这些：

类型	典型来源	内容示例
系统日志	操作系统内核、systemd、syslog	内核错误、磁盘IO、网络状态
应用日志	Web服务器、数据库、业务代码	HTTP 500、SQL慢查询、业务异常
安全日志	防火墙、入侵检测、sudo 审计	登录失败、端口扫描、权限变更
事件日志	Windows Event Log、SNMP Trap	服务启动/停止、硬件告警
性能日志	Prometheus、Zabbix、JMX	CPU使用率、内存占用、响应时间

你想想看，没有日志，我们就像在黑暗里修机器。日志就是那一盏手电筒。

1.2 日志在系统运维中的作用

日志的作用我能列出一串，但挑几个最关键的说说。

• 故障排查——这是最直接的用途。我遇到过几次线上故障，业务挂了但监控显示一切正常，最后翻应用日志才发现是某个第三方接口返回了非标准响应。没有日志，你连对手在哪都找不到。
• 性能分析——慢查询日志、GC日志、请求耗时日志，能帮你精确定位瓶颈。我记得帮一家电商公司优化过系统，就是因为每次大促时GC日志显示Full GC间隔越来越短，最后调优JVM参数后才稳住。
• 安全审计——谁在什么时候对哪个资源做了什么操作？日志说了算。合规部门会定期要求导出审计日志，不能造假，也不能缺失。
• 容量规划——通过长期日志量增长趋势，可以预估磁盘、CPU、带宽的需求。我习惯每季度拉一次日志量曲线，提前扩容，省了多少次半夜被叫醒的麻烦。
• 问题复盘——事后分析根因，日志是唯一的客观证据。没有日志，复盘会变成猜谜会。

日志还有一个容易被忽视的作用——监控告警的可靠性。很多告警信号实际上来自日志模式的匹配（比如ERROR级别出现的频率）。我曾经维护过一个业务，就是因为日志级别设错了，线上报错全都是debug，差点让告警机制失效。你想想看，那得多危险。

1.3 日志管理不善的后果

说完了好处，必须泼一盆冷水。日志管不好，后果比你想的严重。

• 磁盘写满，服务瘫痪——这是最常见的。我记得有一次，一个Java应用没配日志轮转，结果日志文件涨到50GB，直接把磁盘撑爆了，数据库连不上。半夜爬起来清日志的滋味，真不好受。
• 关键线索被覆盖——如果日志滚动得太快或归档策略太差，两周前的日志自动删了，出了事故根本查不到根因。我见过有团队为了省空间，只保留一天的日志……结果出事时两眼一抹黑。
• 性能拖垮系统——日志输出太频繁（比如每个请求打5行日志），在高并发下会让应用响应时间陡增。我曾经调过一个接口，去掉不必要的日志后，吞吐量提升了30%。
• 合规罚款——金融、医疗行业对日志保留有硬性要求（比如至少保留6个月）。如果审计时发现日志缺失，轻则罚款，重则吊销资质。
• 安全事件无法追溯——黑客入侵后通常会清除日志。如果你连备份都没有，根本不知道对方从哪里进来的。那些事后分析报告会变成一张白纸。

所以，日志管理不是什么锦上添花的事，它是运维的底线。

你看这张图就明白了：日志从产生到采集、存储、分析、归档，每个环节都环环相扣。任何一个环节出了问题，最后倒霉的都是我们运维。