1. 课程导论：云原生日志平台的重要性、整体架构概览、从采集到存储的端到端流程
1.1 为什么云原生环境需要专用日志平台？
在传统单体架构中，日志通常以文件形式保存在服务器本地，运维人员通过 SSH 登录或集中式日志工具（如 ELK Stack）即可完成排查。然而，云原生环境带来了三个根本性变化：
- 实例动态性：Pod 随时可能被调度、扩缩或驱逐，日志无法持久化在容器内。
- 数据爆炸增长：微服务数量可达数百个，单日日志量从 GB 级跃升至 TB 甚至 PB 级。
- 排障复杂度剧增：一次请求可能跨越 10+ 服务，需要关联 Trace ID 与日志上下文。
核心结论：云原生日志平台不再是可选项，而是保障可观测性（Observability）的必备基础设施。它必须解决日志的采集可靠性、传输低延迟、存储低成本与查询高性能四大挑战。
1.2 整体架构概览：五层组件拓扑
一个生产级的云原生日志平台通常由以下五层构成，每一层都有明确的职责与代表性组件：
| 层级 | 职责 | 代表组件 | 关键指标 |
|---|---|---|---|
| 采集层 | 从容器 stdout/stderr 或日志文件读取日志 | Fluent Bit, Filebeat, Vector | 采集延迟 < 1s，资源占用 < 5% CPU |
| 传输层 | 缓冲、压缩、路由日志到下游 | Kafka, NATS, RabbitMQ | 吞吐量 > 100MB/s，数据不丢失 |
| 处理层 | 解析、过滤、富化、聚合日志 | Logstash, Fluentd, Vector | 处理延迟 < 500ms，支持多行合并 |
| 存储层 | 持久化日志并提供高效检索 | Elasticsearch, Loki, ClickHouse | 写入 TPS > 10万/s，压缩比 > 5:1 |
| 查询与展示层 | 可视化、告警、日志上下文关联 | Kibana, Grafana, OpenSearch Dashboards | 查询 P99 < 2s，支持 Lucene/PromQL |
架构设计原则：每一层都应具备水平扩展能力，避免单点瓶颈。例如，采集层通过 DaemonSet 部署，传输层通过 Kafka 分区实现并行，存储层通过分片（Shard）分散写入压力。
1.3 端到端流程：从采集到存储的完整链路
下图展示了日志数据从产生到可查询的完整流动路径。每个阶段都涉及特定的组件与配置，后续章节将逐一深入。
1.4 关键流程步骤清单
为了帮助您快速建立全局认知，以下将端到端流程拆解为 7 个核心步骤：
- 日志产生：应用容器将日志写入 stdout/stderr，或挂载卷中的日志文件。
- 日志采集：采集代理（如 Fluent Bit）通过 tail 或 CRI 接口读取日志，添加元数据（Pod Name、Namespace、Container Name）。
- 日志缓冲：采集代理将日志发送到消息队列（如 Kafka Topic），实现削峰填谷。
- 日志消费：处理层从消息队列拉取日志，进行解析、过滤、多行合并。
- 日志写入：处理层将格式化后的日志批量写入存储引擎（如 Elasticsearch 的 Bulk API）。
- 日志索引：存储引擎对日志字段建立倒排索引，支持全文检索与聚合分析。
- 日志查询：用户通过 Kibana 或 Grafana 输入查询语句，系统返回匹配结果并可视化展示。
常见误区：很多初学者跳过消息队列，直接将采集代理写入存储引擎。这在日志量 < 10GB/天时勉强可行，但一旦流量突增，存储引擎会因写入压力过大而拒绝连接，导致日志丢失。生产环境务必引入缓冲层。