2. 日志平台架构基础：采集层、缓冲层、存储层与展示层

在云原生环境中，日志平台通常采用“采集 → 缓冲 → 存储 → 展示”的四层架构。每一层承担不同的职责，选型也直接影响版本漂移治理的复杂度。本章将逐一拆解各层的核心组件、数据流关系以及版本一致性关注点。

2.1 四层架构总览

下图展示了日志平台的标准分层结构，数据从业务容器出发，经过采集、缓冲、存储最终到达展示界面。

2.2 采集层：Fluentd 与 Logstash

采集层负责从 Pod、节点、持久卷等来源拉取或接收日志。Fluentd 和 Logstash 是当前最主流的云原生采集器。

2.3 缓冲层：Kafka 与内存/磁盘 Buffer

缓冲层是日志平台的“蓄水池”，用于削峰填谷、解耦采集与存储。Kafka 是分布式缓冲的事实标准，而 Fluentd/Logstash 也内置了内存或磁盘 Buffer 作为轻量替代。

• Kafka 缓冲：适合大规模、多消费者场景。版本漂移主要体现为 Producer/Consumer 客户端版本与 Broker 版本不匹配。
• 内存 Buffer：Fluentd 的 buf_memory 和 Logstash 的 memory queue，延迟低但重启会丢数据。
• 磁盘 Buffer：Fluentd 的 buf_file，保证持久性，但 I/O 开销较高。

2.4 存储层：Elasticsearch 与 Loki

存储层决定日志的索引策略、查询性能和保留周期。Elasticsearch 是全文搜索型存储，Loki 是标签索引型存储，两者在版本治理上差异显著。

2.5 展示层：Kibana 与 Grafana

展示层是用户与日志数据的交互界面。Kibana 与 Elasticsearch 深度绑定，Grafana 则通过 Loki 或 Elasticsearch 数据源实现多后端统一展示。

• Kibana：版本必须与 Elasticsearch 主版本一致（例如 7.17.x 对应 ES 7.x）。跨版本连接会导致仪表板加载失败或查询接口不兼容。
• Grafana：通过数据源插件连接后端。版本漂移风险较低，但 Loki 数据源插件版本需与 Loki API 版本匹配。

2.6 版本漂移在四层中的典型表现

下表汇总了各层常见的版本漂移场景及其影响范围，帮助你在多集群治理中快速定位问题。