Управление жизненным циклом индекса - это функция, которая помогает автоматизировать создание, управление и удаление индекса Elasticsearch.
Возможность автоматизировать создание нового индекса, когда индекс достигает оптимального размера в 50 ГБ на шард, очень полезна. Настройка индекса на основе времени с одним индексом в день или одним индексом в месяц, скорее всего, приведет к созданию шардов с оптимальным размером индекса. Слишком маленькие или слишком большие шарды могут вызывать различные проблемы - подробнее см. в этом руководстве.
Если в индекс больше не записываются данные, полезно оптимизировать его, чтобы сэкономить ресурсы кластера. Это может включать в себя:
- Принудительное слияние индекса, чтобы оптимизировать место, занимаемое индексом на диске.
- Сокращение индекса для уменьшения количества шардов.
- Распределение шарда на менее производительное / оптимизированное для хранения данных оборудование.
Когда срок службы индекса подходит к концу, мы можем захотеть:
- Убедиться, что снимок индекса был успешно сделан.
- Удалить индекс
Посмотрите видео ниже о важности настройки ILM в вашем развертывании.
Как настроить управление жизненным циклом индекса
Определите политику управления жизненным циклом
Политика управления жизненным циклом индекса может быть применена к любому количеству индексов. Политика состоит из нескольких определенных фаз и указывает действия, которые следует предпринять при переходе от одной фазы к другой.
В многоуровневой реализации Elasticsearch эти уровни называются "горячий", "теплый", "холодный" и "замороженный". И на протяжении своего жизненного цикла данные проходят их в таком порядке. Не обязательно реализовывать все уровни, в большинстве случаев присутствует только горячий уровень, поскольку он служит точкой входа - все политики должны начинаться с фазы HOT.
Переход от одной фазы к другой определяется временем, прошедшим с момента создания индекса. Дополнительные сведения об архитектуре "горячий-теплый-холодный" см. в Библии многоуровневой архитектуры. На диаграмме ниже показан пример многоуровневой архитектуры.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 | PUT _ilm/policy/hot_warm_delete { "policy": { "phases": { "hot": { "min_age": "0ms", "actions": { "rollover": { "max_size": "50gb", "max_age": "3d" }, "set_priority": { "priority": 50 } } }, "warm": { "min_age": "7d", "actions": { "forcemerge": { "max_num_segments": 1 }, "set_priority": { "priority": 25 }, "shrink": { "number_of_shards": 1 } } }, "delete": { "min_age": "15d", "actions": { "delete": { "delete_searchable_snapshot": true } } } } } } |
Вышеуказанная политика определяет следующее:
Горячая фаза
Во время горячей фазы новый индекс будет создан, когда его размер достигнет 50 ГБ или когда индексу исполнится 3 дня.
Теплая фаза
Через 7 дней горячий индекс переходит в теплую фазу. Индекс будет принудительно объединен, и будет выполнена операция сокращения, чтобы уменьшить индекс до одного шарда.
Фаза удаления
Через 15 дней индекс будет удален.
В данном случае не были настроены "холодная" и "замороженная" фазы.
Настройка шаблона для добавления политики ILM в настройки индекса
| 1 2 3 4 5 6 7 8 9 10 11 12 | PUT _index_template/my_apache_log { "index_patterns": ["my_apache_log*"], "template": { "settings": { "number_of_shards": 1, "number_of_replicas": 1, "index.lifecycle.name": "hot_warm_delete", "index.lifecycle.rollover_alias": "my_apache_log" } } } |
Приведенная выше команда создает шаблон индекса для применения политики hot_warm_delete, которую мы создали выше, к любым индексам с префиксом "my_apache_log".
Она также определяет псевдоним, который будет применяться к новому индексу, когда исходный индекс перевернется.
Ручное создание первого индекса
Нам нужно вручную создать первый индекс для серии my_apache_log.
| 1 2 3 4 5 6 7 8 | PUT my_apache_log-000001 { "aliases": { "my_apache_log": { "is_write_index": true } } } |
Приведенный выше индекс создает первый индекс с псевдонимом my_apache_log.
Затем нам нужно убедиться, что клиентское приложение отправляет все записи в псевдоним "my_apache_log" (а не в полное имя индекса). Elasticsearch будет записывать эти журналы в индекс my_apache_log-000001 до тех пор, пока этот индекс не достигнет размера 50 ГБ (как определено в нашей политике ILM), а затем свернет индекс, автоматически создав новый индекс my_apache_log-000002 и так далее.
Изменение политики ILM
Если вы измените политику ILM, изменения будут применены ко всем индексам, использующим эту политику. Однако изменения будут применены только для новых изменений фазы. Любые изменения фазы, которые уже были применены в предыдущих версиях политики, не могут быть откачены.
Действия ILM
Наиболее распространенными действиями являются переворачивание, принудительное слияние, ожидание моментального снимка и удаление. Однако возможны все следующие действия:
Действия ILM
Наиболее распространенными действиями являются переворачивание, принудительное слияние, ожидание моментального снимка и удаление. Однако возможны все следующие действия:
- Allocate - Распределить настройки для индекса, чтобы переместить шарды на разные узлы или изменить количество реплик.
- Delete - Удалить индекс.
- Force merge - Принудительно объединить индекс, чтобы оптимизировать структуру на диске.
- Freeze - Заморозить индекс, чтобы минимизировать занимаемую им память. Это подходит только для старых индексов, которые очень редко ищутся. Обратите внимание, что поиск в замороженном индексе займет несколько секунд или даже минут, поскольку некоторые структуры данных придется перестраивать на лету.
- Migrate - Перенести шарды индексов на уровень данных, используемый фазой ILM. Это целесообразно только в том случае, если в вашей архитектуре используются уровни данных.
- Read only - Только чтение, чтобы предотвратить запись в индекс.
- Rollover - для создания нового индекса для записи.
- Searchable snapshot - Искать по снимку индекса, чтобы включить использование этого механизма для снижения требований к памяти и диску для индексов с редким поиском.
- Set priority - Установить приоритет индекса, чтобы Elasticsearch знал, какие индексы нужно восстанавливать в первую очередь.
- Shrink - Сократить количество первичных шардов в индексе (при этом создается новый индекс).
- Unfollow - Отключить индекс кросс-кластерной репликации. Это подходит только для кластеров, использующих кросс-кластерную репликацию.
- Wait for snapshot - Дождаться моментального снимка перед удалением индекса.
Ошибки ILM
Если вы видите, что ILM ведет себя не так, как ожидалось, вы можете проверить состояние ILM в индексе с помощью следующей команды:
| 1 | GET /my-index-000001/_ilm/explain |
Внимательно прочитайте сообщение об ошибке и попытайтесь ее устранить. Как правило, ошибку можно устранить, либо изменив политику ILM, либо скорректировав настройки индекса. Как только вы это сделаете, вы можете выполнить эту команду:
| 1 | POST /my-index-000001/_ilm/retry |