Closed jmvermeulen closed 1 year ago
First of all, a friendly reminder that we ask people to fill in the issue template for good reasons. Your issue report is omitting almost all requested logs, and one error in isolation doesn't provide enough context for solving most issues.
If this is indeed an authentication issue, please share the output of docker compose logs setup
(example) so we can at least confirm that the kibana_system
user was initialized correctly.
If not, the root cause is hidden somewhere else in the logs.
One wild guess—without seeing the logs—maybe Elasticsearch is throwing the following error (sanitized and pretty printed for readability):
{
"log.level": "WARN",
"message": "high disk watermark [90%] exceeded on [7dX6kMvsRvmjXZVi0ugi_w][ecfad7cdffbc][/usr/share/elasticsearch/data] free: 4.6gb[9.9%], shards will be relocated away from this node; currently relocating away shards totalling [0] bytes; the node is expected to continue to exceed the high disk watermark when these relocations are complete",
"process.thread.name": "elasticsearch[ecfad7cdffbc][masterService#updateTask][T#1]",
"log.logger": "org.elasticsearch.cluster.routing.allocation.DiskThresholdMonitor"
}
This is an indicator that your disk is dangerously full (> 90%), in which case Elasticsearch's default behaviour is to switch to read-only mode.
If you see such error in your logs, consider setting watermarks for disk usage higher than the default values in your Elasticsearch config:
cluster.routing.allocation.disk.watermark.high: 95%
cluster.routing.allocation.disk.watermark.flood_stage: 97%
Cross-referencing https://github.com/deviantony/docker-elk/issues/729#issuecomment-1170571124
Indeed it was the disk space..! Thank you.
One wild guess—without seeing the logs—maybe Elasticsearch is throwing the following error (sanitized and pretty printed for readability):
{ "log.level": "WARN", "message": "high disk watermark [90%] exceeded on [7dX6kMvsRvmjXZVi0ugi_w][ecfad7cdffbc][/usr/share/elasticsearch/data] free: 4.6gb[9.9%], shards will be relocated away from this node; currently relocating away shards totalling [0] bytes; the node is expected to continue to exceed the high disk watermark when these relocations are complete", "process.thread.name": "elasticsearch[ecfad7cdffbc][masterService#updateTask][T#1]", "log.logger": "org.elasticsearch.cluster.routing.allocation.DiskThresholdMonitor" }
This is an indicator that your disk is dangerously full (> 90%), in which case Elasticsearch's default behaviour is to switch to read-only mode.
If you see such error in your logs, consider setting watermarks for disk usage higher than the default values in your Elasticsearch config:
cluster.routing.allocation.disk.watermark.high: 95% cluster.routing.allocation.disk.watermark.flood_stage: 97%
Cross-referencing #729 (comment)
It actually worked. I'm suprised, what kind of relations is there between authentication user and disk space. Weird.
@mnuriyumusak the relation is that docker-elk's setup
container needs to write into the .security-7
index to enable the kibana_system
user (disabled by default), but this index is read-only due to the high disk watermark. Meanwhile Kibana keeps trying to authenticate, so you see these authentication errors on top of the watermark errors.
Hello,
A fresh
docker compose up
gives authentication errors. Tried to build first, removed all docker cache etc. Nothing works.Do you have a suggestion?
"org.elasticsearch.action.UnavailableShardsException: at least one primary shard for the index [.security-7] is unavailable