Чому логи переповнюють диск: де ламається ротація логів
Безконтрольне зростання файлів логів виглядає нешкідливо, поки є вільне місце: сервіс відкриває файл на дозапис і тримає дескриптор, а розмір збільшується на кожен запит, помилку та запис журналу.
Поки ротацію налаштовано, файл закривається за розміром або за календарем — за її відсутності єдиним запобіжником залишається вільне місце на розділі. Типова історія: увімкнули докладне логування на час розбору інциденту, забули повернути рівень назад, і за добу диск заповнений.
Насамперед за нестачі місця на диску деградує не сервіс, а запис: застосунок отримує від файлової системи відмову за місцем, буфери журналу перестають скидатися, частина повідомлень втрачається, а за необробленого винятку падає й сам процес.
Збій запису логів рідко виглядає як аварія — частіше це «сервіс відповідає, але нічого не логує», і розбір інциденту доводиться вести наосліп. Окрема пастка — видалення файлу вручну: місце не повертається, поки процес тримає відкритий дескриптор.
У контейнерах картина та сама, тільки файл на кожен контейнер створює драйвер журналювання, і без обмежень за розміром та кількістю файлів він зростає разом із навантаженням.
Базова страховка — logrotate: ротація за розміром і календарем, ліміт на кількість збережених архівів, стиснення та коректне повторне відкриття дескриптора.
Далі розбираємо, як це закривається на рівні системи й сервісів: від політик зберігання до контролю зайнятого місця та оповіщень про переповнення диска логами.
Що дає керована ротація та зберігання логів
Керована ротація — це не «увімкнути logrotate і забути», а набір правил: за якими умовами файл закривається і стискається, скільки копій живе локально, що йде в довготривале сховище і за яким терміном видаляється.
Правила формулюються в розмірах і часі, а не «коли стане багато», тому обсяг логів у реєстрі перестає бути сюрпризом, а політика зберігання логів стає перевірюваною, а не декларативною.
Що видно в метриках після переведення на керовану схему:
- Зайняте місце на вузлі коливається в відомому коридорі: ротація за розміром спрацьовує раніше, ніж розділ упирається в межу, і клас відмов «сервіс упав через переповнений диск» зникає зі статистики.
- Стиснені архіви займають у рази менше вихідного обсягу, тому глибина історії зростає без зростання сховища.
- Час розбору інциденту скорочується: потрібний інтервал лежить в одному файлі з зрозумілим ім’ям і міткою періоду, а не розмазаний по десятках незротованих логів.
- Пошук за архівами залишається швидким, бо межі файлів збігаються з межами діб і часових поясів сервісу.
- Видалення відбувається за терміном, а не за залишком місця, — очищення перестає бути аварійною операцією під навантаженням.
- Налаштування лежать у системі керування конфігурацією, тому новий вузол отримує ту саму політику без ручного редагування.
Підсумок — передбачуваний обсяг реєстру та стабільність сервісу: місце на диску перестає бути змінною, що впливає на доступність, а черговий під час розбору інциденту одразу знає, де шукати дані. Далі розберемо, які параметри задають ці межі та як їх перевіряти.
Порівняння підходів до ротації логів: розмір, час, надсилання
Передбачуваність ротації — це вибір між передбачуваним розміром файлу та передбачуваним моментом зрізу. Ротація за розміром спрацьовує, коли файл перевищив заданий поріг, тому місце на диску не закінчиться навіть за сплеску навантаження.
Ротація за розкладом прив’язана до хвилин або годин, і тоді файл за потрібний період лежить одним шматком — з ним зручно зіставляти розгортання нової версії або розбір інциденту.
Обидві схеми закривають лише першу половину завдання — звільнити місце. Друга половина в тому, що робити зі зрізаним файлом: стискати на місці, складати в архів або одразу надсилати до зовнішнього сховища логів, де пошук іде по всіх вузлах одразу, а не по кожному по черзі.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ротація за розміром | Рівний потік записів, щільно зайнятий диск, вузли з жорсткою квотою | Момент зрізу непередбачуваний: за піку файл дробиться на десятки дрібних частин |
| Ротація за розкладом | Регулярне навантаження, аудит, прив’язка логів до вікон розгортання | Між зрізами місце може закінчитися; у тихі години з’являються порожні файли |
| Надсилання до зовнішнього сховища | Багато вузлів, потрібен єдиний пошук і термін зберігання за класами даних | Залежить від каналу й самого сховища — на місці все одно потрібен буфер на час недоступності |
На практиці беруть поєднання: зріз за розміром як страховка від переповнення, зріз за розкладом як точка відліку для розбору, стиснення старих логів і вивантаження до зовнішнього сховища з політикою зберігання.
Тоді архівація логів перестає бути ручною операцією, а термін зберігання задається правилом, а не пам’яттю чергового.
Порядок впровадження: від аудиту до передачі регламенту
Ротація «на око» дає один із двох результатів: диск переповнюється в найневдаліший момент або логи інциденту видалені раніше, ніж до них дійшли руки. Тому йдемо етапами — від інвентаризації джерел до регламенту для чергової зміни.
- Аудит джерел логів. Фіксуємо, хто пише на диск: шлях, інтенсивність, поведінку за сплесків, хто тримає файл відкритим. Окремо розбираємо контейнери й системний журнал — у них своя логіка зберігання.
- Схема ротації та вікна зберігання. Для кожної групи вибираємо поріг за розміром або інтервал, кількість збережених копій і стиснення. Класи розводимо: аудит і доступи зберігаємо довше, налагоджувальні — кілька діб.
- Налаштування правил. Конфігурації у форматі logrotate за групами: стиснення архівів, дії після ротації для повторного відкриття дескриптора, копіювання з усіченням там, де процес не реагує на сигнал, права на каталоги.
- Перевірка під навантаженням. Проганяємо потік вище пікового: правило спрацьовує на порозі, рядки не губляться на стику файлів, стиснення не блокує запис, старі копії справді видаляються.
- Спостережуваність. Алерти на вільне місце, вік останнього файлу та помилки ротації — інакше збій помітять за недоступним сервісом, а не за метрикою.
- Передача регламенту. Документ і розбір із черговою зміною: де лежать логи, що робити при переповненні, як безпечно звільнити місце й відкотити правило.
Артефакти впровадження: конфігурації, схеми, регламенти
Впровадження закрито не тоді, коли ротація працює, а коли замовник може її змінити, перевірити й відновити після збою без нас. Тому передаємо комплект: конфігурації під контролем версій, схему зберігання з термінами, регламенти для чергових і модель доступу.
- Конфігурація ротації за кожним джерелом: умова спрацювання (за розміром або календарем), кількість збережених копій, стиснення, відкладене архівування та дія після повторного відкриття файлу процесом.
- Регламент зберігання: таблиця «клас логів — термін гарячого зберігання — термін архіву — носій — хто має право видалити достроково».
- Карта джерел: перелік сервісів і вузлів, що пишеться у файл, що йде в системний журнал, де дублюється і чому.
- Документація для чергових: що робити при заповненні диска, при ротації, що не спрацювала, за потреби терміново підняти докладність — з готовими командами та очікуваним виводом.
- Права доступу до логів: матриця ролей — читання напряму, доступ за запитом, де маскуються персональні дані, хто має право змінювати терміни й конфігурацію.
- Перевірки та оповіщення: спрацьовують, якщо ротація не пройшла, архів не вивантажився або вільне місце нижче порогу, — з прив’язкою до конкретного чергового.
- Інструкція з відкату: як повернути попередню конфігурацію й підняти видалені копії з архіву, поки термін зберігання не минув.
- Заміри до і після: обсяг логів на диску, частка вузла під ними, кількість інцидентів через переповнення — база для порівняння після змін.
Кейс: перестали втрачати логи при піковому навантаженні
Сервіс писав логи у файли на кожному вузлі, а ротація була налаштована одним рядком: по 100 МБ, зберігати все.
На піку застосунок продовжував писати в уже зротований файл, і частина записів ішла в нікуди — «дірки» з’являлися рівно в ті хвилини, коли розбір інциденту потрібен найбільше. Пошук потрібної події займав 20–30 хвилин: інженер обходив вісім вузлів і шукав за архівами вручну.
Що змінили
Розвели політики за класами: застосунок, системний журнал і аудит отримали окремі правила замість спільного конфігу. Поворот виконується за розміром і за часом, а демон отримує сигнал — файл не перевідкривається застосунком, тому жоден запис не губиться на зміні.
Правила описали в logrotate, доставку в централізоване сховище винесли в окремий агент із буфером на диску: якщо сховище недоступне, записи накопичуються локально, а не зникають. Глибину зберігання задали окремо для гарячого шару й архіву, старі файли стискаються.
Метрики до і після
Частка втрачених на піку записів упала з 3–7% до нуля — звіряли лічильники застосунку з кількістю рядків у сховищі. Пошук однієї події скоротився з 20–30 хвилин до 10–20 секунд за індексом, без обходу вузлів і ручного розбору архівів.
Гарячий шар зменшився приблизно втричі за тієї ж глибини архіву: реєстр перестав зростати лінійно, старі дані витісняються за політикою.
Чим відрізняється ротація за розміром від ротації за часом?
Ротація за розміром спрацьовує, коли файл переростає заданий поріг: споживання місця на розділі залишається передбачуваним, але момент перемикання залежить від навантаження — у спокійний день файл живе добу, у піковий закривається за хвилини.
Ротація за часом прив’язана до розкладу: файл закривається за календарем, тому набір файлів за період завжди однаковий, і за ними зручно будувати вибірки. Різниця стає помітною саме на нерівномірному профілі навантаження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ротація за розміром | Висока й рвана частота запису, ризик переповнення розділу, потрібна жорстка стеля за обсягом | Межі файлів непередбачувані, важкі інтервали та обриви посеред активності сервісу |
| Ротація за часом | Рівний потік, прив’язка логів до звітних періодів, однакова гранулярність файлів | Один сплеск може зайняти весь розділ до наступного спрацювання |
| Розклад плюс поріг зверху | Сервіси з добовим піком і нічним затишшям | Потрібні дві умови одразу й контроль, що стиснення встигає за записом |
Для вибору режиму дивляться на частоту запису в піку, а не в середньому за добу.
Якщо розкид між піком і затишшям більший за порядок, чиста ротація за часом залишає вікно, у якому розділ переповнюється, — тоді розклад задають разом із порогом за розміром, щоб файл закривався за будь-якою з двох умов.
Термін зберігання рахують від швидкості появи файлів: за ротації за часом за добу їх передбачувана кількість, за ротації за розміром — змінна, і політика видалення за кількістю файлів дає різну глибину історії.
Тому за частими тегами зручніше рахувати глибину в днях, а обсяг обмежувати стисненням і загальною стелею каталогу.
Часті технічні питання щодо ротації та зберігання логів
Сумніви навколо ротації зазвичай не про те, як її увімкнути, а про те, чи не порвемо ми живий сервіс і чим доведемо, що політика працює. Нижче — відповіді на те, що найчастіше виринає під час передачі інфраструктури іншій команді.
Терміни, цілісність і розбір інцидентів
Який термін зберігання логів вибрати?
Термін диктують не звички, а завдання: розбір інцидентів, вимоги аудиту та безпека. Робочий компроміс — гаряче вікно на швидкому диску для оперативної діагностики, далі стиснений архів у холодному шарі.
Важливіше за конкретну цифру — єдиний регламент: він фіксує, що видаляється за розкладом, а не за залишком місця.
Чи можна ротувати без перезапуску сервісу?
Так. Якщо процес уміє перевідкривати дескриптор за сигналом — ротація йде без обриву з’єднань, файл змінює ім’я, запис продовжується в новий.
Якщо не вміє й тримає файл відкритим, використовуємо копіювання з усіченням: частина рядків у момент копіювання може потрапити в обидва файли або загубитися, тому вікно підбираємо під пікове навантаження й перевіряємо на стенді.
Як переконатися, що політика справді застосовується?
Конфігурація — це ще не результат. Проганяємо ротацію примусово на тестовому контурі, звіряємо кількість рядків до і після, дивимося, чи не залишилося порожніх і «залиплих» файлів, і ставимо алерти на зростання каталогу та на збій ротації. Окремо перевіряємо, що стиснення й видалення не конфліктують з активною записом.
Що дає аудит логів і як зберігати архів?
Аудит відповідає на питання «хто змінював політику» і «чи можна довіряти записам». Для цього архів вивантажуємо в незмінне сховище з контролем цілісності, а правки конфігурації ведемо через версіонування з історією змін. Тоді відновлення конкретного вікна часу займає хвилини, і є чим підтвердити достовірність даних.
Обговоримо завдання й повернемося з планом ротації логів
Перша розмова — про вашу інфраструктуру, а не про наші регламенти. Нам важливо зрозуміти, які сервіси пишуть логи, де вони лежать, скільки займають і що вже болить: ротація не налаштована, диск переповнюється за ніч.
Окремо проговорюємо терміни зберігання та чим вони задані — аудитом, розбором інцидентів або правилами безпеки.
Із цієї розмови збирається план впровадження політик — за вашими контурами, а не за шаблоном:
- Що потрібно від вас: список серверів і контурів, де живуть логи, поточні конфігурації зберігання та вікна, коли допустимо змінювати бойовий контур.
- Що дивимося ми: обсяги та швидкість зростання логів, хто і як часто їх читає, які файли потрібні для розбору інцидентів, а які — баласт.
- Схема ротації: за розміром, за часом або за обома порогами, зі стисненням і розбивкою за сервісами.
- Політика зберігання: скільки тримаємо в гарячому вигляді, що йде в архів, що знімається за правилом життєвого циклу автоматично.
- Оцінка робіт: перелік змін за кожним контуром, трудовитрати, порядок викочування та крок відкату.
- Впровадження політик: спочатку небойові контури й перевірка на реальному потоці, потім бойовий — з контролем, що вільне місце зростає, а потрібні логи залишаються доступними.
Наступний крок — за вами: опишіть завдання в двох-трьох абзацах або надішліть поточні конфігурації. Повернемося з оцінкою робіт і планом впровадження, розкладеним за етапами.
