Elasticsearch ILM не налаштовано: що ламається в кластері
Кластер, який запускали під логи й метрики, живе без правил: індекс на кожен день або на кожен сервіс, шаблон задано, а що робити з накопиченим далі — не описано.
Індекси зростають, шарди множаться, кожен день додає сегменти, і гарячий рівень перестає бути гарячим — він тримає і свіжі дані, і весь архів.
Перший помітний симптом — переповнення сховища на вузлах гарячого рівня.
Коли спрацьовують дискові водяні знаки, Elasticsearch переводить індекси в режим лише для читання, алокація нових шардів зупиняється, репліки перестають розміщуватися — кластер переходить у жовтий, потім у червоний стан.
Далі деградація йде ланцюжком: сегменти не об’єднуються, на один пошуковий запит сканується дедалі більше сегментів, час відгуку зростає.
Пошук і запис заважають одне одному, бо ділять одні й ті самі потоки, дисковий ввід-вивід і кеш. Індексація витісняє запити з кешу, черга пошуку переповнюється, клієнти отримують відмови за таймаутом — і сам запис при цьому не встигає скидати буфери.
Діагностика ускладнюється: кластер технічно живий, вузли виглядають терпимо, а відповідей користувачі вже не отримують.
Корінь проблеми не в обладнанні, а у відсутності описаного життєвого циклу індексів: нікому перевести старі дані на теплий і холодний рівні, об’єднати сегменти й видалити те, що вийшло за термін зберігання. Розбираємо, як це закривається ILM в Elasticsearch — від перекочування індексу до видалення.
Ефект керованого життєвого циклу індексів на бойовому кластері
Після впровадження ILM кластер перестає бути однорідним звалищем індексів. Свіжі дані пишуться на гарячий рівень із швидкими дисками, після фази ротації Elasticsearch переносить їх на теплий, а згодом на холодний — із щільним пакуванням сегментів.
Навантаження на пошук перерозподіляється: гарячий рівень обслуговує лише актуальне вікно, і запити за свіжими даними більше не конкурують з історією за місяці.
Ротація індексів прив’язана до розміру або кількості документів, а не до календаря. Індекс запису завжди обмежений, кількість сегментів передбачувана, пошук не розмазується по сотнях дрібних шардів.
Саме це дає стабільний час відгуку: він залежить від обсягу вибірки, а не від того, скільки записів накопичилося з попереднього ручного чищення.
Автоматичне видалення індексів закриває останнє джерело зростання. Політика утримання задає термін або кількість поколінь, решта зникає без участі людини. Обсяг збереженого стає передбачуваним — за графіком зростання видно, коли знадобиться ємність, а не коли закінчиться диск.
Зникає цілий клас відмов: переповнення диска, переведення шардів у режим лише для читання, нічні ручні чищення та аварійне перенесення даних під навантаженням.
Відкат на попередній реліз при цьому залишається можливим — старі покоління індексів живуть до спливання терміну утримання.
Схеми управління індексами: порівняння варіантів і обмежень
Схема управління індексами задає, на яких вузлах живуть свіжі дані, у який момент запускається перекладання даних на холодний рівень і що взагалі відбувається з індексом далі. Нижче — чотири схеми, між якими реально обирають на практиці, з їхніми обмеженнями.
| Схема | Коли підходить | Обмеження |
|---|---|---|
| Єдиний рівень | Невеликий обсяг, пошук лише за свіжими даними, звернення глибше місяця рідкі | Профіль вузлів не дешевшає з віком індексів, обсяг зростає — зростає й контур; архіву як окремої сутності немає |
| Два рівні: гарячий і теплий | Дані старші за кілька днів потрібні лише для звітів | Немає стадії видалення — реєстр зростає, доки його не почистять руками; теплий контур з часом отримує те саме навантаження, що й гарячий |
| Три рівні: гарячий, теплий, холодний з видаленням | Тривале зберігання з рідкими запитами, є вимоги щодо термінів зберігання | Помилка в умові видалення незворотна без знімка індексів; перекладання даних має встигати за надходженням, інакше холодний рівень переповнюється |
| Ручне адміністрування | Нерегулярний потік даних, разові завдання | Немає передбачуваності: індекс переноситься, коли про нього згадали, терміни зберігання порушуються мовчки |
Трирівнева схема закриває найбільше вимог, але її обмеження знімаються лише знімками індексів і явним контролем за перекладанням. Якщо знімків немає, видалення за віком — найнебезпечніше налаштування у всій конфігурації.
Порядок впровадження: від обстеження до передачі регламентів
Порядок робіт однаковий і для кластера на кілька вузлів, і для інсталяції з десятками терабайт: спочатку фіксуємо факти, потім проєктуємо, і лише згодом змінюємо налаштування.
Перестановка кроків — головна причина, через яку політики життєвого циклу починають видаляти потрібні дані або не спрацьовувати взагалі.
- Аудит кластера. Знімаємо фактичну картину: перелік індексів, швидкість зростання, розкид розмірів шардів, терміни зберігання, поточні шаблони та незакриті псевдоніми. Без цих цифр будь-який рівень hot-warm-cold проєктується навмання.
- Проєктування рівнів. Визначаємо, які дані залишаються на гарячому рівні, що переходить на теплий, що на холодний і в який момент видаляється. Окремо фіксуємо поведінку під час відмови вузла — політика не повинна залежати від єдиного екземпляра.
- Складання політик і шаблонів індексів. Пишемо самі правила переходу й прив’язуємо їх до шаблонів, щоб нові індекси підхоплювали життєвий цикл автоматично, а не через ручне втручання чергового.
- Перевірка на копії. Проганяємо політики на тестовому контурі з реальною структурою даних і прискореним часом переходів. Так помилки в умовах переходу видно до продакшену, а не через місяць на бойовому кластері.
- Викочування на робочий контур. Вмикаємо політики поетапно, групами індексів, з контролем стану переходів і можливістю відкотити правило, доки воно не зачепило старі дані.
- Передача регламентів. Віддаємо опис рівнів, схеми шаблонів, порядок додавання нових індексів та інструкцію, що робити при відхиленні переходу — щоб зміни далі вносилися без нас.
Ключ до результату — четвертий крок: перевірка на копії займає більше часу, ніж налаштування, але саме вона відділяє робочу політику від набору правдоподібних умов.
Комплект на виході: політики, шаблони, регламенти
Після впровадження ILM у команди залишається не «налаштований кластер», а відтворюваний комплект артефактів: за ним конфігурація піднімається на новому контурі й передається в супровід без нас.
Усе лежить у репозиторії та застосовується через керуючий інтерфейс, тому ручних правок в інтерфейсі не залишається.
- Політики управління індексами — переходи між рівнями hot-warm-cold, пороги за віком і розміром шарда, термін зберігання й видалення; окремими політиками під кожен клас даних: логи застосунків, аудит, метрики.
- Шаблони індексів і компонентні шаблони — мапінги, кількість шардів і реплік, прив’язка до політики за маскою імені, щоб новий індекс отримував налаштування автоматично.
- Схема рівнів — які вузли до яких ролей віднесено, де закінчується гарячий шар, як влаштовано холодне зберігання і який запас місця зарезервовано під відновлення.
- Політики доступу — ролі під збирачі логів, аналітиків і чергову зміну, окремі права на видалення індексів і роботу зі знімками.
- Знімки й відновлення — розклад, термін життя знімків і перевірений сценарій відкату індексу на потрібну дату.
- Регламенти та інструкції для команди — як завести новий індекс, як змінити термін зберігання, що робити при заповненні диска і як читати помилки політик.
- Моніторинг — дашборди й оповіщення за стадіями переходу, кроками, що відмовили, і зростанням обсягу даних.
Кейс: як розвантажили кластер і скоротили обсяг збереженого
Кластер пошуку за логами застосунків і подіями безпеки працював на одному профілі вузлів: запис, свіжі читання й архів лежали впереміш. Запити за свіжими даними відповідали швидко, але вибірки за квартал ішли в таймаут, а диск заповнювався швидше, ніж зростав потік подій.
Що було до
Розбір показав: індекси Elasticsearch писалися за днями без переходу за фазами, усі шарди жили на гарячих вузлах, репліка займала стільки ж місця, скільки основний шард.
Ротації індексів не було: старі видаляв черговий вручну, а злиття сегментів запускали лише після інциденту, коли пошук деградував. Час пошуку за 90 днів — до 8 секунд, частка даних на холодному рівні — нуль, ручних втручань — 9–12 на місяць.
Що зробили
Зібрали політику ILM: rollover за розміром шарда й віком індексу, потім фази — гаряча для запису та свіжих читань, тепла для даних тижневої давності, холодна для архіву.
На теплій фазі зняли репліки й увімкнули злиття сегментів до одного шарда на індекс, на холодній додали сильне стиснення. Видалення прив’язали до віку: дані старші за вікно зберігання зникають цілком, без команд чергового.
Метрики після
- Час пошуку за 90 днів: 8 секунд → 600–800 мс.
- Частка даних на холодному рівні: 0 → 71% обсягу.
- Обсяг збереженого: стиснення плюс видалення за віком скоротили втричі, зростання реєстру зупинилося.
- Ручні втручання чергового: 9–12 → 0 на місяць.
Клас відмов, який зник разом із цим, — переповнення диска й таймаути на історичних вибірках. Відкат залишився можливим: снапшоти знімаються за розкладом, а попередній індекс доступний до спливання вікна зберігання.
Чим відрізняється Elasticsearch ILM від ручного видалення індексів?
ILM — це політика, яка описує життєвий цикл індексу фазами: поки йде запис, індекс живе в гарячій фазі; за порогом розміру або віку політика перекочує його за аліасом на запис, знімає частину реплік, переносить шарди на холодні вузли, запускає злиття сегментів і на останньому переході видаляє індекс. Рішення ухвалює кластер, а інженер один раз задає правило й далі дивиться лише на метрики.
Ручна ротація влаштована інакше: індекс створюється за датою в імені, а чищення робить скрипт за розкладом або черговий руками.
Поки все йде за планом, різниця майже не видна, але вона проявляється у збої — завдання не відпрацювало, шаблон не застосувався, і старі добки залишилися на вузлах. Диск заповнюється, кількість шардів зростає, запис упирається в пороги заповнення.
Ціна помилки при ручному видаленні вища: команда за маскою легко зачіпає індекс, у який прямо зараз іде запис, а відкат потребує снапшота й означає втрату вікна даних.
В автоматизації видалення прив’язане до умов — індекс зникає лише після переходу у фазу видалення і лише якщо політика це дозволяє. Передбачуваність тримається на аліасі на запис, а не на домовленості в голові чергового.
Ручна ротація живе, доки живе її автор: іде інженер — застаріває скрипт, накопичуються винятки. Політика ж лежить у шаблоні поруч із мапінгом і успадковується новими індексами без додаткових дій.
Точково ручне видалення виправдане — разове чищення архіву, нестандартні вимоги зберігання, розбір інциденту, — але як постійний режим воно програє: правила переїжджають із голови чергового в конфігурацію, і обсяг реєстру перестає залежати від того, хто сьогодні на зміні.
Часті технічні питання щодо політик життєвого циклу
Політика життєвого циклу не вмикається сама по собі: її призначають індексу вручну або через шаблон. Фази рахуються від віку індексу, а не від моменту призначення, тому старий набір із великим терміном зберігання може одразу піти у видалення.
Перед увімкненням проганяємо розрахунок фаз на копії й звіряємо, на якому кроці опиниться кожен індекс.
Відкат залежить від того, що вже спрацювало. Перехід між рівнями зворотний: індекс повертають на гарячий рівень звичайним переїздом сегментів. Видалення незворотне — цю фазу вмикаємо останньою і лише за наявності знімків.
Чи можна застосувати політику до старих індексів?
Так — призначенням на наявний набір або через шаблон для нових. Політика не перераховує історію заново, тому для старих даних окремо перевіряємо, чи не спрацює перехід у видалення одразу після підключення.
Що робити, якщо видалення вже спрацювало?
Відновити індекс із останнього знімка і до повернення в потік призначити виправлену політику. Якщо знімків немає, дані не повернути — цей клас відмов закривається лише регулярними знімками й перевіркою відновлення.
Наскільки повільніший пошук на холодному рівні?
Помітно повільніший, і це ціна за обсяг: холодний рівень тримаємо на накопичувачах великого розміру з меншою швидкістю доступу. Туди виводимо лише те, що запитують рідко, — за статистикою звернень, а не за віком навмання.
Чи потрібні рівні на невеликому кластері?
На двох-трьох вузлах розділення дає мало: переїзди сегментів витрачають ресурси, а виграш у зберіганні невеликий. Достатньо однієї політики з контролем розміру індексів, знімками й видаленням останньою фазою.
Як вибирати терміни зберігання?
Від добового приросту й вимог до даних: рахуємо обсяг за день, множимо на термін і звіряємо з доступним місцем. Терміни задаємо за фазами — гаряча частина коротша, тепла й холодна довші, видалення в кінці.
Обговоримо задачу: як налаштувати життєвий цикл під ваш потік даних
Щоб правила життєвого циклу працювали на вашому реальному потоці, а не на тестовому індексі, потрібен короткий ввід від замовника: профіль запису за індексами, горизонт зберігання й вимоги до відновлення.
Із цим набором ми рахуємо навантаження на гарячий ярус, кількість переїздів між ярусами та обсяг, який піде під видалення, — і приходимо до оцінки та плану робіт.
Що варто надіслати, щоб оцінка була предметною:
- карту індексів і шаблонів: які сервіси пишуть, з якою частотою, середній і піковий розмір документа;
- вимоги до зберігання: скільки тримаємо в гарячому, теплому й холодному ярусі та що видаляємо безповоротно;
- допустиме вікно втрати даних і час відновлення після відмови вузла;
- поточні обмеження: кількість вузлів, типи дисків, вільне місце, актуальна гілка Elasticsearch;
- вікна обслуговування: коли можна рухати індекси, схлопувати сегменти й змінювати реплікацію;
- точки доступу й власник кластера — від кого отримуємо права на зміну політик;
- історію інцидентів: що вже ламалося і які індекси зростали швидше за прогноз.
Із цього набору починається налаштування життєвого циклу: політики, пороги переходу між ярусами, терміни видалення й правила відкату.
Після узгодження перевіряємо все на копії даних, виводимо в роботу й передаємо знання — регламенти, панелі моніторингу, розбір типових відмов, щоб ваша команда правила політики сама. Підтримка кластера залишається на нашій стороні, доки ви не вирішите інакше.
Опишіть задачу — обговоримо її та повернемося з оцінкою й планом.
