📚 课程目录第3章云原生日志平台架构概览

3. 云原生日志平台架构概览：主流方案对比与核心链路

在构建云原生日志平台时，选择合适的技术栈是保障可观测性与成本效益的关键。本章将对比 Loki、Elasticsearch、ClickHouse 三大主流方案，并深入解析日志从采集、存储到查询的完整链路。

不同方案在索引机制、存储成本、查询性能与生态集成上存在显著差异。下表从核心维度进行对比：

维度	Loki (Grafana Labs)	Elasticsearch (ELK)	ClickHouse (列式存储)
存储模型	仅索引元数据（标签），日志内容以块存储	全文倒排索引 + 文档存储	列式压缩存储，按列组织数据
查询语言	LogQL（类 PromQL）	Query DSL (JSON) / ES\|QL	SQL 扩展
存储成本	极低（无全文索引）	高（索引膨胀 1.5-3x）	低（列压缩 5-10x）
查询性能	标签过滤快，全文搜索慢	全文搜索极快，聚合较慢	聚合分析极快，全文搜索需额外配置
运维复杂度	低（无状态 + 对象存储）	高（集群调优、分片管理）	中（需优化分区键与排序键）
典型场景	Kubernetes 日志、云原生环境	全文检索、安全分析、SIEM	大规模日志分析、指标聚合、Trace 关联

选型建议： 如果你的团队已深度使用 Grafana 且关注成本，Loki 是首选；如果需要强大的全文检索能力（如关键字搜索），Elasticsearch 仍不可替代；若日志规模超 10TB/天且需要实时聚合分析，ClickHouse 在性价比上优势明显。

一个完整的云原生日志平台通常包含三个核心阶段：采集层 → 缓冲/传输层 → 存储与查询层。下图展示了以 Loki 为例的典型架构：

数据源：Kubernetes 容器标准输出（stdout/stderr）、应用日志文件、系统日志。
采集器选型：
- Promtail：Loki 原生采集器，与 Kubernetes API 深度集成，自动发现 Pod 并添加标签。
- Fluent Bit：高性能、低资源消耗，支持多输出端（Loki、Elasticsearch、Kafka）。
- Vector：Rust 编写，支持复杂的数据转换与路由。
关键操作：日志解析（JSON、正则）、多行合并（如堆栈跟踪）、元数据注入（namespace、pod、container）。

作用：应对采集峰值，防止存储后端被突发流量打满；实现采集与存储的解耦。
常用组件：
- Apache Kafka：高吞吐、持久化，适合大规模生产环境。
- gRPC 流：Loki 原生支持，适合中小规模或低延迟场景。
注意事项：合理设置分区数与副本数，避免数据倾斜；监控消费者 lag。

存储模型：
- Loki：日志块（chunk）存储在对象存储（S3/MinIO/GCS），标签索引存储在 BoltDB 或 TSDB。
- Elasticsearch：分片（shard）存储在本地磁盘或云存储，倒排索引常驻内存。
- ClickHouse：数据按列压缩存储，分区与排序键决定查询性能。
查询路径：
1. 用户通过 Grafana 或 API 提交查询（LogQL/DSL/SQL）。
2. 查询器（Querier）根据标签/索引定位相关数据块。
3. 从存储后端读取数据块，执行过滤、聚合、排序。
4. 返回结果集到前端展示。

  性能关键点： 在 Loki 中，查询速度主要取决于标签基数与时间范围。建议将标签数量控制在 5-8 个以内，避免高基数标签（如 request_id）导致索引膨胀。ClickHouse 则需合理设计排序键（ORDER BY），将常用过滤字段放在前面。

以下决策树可帮助团队根据自身需求快速定位合适方案：

注意： 决策树仅提供通用指导。实际选型还需考虑团队技术栈、运维能力、已有基础设施（如是否已部署 Kafka、对象存储）以及未来扩展性。建议在非生产环境进行 POC 验证。