第1章 课程介绍与日志基础
1.1 什么是日志
日志，说白了就是系统运行过程中留下的「行为记录」。每一行日志都对应一个具体的操作——谁、在什么时候、做了什么、结果怎么样。我刚开始接触分布式系统时，觉得日志无非是调试用的“打印消息”。后来才发现，这玩意儿是系统运行状态的“黑匣子”，尤其是在异常诊断和故障恢复中，没它寸步难行。
你想想看，一个线上服务每天产生几十亿条日志。正常流量下它们安静地躺着，但一旦出现故障，这些日志就成为唯一能还原事故现场的证据。我在项目中遇到过两次线上事故，一次是因为磁盘写满导致数据丢失，另一次是内存泄漏引发的节点崩溃。每次都是通过回溯关键节点的错误日志，才定位到根因。
1.2 日志的分类
日志不是铁板一块。我把它们分成三类，每类在异常检测中的「戏份」不同。
| 分类 | 典型来源 | 关注点 | 异常检测价值 |
|---|---|---|---|
| 系统日志 | 操作系统、内核、系统服务（syslog、dmesg） | CPU/内存/磁盘/网络状态、进程崩溃、硬件告警 | 高：直接反映基础设施健康度 |
| 应用日志 | Web服务器、业务应用、中间件（Nginx、Tomcat、Kafka） | 请求处理、业务逻辑、异常堆栈、响应状态码 | 极高：大部分业务异常都体现在这里 |
| 安全日志 | 防火墙、入侵检测、认证系统 | 登录尝试、权限变更、网络连接、规则命中 | 中等：关注异常访问和攻击模式 |
我曾经接手过一个反爬虫项目，安全日志里记录了海量的请求IP和UA信息。用深度学习模型分析这些日志的访问模式，比传统规则能多检出37%的异常流量。所以别小看安全日志，它里面藏着很多「隐形」的异常特征。
1.3 日志格式
日志格式五花八门，但主流的有两种：自由文本和结构化文本。早期系统喜欢用自由文本，比如Apache的Combined Log Format。
192.168.1.1 - - [10/May/2025:14:30:15 +0800] "GET /index.html HTTP/1.1" 200 2326这种格式看着直观，但机器解析起来很头疼。正则写得好的人能一把抓，写不好就容易漏字段。我个人习惯推荐使用结构化日志，比如JSON格式。
{
"timestamp": "2025-05-10T14:30:15.123Z",
"source": "web-server-01",
"level": "ERROR",
"logger": "com.example.OrderController",
"message": "订单提交失败：用户ID=98765-订单总额超限",
"request_id": "a1b2c3d4"
}结构化日志的好处是字段清晰、类型明确，直接能被日志采集工具（如Filebeat、Fluentd）解析，存储到Elasticsearch或ClickHouse中。对于深度学习异常检测来说，结构化日志能大幅减少预处理的工作量——你不需要写一堆正则来拆字段。
1.4 日志存储与采集
日志量太大，不可能全丢到磁盘的单个文件里。生产环境一般采用分层存储策略。
- 热存储： 最近24小时内的日志，存放在Elasticsearch或内存数据库中，支持实时查询和近实时告警。
- 温存储： 24小时到7天的日志，存放在SSD集群或ClickHouse中，支持快速检索和分析。
- 冷存储： 超过7天的归档日志，压缩后存放于HDFS或对象存储（S3/MinIO），用于历史回溯和模型训练。
采集环节，我推荐使用Agent + 总线的模式。每台机器上部署一个轻量Agent（如Filebeat），监听日志文件变动，将新产生的日志行发送到消息队列（如Kafka）。下游的消费程序（Logstash、自定义Spark/Flink任务）再从Kafka拉取数据进行清洗、解析和存储。
整个日志到异常检测的流程可以用下面这张图概括——我们从日志产生、采集、传输、存储到最终做深度学习异常检测，每一步都有自己的坑和技巧。
图中展示了从日志产生到最终异常检测的完整链路。你会发现，日志存储并不是终点，它和深度学习检测之间还有一层「喂数据」的管道。这个管道怎么设计、怎么保证数据不丢不重、怎么处理字段缺失——这些都是后续章节会深入的内容。
嗯，日志基础就讲到这里。记住一句话：没有结构化的日志，就没有可靠的异常检测。