2. 云原生日志平台基础架构：采集层、传输层、存储层、查询层的组件与职责
云原生日志平台采用分层解耦架构，将日志生命周期划分为采集、传输、存储、查询四个核心层次。每一层独立演进、水平扩展，并通过标准接口（HTTP/gRPC/消息队列）进行数据交换。理解各层的组件与职责，是进行版本漂移校准与标签清单化验收的前提。
架构原则：日志平台遵循“写分离、读分离、存算分离”的设计理念。采集层只负责发现与发送，传输层负责缓冲与路由，存储层负责持久化与压缩，查询层负责索引与检索。任何一层的组件版本漂移，都会直接影响日志的完整性、时效性与可观测性。
2.1 四层架构总览
下图展示了云原生日志平台的四层基础架构及各层核心组件之间的数据流向关系。
2.2 采集层（Agent / Sidecar）
采集层是日志平台的“触角”，部署在每一个 Kubernetes 节点或 Pod 中，负责从各种数据源发现、读取、解析并发送日志数据。在云原生环境中，采集层通常以 DaemonSet（节点级）或 Sidecar（Pod 级）模式运行。
| 组件 | 部署模式 | 核心职责 | 典型版本关注点 |
|---|---|---|---|
| Fluent Bit | DaemonSet / Sidecar | 高性能日志采集、解析、过滤、转发；支持 tail/input/parser/filter/output 插件链 | 插件兼容性、内存限制、多行日志处理 |
| Filebeat | DaemonSet | 轻量级日志采集，支持多行合并、模块化配置、Kubernetes 元数据自动关联 | Harvester 版本、Kubernetes 元数据字段映射 |
| Vector | DaemonSet / Sidecar | 统一可观测数据管道，支持日志、指标、Trace 采集；VRL 语言进行数据转换 | VRL 语法变更、组件（source/transform/sink）版本 |
| Logstash | Sidecar / 独立部署 | 丰富的插件生态，支持复杂过滤与数据转换；常用于非实时场景 | JVM 版本、插件版本、Pipeline 配置兼容性 |
| OpenTelemetry Collector | DaemonSet / Sidecar | 统一采集日志、指标、Trace；支持 OTLP 协议，原生云原生可观测性 | OTLP 版本、Receiver/Processor/Exporter 版本 |
版本漂移校准要点：采集层组件版本漂移通常表现为：日志字段格式变化（如 JSON key 重命名）、多行日志合并规则失效、Kubernetes 元数据标签丢失、内存泄漏导致 OOM。验收时需逐组件核对
version、plugin_version、config_hash。
2.3 传输层（消息队列 / 缓冲）
传输层位于采集层与存储层之间，承担日志数据的缓冲、削峰填谷、解耦和路由职责。在云原生架构中，传输层通常采用分布式消息队列，确保日志数据在采集层故障或存储层抖动时不丢失。
- Apache Kafka：业界标准日志传输中间件，支持高吞吐、持久化、分区消费。版本漂移风险集中在
protocol version、message format、topic 配置的兼容性。 - Apache Pulsar：支持分层存储与多租户，适合大规模日志场景。版本漂移关注
BookKeeper版本、Broker配置兼容性。 - RabbitMQ / Redis Streams / NATS：适用于中小规模或低延迟场景，版本漂移风险较低，但需关注
exchange、queue、stream的持久化策略变更。
| 传输组件 | 数据持久化 | 消费模式 | 版本漂移典型表现 |
|---|---|---|---|
| Kafka | 磁盘持久化，可配置保留策略 | Pull 模式，分区顺序消费 | Producer/Consumer 协议不兼容、Leader 选举异常 |
| Pulsar | BookKeeper 分层存储 | Pull 模式，支持独占/共享/灾备订阅 | BookKeeper 版本与 Broker 版本不匹配 |
| RabbitMQ | 内存/磁盘混合 | Push 模式，Exchange 路由 | Erlang 版本、Queue 镜像策略变更 |
传输层验收红线：传输层版本漂移可能导致日志数据丢失或重复消费。验收时必须确认 Producer 端（采集层）与 Broker 端的
protocol version 一致，Consumer 端（存储层）的消费组偏移量（offset）无异常跳跃。
2.4 存储层（索引 / 持久化）
存储层负责将传输层送达的日志数据进行索引构建、持久化存储、压缩与生命周期管理。云原生日志存储层通常采用分布式搜索引擎或列式存储引擎，支持水平扩展与冷热分层。
| 存储组件 | 索引模型 | 存储后端 | 版本漂移风险点 |
|---|---|---|---|
| Elasticsearch / OpenSearch | 倒排索引（分片 + 副本） | 本地磁盘 / NAS | Lucene 版本、Mapping 兼容性、集群升级滚动策略 |
| Loki | 日志流压缩 + 标签索引 | 对象存储（S3/MinIO/GCS） | Ingester/Querier 版本、TSDB 索引格式变更 |
| ClickHouse | 列式存储 + 跳数索引 | 本地磁盘 / 对象存储 | MergeTree 引擎版本、物化视图 SQL 兼容性 |
存储层验收要点：版本漂移在存储层通常表现为：索引 Mapping 冲突导致写入拒绝、查询语法不兼容、冷热分层策略失效、分片分配异常。验收时需核对
cluster_version、index_template、shard_allocation 配置一致性。
2.5 查询层（API / 可视化 / 告警）
查询层是日志平台的“窗口”，为用户提供日志检索、分析、可视化与告警能力。查询层通常无状态，通过 API 网关或负载均衡器与存储层交互，支持多租户隔离与权限控制。
- Kibana / OpenSearch Dashboards：与 Elasticsearch/OpenSearch 深度集成，提供 Lucene 查询语法、可视化仪表盘、告警规则管理。版本漂移风险集中在
saved object格式、visualization配置兼容性。 - Grafana：统一可观测性仪表盘，支持 Loki、Elasticsearch、ClickHouse 等多种数据源。版本漂移关注
datasource插件版本、dashboard JSON模型变更。 - 自定义查询 API：基于 HTTP/gRPC 的日志查询接口，通常封装在 BFF（Backend For Frontend）层。版本漂移风险集中在
API 路由、请求/响应模型、认证鉴权的兼容性。
| 查询组件 | 数据源支持 | 查询语法 | 版本漂移典型表现 |
|---|---|---|---|
| Kibana | Elasticsearch | Lucene / KQL | Saved Object 导入失败、可视化图表渲染异常 |
| OpenSearch Dashboards | OpenSearch | Lucene / DQL | 索引模式（Index Pattern）兼容性、告警规则迁移失败 |
| Grafana | Loki / ES / ClickHouse / Prometheus | LogQL / PromQL / SQL | 数据源插件版本不匹配、Dashboard 变量失效 |
查询层验收建议：在版本漂移校准交付前，建议构建一组验收查询用例，覆盖：全文检索、字段过滤、聚合统计、时间范围查询、告警规则触发。逐用例验证查询结果与预期一致，确保查询层版本变更不影响用户侧体验。
2.6 四层架构的版本依赖关系
各层组件之间存在严格的版本依赖关系，任何一层的版本漂移都可能引发连锁反应。下表总结了层间版本依赖的关键约束：
| 依赖方向 | 依赖关系 | 版本约束示例 |
|---|---|---|
| 采集层 → 传输层 | Producer 协议版本与 Broker 协议版本兼容 | Fluent Bit Kafka Output 需匹配 Kafka Broker 2.x/3.x |
| 传输层 → 存储层 | Consumer 协议版本与 Broker 协议版本兼容 | Logstash Kafka Input 需匹配 Kafka Consumer 版本 |
| 存储层 → 查询层 | 查询 API 版本与存储引擎版本兼容 | Kibana 7.x 无法连接 Elasticsearch 8.x（需升级） |
| 采集层 → 存储层（直连） | 数据格式（JSON/Protobuf）与存储层索引 Mapping 兼容 | Loki 的日志标签键值对格式需与采集层一致 |
版本漂移校准核心：在交付验收前，必须建立版本依赖矩阵，明确每一层组件的兼容版本范围。任何组件的版本变更，都需在矩阵中标注影响范围，并触发对应层的回归测试。这是日志标签清单化验收的基础数据之一。