We using elastic search on a single node and unassigned monitoring shards are piling up.
Where do those shards come from and how can they be avoided?
# curl http://localhost:9200/_cat/shards?pretty|grep UNASSIGNED
--:.monitoring-es-6-2021.02.08 0 r UNASSIGNED
--:.monitoring-es-6-2021.01.25 0 r UNASSIGNED
--.monitoring-es-6-2021.01.29 0 r UNASSIGNED
--.monitoring-es-6-2021.02.17 0 r UNASSIGNED
:-.monitoring-es-6-2021.01.20 0 r UNASSIGNED
-:--.monitoring-es-6-2021.01.31 0 r UNASSIGNED
-.monitoring-es-6-2021.02.01 0 r UNASSIGNED
-:-.monitoring-es-6-2021.02.09 0 r UNASSIGNED
-:.monitoring-es-6-2021.02.07 0 r UNASSIGNED
--.monitoring-es-6-2021.02.12 0 r UNASSIGNED
13.monitoring-es-6-2021.02.15 0 r UNASSIGNED
18k.monitoring-es-6-2021.02.16 0 r UNASSIGNED
.monitoring-es-6-2021.01.19 0 r UNASSIGNED
.monitoring-es-6-2021.01.22 0 r UNASSIGNED
.monitoring-es-6-2021.02.18 0 r UNASSIGNED
.monitoring-es-6-2021.02.11 0 r UNASSIGNED
.monitoring-es-6-2021.01.18 0 r UNASSIGNED
.monitoring-es-6-2021.01.24 0 r UNASSIGNED
....
We start elasticsearch using a docker image, form a Dockerfile like this:
ARG version=5.6.16
FROM docker.elastic.co/elasticsearch/elasticsearch:${version}
RUN /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-phonetic \
&& /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-icu
With this env:
environment:
- xpack.security.enabled=false
- discovery.type=single-node
- TAKE_FILE_OWNERSHIP=true
We found https://www.datadoghq.com/blog/elasticsearch-unassigned-shards/ but it seems to solve this only temporarily and would be needed to be executed regularily. We try to avoid a hacky cron job solution and want to solve the root cause :-)