2. 现状评估与迁移就绪度分析

迁移项目失败最常见的原因，不是目标集群搭不起来，而是对源集群的真实状况估计不足。现状评估的目标，是把"我们有一个 ES 集群"这种模糊认知，转化为一组可量化、可对比、可决策的事实：集群到底有多大、索引结构是否合理、查询模式能否被目标平台承接、插件和安全配置是否构成硬约束、性能瓶颈究竟在哪里。本节围绕这六个维度，给出可落地的盘点方法与工具选择。

一、集群规模：不只看节点数

规模盘点要同时采集三类数据。第一类是容量数据：节点数、数据节点与协调节点配比、堆内存总量、磁盘总量与已用比例、分片总数。第二类是负载数据：写入 TPS、查询 QPS、平均与 P95 延迟、段合并压力。第三类是增长数据：近 30 天索引数量与数据量增速。

采集方式以 API 为主，建议一次性抓取并归档为基线快照：

GET _cluster/health?pretty
GET _cat/nodes?v&h=name,node.role,heap.percent,disk.used_percent,cpu
GET _cat/indices?v&h=index,pri,rep,docs.count,store.size&s=store.size:desc
GET _nodes/stats/jvm,fs,os?pretty

关键判断指标是分片密度：单节点承载的分片数超过 600、或单分片平均大小低于 1GB，通常意味着分片过碎，迁移后恢复慢、集群状态压力大。另一个是堆内存与数据量比：经验上每 1GB 堆内存对应 20～30GB 磁盘数据较为健康，若明显偏离，说明存在大分片或字段膨胀问题。这些数字不是迁移的阻碍，而是迁移前必须处理的"技术债清单"。

二、索引结构与查询模式

索引结构盘点要落到 mapping 层面，重点看四件事：字段总数（超过 1000 个字段的索引往往存在动态映射失控）、字段类型是否合理（大量 text 字段却只做精确匹配）、是否使用了嵌套或父子文档、以及是否依赖自定义 analyzer。可用以下方式批量导出：

GET my-index/_mapping
GET _cat/templates?v
GET _cat/aliases?v

查询模式盘点不能靠猜。开启慢查询日志是成本最低的手段：

PUT my-index/_settings
{
  "index.search.slowlog.threshold.query.warn": "2s",
  "index.search.slowlog.threshold.fetch.warn": "1s"
}

运行一个完整业务周期后，从慢日志中统计高频查询形态：是 term 精确匹配、range 范围扫描，还是 wildcard、regexp、script 这类高开销查询。同时统计聚合的使用比例——如果大量查询依赖多层嵌套聚合，迁移到向量检索或轻量搜索引擎时就需要重新设计。查询模式直接决定目标平台的选型：以日志检索为主、聚合简单，可考虑 OpenSearch 或对象存储 + 查询引擎；以全文相关性排序为主，则需保留 Lucene 系能力。

三、插件依赖：迁移的硬约束

插件是最容易被低估的风险点。执行 GET _cat/plugins?v 得到完整清单后，逐个分类：官方自带插件（如 analysis-ik 这类第三方分词器需单独确认）、安全类插件、监控类插件、以及自研插件。判断标准只有一条——目标平台是否有等价能力。例如源集群依赖自研的评分插件，迁移到托管服务后无法加载自定义 JAR，就必须把评分逻辑上移到应用层或改用脚本字段。建议把插件清单整理成"插件名 / 版本 / 用途 / 目标平台替代方案 / 风险等级"五列，作为迁移方案的必要附件。

四、安全配置与性能瓶颈

安全配置盘点包括：是否启用 TLS、认证方式（基础认证 / LDAP / SAML / OIDC）、角色与权限模型、是否使用字段级或文档级安全、API Key 与快照仓库的凭据管理方式。迁移时最容易出问题的是权限模型映射：源集群中大量基于索引通配符的角色，在目标平台可能不支持同样的通配语义，需要逐条重写。建议导出角色定义后做一次映射演练，确认每个业务账号在目标平台能拿到等价权限。

性能瓶颈定位则依赖三类信号：JVM 老年代 GC 频率与耗时（_nodes/stats/jvm）、段合并线程的积压情况、以及分片级的热点分布（_cat/thread_pool 与 _cat/shards 的写入倾斜）。如果 P95 延迟的基线本身已经接近业务容忍上限，那么迁移过程中任何一次全量重建索引都可能击穿 SLA，此时应优先安排限流与错峰窗口，而不是直接开始搬迁。

最后要强调评估的时效性：集群规模与查询模式会随业务变化，一次盘点只能代表一个时间切片。建议在正式迁移前 2～4 周再做一次增量复核，重点确认索引增速、新增字段和慢查询形态是否发生偏移，避免用过期基线做容量规划。