用 STAROps 排查 Elasticsearch 搜索变慢
AI 总结
这篇掘金教程演示了如何通过 STAROps 的 Elasticsearch 智能助手，按节点检查 CPU、查询负载和分片分布，以排查搜索延迟。示例指出，集群状态为 Green、平均 CPU 正常时，仍可能有单节点持续高负载，而确认根因仍需补充慢日志和线程池拒绝数增量。
深度见解
文章给出了一套可落地的 AI 辅助可观测性流程，也说明仅看集群级健康指标可能遗漏不均衡的单节点压力。
本文作者：但丁(孔祥超)、杜尘(王明)、逸陵(阳其凯)
某电商平台的商品搜索服务使用一台 6 个数据节点的 Elasticsearch 实例。周五北京时间 20:00 起，业务陆续反馈搜索变慢。业务监控中的搜索接口 P99 从平时约 200 ms 升到 2s 以上，部分请求超时。值班工程师打开控制台：集群状态为 Green，没有未分配分片，集群平均 CPU 约 40%，乍看不像资源已经吃紧。
按节点展开后，问题才显露出来：节点 A 从 20:05 起 CPU 持续高于 95%，其余 5 个节点在 20%～40%。线程池里能看到 search 累计拒绝上万次，却不知道今晚新增了多少；等抓取热线程时，峰值已经回落，堆栈也没能解释刚才为什么慢。
业务还在等恢复进展。工程师需要弄清楚：今晚请求更多了，某类查询变重了，还是压力集中到了节点 A？这个节点承载了哪些分片，慢查询又落在哪里？这些问题需要把同一时段的证据放在一起看。