第二章 日志基础：日志的作用、类型与存储
日志这东西，说实话，刚入行那会儿我根本没当回事。总觉得程序能跑就行，日志不就是一堆没用的文本嘛。直到我第一次线上事故——数据库被人删了表，查了半天连谁干的、什么时候干的都不知道。从那以后，我才真正明白，日志不是摆设，它是你的眼睛。
本章我们就把日志的底裤扒干净：它到底能干嘛、有哪些种类、存哪儿合适。
日志的作用——不只是排错
很多人以为日志就是出了Bug才看，其实远不止。我总结了几条核心作用：
- 故障排查：出问题时，第一反应就是翻日志。没有日志，等于盲修。我在项目里遇到过Redis频繁超时，查网络、查配置都无解，最后靠慢查询日志发现是某个key太大。
- 安全审计：谁在什么时间干了什么，日志全记着。合规检查（比如PCI-DSS、等保）要求保留180天以上的审计日志，这可不是闹着玩的。
- 性能分析：通过响应时间、错误率的变化趋势，你能提前发现系统是不是在“生病”。我记得有一次发现日志里Timeout出现频率突然升高，排查后发现是数据库连接池不够了。
- 业务复盘：用户行为日志能告诉你功能使用情况。说白了，就是指导你产品下一步改什么。
核心观点：日志是系统运行的“黑匣子”，别等出事了才想起来没开启。
日志的类型——各有各的脾气
日志不是千篇一律的。不同源、不同格式、不同用途。我习惯把它们分为以下几类：
| 类型 | 典型来源 | 特点 | 常见格式 |
|---|---|---|---|
| 系统日志 | Linux syslog, Windows Event Log | 记录OS级别事件，如启动、关机、硬件错误 | 标准Syslog格式(RFC 5424) |
| 应用日志 | Web服务、微服务、自定义程序 | 记录业务逻辑、请求、异常 | JSON, 纯文本, 结构化日志 |
| 安全日志 | 防火墙、IDS/IPS、WAF | 告警、攻击事件、访问控制 | CEF (Common Event Format) |
| 审计日志 | 数据库、特权账号管理 | 谁、何时、做了什么操作 | CSV, JSON |
| 访问日志 | Nginx, Apache, CDN | 请求来源、URL、状态码、响应时间 | Combined Log Format |
你想想看，不同类型日志，采集方式和处理手段大概率不一样。比如系统日志量大但结构化差，应用日志通常需要自己定义字段。我个人习惯：能JSON就别用纯文本，方便后续解析。
小技巧：写应用日志时，加上请求ID (traceId) 和用户ID，排查问题时能串联上下游。
日志存储——别让数据“死在”磁盘里
日志怎么存？这个问题我在好几个项目里都踩过坑。刚开始直接往一个文件里写，结果磁盘爆了；后来用log rotate，又发现查历史日志太慢。所以说，存储不是简单往硬盘一扔就完事。
常见的存储方案有这几种：
- 本地文件：适合开发环境或小规模。配合logrotate按天/按大小轮转，压缩旧日志。
- 集中式日志平台：ELK (Elasticsearch, Logstash, Kibana)、Loki、Splunk。我现在项目用的是ELK，搜索引擎快，聚合分析方便。
- 云存储：比如阿里云SLS、AWS CloudWatch。按量付费，扩容省心。
- 数据库：MySQL、PostgreSQL临时存少量结构化日志。不推荐存大量日志，写和查都很慢。
这里有几个存储原则我很看重：
- 不可变性：一旦写入，不允许修改或删除。防止篡改审计证据。
- 轮转与压缩：避免磁盘写满。我曾经有个项目没做轮转，日志一天写了20GB，服务直接挂了。
- 分级保留：热数据（7天内）放SSD或高速存储，温数据（30天内）放SATA，冷数据（超过30天）放压缩归档。
避坑指南：我曾经以为日志压缩后就不用管了，结果发现压缩包放在同一个磁盘分区，导致inode用尽，新日志写不进去。后来把归档目录挂载到独立文件系统才解决。
上面这张图应该能帮你快速建立日志存储的全局观。说白了，从生成到归档，每个环节都有坑。
最后说一句：日志存储不是存了就完，你得能搜、能查、能保。 没有备份的日志，跟没有一样。