问题描述:

在kibana上查询业务日志有丢失的情况，有的能查出来，有的日志查询不到。很奇怪，要么都不出来，要么都能出来，有的能出来，有的查不到这种很不好排查。一点一点排查吧。

解决步骤：

遇到这种问题，只能一步一步进行排查了。

1.首先看filebeat里有没有采集到应用的日志，查询filebeat的日志，是有采集到应用日志的。说明filebeat这块没有问题，继续排查。

2.es有的日志能查到，有的日志查不到，说明es没有问题，如果有问题应该啥日志都查询不到。说明问题不是在es这里。继续排查。

由于我们的架构是filebeat的日志给到logstash，由logstash来做日志分析和过滤。所以需要看logstash的日志有不有问题。

3.查看logstash的pod日志。logstash一共2个pod，其中一个pod日志是没有问题的，可以正常输出日志，另外一个pod是有问题的。一直报这个错误。如下图所示：

es 日志写入性能 测试 18亿 es日志查看_开发者工具

看来丢日志的问题出在这了。网上搜了一堆，都是说索引是只读的，需要使用这个命令调整成读写的。我执行了以后发现没有解决问题，依然报这个问题。

PUT /_all/_settings
{
  "index.blocks.read_only_allow_delete": null
}

4.先将副本数调整成1个吧，在看下是否还会出现retrying failed action with response code: 403这个问题。将副本数调整成一个以后，依然报这个问题，kibana里显示的日志竟然不更新了。停止在设置成2个副本之前的日志数据了。看来问题还是出现在索引上。

5.在开发者工具执行下面这条命令，将索引设置成允许写入。运行完这个命令后。我们可以查询logstash的日志看是否恢复正常。

PUT /_all/_settings
{
  "index.blocks.write": null
}

6.查询lotstash日志发现可以正常输出日志了，没有再报retrying failed action with response code: 403这个问题了。说明logstash这边的问题解决了。这时候到kibana上查看日志已经恢复正常了，没有丢失日志的情况了。