Diagnosing Slow Elasticsearch Search with STAROps
A Juejin tutorial demonstrates how engineers can use the STAROps Elasticsearch 智能助手 to inspect per-node CPU, query load, and shard distribution during a search slowdown. Its worked example shows how a Green cluster and healthy average CPU can conceal sustained pressure on one node, while emphasizing that slow logs and thread-pool rejection deltas are still needed to establish the root cause.
The article provides a concrete AI-assisted observability workflow for Elasticsearch incidents and shows why cluster-level health indicators alone may miss uneven node pressure.
本文作者：但丁(孔祥超)、杜尘(王明)、逸陵(阳其凯)
某电商平台的商品搜索服务使用一台 6 个数据节点的 Elasticsearch 实例。周五北京时间 20:00 起，业务陆续反馈搜索变慢。业务监控中的搜索接口 P99 从平时约 200 ms 升到 2s 以上，部分请求超时。值班工程师打开控制台：集群状态为 Green，没有未分配分片，集群平均 CPU 约 40%，乍看不像资源已经吃紧。
按节点展开后，问题才显露出来：节点 A 从 20:05 起 CPU 持续高于 95%，其余 5 个节点在 20%～40%。线程池里能看到 search 累计拒绝上万次，却不知道今晚新增了多少；等抓取热线程时，峰值已经回落，堆栈也没能解释刚才为什么慢。
业务还在等恢复进展。工程师需要弄清楚：今晚请求更多了，某类查询变重了，还是压力集中到了节点 A？这个节点承载了哪些分片，慢查询又落在哪里？这些问题需要把同一时段的证据放在一起看。