4. 日志平台组件架构：版本依赖与兼容性矩阵

日志平台并非单一软件，而是一套由多个组件构成的分布式系统。每个组件独立演进，但组件间的版本依赖关系决定了整个平台的稳定性。在容量规划与版本升级控制中，理解组件架构与版本兼容性是避免“版本漂移”的前提。

4.1 常见日志平台组件与职责

一个完整的日志平台通常包含以下五大功能域，每个域对应一类或几类组件：

4.2 组件间的版本依赖关系

组件之间并非独立运行，而是通过 API、协议、数据格式形成依赖链。以 ELK/EFK 技术栈为例，典型的依赖关系如下：

• 采集 → 传输： Agent 输出协议（如 Beats 协议、HTTP/JSON）必须与消息队列或 Logstash 的输入插件版本匹配。
• 传输 → 存储： Kafka 的 topic 分区策略与 Elasticsearch 的 bulk 写入接口版本兼容；序列化格式（如 Avro、Protobuf）的 schema 版本需一致。
• 存储 → 检索： Elasticsearch 与 Kibana 的版本必须遵循严格的 Major.Minor 对齐 规则（例如 ES 7.17.x 只能搭配 Kibana 7.17.x）。
• 检索 → 告警： 告警引擎依赖检索层提供的查询 API 版本；Grafana Alerting 与 Prometheus 或 Loki 的 API 版本需在兼容范围内。

4.3 版本兼容性矩阵

版本兼容性矩阵是容量规划与升级控制的“对照表”。它定义了组件 A 的哪个版本可以与组件 B 的哪个版本协同工作。以下以 Elastic Stack 为例，展示核心组件的兼容性矩阵（简化版）：

4.4 组件架构与版本依赖关系图

下图展示了日志平台五大组件之间的数据流与版本依赖边界。箭头方向表示数据流向，虚线框表示版本必须严格对齐的组件对。

4.5 版本兼容性检查清单

在容量规划与版本升级前，SRE 团队应逐项核对以下清单，避免版本漂移：

1. Major 版本一致性： 存储层与检索层必须处于同一 Major 版本（如 7.x 或 8.x）。
2. Minor 版本范围： 采集组件通常允许向后兼容 1–2 个 Minor 版本，但需查阅官方兼容性矩阵。
3. API 变更影响： 检查存储层升级后，检索层使用的查询 API 是否被标记为 deprecated 或移除。
4. 序列化格式： 如果使用 Avro/Protobuf，确保 schema registry 版本与生产者和消费者版本匹配。
5. 插件/扩展版本： Logstash 插件、Beats module、告警规则模板可能依赖特定组件版本。
6. 滚动升级顺序： 先升级存储层（如 Elasticsearch），再升级检索层（Kibana），最后升级采集层（Beats）。

4.6 版本漂移校准策略

当发现版本漂移（如组件版本不匹配）时，校准策略包括：

• 原地升级： 将低版本组件升级到与高版本组件对齐的版本，适用于 Minor 版本差异。
• 回滚： 如果升级导致兼容性问题，回滚到上一个已知兼容的版本组合。
• 双跑验证： 在预发环境搭建与生产一致的版本组合，运行全量流量测试后再升级生产。
• 版本锁定： 使用容器镜像标签（如 elasticsearch:7.17.15）或配置管理工具锁定组件版本，防止自动更新导致漂移。

# 示例：使用 Docker Compose 锁定版本组合
version: '3.8'
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.15
  kibana:
    image: docker.elastic.co/kibana/kibana:7.17.15
  filebeat:
    image: docker.elastic.co/beats/filebeat:7.17.15