第一章：日志采集概述
1.1 为什么需要日志采集
先说一个我亲身经历的事儿。几年前我在一家电商平台负责后端服务，双十一那天凌晨流量突然暴涨，系统响应慢得像蜗牛。运维群里炸了锅，但谁都不知道问题出在哪。查了十多分钟才发现，数据库连接池被打满了——可日志文件散落在几十台服务器上，根本没法快速定位。
那会儿我就明白了一个道理：没有日志采集，系统就相当于在黑暗中裸奔。日志是系统的“黑匣子”，但不采集、不集中，就是一堆废纸。
具体来说，日志采集解决三个核心痛点：
- 故障定位：系统出问题后，你得知道哪里挂了、为什么挂。分散的日志等于没有日志。
- 行为审计：谁在什么时候干了什么？安全合规要求你必须留痕。
- 数据分析：用户点击路径、接口响应趋势、资源使用率——这些都能从日志里挖出来。
避坑指南：我曾经遇见过一个团队，被安全审计追着要半年内的操作日志，结果发现日志因为没采集被自动清理了。那次事故之后，我定了一条铁律——日志必须先采后存，哪怕暂时用不上也得收上来。
1.2 典型应用场景
你想想看，日志采集的场景远比你想的广。除了常见的“查Bug”，还有这些：
| 场景 | 日志来源 | 典型需求 |
|---|---|---|
| 线上故障排查 | 应用日志、客户端日志 | 快速过滤错误堆栈，定位根因 |
| 监控告警 | 服务器日志、中间件日志 | 实时分析，指标异常时触发告警 |
| 安全审计 | 访问日志、操作日志 | 保留原始记录，支持事后追溯 |
| 业务分析 | 用户行为日志 | 统计UV、PV、转化率等指标 |
| 成本优化 | 资源使用日志 | 分析哪些服务是资源浪费大户 |
我建议你在实际项目里，至少先搞清楚两类场景：实时场景和离线场景。实时场景要求低延迟，比如告警；离线场景要求高吞吐，比如月报统计。架构上它们差别很大。
个人经验：做实时采集时，别把“秒级延迟”当作默认要求。我见过一个项目硬扛每秒10万条日志的实时分析，结果CPU烧到90%。后来改成“准实时+离线双通道”，延迟从1秒放宽到10秒，成本降了60%。你得想清楚业务到底需要多“实时”。
1.3 课程整体规划
这门课一共30章，我会带你走完日志采集的完整链路。来，先看一张整体结构图：
这张图就是课程的整体骨架。我发现很多人学日志采集时容易陷入细节，比如纠结某个采集Agent的配置参数。其实你得先看全貌，知道每个层级的职责边界。
课程内容按六个层次展开：
- 核心基础（第1~5章）：日志格式、采集模型、协议设计。这部分我建议你打好底子，后面遇到奇怪的问题都能回到基础里找答案。
- 采集层（第6~10章）：Agent开发、SDK封装、多语言兼容。我在这里会分享一个Go Agent的完整实现。
- 传输层（第11~15章）：Kafka集群调优、背压处理、可靠传输。这部分是架构里的“高速公路”。
- 存储层（第16~20章）：ES索引设计、ClickHouse写入优化、冷热分离。说白了就是解决“存得下、查得快”。
- 治理层（第21~25章）：采样策略、脱敏规则、压缩编码、生命周期管理。这里有很多避坑经验。
- 应用层（第26~28章）：监控大盘、告警配置、审计查询。
最后两章（29、30章）是完整实战项目：从零搭建一个电商平台的全链路日志采集系统。代码我会放在课程仓库里，你跟着做一遍就能跑起来。
特别注意：前5章看起来偏理论，但千万别跳过。我记得有个学员直接跳到了存储层调ES索引，结果因为日志时间字段格式不一致，导致查询慢了一个数量级。这种坑追根溯源，就是基础定义没对齐。
好了，第一章就聊这么多。日志采集的核心你记住了吗？不是采不采的问题，是怎么采、怎么传、怎么存、怎么用。接下来咱们就从日志标准开始，一步步把架构搭起来。