本文作者：但丁(孔祥超)、杜尘(王明)、逸陵(阳其凯)

某电商平台的商品搜索服务使用一台 6 个数据节点的 Elasticsearch 实例。周五北京时间 20:00 起，业务陆续反馈搜索变慢。业务监控中的搜索接口 P99 从平时约 200 ms 升到 2s 以上，部分请求超时。值班工程师打开控制台：集群状态为 Green，没有未分配分片，集群平均 CPU 约 40%，乍看不像资源已经吃紧。

按节点展开后，问题才显露出来：节点 A 从 20:05 起 CPU 持续高于 95%，其余 5 个节点在 20%～40%。线程池里能看到 search 累计拒绝上万次，却不知道今晚新增了多少；等抓取热线程时，峰值已经回落，堆栈也没能解释刚才为什么慢。

业务还在等恢复进展。工程师需要弄清楚：今晚请求更多了，某类查询变重了，还是压力集中到了节点 A？这个节点承载了哪些分片，慢查询又落在哪里？这些问题需要把同一时段的证据放在一起看。

Green 表示主分片和副本分片均已分配，不能据此判断查询性能正常。接下来，通过 STAROps 技能中心^[1]的 Elasticsearch 智能助手，先检查这一小时的运行情况，再围绕节点 A 继续诊断。

先让数字员工用上

Elasticsearch 智能助手

Cloud Native

首次使用时，先在 STAROps 中为负责这套业务的数字员工添加技能。后续值班遇到问题，就可以直接进入它的会话。

1. 登录 STAROps 控制台^[2]，进入技能中心 → 官网推荐，搜索并选择 Elasticsearch 智能助手。

2. 按照技能卡片指引，将技能添加到数字员工，并确认已启用。

3. 完成助手开通与授权，确认数字员工能够访问待排查的实例，再进入会话。

可以先用一台熟悉的实例确认调用正常。技能配置、助手开通和权限要求分别见技能中心^[3]、Elasticsearch 智能助手^[4]和 STAROps 权限配置^[5]。

Elasticsearch 智能助手目前向 STAROps 开放巡检和诊断能力。实际处置仍由工程师评估，并通过现有运维流程执行。

先巡检这一小时，把平均值展开到每个节点

Cloud Native

工程师把实例、地域和异常时段一起交给数字员工。这次已经知道问题发生在晚高峰，就直接指定 20:00—21:00，避免稍后提问时“最近一小时”已经错过故障。

使用 Elasticsearch 智能助手检查杭州地域 cn-hangzhou 的实例 es-cn-xxxx，时间为故障当天北京时间 20:00—21:00。商品搜索变慢，集群是 Green，但节点 A 的 CPU 很高。请先做一轮巡检，重点按节点对比 CPU、查询负载和分片分布。

实际使用时，将 es-cn-xxxx 和节点 A 替换为真实标识，并填写故障的具体日期。业务接口 P99 的变化也一并提供，方便与集群侧数据对照。

这一轮返回后，工程师拿到的是各节点 CPU、集群查询 QPS 和分片分布。慢日志与异常时段的线程池增量数据还没有取得。报告先把这两部分分开：

本轮结果	示例内容
已取得	20:00—21:00 各节点 CPU 时序、集群查询 QPS，以及本轮查询到的索引与分片分布。节点 A 从 20:05 起持续高于 95%。
业务侧补充	搜索接口 P99 从约 200 ms 升至 2s 以上，部分请求超时。
尚未取得	异常时段慢日志、线程池拒绝数的时序增量；现有累计拒绝数不能直接说明今晚新增了多少。

工程师现在可以给业务一个更具体的进展：“已确认压力集中在节点 A，正在查它承载的查询和分片。”Green 和集群平均值不再挡住调查，尚未取得的数据也有了明确的补查方向。

围绕节点 A 追问，把几条线索接起来

Cloud Native

下一步仍在原会话里进行。工程师需要知道节点 A 为什么比其他节点忙，以及这种差异是否与搜索变慢有关：

继续诊断节点 A 在 20:00—21:00 的高 CPU。把集群查询 QPS 与前一周同一时段对比，查清节点 A 承载了商品搜索索引的哪些分片。结合异常时段的慢日志，看看耗时查询是否集中在这些分片上，还是出现了更多重查询。尚未取得的数据请单独列出。

在这个示例里，集群查询 QPS 与前一周同一时段相近。可以先说没有看到请求总量明显上涨，但还要继续查请求内容：同样的 QPS，较重的聚合或更大的扫描范围，也可能消耗更多 CPU；集群总量不变，也可能只有某个节点承受了更多压力。

这时，诊断结果可以分成三层，方便接手的人知道已经走到了哪一步：

已确认：20:05 起，只有节点 A 的 CPU 持续高于 95%，其余节点为 20%～40%。集群查询 QPS 与前一周同时段相近，暂未发现请求量整体明显上涨。待验证：商品搜索索引的分片布局或数据访问热度可能让查询压力集中在节点 A；也需要核对是否有更多重查询。当前信息还不足以确定根因。需补充：异常时段的慢日志与节点、分片对应关系，以及线程池拒绝数的时序增量。

工程师据此补查日志，再把慢查询对应的索引、分片和节点放到同一时间线上。若异常期间发生过分片迁移，还要核对当时的位置。这样才能判断节点 A 是承载了更多分片，还是分片数量看似均衡、实际访问热度却明显不同。

先前那份峰值回落后的热线程快照，也只能保留为采集当时的状态。它没有出现热点，并不能抹掉 20:05 之后已经发生过的高 CPU；要解释这次故障，仍要回到那一小时的数据。慢日志提供分片执行线索，业务接口 P99 则用于核对用户实际感受到的延迟。

按证据选择处置，再等一个可比的晚高峰

Cloud Native

节点 A 的问题范围缩小以后，工程师再选择处置方式。如果确认查询压力与分片布局或热数据集中有关，就结合分片大小、主副本数量、路由和实际负载，重新评估分片规划。如果调整分布后仍然只有节点 A 偏高，就沿着这个节点继续查。对于已经停止写入的索引，若进一步确认段数量等因素影响搜索效率，可以在评估资源余量后，与低峰安排段合并。

变更完成时可能已经过了晚高峰。即使眼前的 CPU 和 P99 都下降了，工程师也先记录已执行的调整、确认服务可用。到下一个工作日 20:00—21:00 的高峰结束后，再回到原会话发起复查：

我已完成本次评估后的处置。请使用 Elasticsearch 智能助手复查同一实例今天北京时间 20:00—21:00 的运行情况，并与故障当天同一时段比较。重点看节点间 CPU 差距、查询负载，以及新观察窗口内的拒绝数增量。我会补充业务监控中的接口 P99，请一起判断是否恢复。

下一个工作日提供了一个观察窗口，比较前还要核对 QPS、查询类型和活动强度。若周五有促销、工作日负载明显更轻，就继续等负载相近的高峰，或在可控环境中验证。线程池关注新窗口里拒绝是否继续增长，历史累计值无需归零。

复查时，工程师同时看节点 A 是否仍明显高于其他节点、业务 P99 是否恢复，以及请求超时是否还在发生。只有这些变化与可比的业务负载对得上，才有依据告诉业务“这次调整起作用了”，并把仍需观察的问题交给下一班。

创建长期巡检任务并沉淀排查经验

Cloud Native

这次排查留下的经验很具体：只看 Green 和集群平均 CPU，容易漏掉单节点压力。团队可以把按节点比较的要求加入 STAROps 长期任务，让配置好技能的数字员工持续检查。

每天北京时间 21:10，使用 Elasticsearch 智能助手巡检这台商品搜索实例，检查当天 20:00—21:00 的运行情况。按节点对比 CPU 和查询负载；节点间差距超过团队确认的阈值并持续达到约定时长时，继续诊断相关索引和分片。异常和检查失败都通过已配置的渠道通知值班人员。

创建时，要写清实例、地域、时区、差距的比较方式、阈值、持续时间与通知对象，并核对生成的计划。例如，CPU 差距按百分点计算还是按比例计算，应先由团队确定。操作方式见创建与规划长期任务^[6]。

第一轮运行后，值班同学看一次报告，确认能读到各节点的差异，也确认通知能够收到。下一次平均值看似正常、节点 A 再次升高时，接手的人就可以从这轮检查继续查，不必重新拼起那晚的现场。

其他异常的排查方向

Cloud Native

单节点高 CPU 之外，巡检还可能发现其他问题。仍然从本轮发现出发，在原会话补充具体对象和时段：

巡检发现	接着核对什么	要回答的问题
Yellow / Red、分片未分配	分配解释、节点可用性、分配约束与磁盘条件	哪些分片受影响，具体是什么阻止了分配
磁盘水位高、索引只读	节点磁盘、索引限制、分片分布与近期增长	空间有什么占用，是否仍在增长
JVM / GC、内存压力	同一时段的堆内存、GC、查询或写入负载	资源压力是否与业务失败同时发生，集中在哪里

如何用 STAROps Elasticsearch 智能助手看穿“搜索变慢”

相关链接：