你的问题场景： #

我使用Elasticsearch 2.3.4作为文本搜索引擎，已创建若干索引。但发现每隔几天，politics、physics、biology这几个索引的文档数量就会减少，导致搜索质量下降。请问该问题的可能原因是什么？提前致谢。当日相关日志如下：[2018-03-21 14:22:58,349][WARN ][bootstrap ] unable to install syscall filter: seccomp unavailable: CONFIG_SECCOMP not...

针对这个问题，结合ES 2.3.4的版本特性，我整理了几个高概率的排查方向：

• TTL字段自动过期删除：ES 2.3.4还支持_ttl（文档生存时间）特性，如果这几个索引的映射里开启了TTL，并且设置了较短的过期时间（比如7天），文档到期后会被自动清理。你可以通过调用GET /politics/_mapping查看是否有_ttl配置，比如是否存在"_ttl": {"enabled": true, "default": "7d"}这类设置。
• 自定义定时清理脚本误操作：虽然ES 2.3.4没有官方的索引生命周期管理（ILM），但很多团队会自己写定时脚本（比如crontab里的curl命令）来清理旧数据。如果脚本的索引匹配规则写得有问题，把这几个索引纳入了清理范围，就会每隔几天删除文档。可以检查服务器上的定时任务列表，或者有没有专门的ES清理脚本。
• 误删除操作：有没有其他拥有ES写入/删除权限的人员，不小心执行了_delete_by_query或者直接删除分片的操作？比如在Kibana、ES Head这类可视化工具里误操作，或者客户端程序的逻辑错误导致批量删除。如果开启了ES的审计日志，可以去日志里搜索delete关键词找相关记录；也可以用_cat/indices?v对比不同时间的文档数，看是突然骤降还是逐步减少（骤降大概率是误删）。
• 分片故障导致数据丢失：你贴的日志里有seccomp的警告，这个虽然不直接删数据，但说明服务器内核没开启CONFIG_SECCOMP，可能影响ES进程的稳定性。如果集群里的某个节点宕机、磁盘故障，这几个索引的分片刚好在该节点上，恢复时可能出现分片数据不一致，甚至丢失部分文档。可以用_cat/shards?v查看这几个索引的分片状态，有没有未分配、异常的分片。
• 版本冲突或批量操作逻辑错误：如果有程序向这几个索引写入数据时，同时执行了批量更新/删除，可能因为查询条件写错、版本冲突处理不当，误删了大量文档。比如批量删除时用的查询条件匹配了不该删的文档，或者更新操作意外触发了删除逻辑。可以检查客户端程序的日志，看看有没有异常的批量操作记录。

快速排查步骤： #

1. 先查这几个索引的映射和设置，确认TTL是否开启；
2. 翻ES的完整日志（不止你贴的那段），找删除相关的操作记录；
3. 检查服务器定时任务，排查是否有清理脚本；
4. 查看集群分片状态，确认是否有异常分片。

内容的提问来源于stack exchange，提问作者YJ. Yang