Elasticsearch从6.8升级至7.12.1后Zabbix触发Flush latency过高告警排查

问题概述 #

现有Docker部署的3节点Elasticsearch集群，前端部署Nginx作为反向代理转发请求至3个ES节点，将Elasticsearch版本从6.8升级到7.12.1后，Zabbix触发「Flush latency is too high」告警，监控图表显示Flush latency值持续增长：

可能成因 #

• 7.x版本默认Translog Flush策略变更：相比6.8版本，7.x将index.translog.durability默认值从async调整为request，每次写入请求都强制刷盘，直接拉高flush延迟
• Segment Merge策略适配问题：升级后6.8版本生成的旧Segment需要适配7.x的合并规则，后台合并任务占用大量磁盘IO，拖累flush操作执行效率
• Docker资源配置未同步升级：7.12.1对文件句柄、内存、CPU的要求远高于6.8，如果Docker容器的ulimit、资源配额没有对应调整，会导致IO阻塞，flush延迟持续上涨
• JVM配置不兼容：7.12.1捆绑使用JDK11，如果沿用6.8版本的JDK8或者老的GC参数（如UseConcMarkSweepGC），会导致GC停顿变长，间接抬高flush延迟
• 旧索引配置未更新：6.8版本创建的旧索引没有同步升级settings，旧的flush参数和新版本执行逻辑不兼容，导致flush操作频繁重试

修复方案 #

• 调整translog持久化策略：如果业务允许秒级数据丢失风险，将索引级translog改为异步刷盘模式，执行如下命令：

PUT /_all/_settings
{
  "index.translog.durability": "async",
  "index.translog.sync_interval": "30s",
  "index.translog.flush_threshold_size": "1gb"
}

• 优化Segment合并策略：根据磁盘性能调整合并线程数，SSD盘建议设置为2-4，机械盘建议设置为1，执行如下命令：

PUT /_cluster/settings
{
  "persistent": {
    "indices.merge.scheduler.max_thread_count": 2
  }
}

后台旧Segment合并完成后flush延迟会明显回落

• 调整Docker容器资源配置：将容器ulimit nofile调整为不低于65535，memlock设为-1，ES堆内存配置为宿主机物理内存的一半且不超过31G，启动参数添加-XX:+UseG1GC适配JDK11
• 重建旧索引：对6.8版本创建的历史索引，通过_reindex接口重建为7.12.1版本的索引，适配新版本的存储和flush逻辑
• 优化Nginx转发配置：禁用Nginx请求缓冲，避免大请求在Nginx层堆积导致ES侧延迟被误判为flush延迟，添加如下配置：

proxy_request_buffering off;
proxy_buffering off;

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