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

Как заставить Elasticsearch сам переносить стареющие логи на дешёвое хранилище и удалять совсем старые.

ILM (Index Lifecycle Management) — механизм Elasticsearch, автоматически проводящий индекс логов через фазы жизни (hot → warm → cold → delete) по заданным правилам времени и размера.

Зачем управлять жизненным циклом

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

Четыре фазы

  hot (0-3 дня)  -->  warm (3-30 дней)  -->  cold (30-90)  -->  delete (90+)
   SSD, пишем          медленнее            дёшево, сжато       удаляем
   читаем часто        читаем редко         почти не читаем

Пример политики

Политика ILM — это JSON, описывающий переходы. Вот типичная политика для логов: rollover активного индекса при 50 ГБ или 1 дне, через 7 дней — в warm, через 30 — в cold, через 90 — удалить:

{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": { "max_size": "50gb", "max_age": "1d" }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": { "forcemerge": { "max_num_segments": 1 } }
      },
      "cold": {
        "min_age": "30d",
        "actions": { "freeze": {} }
      },
      "delete": {
        "min_age": "90d",
        "actions": { "delete": {} }
      }
    }
  }
}

Самое ценное здесь — фаза delete. Без неё индексы растут вечно и однажды забивают диск под ноль — классическая причина падения кластера логов.

Как работает под капотом

ILM не демон, который ежесекундно крутит данные. Elasticsearch периодически (по умолчанию раз в 10 минут) проверяет каждый индекс: в какой он фазе, выполнено ли условие перехода (min_age с момента rollover, размер). Если да — выполняет действия фазы. forcemerge в warm сливает сегменты Lucene в один, экономя место и ускоряя чтение того, что больше не пишется. Перенос между фазами физически перемещает шарды на узлы с соответствующим «ярлыком» (data tier: data_hot, data_warm, data_cold) — так горячие данные оказываются на SSD-узлах, а холодные на дешёвых.

Как подобрать сроки фаз

Конкретные сроки фаз — это всегда компромисс между удобством доступа, надёжностью и стоимостью, и универсального ответа нет; их подбирают под профиль команды. Отправная точка — спросить: как долго логи реально нужны «под рукой» для оперативного разбора (обычно дни-недели — это hot/warm), как долго их вообще может понадобиться поднять (месяцы — cold), и какой срок диктует комплаенс или закон (иногда годы — тогда холодную фазу или архив в дешёвое объектное хранилище растягивают надолго). Ошибка в обе стороны дорога: слишком короткое удаление — и вы не можете расследовать инцидент недельной давности; слишком длинное хранение горячими — и вы платите за SSD под данные, которые никто не читает.

Полезный приём — разные политики для разных классов логов. Логи аудита и безопасности часто обязаны храниться долго и удаляться поздно; шумные DEBUG-логи приложения можно удалять через считанные дни. Привязав к разным индексам разные ILM-политики через шаблоны, вы не платите за долгое хранение того, что не нужно долго, и не теряете рано то, что нужно хранить. Единая политика «на всё» почти всегда либо переплата, либо риск — классы логов слишком разные по ценности и сроку жизни.

Частые ошибки

• Нет фазы delete. Самая дорогая ошибка: логи копятся, диск кончается, кластер встаёт. Всегда задавайте срок удаления.
• min_age считают не оттуда. min_age отсчитывается от момента rollover индекса, а не от текущего времени или времени события. Непонимание этого ломает ожидания по срокам.
• forcemerge на горячем индексе. forcemerge тяжёлый и нужен на индексах, в которые больше не пишут (warm). На активном hot-индексе он навредит.

Итоги

• ILM автоматически стареет логи по фазам hot → warm → cold → delete, перенося их на всё более дешёвое хранилище.
• Фаза delete обязательна — без неё индексы растут вечно и забивают диск.
• Переходы происходят по min_age (от момента rollover) и размеру; ES проверяет условия периодически.
• Data tiers (data_hot/warm/cold) физически кладут шарды на подходящие узлы.