• 对于注定会优秀的人来说,他所需要的,只是时间!
  • 手懒得,必受贫穷,手勤的,必得富足----《圣经》
  • 帮助别人,成就自己。愿君在本站能真正有所收获!
  • 如果你在本站中发现任何问题,欢迎留言指正!
  • 宝剑锋从磨砺出,梅花香自苦寒来!

<二十一>ELK-学习笔记–记一次日志突然写不进去了的处理

ELK eryajf 1个月前 (07-05) 172°C 已收录 0个评论
本文预计阅读时间 8 分钟

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) ~[?:?]

        ......

之前并没有遇到过这个问题,不过看到了关键字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"
        }
      }
    }
  }
.......

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

3,解决

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

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

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

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

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

4,再探

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

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

.......

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

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


weinxin
扫码订阅本站,第一时间获得更新
微信扫描二维码,订阅我们网站的动态,另外不定时发送WordPress小技巧,你可以随时退订,欢迎订阅哦~

二丫讲梵 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明<二十一>ELK-学习笔记–记一次日志突然写不进去了的处理
喜欢 (0)
[如果想支持本站,可支付宝赞助]
分享 (0)
eryajf
关于作者:
学无止境,我愿意无止境学。书山有路,我愿意举身投火,淬炼成金!永远不要忘记,激情的奋进,就是美好的未来!

您必须 登录 才能发表评论!