Log flood stage disk watermark [95%] exceeded on – How To Solve Related Issues


Log flood stage disk watermark [95%] exceeded on – How To Solve Related Issues

Opster Team

Jan-20, Version: 1.7-8.0

 

Crossing high disk watermarks can be avoided if detected earlier. Before you read this guide, we strongly recommend you run the Elasticsearch Error Check-Up which detects issues in ES that cause ES errors and specifically problems that causes disk space to run out quickly. The tool can prevent flood disk watermark [95%] from being exceeded from occuring again.It’s a free tool that requires no installation and takes 2 minutes to complete. You can run the Check-Up here.

Quick Summary

The cause of this error is low disk space on a data node, and as a preventive measure, Elasticsearch throws this log message and takes some measures explained further. To pinpoint how to resolve issues causing flood stage disk watermark [95%] breached based on your specific use case run the free Check-Up. The tool has several checks on disk watermarks and can provide actionable recommendaions how to resolve and prevent this from occuring (even without increasing disk space).

Explanation

Elasticsearch considers the available disk space before deciding whether to allocate new shards, relocate shards away or put all indices on read mode based on a different threshold of this error. The reason is Elasticsearch indices consists of different shards which are persisted on data nodes and low disk space can cause issues.
Relevant settings related to log:
cluster.routing.allocation.disk.watermark – have three thresholds of low, high, and flood_stage and can be changed dynamically, accepting absolute values as well as percentage values.

Permanent fixes

a) Delete unused indices.
b) Merge segments to reduce the size of the shard on the affected node (read more here)
c) Attach external disk or increase the disk used by the data node.

Temp hack/fixes

a) Changed settings values to a higher threshold by dynamically update settings using update cluster API:

PUT _cluster/settings

{

""transient"": {

""cluster.routing.allocation.disk.watermark.low"": ""100gb"", -->adjust according to your situations

""cluster.routing.allocation.disk.watermark.high"": ""50gb"",

""cluster.routing.allocation.disk.watermark.flood_stage"": ""10gb"",

""cluster.info.update.interval"": ""1m""

}

}

b) Disable disk check by hitting below cluster update API

{

""transient"": {

""cluster.routing.allocation.disk.threshold_enabled"" : false

}

}

c) Even After all these fixes, Elasticsearch won’t bring indices in write mode for that this API needs to be hit.

PUT _all/_settings

{

""index.blocks.read_only_allow_delete"": null

}

Log Context

Log “Flood stage disk watermark [{}] exceeded on {}; all indices on this node will be marked read-only” classname is DiskThresholdMonitor.java
We extracted the following from Elasticsearch source code for those seeking an in-depth context :

      * Warn about the given disk usage if the low or high watermark has been passed
     */
    private void warnAboutDiskIfNeeded(DiskUsage usage) {
        // Check absolute disk values
        if (usage.getFreeBytes() 

 

Optimize Elasticsearch Performance

Try The Tool