第1章 日志基础概念与重要性
说起日志，你第一个想到的是什么？
我刚入行那会儿，觉得日志就是程序打印出来的调试信息。出问题了看一眼，没问题就扔一边。后来有一次线上故障，系统半夜挂了，没有任何告警，登录服务器一看，日志文件早就写爆了磁盘，最后一条记录停在了三小时前。那次之后我才真正意识到——日志不是配角，它是系统的黑匣子。
说白了，日志就是系统运行过程中产生的、带有时间戳的状态记录。它告诉你系统在什么时间、什么地方、发生了什么。没有日志，运维就像蒙着眼睛开车。
1.1 日志到底是什么
日志是系统、应用、设备在运行时输出的结构化或半结构化文本记录。每一条日志通常包含时间戳、事件级别、来源模块、描述信息等要素。
我个人习惯把日志分成两类：程序日志和审计日志。程序日志用来排查故障，审计日志用来追溯操作。两者侧重点不同，但缺一不可。
1.2 日志的核心作用
日志到底能干什么？我总结了四个层面：
- 故障排查：系统出问题了，第一件事就是翻日志。错误堆栈、异常时间点、上下文状态，都在里面。
- 性能分析：通过日志里的响应时间、QPS、错误率，你能快速定位瓶颈。我在项目中遇到过几次接口慢查，最后都是靠日志里的耗时分布找到的。
- 安全审计：谁在什么时间做了什么操作，日志一查便知。这是事后追溯的唯一依据。
- 合规满足：很多行业法规明确要求保留操作日志。没有日志，审计直接挂掉。
你想想看，一个没有日志的系统，出了问题你只能靠猜。猜错的成本，往往比写日志高得多。
1.3 日志的常见类型
日志的类型很多，但主流的有这四种：
| 类型 | 来源 | 典型内容 | 保留周期 |
|---|---|---|---|
| 系统日志 | 操作系统、内核 | 启动记录、硬件状态、内核错误 | 30–90 天 |
| 应用日志 | 业务程序、中间件 | 请求参数、异常堆栈、业务流转 | 15–30 天 |
| 安全日志 | 防火墙、IDS/IPS | 登录尝试、越权访问、攻击告警 | 6–12 个月 |
| 审计日志 | 数据库、堡垒机 | 操作命令、数据变更、权限变更 | 1–7 年 |
嗯，这里要注意：审计日志的保留周期最长，因为它直接关系到合规。我曾经因为审计日志只保留了3个月，被合规检查打了个严重不符合项——从那以后再也不敢轻视保留策略了。
1.4 日志的主要来源
日志来自你系统里的每一个组件：
- 服务器：Linux 的 syslog/rsyslog，Windows 的 Event Log。
- 网络设备：交换机、路由器的 syslog 输出。
- 数据库：MySQL 的 general log、slow log，PG 的 csvlog。
- 应用容器：Docker 的 stdout/stderr，K8s 的 Pod 日志。
- 云服务：AWS CloudTrail、阿里云 ActionTrail。
来源多了就面临一个问题——日志分散。所以日志需要集中采集，这就是后面章节要讲的输出控制。
1.5 合规要求
合规不是IT部门自己定的，是外部法规压下来的。我整理了几个最常见的：
| 法规/标准 | 适用范围 | 核心要求 |
|---|---|---|
| GDPR | 涉及欧盟公民数据的企业 | 操作可追溯，日志保留至多 12 个月 |
| SOX | 美国上市公司 | 财务相关操作日志保留 7 年 |
| PCI DSS | 处理银行卡信息的企业 | 日志至少保留 1 年，不可篡改 |
| 等级保护 2.0 | 中国关键信息基础设施 | 日志记录完整，留存 6 个月以上 |
合规检查时，日志就是你的证据链。缺一条，可能就是一个不符合项。
1.6 日志管理的基本原则
聊完概念，我分享一下日志管理的几个铁律：
- 集中管理：所有日志统一采集到中心平台，方便检索和存档。
- 轮转策略：按大小或时间切分日志，避免单文件过大。我习惯按天轮转 + 100MB 上限。
- 权限控制：日志不能谁都能删，谁都能改。审计日志尤其要只追加。
- 备份与归档：日志要异地备份，防止单点故障导致证据丢失。
- 可读性：日志格式要结构化，JSON 或 key=value 都行，别写一堆无规律字符串。
这些原则看起来简单，但每一条背后都有血泪教训。我见过太多团队只注重写代码，不重视日志，出了事才后悔。
本章核心一句话：日志是系统的黑匣子，是运维的最后一根救命稻草。不要等问题发生了才想起它。
这张图把本章的知识骨架串起来了。从上到下，先理解日志是什么，再掌握它的作用、类型、来源和合规要求。后面的所有实操内容，都是在这个框架上长出来的。