3. 版本兼容性与升级路径规划

在 Elastic 平台迁移与现代化改造中，版本兼容性往往是最先被低估、却最容易在实施中造成阻塞的问题。Elasticsearch、Kibana、Logstash、Beats 四个组件虽然同属 Elastic Stack，但它们的版本兼容规则并不完全一致：Elasticsearch 与 Kibana 要求严格的主次版本对齐，Logstash 与 Beats 对 Elasticsearch 的兼容范围相对宽松，而 Beats 与 Logstash 之间又存在输出插件与采集协议上的版本约束。因此，升级路径规划的第一步不是“选一个目标版本”，而是先建立一张跨版本兼容矩阵，明确哪些组合可以共存、哪些组合必须同步升级、哪些组合只能单向兼容。

一、跨版本兼容矩阵的核心规则

Elastic 官方对版本兼容性的基本约定可以归纳为三条：第一，Elasticsearch 与 Kibana 必须使用完全相同的主次版本号，例如 7.17.x 与 7.17.y 可以共存，但 7.17 与 8.6 不能直接混用；第二，Logstash 与 Beats 通常支持向“同主版本或更高主版本”的 Elasticsearch 输出，但反向兼容（高版本采集端向低版本集群写入）往往不可靠；第三，Beats 与 Logstash 之间的兼容性取决于 Beats 输出协议与 Logstash 输入插件的匹配程度，跨大版本时建议同步升级。

下面这张兼容矩阵图展示了四个组件在 7.x 与 8.x 之间的典型兼容关系，以及滚动升级与全量迁移两种路径的决策分叉点。图中用绿色表示可直接共存，橙色表示需要条件兼容，红色表示不可直接混用。

二、滚动升级的适用条件与操作要点

滚动升级的核心优势在于“不停机、不丢数据、逐步验证”。它适用于同一集群内从 7.17 升级到 8.x 的场景，前提是集群节点数不少于 3 个，且索引没有使用已废弃的映射类型或 API。实际操作中，滚动升级的顺序是：先升级 Elasticsearch 节点（每次下线一个节点，升级后重新加入集群，等待分片恢复绿色），再升级 Kibana，最后升级 Logstash 与 Beats。

在升级 Elasticsearch 之前，必须执行一次废弃 API 扫描。例如使用以下命令检查集群中是否存在将在 8.x 中移除的 API 调用：

GET /_migration/deprecations
{
  "index_settings": {
    "index.number_of_shards": "1"
  }
}

返回结果中如果出现 critical 级别的废弃项，必须先修复再升级。例如，7.x 中允许的 _type 字段在 8.x 中已完全移除，如果索引中仍存在自定义类型，升级后会导致索引无法打开。此时需要先执行 _reindex 将数据迁移到无类型索引中。

三、全量迁移的决策依据与实施框架

当出现以下任一情况时，滚动升级不再适用，应转为全量迁移：跨越大版本（如 6.x 直接到 8.x）、集群架构发生根本性变化（如从自建机房迁移到云托管）、索引数量或数据量过大导致滚动升级窗口不可接受、或者需要同时更换硬件与存储介质。全量迁移的典型做法是搭建一套全新的目标版本集群，通过快照恢复或 Logstash/Beats 双写的方式将数据迁移过去，待校验一致后再切换流量。

全量迁移的关键在于“双跑验证”。在目标集群搭建完成后，先恢复一份历史快照，确认索引映射、分词器、聚合查询结果与源集群一致；然后开启采集端双写，让新数据同时写入源集群和目标集群，运行至少一个完整的业务周期（例如 7 天），对比两边文档数量、关键字段聚合值、查询响应时间。只有校验通过后，才将 Kibana 和查询流量切换到目标集群。

四、版本兼容性检查清单

为了把兼容性判断落到可执行的层面，下面给出一份升级前检查清单，覆盖四个组件的关键验证项。该清单可直接用于升级评审会议逐项确认。

最后需要强调的是，版本兼容性不是一次性判断，而是一个持续跟踪的过程。Elastic 每个主版本的生命周期通常为 18 至 24 个月，在规划升级路径时，应同时考虑目标版本的维护窗口和下一个大版本的发布时间，避免刚完成升级就面临再次升级的压力。建议将版本规划纳入年度运维计划，提前 6 个月启动兼容性评估，留出充足的测试与回滚准备时间。