Elastic Search索引文档触发maxtimeout reached超时问题排查

3个master节点组成的ES集群宕机1台，完全可能触发你遇到的索引请求返回maxtimeout reached、间隔后自动恢复的现象。结合你给出的集群配置，除了master宕机本身的选主流程影响外，现有master节点的规格短板会大幅拉长故障影响窗口，提升超时出现概率。

• 3节点master集群的法定选举人数（quorum）为2，单台master宕机后剩余2台节点仍满足选举条件，会自动触发主节点重选流程。选主期间集群会短暂进入元数据不可写状态，所有涉及元数据交互的操作（包括文档索引的分片路由、写入位点同步、分片状态更新等）都会被阻塞。如果阻塞时长超过客户端配置的请求超时阈值，就会直接返回超时响应；等新主节点选出、集群状态全量同步完成后，索引操作会自动恢复，和你观测到的故障现象完全吻合。
• 你当前的master节点配置存在明显短板，会放大故障影响：
  • 单master节点memory limit和heap size均配置为4GB，规格严重偏低。master节点需要常驻全量集群元数据、处理全节点心跳、执行分片分配决策，4GB堆内存对生产集群来说冗余度极低，选主、同步集群状态的过程中很容易触发长时间GC停顿，直接拉长集群不可用的时长，导致更多请求触发超时。
  • 单master节点磁盘容量仅配置10GB，部署在Kubernetes环境下很容易因为系统组件日志、ES运行日志堆积触发磁盘高水位。ES默认master节点磁盘使用率超过85%时会限制元数据写入操作，会进一步拉长故障恢复时间。

• 拉取故障时段ES master节点日志，检索是否存在master node changed、cluster state recovered相关记录，统计选主+集群状态恢复的总时长，确认是否和请求超时时段完全重合
• 查看故障时段剩余2台存活master节点的监控数据，重点核对GC停顿时长、堆内存使用率、磁盘使用率指标，确认是否存在长GC、磁盘打满的异常
• 拉取故障时段data节点日志，检索是否存在SERVICE_UNAVAILABLE/state not recovered类的写入阻塞报错
• 核对索引客户端的超时配置，若配置的最大等待时长小于集群选主+状态恢复的平均耗时，会稳定出现这类超时返回

内容的提问来源于stack exchange，提问作者Balaji Arun