Amazon Elasticsearch Service升级OpenSearch后性能变慢求排查方案

1. 优先排查Master节点连通性告警（最高优先级） #

• 确认集群实例规格是否匹配升级后的OpenSearch最低要求：AWS托管的OpenSearch升级后如果原实例是t2/t3小规格，新版本对计算、网络资源要求提升15%~30%，之前刚好够用的规格会出现间歇性连通失败
• 检查Master节点的网络ACL、安全组是否存在未知的规则变更：升级过程中会自动调整部分控制面访问规则，偶发规则残留导致Dashboards到Master的控制面请求丢包，可直接重置安全组为OpenSearch默认预置规则验证
• 执行GET _cat/master?v、GET _cluster/health?pretty命令，确认集群是否存在无主、选举抖动的情况，若10分钟内Master节点切换超过1次，直接临时升配Master节点规格验证

2. OpenSearch Dashboards服务专项排查 #

• 检查Dashboards的实例数是否和集群节点数匹配：升级后如果Dashboards仍只有1个单实例，且绑定了多个数据节点，会出现请求分发瓶颈，可在控制台调整Dashboards实例数为2~3个验证
• 清理Dashboards的内置系统索引：升级过程中旧版Kibana的系统索引（.kibana*系列）残留大量无效配置，执行以下操作清理：
  1. 先备份现有Dashboards配置：POST _snapshot/<你的快照仓库名>/snapshot_dashboards_backup?wait_for_completion=true，索引指定为.kibana*
  2. 删除旧的.kibana索引：DELETE .kibana_*
  3. 重启Dashboards服务，系统会自动重建适配当前版本的系统索引
• 关闭Dashboards不必要的内置插件：升级后默认开启的安全审计、报表定时任务、异常检测插件会占用大量前端请求资源，可在控制台Dashboards配置中关闭opensearch_security.audit.enabled、reports.enabled等非必要配置项

3. 集群性能残留问题排查 #

• 检查JVM堆内存配置是否合理：小集群的JVM堆内存建议设置为物理内存的50%，且不超过32GB，升级过程中如果堆内存配置被重置为默认值（过小）会导致频繁GC，执行GET _nodes/jvm?pretty确认每个节点的堆内存占比是否稳定
• 检查分片配置是否合理：总数据仅15~20M的情况下，单个索引的分片数不要超过1，副本数不要超过1，过多的分片会导致元数据同步开销陡增，执行GET _cat/shards?v查看是否存在大量小分片，合并多余分片
• 检查是否存在旧版兼容配置残留：升级后如果仍保留elasticsearch相关的旧兼容配置，会导致集群反复执行兼容校验逻辑，占用控制面资源，执行GET _cluster/settings?include_defaults=true排查所有包含elasticsearch.前缀的配置项，逐一删除

4. 快速验证操作 #

如果需要快速定位问题，可先执行以下操作验证效果：

• 临时将集群所有节点升配1个规格，Dashboards实例数调整为2个，观察15分钟内是否有性能提升
• 重置集群安全配置为默认状态，关闭自定义的细粒度权限控制规则，验证是否是权限校验逻辑导致的请求阻塞

内容的提问来源于stack exchange，提问作者gbegley