На кластере Elasticsearch существуют различные пороговые значения "watermark". По мере заполнения диска на узле первым порогом, который будет преодолен, будет "low disk watermark ". Вторым порогом будет " high disk watermark". Наконец, будет достигнута "disk flood stage". После прохождения этого порога кластер заблокирует запись во ВСЕ индексы, имеющие один шард (основной или реплику) на узле, прошедшем "водяной знак". Чтение (поиск) по-прежнему будет возможно.
Пример ошибки:
1 | FATAL Error: Unable to complete saved object migrations for the [.kibana_task_manager] index. Please check the health of your Elasticsearch cluster and try again. Unexpected Elasticsearch ResponseError: statusCode: 429, method: PUT, url: /.kibana_task_manager_7.17.6_001/_mapping?timeout=60s error: [cluster_block_exception]: index blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block];, |
Как решить проблему
Превышение этого порога приводит к потере данных в приложении, поэтому не следует медлить с принятием мер. Ниже перечислены возможные действия, которые можно предпринять для решения этой проблемы:
- Удалить старые индексы
- Удалить документы из существующих индексов
- Увеличить дисковое пространство на узле
- Добавить в кластер новые узлы данных.
Хотя удаление данных может быть нежелательным, в системе протоколирования часто лучше удалить старые индексы (которые впоследствии можно будет восстановить из моментального снимка, если он будет доступен), чем потерять новые данные. Однако это решение будет зависеть от архитектуры системы и имеющихся механизмов организации очередей.
Проверка дискового пространства на каждом узле
Вы можете посмотреть свободное дисковое пространство на каждом узле, выполнив команду:
1 | GET _nodes/stats/fs |
Проверьте, выполняется ли ребалансировка кластера
Если был пройден высокий уровень, то Elasticsearch должен начать перебалансировку на другие узлы, которые все еще находятся ниже низкого уровня. Проверить, происходит ли ребалансировка, можно с помощью вызова:
1 | GET _cluster/health/ |
Если вам кажется, что ваш кластер должен перераспределять шарды на другие узлы, но этого не происходит, то, вероятно, этому мешают какие-то другие правила распределения кластера. Наиболее вероятными причинами являются:
- Другие узлы уже находятся выше отметки "низкий уровень диска".
- Существуют правила распределения кластера, которые регулируют распределение шардов между узлами и противоречат требованиям ребалансировки. (например, распределение по зонам)
- Выполняется слишком много операций ребалансировки
- На других узлах уже имеются реплики тех шардов, которые могут быть ребалансированы
Проверка настроек кластера
Просмотреть примененные настройки можно с помощью этой команды:
1 | GET _cluster/settings |
Если они не подходят, их можно изменить с помощью команды, приведенной ниже:
1 2 3 4 5 6 7 8 9 10 | PUT _cluster/settings { "transient": { "cluster.routing.allocation.disk.watermark.low": "85%", "cluster.routing.allocation.disk.watermark.high": "90%", "cluster.routing.allocation.disk.watermark.flood_stage": "95%", "cluster.info.update.interval": "1m" } } |
Как предотвратить достижение этой стадии
Существуют различные механизмы, позволяющие автоматически удалять устаревшие данные.
Как автоматически удалять устаревшие данные:
- Применить ILM (Index Lifecycle Management)
Используя ILM, можно заставить Elasticsearch автоматически удалять индекс, когда текущий размер индекса достигает заданного возраста. - Использование индексов, основанных на дате
Если в вашем приложении используются индексы, основанные на дате, то старые индексы легко удалить с помощью скрипта или такого инструмента, как Elasticsearch curator. - Использование моментальных снимков для автономного хранения данных
Может оказаться целесообразным хранить моментальные снимки данных в автономном режиме и восстанавливать их в том случае, если архивные данные необходимо просмотреть или изучить. - Автоматизация/упрощение процесса добавления новых узлов данных
Используйте средства автоматизации, такие как terraform, для автоматизации процесса добавления новых узлов в кластер. Если это невозможно, то, по крайней мере, убедитесь, что у вас есть четко документированный процесс создания новых узлов, добавления сертификатов TLS и конфигурации и включения их в кластер Elasticsearch в короткие и предсказуемые сроки.