DevOps

Elasticsearch Index Lifecycle Management (ILM) в 2026 году: автоматическое управление индексами и оптимизация хранилища

Ruslan Ismailov Опубликовано 12 мин чтения
E

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

В production-среде Elasticsearch индексы растут непрерывно. Логи приложений, метрики, события аудита — всё это создаёт новые документы каждую секунду. Без автоматизации инженеры вынуждены вручную создавать новые индексы, переносить старые данные на холодные узлы, удалять устаревшие шарды и следить за балансом дискового пространства. При объёмах в сотни гигабайт в день это становится отдельной полноценной задачей.

Index Lifecycle Management (ILM) — встроенный механизм Elasticsearch, который решает эту проблему декларативно. Вы описываете политику жизненного цикла один раз, привязываете её к шаблону индекса или data stream, и кластер сам управляет перемещением, оптимизацией и удалением данных. В 2026 году ILM стал стандартом де-факто для любого highload-проекта на Elasticsearch.

Концепция ILM: фазы и их назначение

Политика ILM описывает последовательность фаз, через которые проходит индекс за время своей жизни. Каждая фаза соответствует определённому состоянию данных — от активной записи до архива.

Hot

Фаза активной записи и частого чтения. Индекс находится на быстрых узлах (обычно SSD). Здесь настраивается ролловер — условие, при котором создаётся новый индекс. Это ключевой механизм предотвращения разрастания одного индекса до неуправляемых размеров.

Warm

Данные больше не записываются, но читаются достаточно часто. На этой фазе выполняются force merge (слияние сегментов для уменьшения количества файлов) и shrink (уменьшение количества первичных шардов). Узлы warm обычно используют более медленные и дешёвые диски.

Cold

Данные читаются редко. Elasticsearch может перенести индекс на узлы cold или применить searchable snapshots — механизм, при котором индекс монтируется из объектного хранилища (S3, GCS, Azure Blob) без полного копирования на диск узла.

Frozen

Максимальная экономия ресурсов: индекс полностью выгружается из памяти и подгружается только при запросе. Время отклика значительно выше, чем в предыдущих фазах, но стоимость хранения минимальна. Подходит для данных, которые нужны эпизодически — например, для compliance-аудита.

Delete

Индекс удаляется по истечении заданного возраста или других условий. Это финальная фаза retention-политики.

Настройка политики ILM через REST API: пошаговое руководство

Создать политику ILM можно через Kibana (раздел Stack Management → Index Lifecycle Policies) или напрямую через REST API. Рассмотрим API-подход как наиболее воспроизводимый в CI/CD-пайплайнах.

Пример политики для логов приложения с retention 90 дней:

PUT _ilm/policy/app-logs-policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_primary_shard_size": "50gb",
            "max_age": "1d",
            "max_docs": 50000000
          },
          "set_priority": {
            "priority": 100
          }
        }
      },
      "warm": {
        "min_age": "3d",
        "actions": {
          "forcemerge": {
            "max_num_segments": 1
          },
          "shrink": {
            "number_of_shards": 1
          },
          "set_priority": {
            "priority": 50
          }
        }
      },
      "cold": {
        "min_age": "14d",
        "actions": {
          "searchable_snapshot": {
            "snapshot_repository": "my-s3-repository"
          },
          "set_priority": {
            "priority": 0
          }
        }
      },
      "frozen": {
        "min_age": "45d",
        "actions": {
          "searchable_snapshot": {
            "snapshot_repository": "my-s3-repository"
          }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

Обратите внимание: min_age в фазах warm, cold и далее отсчитывается от момента ролловера (создания нового индекса), а не от даты создания самого индекса. Это важно при диагностике задержек переходов между фазами.

Привязка политики к шаблону индекса и data stream

Политика ILM не применяется к индексам напрямую при каждом создании — она привязывается к index template. Все новые индексы, соответствующие шаблону, автоматически наследуют политику.

Пример создания component template с настройками ILM:

PUT _component_template/app-logs-settings
{
  "template": {
    "settings": {
      "index.lifecycle.name": "app-logs-policy",
      "index.lifecycle.rollover_alias": "app-logs",
      "number_of_shards": 3,
      "number_of_replicas": 1
    }
  }
}

Затем создаём index template, ссылающийся на component template:

PUT _index_template/app-logs-template
{
  "index_patterns": ["app-logs-*"],
  "data_stream": {},
  "composed_of": ["app-logs-settings"],
  "priority": 200
}

При использовании data stream (рекомендуемый подход с Elasticsearch 7.9+) поле "data_stream": {} автоматически активирует механизм ролловера без необходимости управлять псевдонимом вручную. Data stream всегда пишет в текущий backing index, а при ролловере создаётся следующий.

Ролловеры: условия и тонкости настройки

Ролловер — сердце ILM в фазе hot. Он создаёт новый индекс-преемник и переключает запись на него. Условия ролловера работают по принципу ИЛИ: достаточно выполнения любого одного.

  • max_primary_shard_size — максимальный размер первичного шарда (например, 50gb). Рекомендуемое значение для большинства случаев.
  • max_age — максимальный возраст индекса (например, 1d для суточной ротации логов).
  • max_docs — максимальное количество документов. Полезно при неравномерном объёме данных.
  • max_size — общий размер индекса (все шарды). Устарел в пользу max_primary_shard_size, но всё ещё поддерживается.

Для классических индексов (не data stream) необходимо создать начальный индекс с псевдонимом вручную:

PUT app-logs-000001
{
  "aliases": {
    "app-logs": {
      "is_write_index": true
    }
  }
}

После этого ILM будет автоматически создавать app-logs-000002, app-logs-000003 и так далее при выполнении условий ролловера.

Оптимизация хранилища: force merge, shrink, freeze и searchable snapshots

Force Merge

Elasticsearch хранит данные в сегментах Lucene. Каждый документ при индексации создаёт новые сегменты, которые периодически сливаются фоновым процессом. Force merge принудительно сливает все сегменты индекса в один (или заданное количество), что уменьшает использование памяти heap, ускоряет поиск и сокращает количество файловых дескрипторов. Выполняется только на индексах, доступных только для чтения.

Shrink

Операция shrink уменьшает количество первичных шардов индекса. Если индекс создан с 3 шардами, а данные активно не растут, shrink позволяет схлопнуть его до 1 шарда, снижая накладные расходы кластера. Новое количество шардов должно быть делителем исходного.

Searchable Snapshots

Это один из наиболее мощных инструментов оптимизации стоимости хранения в 2026 году. Вместо хранения индекса на дисках узлов Elasticsearch монтирует его прямо из snapshot-репозитория (S3, GCS). Данные кешируются локально только при обращении. В фазе frozen кеш минимален, что делает стоимость хранения сравнимой с raw-объектным хранилищем.

Для использования searchable snapshots необходимо зарегистрировать репозиторий:

PUT _snapshot/my-s3-repository
{
  "type": "s3",
  "settings": {
    "bucket": "my-elasticsearch-snapshots",
    "region": "eu-west-1",
    "base_path": "ilm-snapshots"
  }
}

Мониторинг состояния политик: Explain API и диагностика

Для проверки текущего состояния индекса в жизненном цикле используется Explain API:

GET app-logs-000001/_ilm/explain

Ответ содержит текущую фазу, действие, шаг и время последнего перехода. Типичные поля для анализа: phase, action, step, step_info (содержит сообщение об ошибке при сбое).

Наиболее частые проблемы и их причины:

  • Индекс застрял в фазе warm/cold — как правило, узлы с нужным атрибутом (data_warm, data_cold) недоступны или их нет в кластере. Проверьте настройки node allocation.
  • Shrink завис — индекс не переведён в режим read-only перед shrink. ILM делает это автоматически, но если на индексе есть активные write-запросы, операция заблокируется.
  • Ролловер не срабатывает — псевдоним не настроен как is_write_index, или для data stream не создан первый backing index через создание data stream.
  • Политика не применяется к новым индексам — index template имеет более низкий приоритет, чем конкурирующий шаблон. Проверьте поле priority в шаблоне.

Для просмотра всех индексов с ошибками ILM удобно использовать:

GET */_ilm/explain?only_errors=true

Интеграция ILM с микросервисной архитектурой

В microservices-окружении часто возникает вопрос: кто отвечает за создание индексов и применение политик? Практика 2026 года предлагает следующий подход.

Index template и политику ILM создаёт платформенная команда (DevOps/SRE) как часть инфраструктурного кода — Terraform, Ansible или через GitOps-пайплайн с вызовами REST API Elasticsearch. Сами микросервисы пишут данные в data stream (или псевдоним), не зная о деталях шардирования и ротации индексов.

Такое разделение ответственности позволяет:

  • Изменять политику retention без деплоя приложения.
  • Централизованно управлять стоимостью хранения.
  • Применять разные политики для разных сред (dev, staging, production) через разные шаблоны с разными паттернами имён.

При автоматическом создании data stream через REST API достаточно одного запроса — Elasticsearch сам создаст первый backing index и применит политику из шаблона:

PUT _data_stream/app-logs

Практический кейс: настройка ILM для логов с retention 90 дней

Рассмотрим полный сценарий для типичного production-приложения: микросервис генерирует структурированные JSON-логи, которые нужно хранить 90 дней. Первые 3 дня — горячий доступ, 3–14 дней — тёплый, 14–45 дней — холодный (searchable snapshot), 45–90 дней — замороженный, после — удаление.

Шаг 1: создание политики (см. пример выше в разделе REST API).

Шаг 2: создание маппинга через component template:

PUT _component_template/app-logs-mappings
{
  "template": {
    "mappings": {
      "properties": {
        "@timestamp": { "type": "date" },
        "service": { "type": "keyword" },
        "level": { "type": "keyword" },
        "message": { "type": "text" },
        "trace_id": { "type": "keyword" }
      }
    }
  }
}

Шаг 3: финальный index template, объединяющий всё:

PUT _index_template/app-logs-template
{
  "index_patterns": ["app-logs"],
  "data_stream": {},
  "composed_of": ["app-logs-settings", "app-logs-mappings"],
  "priority": 200,
  "_meta": {
    "description": "Template for application logs with 90-day retention"
  }
}

Шаг 4: активация data stream:

PUT _data_stream/app-logs

После этого микросервис может писать логи в индекс app-logs через стандартный bulk API. ILM автоматически выполнит всю цепочку переходов в течение 90 дней.

Для верификации настройки через несколько часов после запуска:

GET _data_stream/app-logs
GET app-logs/_ilm/explain

Заключение

Elasticsearch Index Lifecycle Management в 2026 году — это не просто удобная функция, а необходимый элемент любой production-архитектуры с Elasticsearch. Правильно настроенная политика ILM автоматически решает задачи ротации индексов, оптимизации дискового пространства через force merge и shrink, экономии затрат через searchable snapshots и соблюдения retention-требований через автоматическое удаление.

Ключевые рекомендации для практического применения: используйте data streams вместо классических индексов с псевдонимами, разделяйте ответственность между платформенной командой и разработчиками микросервисов, регулярно мониторьте состояние политик через Explain API и тестируйте переходы между фазами в staging-среде до применения в production. Инвестиция времени в правильную настройку ILM окупается многократно снижением операционной нагрузки и оптимизацией инфраструктурных затрат.

Технологии

Теги

Руслан Исмаилов

Senior Web / Backend разработчик. Senior web/backend разработчик с 9-летним опытом. Стек: PHP, Laravel, PostgreSQL, Redis, Docker, Kubernetes, REST, микросервисы, CI/CD. Подробнее обо мне →