Logstash Elasticsearch输出插件删除文档后无法立即重新插入的问题求助

先聊聊问题根源 #

你碰到的这个情况我之前帮同行排查过类似的，本质是两个核心因素在作祟：

1. Elasticsearch的自动刷新延迟：默认ES每1秒才会把内存中的操作刷新到可查询的索引状态，删除操作刚执行完的几十毫秒内，ES还没同步这个删除状态，此时发送upsert请求，ES可能误判文档状态，或者出现处理顺序混乱；
2. Logstash异步批量的不确定性：Logstash的ES输出插件是异步批量发送请求的，虽然你是先执行删除再执行upsert，但有可能ES端收到请求的顺序发生颠倒，最终变成「先插后删」，导致文档只被删除而没有重新插入。

几个实用解决方案（按生产环境适用性排序） #

1. 用版本控制锁死操作顺序（最推荐生产使用）

给文档添加版本号，让ES严格按照版本优先级处理请求：

• 应用端在发送给Logstash的对象中，新增[@metadata][version]字段，每次操作版本号递增；
• 修改Logstash的ES输出配置，开启版本控制：

output {
  elasticsearch {
    hosts => ["http://your-es-host:9200"]
    index => "your_index"
    action => "%{[@metadata][action]}" # 假设你用该字段指定操作类型（delete/upsert）
    version => "%{[@metadata][version]}"
    version_type => "external" # 使用外部版本号，确保高版本操作覆盖低版本
  }
}

这样就算删除和upsert请求在ES端乱序，高版本的upsert也会覆盖低版本的删除操作，保证最终得到你预期的结果。

2. 强制Logstash逐个发送请求（简单粗暴，适合低流量场景）

修改Logstash配置，将批量请求大小设为1，强制每个请求按顺序同步发送：

output {
  elasticsearch {
    hosts => ["http://your-es-host:9200"]
    index => "your_index"
    action => "%{[@metadata][action]}"
    flush_size => 1 # 每个批次仅包含1条请求
    idle_flush_time => 0 # 不等待，立即发送请求
  }
}

这种方式能从根源上保证删除请求完全处理完成后，再执行upsert操作，但缺点是高流量场景下会降低Logstash和ES的整体性能。

3. 手动触发ES索引刷新（仅用于测试，禁止生产环境使用）

在删除操作执行后，主动调用ES的刷新API，强制将删除操作同步到索引：

POST /your_index/_refresh

应用端发送完删除请求后，先调用该接口，等待返回成功后再执行upsert操作。但频繁调用刷新会严重消耗ES的IO资源，生产环境绝对不要采用这种方式。

4. 临时调整ES索引刷新间隔（应急场景使用）

如果是临时业务需求，可以将目标索引的刷新间隔改短（比如100ms）：

PUT /your_index/_settings
{
  "index.refresh_interval": "100ms"
}

完成操作后记得改回默认的1秒刷新间隔，否则会持续影响ES的性能。

验证问题是否解决的方法 #

你可以将Logstash的ES输出日志级别调到trace，查看每个请求的处理顺序和ES的响应详情：

output {
  elasticsearch {
    # 保留原有配置
    log_level => "trace"
  }
}

从日志中可以清晰看到两个请求的处理先后顺序，以及ES是否返回了错误信息，以此确认问题是否得到解决。

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