背景：
客户反馈主机 gzhmapp 的 Elasticsearch（ES）服务 CPU 使用率达到 100%，业务查询受到严重影响。ES 二线团队远程协助海雄开展问题诊断工作。
排查过程
2025 年 11 月 17 日 20:30，接到 ES 集群内存过高的通知。入会后查看 Grafana 监控，发现集群无相关日志生成，无法判断历史是否存在类似情况及持续时长。
（一）检查集群索引状态
通过执行命令 _cat/shards?h=index,shard,prirep,state,unassigned.reason，查看当前索引任务执行情况。结果显示所有索引均处于完成状态，索引正常，数据写入未受影响。涉及的主要索引包括 cml_sent_info_06（2025 年 11 月）、atm_tran_info 等，其主分片（p）和副本分片（r）均为 STARTED 状态。
（二）检查集群任务状态
执行命令 _cat/tasks 查看集群任务状态，发现集群存在大量持续的链接查询操作。这些查询任务持续时长超 40 分钟，且伴随断开重连的情况，涉及节点包括 10.5.6.168（sent-node-168）、10.5.6.169（sent-node-169）、10.5.6.170（sent-node-170），任务类型均为 indices:data/read/searchphase/query
进一步查询具体任务详情（如命令 _XGET http://10.5.6.170:9200/_tasks/BXAjp51_SB2Kmj24Phur6Q:660914358），发现查询针对 cml_sent_info_11、cml_sent_info_10 等多个 cml_sent_info* 系列索引，采用大量通配符（*）进行全文档匹配查询，且查询条件复杂、无有效过滤条件。
（三）业务侧沟通反馈
通知一线联系业务同事核实集群操作情况，询问是否可释放链接重连以缓解压力。业务侧反馈无法中断现有操作，需保持原有运行状态。
三、结论与优化建议
（一）问题根本原因
业务代码存在异常或查询设计不合理，针对 cml_sent_info* 系列索引进行频繁、大规模的全文档通配符查询，导致 ES 集群 CPU 和内存资源被持续占用，最终引发 CPU 使用率达 100%、业务查询受影响的问题。结合集群运行超 2 年的情况，判断数据存储量和正常使用量并不大，排除数据量过载导致的资源紧张。
（二）优化建议
搭建监控告警体系：建立 ES 集群专属监控面板，覆盖 CPU、内存、查询吞吐量、任务执行时长等核心指标，实现异常情况实时告警，并留存历史监控数据，便于问题追溯分析。
扩容 ES 内存：当前 ES 程序内存分配为 4G，主机内存 32G 剩余充足，建议将 ES 内存扩容至 8G，提升查询处理速度和并发承载能力。
集群节点扩容：增加 ES 集群节点数量，分散查询压力，提高集群整体处理性能。
业务查询优化：通知业务侧优化程序代码，减少无差别全文档查询，增加精准过滤条件；避免频繁使用通配符（*）进行大范围匹配，缩短查询执行时间，降低资源占用。
索引拆分管理：针对单个容量超 100G 的索引，建议设定 30G 为拆分阈值，按时间或业务维度拆分索引，提升查询效率和维护便捷性。