ILM-политики Elasticsearch: hot-warm-cold и удаление

Elasticsearch ILM не настроен: что ломается в кластере

Кластер, который запускали под логи и метрики, живёт без правил: индекс на каждый день или на каждый сервис, шаблон задан, а что с накопленным делать дальше — не описано. Индексы растут, шарды множатся, каждый день добавляет сегменты, и горячий уровень перестаёт быть горячим — он держит и свежие данные, и весь архив.

Первый заметный симптом — переполнение хранилища на узлах горячего уровня. Когда срабатывают дисковые водяные знаки, Elasticsearch переводит индексы в режим только для чтения, аллокация новых шардов останавливается, реплики перестают размещаться — кластер уходит в жёлтое, затем в красное состояние. Дальше деградация идёт по цепочке: сегменты не объединяются, на один поисковый запрос сканируется всё больше сегментов, время отклика растёт.

Поиск и запись мешают друг другу, потому что делят одни и те же потоки, дисковый ввод-вывод и кэш. Индексация вытесняет запросы из кэша, очередь поиска переполняется, клиенты получают отказы по таймауту — и сама запись при этом не успевает сбрасывать буферы. Диагностика осложняется: кластер технически жив, узлы выглядят терпимо, а ответов пользователи уже не получают.

Корень проблемы не в оборудовании, а в отсутствии описанного жизненного цикла индексов: некому перевести старые данные на тёплый и холодный уровни, объединить сегменты и удалить вышедшее за срок хранения. Разбираем, как это закрывается ILM в Elasticsearch — от переката индекса до удаления.

Эффект управляемого жизненного цикла индексов на боевом кластере

После внедрения ILM кластер перестаёт быть однородной свалкой индексов. Свежие данные пишутся на горячий уровень с быстрыми дисками, после фазы ротации Elasticsearch переносит их на тёплый, а затем на холодный — с плотной упаковкой сегментов. Нагрузка на поиск перераспределяется: горячий уровень обслуживает только актуальное окно, и запросы по свежим данным больше не конкурируют с историей за месяцы.

Ротация индексов привязана к размеру или числу документов, а не к календарю. Индекс записи всегда ограничен, число сегментов предсказуемо, поиск не размазывается по сотням мелких шардов. Именно это даёт стабильное время отклика: оно зависит от объёма выборки, а не от того, сколько записей накопилось с прошлой ручной чистки.

Автоматическое удаление индексов закрывает последний источник роста. Политика удержания задаёт срок или число поколений, остальное уходит без участия человека. Объём хранимого становится предсказуемым — по графику роста видно, когда понадобится ёмкость, а не когда закончится диск.

Уходит целый класс отказов: переполнение диска, перевод шардов в режим только для чтения, ночные ручные чистки и аварийный перенос данных под нагрузкой. Откат на предыдущий релиз при этом остаётся возможным — старые поколения индексов живут до истечения срока удержания.

Схемы управления индексами: сравнение вариантов и ограничений

Схема управления индексами задаёт, на каких узлах живут свежие данные, в какой момент запускается перекладка данных на холодный уровень и что вообще происходит с индексом дальше. Ниже — четыре схемы, между которыми реально выбирают на практике, с их ограничениями.

Трёхуровневая схема закрывает больше всего требований, но её ограничения снимаются только снимками индексов и явным контролем за перекладкой. Если снимков нет, удаление по возрасту — самая опасная настройка во всей конфигурации.

Порядок внедрения: от обследования до передачи регламентов

Порядок работ одинаков и для кластера на несколько узлов, и для инсталляции с десятками терабайт: сначала фиксируем факты, потом проектируем, и только затем меняем настройки. Перестановка шагов — главная причина, по которой политики жизненного цикла начинают удалять нужные данные или не срабатывать вовсе.

1. Аудит кластера. Снимаем фактическую картину: перечень индексов, скорость роста, разброс размеров шардов, сроки хранения, текущие шаблоны и незакрытые псевдонимы. Без этих цифр любой уровень hot-warm-cold проектируется наугад.
2. Проектирование уровней. Определяем, какие данные остаются на горячем уровне, что уходит на тёплый, что на холодный и в какой момент удаляется. Отдельно фиксируем поведение при отказе узла — политика не должна зависеть от единственного экземпляра.
3. Сборка политик и шаблонов индексов. Пишем сами правила перехода и привязываем их к шаблонам, чтобы новые индексы подхватывали жизненный цикл автоматически, а не по ручному вмешательству дежурного.
4. Проверка на копии. Прогоняем политики на тестовом контуре с реальной структурой данных и ускоренным временем переходов. Так ошибки в условиях перехода видны до продакшена, а не через месяц на боевом кластере.
5. Выкатка на рабочий контур. Включаем политики поэтапно, группами индексов, с контролем состояния переходов и возможностью откатить правило, пока оно не затронуло старые данные.
6. Передача регламентов. Отдаём описание уровней, схемы шаблонов, порядок добавления новых индексов и инструкцию, что делать при отклонении перехода — чтобы изменения дальше вносились без нас.

Ключ к результату — четвёртый шаг: проверка на копии занимает больше времени, чем настройка, но именно она отделяет работающую политику от набора правдоподобных условий.

Комплект на выходе: политики, шаблоны, регламенты

После внедрения ILM у команды остаётся не «настроенный кластер», а воспроизводимый комплект артефактов: по нему конфигурация поднимается на новом контуре и передаётся в сопровождение без нас. Всё лежит в репозитории и применяется через управляющий интерфейс, поэтому ручных правок в интерфейсе не остаётся.

• Политики управления индексами — переходы между уровнями hot-warm-cold, пороги по возрасту и размеру шарда, срок хранения и удаление; отдельными политиками под каждый класс данных: логи приложений, аудит, метрики.
• Шаблоны индексов и компонентные шаблоны — маппинги, число шардов и реплик, привязка к политике по маске имени, чтобы новый индекс получал настройки автоматически.
• Схема уровней — какие узлы к каким ролям отнесены, где заканчивается горячий слой, как устроено холодное хранение и какой запас места зарезервирован под восстановление.
• Политики доступа — роли под сборщики логов, аналитиков и дежурную смену, отдельные права на удаление индексов и работу со снимками.
• Снимки и восстановление — расписание, срок жизни снимков и проверенный сценарий отката индекса на нужную дату.
• Регламенты и инструкции для команды — как завести новый индекс, как изменить срок хранения, что делать при заполнении диска и как читать ошибки политик.
• Мониторинг — дашборды и оповещения по стадиям перехода, отказавшим шагам и росту объёма данных.

Кейс: как разгрузили кластер и сократили объём хранимого

Кластер поиска по логам приложений и событиям безопасности работал на одном профиле узлов: запись, свежие чтения и архив лежали вперемешку. Запросы по свежим данным отвечали быстро, но выборки за квартал уходили в таймаут, а диск заполнялся быстрее, чем рос поток событий.

Что было до

Разбор показал: индексы Elasticsearch писались по дням без перехода по фазам, все шарды жили на горячих узлах, реплика занимала столько же места, сколько основной шард. Ротации индексов не было: старые удалял дежурный вручную, а слияние сегментов запускали только после инцидента, когда поиск деградировал. Время поиска по 90 дням — до 8 секунд, доля данных на холодном уровне — ноль, ручных вмешательств — 9–12 в месяц.

Что сделали

Собрали политику ILM: rollover по размеру шарда и возрасту индекса, затем фазы — горячая для записи и свежих чтений, тёплая для данных недельной давности, холодная для архива. На тёплой фазе сняли реплики и включили слияние сегментов до одного шарда на индекс, на холодной добавили сильное сжатие. Удаление привязали к возрасту: данные старше окна хранения уходят целиком, без команд дежурного.

Метрики после

• Время поиска по 90 дням: 8 секунд → 600–800 мс.
• Доля данных на холодном уровне: 0 → 71% объёма.
• Объём хранимого: сжатие плюс удаление по возрасту сократили втрое, рост реестра остановился.
• Ручные вмешательства дежурного: 9–12 → 0 в месяц.

Класс отказов, который ушёл вместе с этим, — переполнение диска и таймауты на исторических выборках. Откат остался возможным: снапшоты снимаются по расписанию, а предыдущий индекс доступен до истечения окна хранения.

Чем отличается Elasticsearch ILM от ручного удаления индексов?

ILM — это политика, которая описывает жизненный цикл индекса фазами: пока идёт запись, индекс живёт в горячей фазе; по порогу размера или возраста политика перекатывает его по алиасу на запись, снимает часть реплик, переносит шарды на холодные узлы, запускает слияние сегментов и на последнем переходе удаляет индекс. Решения принимает кластер, а инженер один раз задаёт правило и дальше смотрит только на метрики.

Ручная ротация устроена иначе: индекс создаётся по дате в имени, а чистку делает скрипт по расписанию или дежурный руками. Пока всё идёт по плану, разница почти не видна, но она проявляется в сбое — задача не отработала, шаблон не применился, и старые сутки остались на узлах. Диск заполняется, число шардов растёт, запись упирается в пороги заполнения.

Цена ошибки при ручном удалении выше: команда по маске легко задевает индекс, в который прямо сейчас идёт запись, а откат требует снапшота и означает потерю окна данных. В автоматизации удаление привязано к условиям — индекс уходит только после перехода в фазу удаления и только если политика это разрешает. Предсказуемость держится на алиасе на запись, а не на договорённости в голове дежурного.

Ручная ротация живёт, пока живёт её автор: уходит инженер — устаревает скрипт, копятся исключения. Политика же лежит в шаблоне рядом с маппингом и наследуется новыми индексами без дополнительных действий. Точечно ручное удаление оправдано — разовая чистка архива, нестандартные требования хранения, разбор инцидента, — но постоянным режимом оно проигрывает: правила уезжают из головы дежурного в конфигурацию, и объём реестра перестаёт зависеть от того, кто сегодня на смене.

Частые технические вопросы по политикам жизненного цикла

Политика жизненного цикла не включается сама по себе: её назначают индексу вручную или через шаблон. Фазы считаются от возраста индекса, а не от момента назначения, поэтому старый набор с большим сроком хранения может сразу уйти в удаление. Перед включением прогоняем расчёт фаз на копии и сверяем, на каком шаге окажется каждый индекс.

Откат зависит от того, что уже сработало. Переход между уровнями обратим: индекс возвращают на горячий уровень обычным переездом сегментов. Удаление необратимо — эту фазу включаем последней и только при наличии снимков.

Что делать, если удаление уже сработало?

Восстановить индекс из последнего снимка и до возврата в поток назначить исправленную политику. Если снимков нет, данные не вернуть — этот класс отказов закрывается только регулярными снимками и проверкой восстановления.

Насколько медленнее поиск на холодном уровне?

Заметно медленнее, и это цена за объём: холодный уровень держим на накопителях большого размера с меньшей скоростью доступа. Туда уводим только то, что запрашивают редко, — по статистике обращений, а не по возрасту вслепую.

Нужны ли уровни на небольшом кластере?

На двух-трёх узлах разделение даёт мало: переезды сегментов расходуют ресурсы, а выигрыш в хранении невелик. Достаточно одной политики с контролем размера индексов, снимками и удалением последней фазой.

Как выбирать сроки хранения?

От суточного прироста и требований к данным: считаем объём за день, умножаем на срок и сверяем с доступным местом. Сроки задаём по фазам — горячая часть короче, тёплая и холодная дольше, удаление в конце.

Обсудим задачу: как настроить жизненный цикл под ваш поток данных

Чтобы правила жизненного цикла работали на вашем реальном потоке, а не на тестовом индексе, нужен короткий ввод от заказчика: профиль записи по индексам, горизонт хранения и требования к восстановлению. С этим набором мы считаем нагрузку на горячий ярус, число переездов между ярусами и объём, который уйдёт под удаление, — и приходим к оценке и плану работ.

Что стоит прислать, чтобы оценка была предметной:

• карту индексов и шаблонов: какие сервисы пишут, с какой частотой, средний и пиковый размер документа;
• требования к хранению: сколько держим в горячем, тёплом и холодном ярусе и что удаляем безвозвратно;
• допустимое окно потери данных и время восстановления после отказа узла;
• текущие ограничения: число узлов, типы дисков, свободное место, актуальная ветка Elasticsearch;
• окна обслуживания: когда можно двигать индексы, схлопывать сегменты и менять репликацию;
• точки доступа и владельца кластера — от кого получаем права на изменение политик;
• историю инцидентов: что уже ломалось и какие индексы росли быстрее прогноза.

С этого набора начинается настройка жизненного цикла: политики, пороги перехода между ярусами, сроки удаления и правила отката. После согласования проверяем всё на копии данных, выводим в работу и передаём знания — регламенты, панели мониторинга, разбор типовых отказов, чтобы ваша команда правила политики сама. Поддержка кластера остаётся на нашей стороне, пока вы не решите иначе.

Опишите задачу — обсудим её и вернёмся с оценкой и планом.