将要放假前夕，一个同事过来说，某某日志在kafka里边不消费了，我一开始没在意，去kafka的监控一看，果然是堆积了不少。 这个时候首先检查了一波logstash的情况，因为日常变更也就它了，其他组件一般都是没人调整的，但是看了一圈，好像这个时间点也没人做变更，只是在日志里看到一些索引在与某处建联的时候有拒绝的情况。 此时想着去看看kafka集群，是不是有什么问题呢，可是从kafka自身日志当中看了一圈，并没有发现任何异常信息，况且同时段情况下，另一个日志集群共用这套kafka，还在正常消费，说明这条线应该没问题。
当我在监控中排除刚刚那个索引的消费情况，可以看到其他日志也有上扬堆积的情况，如此看来，应该是es那块儿有问题了，于是开始从查es运行日志开始入手，很快，在master节点看到了如下日志：
之前并没有遇到过这个问题，不过看到了关键字read-only，查了一下说是有主机磁盘到达水位线了，从而触发es自身保护机制，使索引只读，以防被爆掉。
通过在kibana控制台Dev工具可以看到： 此处也可以看到好多索引的 read_only_allow_delete值变成了true，表示对应索引已经无法写入。
解决方法可通过如下命令将所有的索引置为可写： 如果此时kibana无法进入，也可以将如上命令转为curl方式进行配置：
通过执行如下命令，我们可以获得如下信息：
此处的 watermark就表示磁盘的水位线，我们看到有一个low和high，当磁盘空间达到high的界线，就会触发es集群将该节点上存在的分片对应的索引置为只读，从而保护整个集群。这一点在我回看集群磁盘监控时，也的确被证实了，某一个节点磁盘达到了95%。
因此更改了刚刚那个参数之后，还应该针对性地进行一些清理，从而使负载降下来
