记一次日志突然写不进去了的处理

文章发布较早，内容可能过时，阅读注意甄别。

# 1，前言

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

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

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

# 2，寻因

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13

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

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

GET _settings
......
"set_099" : {
    "settings" : {
      "index" : {
        "number_of_shards" : "5",
        "blocks" : {
          "read_only_allow_delete" : "true"
        },
        "provided_name" : "set_099",
        "creation_date" : "1573130020809",
        "number_of_replicas" : "0",
        "uuid" : "L_gtQfu0SWq6oAcV35_pOQ",
        "version" : {
          "created" : "6050499"
        }
      }
    }
  }
.......

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

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

# 3，解决

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

PUT _settings
{
    "index": {
        "blocks": {
            "read_only_allow_delete": "false"
        }
    }
}

1
2
3
4
5
6
7
8

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

curl -XPUT "http://localhost:9200/_settings" -H 'Content-Type: application/json' -d'
{
    "index": {
        "blocks": {
            "read_only_allow_delete": "false"
        }
    }
}'

1
2
3
4
5
6
7
8

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

# 4，再探

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

GET _cluster/settings
.......
    "cluster" : {
      "routing" : {
        "allocation" : {
          "disk" : {
            "watermark" : {
              "low" : "90%",
              "high" : "95%"
            }
          }
        }
      }
    }
.......