search Troubleshooting
Elasticsearch 慢查询排查方法
Elasticsearch 查询变慢或聚合超时时，开启 index.search.slowlog 抓取慢 query，用 _nodes/stats/indices/search 观察 query_time，_cat/thread_pool/search 看 active/queue/rejected 判断是 CPU 瓶颈还是队列堆积，再优化聚合、深分页和 wildcard 查询。
慢查询先开启慢查询日志抓取慢 query，再用 _nodes/stats/indices/search 和 thread_pool/search 定位是 CPU 还是队列问题
Scenario
这篇文章解决什么问题
适用于“Elasticsearch 慢查询排查方法”对应的线上或本地排障场景。不要只根据最终报错下结论，应先把问题拆成入口、链路、目标服务和资源限制几层，再用命令逐层证实。慢查询先开启慢查询日志抓取慢 query，再用 _nodes/stats/indices/search 和 thread_pool/search 定位是 CPU 还是队列问题
Symptoms
典型现象
- Elasticsearch 查询变慢或聚合超时时，开启 index.search.slowlog 抓取慢 query，用 _nodes/stats/indices/search 观察 query_time，_cat/thread_pool/search 看 active/queue/rejected 判断是 CPU 瓶颈还是队列堆积，再优化聚合、深分页和 wildcard 查询。
- 相关日志、命令或页面中反复出现 elasticsearch、慢查询、聚合 等关键词。
- 同一服务在不同机器、不同入口或不同时间段表现不一致，需要通过证据链缩小范围。
Before Debugging
排查前先确认
- 先确认是索引设计、查询写法还是集群资源问题，避免在错误的层面调参。
- 保留慢查询、分片状态和节点资源水位，作为定位依据。
- 区分查询慢（读路径）和写入慢（写路径），两者优化方向相反。
Root Causes
常见根因分层
分片未分配或磁盘水位线触发
节点磁盘超 flood watermark 会拒绝写入、分片无法分配，集群变 red 或 yellow，表现为大面积失败。
- 看集群 health 和分片分配
- 检查节点磁盘水位
- 看 allocation explain
查询未用 filter 上下文或聚合过高基数
用 query 而非 filter 不走缓存、聚合字段基数过高、深分页 from+size 过大，都会让查询又慢又耗资源。
- 区分 filter 和 query
- 看聚合基数和分桶数
- 排查深分页改 search_after
线程池满或熔断器触发
search/write 线程池队列打满会拒绝请求，parent breaker 触发会让大查询直接失败。
- 看线程池 queue 和 rejected
- 确认是否触发 breaker
- 排查大聚合和全量扫描
Diagnosis Path
分步诊断流程
1. 固定现场，避免追着变化状态跑
先记录故障时间、影响入口、完整错误和最近一次变更。Elasticsearch 慢查询排查方法 这类问题经常在重启、重试或缓存刷新后短暂消失，没有现场信息会很难复盘。
- 截图或保存完整错误文本
- 记录请求域名/IP/端口/namespace/服务名
- 标出最近发布、配置、证书、镜像或依赖变更
curl -X GET "http://localhost:9200/_nodes/stats/indices/search?pretty"
curl -X GET "http://localhost:9200/_cat/thread_pool/search?v&h=node_name,active,queue,rejected,completed"2. 在故障发生的同一位置复现
很多误判来自测试位置不同：本机通不代表服务器通，容器内通不代表宿主机通，集群外通也不代表 Pod 内通。复现命令要尽量贴近真实流量路径。
- 从报错服务所在机器执行测试
- 必要时加 Host、SNI、namespace 或代理参数
- 把成功路径和失败路径的输出并排比较
curl -X GET "http://localhost:9200/_cat/thread_pool/search?v&h=node_name,active,queue,rejected,completed"
curl -X GET "http://localhost:9200/<index>/_settings?pretty"
curl -X PUT "http://localhost:9200/<index>/_settings" -H 'Content-Type: application/json' -d'{"index.search.slowlog.threshold.query.warn":"2s","index.search.slowlog.threshold.fetch.warn":"1s"}'3. 读取服务端证据，而不是只看客户端提示
客户端报错通常是结果摘要。真正能区分根因的是服务端日志、内核日志、事件、进程状态或数据库状态。
- 开启 search.slowlog，设置 query/fetch 的 warn 阈值抓取慢查询
- 查看 _nodes/stats/indices/search 的 query_time/query_total 计算平均查询耗时
- 用 _cat/thread_pool/search 观察 active/queue/rejected，判断是否队列堆积
curl -X GET "http://localhost:9200/<index>/_settings?pretty"
curl -X PUT "http://localhost:9200/<index>/_settings" -H 'Content-Type: application/json' -d'{"index.search.slowlog.threshold.query.warn":"2s","index.search.slowlog.threshold.fetch.warn":"1s"}'4. 做最小修复并立即回归验证
每次只改一个变量，修复后用同一条复现命令回测，并观察日志是否停止增长。这样可以避免多个临时改动互相掩盖。
- 用 _cat/thread_pool/search 观察 active/queue/rejected，判断是否队列堆积
- 分析慢查询日志中的 query 体，识别大聚合、深分页或 wildcard 查询
- 优化查询：限制时间范围、用 filter 替代 query、调整 size、增加分片数或缓存
curl -X GET "http://localhost:9200/<index>/_settings?pretty"
curl -X PUT "http://localhost:9200/<index>/_settings" -H 'Content-Type: application/json' -d'{"index.search.slowlog.threshold.query.warn":"2s","index.search.slowlog.threshold.fetch.warn":"1s"}'Commands
排查命令与使用意图
命令 1
用于从指定位置模拟真实请求。加 -v 可以看到 DNS、TCP、TLS、HTTP 头和代理连接过程，是定位链路阶段的关键证据。
curl -X GET "http://localhost:9200/_nodes/stats/indices/search?pretty"命令 2
用于从指定位置模拟真实请求。加 -v 可以看到 DNS、TCP、TLS、HTTP 头和代理连接过程，是定位链路阶段的关键证据。
curl -X GET "http://localhost:9200/_cat/thread_pool/search?v&h=node_name,active,queue,rejected,completed"命令 3
用于从指定位置模拟真实请求。加 -v 可以看到 DNS、TCP、TLS、HTTP 头和代理连接过程，是定位链路阶段的关键证据。
curl -X GET "http://localhost:9200/<index>/_settings?pretty"命令 4
用于从指定位置模拟真实请求。加 -v 可以看到 DNS、TCP、TLS、HTTP 头和代理连接过程，是定位链路阶段的关键证据。
curl -X PUT "http://localhost:9200/<index>/_settings" -H 'Content-Type: application/json' -d'{"index.search.slowlog.threshold.query.warn":"2s","index.search.slowlog.threshold.fetch.warn":"1s"}'Risk Notes
容易踩坑的地方
- 不要在集群 red 状态下强制分配分片，可能造成数据丢失或不一致。
- 不要随意调大熔断器阈值掩盖大查询问题，会让节点 OOM 导致更大的集群故障。
- 不要使用深分页（from+size 超过 10000），应改用 search_after 或 scroll API。
Verification
修复后怎么确认
- 原始故障现象已经消失，且使用同一入口重新测试 Elasticsearch 慢查询 能稳定成功。
- 服务端日志不再出现同类错误，监控中的错误率、重启次数、连接数或延迟回到正常区间。
- 如果做过临时绕过，已经记录恢复计划，例如还原宽松策略、补监控、补限制或提交正式配置。
Prevention
后续预防
- 监控集群 health、磁盘水位和线程池 rejected，建立趋势告警，提前发现集群问题。
- 为索引设置 ILM 策略，自动滚动、收缩和删除，避免单索引无限膨胀导致性能下降。
- 查询统一用 filter 上下文，并按数据量规划合理分片数，避免过度分片或分片不足。
- 定期使用 Profile API 分析慢查询，优化查询 DSL 和索引映射。
常见问题
聚合查询总是超时怎么优化？
缩小聚合桶基数，使用 doc_values，必要时用 runtime field 预计算；对大范围聚合考虑用 transform 或预聚合索引。
thread_pool/search rejected 高说明什么？
说明搜索线程池队列已满，查询被拒绝；需降低查询并发、优化慢查询，或调大 search ThreadPool queue_size。
Long-tail SEO
你可能正在搜索这些报错
下面这些错误原文、场景词和中英文搜索词，都是排查同类问题时常见的入口。
- elasticsearch 慢查询
- ES search.slowlog 配置
- elasticsearch 聚合查询超时
- _cat/thread_pool/search rejected
- elasticsearch 查询慢 排查
- ES query_time 优化
Need More Help
这个问题还没完全解决？
把你的报错、环境和已经尝试过的步骤发给我，后续会优先补充到排障手册。