ELK-学习笔记–记一次日志突然写不进去了的处理 |坐而言不如起而行！ 二丫讲梵

将要放假前夕，一个同事过来说，某某日志在kafka里边不消费了，我一开始没在意，去kafka的监控一看，果然是堆积了不少。

这个时候首先检查了一波logstash的情况，因为日常变更也就它了，其他组件一般都是没人调整的，但是看了一圈，好像这个时间点也没人做变更，只是在日志里看到一些索引在与某处建联的时候有拒绝的情况。

此时想着去看看kafka集群，是不是有什么问题呢，可是从kafka自身日志当中看了一圈，并没有发现任何异常信息，况且同时段情况下，另一个日志集群共用这套kafka，还在正常消费，说明这条线应该没问题。

当我在监控中排除刚刚那个索引的消费情况，可以看到其他日志也有上扬堆积的情况，如此看来，应该是es那块儿有问题了，于是开始从查es运行日志开始入手，很快，在master节点看到了如下日志：

1. [2020-06-24T17:17:19,548][WARN ][o.e.x.m.e.l.LocalExporter] [log-center-c2-1] unexpected error while indexing monitoring document
2. org.elasticsearch.xpack.monitoring.exporter.ExportException: ClusterBlockException[blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];]
3. at org.elasticsearch.xpack.monitoring.exporter.local.LocalBulk.lambda$throwExportException$2(LocalBulk.java:128) ~[?:?]
4. at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) ~[?:1.8.0_121]
5. at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) ~[?:1.8.0_121]
6. at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) ~[?:1.8.0_121]
7. ......
8. [2020-06-24T17:17:19,550][WARN ][o.e.x.m.MonitoringService] [log-center-c2-1] monitoring execution failed
9. org.elasticsearch.xpack.monitoring.exporter.ExportException: Exception when closing export bulk
10. at org.elasticsearch.xpack.monitoring.exporter.ExportBulk$1$1.<init>(ExportBulk.java:95) ~[?:?]
11. at org.elasticsearch.xpack.monitoring.exporter.ExportBulk$1.onFailure(ExportBulk.java:93) ~[?:?]
12. at org.elasticsearch.xpack.monitoring.exporter.ExportBulk$Compound$1.onResponse(ExportBulk.java:206) ~[?:?]
13. ......

之前并没有遇到过这个问题，不过看到了关键字read-only，查了一下说是有主机磁盘到达水位线了，从而触发es自身保护机制，使索引只读，以防被爆掉。

通过在kibana控制台Dev工具可以看到：

1. GET _settings
2. ......
3. "set_099" : {
4. "settings" : {
5. "index" : {
6. "number_of_shards" : "5",
7. "blocks" : {
8. "read_only_allow_delete" : "true"
9. },
10. "provided_name" : "set_099",
11. "creation_date" : "1573130020809",
12. "number_of_replicas" : "0",
13. "uuid" : "L_gtQfu0SWq6oAcV35_pOQ",
14. "version" : {
15. "created" : "6050499"
16. }
17. }
18. }
19. }
20. .......

此处也可以看到好多索引的 read_only_allow_delete值变成了true，表示对应索引已经无法写入。

解决方法可通过如下命令将所有的索引置为可写：

1. PUT _settings
2. {
3. "index": {
4. "blocks": {
5. "read_only_allow_delete": "false"
6. }
7. }
8. }

如果此时kibana无法进入，也可以将如上命令转为curl方式进行配置：

1. curl -XPUT "http://localhost:9200/_settings" -H 'Content-Type: application/json' -d'
2. {
3. "index": {
4. "blocks": {
5. "read_only_allow_delete": "false"
6. }
7. }
8. }'

当然这种解决只是临时解除限制，真正导致这个情况的根因还是要解决的。

通过执行如下命令，我们可以获得如下信息：

1. GET _cluster/settings
2. .......
3. "cluster" : {
4. "routing" : {
5. "allocation" : {
6. "disk" : {
7. "watermark" : {
8. "low" : "90%",
9. "high" : "95%"
10. }
11. }
12. }
13. }
14. }
15. .......

此处的 watermark就表示磁盘的水位线，我们看到有一个low和high，当磁盘空间达到high的界线，就会触发es集群将该节点上存在的分片对应的索引置为只读，从而保护整个集群。这一点在我回看集群磁盘监控时，也的确被证实了，某一个节点磁盘达到了95%。

因此更改了刚刚那个参数之后，还应该针对性地进行一些清理，从而使负载降下来。