1.问题产生:存在es中的2020年的日志查不出来了,但是2019年的可以查出来。
2.排查:经过排查发现是operatetime字段排序造成的问题,再查看2019年和2020年的索引结构发现operatetime在2019年是keyword类型而2020年是text类型。
3.问题产生原因分析:由于2020年部分产品的升级导致logstash向es里写数据的时候创建索引的结构发生了变化。而查询需要一些排序聚合等操作时text类型是行不通的。
4.解决方案:将2020年的日志导入到新建的索引中然后把旧的索引删掉最后再给新的索引起个别名。
4.1新建索引
PUT testlog-2020-01 { "settings": { "index": { "refresh_interval": "5s", "number_of_shards": "1", "number_of_replicas": "0" } }, "mappings": { "logs": { "properties": { "operatetime": { "type": "keyword" }, ......省去好多字段 } } } }
4.2迁移数据(迁移当月的日志时需要先将logstash停掉)
POST _reindex?slices=6 { "source": { "index": "testlog-2020-01", "type": "logs", "size": 5000 }, "dest": { "index": "testlog-2020-01-copy", "type": "logs" } }
但是发现迁移失败,原因是text类型往keyword类型存的时候前者比后者存储量更大,所以需要第一步创建副本索引的时候就给operatetime指定为:
"operatetime": { "type": "keyword", "ignore_above": 256 }
4.3删掉原先的索引,直接delete
4.4给副本起个和原先索引名一样的别名
POST testlog-2020-01-copy/_alias/testlog-2020-01(想要删除的话直接delete)
4.5之后需要提前建好索引结构,避免logstash给创建不符合规范的索引