ILM: горячие, тёплые и холодные данные

Вчера индекс логов занимал 200 ГБ, сегодня 220. Если ничего не менять, поиск будет работать, пока не кончится диск. У библиотекаря новые газеты лежат на столе, прошлую неделю он убирает на полку, старые выпуски в архив, а ненужные списывает. Логи тоже проходят возрастные этапы, и правила можно задать заранее.

Четыре нужные нам фазы

ILM

работает в Elasticsearch, не в Kibana. Kibana лишь помогает настроить политику.

Фаза	Что ожидаем от логов
hot	принимаем запись, часто ищем, быстрые диски
warm	новых записей нет, ищем реже
cold	редкий поиск по старым данным
delete	удаляем индекс целиком

Есть и frozen, обычно связанная с частично смонтированными searchable snapshots. Для первых 30 дней она нам не нужна. Для серверного Elasticsearch можно выбирать ILM; в Elasticsearch Serverless применяют data stream lifecycle, а не ILM. Возможности searchable snapshots и действие конкретной подписки сверяй отдельно.

Возраст чего именно

Ролловер из урока про data streams открывает новый backing-индекс. Возраст для следующих фаз ILM считают от времени ролловера предыдущего индекса, не от @timestamp каждой строки. Без ролловера основой служит дата создания индекса.

Поэтому delete.min_age: "30d" не означает «удалить каждую запись ровно на тридцатый день её жизни». Поздняя июньская запись, пришедшая в июле, попадёт в текущий индекс и проживёт вместе с ним. Для требования о точном сроке удаления личных данных такое округление надо учитывать.

Политика и привязка

1. Создай политику через PUT /_ilm/policy/имя.
2. Привяжи её настройкой index.lifecycle.name в шаблоне будущих индексов.
3. Начни писать в data stream, созданный по этому шаблону.
4. Проверяй GET /имя/_ilm/explain: политика существует и назначена, фаза и шаг понятны.

Для production hot-ролловер обычно ограничивают max_primary_shard_size: "50gb" и max_age: "1d" после оценки нагрузки. Любое выполненное max_* разрешает переход, но все заданные min_* должны выполняться. По умолчанию пустые write-индексы ILM не переключает.

Открой новую тетрадь

В браузере часы фиксированы. Мы сохраняем политику с порогом 100 документов, но проверяем ручной условный rollover уже после двух документов. Поэтому автоматический ILM не переключит индекс раньше нашего запроса. Мы не ждём 30 дней и не притворяемся, что здесь есть cold-узлы. Фазы без действий ниже описывают сроки, но не переносят байты между дисками.

После переключения два документа остаются в старом индексе, а новое поколение принимает следующие записи. Измени условие запроса _rollover на max_docs: 3: без третьего документа ответ покажет rolled_over: false. Имя policy само по себе ничего не удаляет, нужна настройка на индексах.