Сайт працює, база відповідає, резервна копія начебто є — а потім VPS раптом перестає приймати записи, бо системний диск заповнився логами. Це не екзотична аварія. Лог може рости через звичайний access log, повторювану помилку застосунку, невдалий запит до зовнішнього сервісу або журнал системної служби. Хороша новина: проблему можна зробити передбачуваною, якщо не плутати збереження доказів із безстроковим накопиченням файлів.
У цій інструкції ви побудуєте простий порядок: знайдете, що займає місце, визначите строки зберігання, налаштуєте ротацію та перевірите, що стиснення або видалення не зламає збір логів. Це підходить і для невеликого VPS із сайтом, і для сервера з кількома службами — різниться лише глибина перевірки.
Лог корисний не тому, що він великий, а тому, що у потрібний момент у ньому можна знайти пояснення події.
Крок 1. Знайдіть джерело росту, а не лише повний диск
Ротація логів — це керований процес зміни активного лог-файлу, збереження попередньої копії на визначений строк, за потреби стиснення та безпечного видалення після завершення строку зберігання.
Почніть із вільного місця та каталогів, які ростуть. Не робіть висновок лише з одного великого файлу: інколи місце утримує вже видалений файл, який ще відкритий процесом. Тоді директорія виглядає чистішою, ніж фактичне використання файлової системи. Перевіряйте і загальну картину, і службу, що пише записи.
- Зафіксуйте використання файлової системи та інодів.
- Перегляньте найбільші каталоги журналів і дані застосунку.
- Визначте процеси, які активно пишуть або тримають відкриті файли.
- Відокремте корисні журнали безпеки та помилок від надмірного налагоджувального шуму.
Три типові ситуації
Для сайту на Nginx або Apache access log може різко зрости через ботів чи невдалу інтеграцію. Для інтернет-магазину застосунок може повторювати одну помилку платежу в кожному запиті. Для команди розробки журнал контейнера часто роздувається через debug-режим, який забули вимкнути після діагностики. У всіх трьох випадках ротація потрібна, але лікування першопричини різне.
Не очищайте журнали навмання, коли диск уже переповнений. Спершу збережіть мінімальні дані для розслідування, зафіксуйте часовий інтервал і перевірте, що саме генерує потік. Якщо стерти єдиний слід повторюваної помилки або атаки, ви звільните місце, але втратите можливість безпечно усунути причину.
Крок 2. Визначте політику зберігання
Політика не мусить бути складним документом. Для кожного класу журналу дайте чотири відповіді: хто його читає, скільки часу він потрібен, чи можна його стискати та що має статися, коли ліміт досягнуто. Журнали аудиту, помилок і доступу мають різну цінність; однакова кількість днів для всіх часто є випадковим рішенням.
| Тип журналу | Що перевірити | Типове рішення |
| Веб-доступ | Піки, боти, аналіз інцидентів | Ротація за часом або розміром, стиснення |
| Помилки застосунку | Чи повторюється одна причина | Коротший файл, усунення помилки |
| systemd journal | Потрібність централізованого пошуку | Ліміти диска або часу |
| Налагодження | Чи ввімкнене тимчасово | Вимкнути після діагностики |
Крок 3. Налаштуйте ротацію обережно
У багатьох Linux-дистрибутивах для файлових журналів використовується logrotate. Його правила можуть обертати файл за розкладом або розміром, створювати новий, стискати старий і залишати обмежену кількість копій. Важливо зрозуміти, як конкретна служба реагує на заміну файла: деяким процесам потрібен сигнал або перезапуск, щоб вони відкрили новий дескриптор.
Безпечна послідовність
- Створіть правило для одного конкретного журналу, не для всього каталогу без розуміння вмісту.
- Перевірте конфігурацію в режимі налагодження або сухого запуску, якщо це підтримує ваш інструмент.
- Зробіть тестову ротацію у контрольований час і переконайтеся, що служба продовжила запис у новий файл.
- Перевірте права, власника та читабельність для процесу, який пише журнал.
- Переконайтеся, що стиснені архіви відкриваються, а політика видалення відповідає потребам.
Не копіюйте чужу конфігурацію logrotate без перевірки шляху, користувача, сигналу службі та способу запису. Неправильна ротація може тихо припинити логування саме тоді, коли воно найпотрібніше.
Крок 4. Не забудьте про systemd journal і контейнери
Файли в /var/log — не єдине джерело. systemd-journald веде власний журнал, а контейнерний рушій може мати окремі драйвери та правила ротації. Якщо ви обмежите лише веб-логи, але залишите без ліміту журнал служби або контейнера, проблема повернеться з іншого боку. Тому після зміни перевірте загальний стан диска, а не лише один каталог.
Тут корисна аналогія з водою в будинку: перекрити один кран недостатньо, якщо тече бойлер. Коли ви бачите заповнений VPS, думайте про всі шляхи запису — застосунок, веб-сервер, systemd, база даних, контейнери, тимчасові файли та резервні копії.
Крок 5. Додайте спостереження та перевірку
Ротація без моніторингу схожа на будильник без батарейки. Налаштуйте попередження про вільне місце завчасно, а не на 100 відсотках використання. Після оновлення застосунку, зміни рівня логування або появи нової інтеграції перегляньте динаміку ще раз. Це не бюрократія: так ви виявите аномалію до того, як вона зупинить запис у базу даних або роботу сервісу.
Якщо ви шукаєте базу для такого керованого сервера, перегляньте доступні варіанти VPS на DeltaHost через анкор оренда VPS для контрольованого розгортання. Вибір ресурсу не замінює політику журналів, але дає вам середовище, у якому цю політику можна підтримувати.
Підсумок
Щоб системний диск не заповнювався логами, вам не потрібна складна платформа: достатньо знати джерела запису, мати строки зберігання, тестувати ротацію і спостерігати за вільним місцем. Найкраща ротація — та, яку ви перевірили в роботі й яка не позбавляє команду важливих доказів. Почніть з одного критичного журналу, задокументуйте результат і розширюйте правило поступово.
Як відрізнити архів від сміття
Не кожен старий файл можна видалити тільки тому, що він старий. Перед політикою зберігання з’ясуйте, чи потрібні записи для розслідування інцидентів, безпеки, бухгалтерського процесу або договору. Якщо потреба існує, краще перемістити архів у відповідне контрольоване сховище з обмеженим доступом, ніж безмежно тримати його на системному диску VPS. Якщо потреби немає, строк видалення має бути явним, а не випадковим наслідком заповненого диска.
Стиснення зазвичай добре підходить для завершених текстових журналів, але не замінює контроль обсягу. Воно не виправляє лог, який щохвилини повторює однакову помилку, і не гарантує, що архів ніколи не знадобиться. Після налаштування відкрийте одну стиснену копію, перевірте часові мітки та переконайтеся, що команда знає, де шукати дані.
Мінімальний щотижневий огляд
Раз на тиждень достатньо переглянути вільне місце, найбільші каталоги, останні попередження та нові служби, додані після релізів. Якщо показник росте, не чекайте ліміту: запитайте, чи змінився трафік, рівень логування або поведінка інтеграції. Такий короткий ритм набагато спокійніший за нічне звільнення місця під тиском.
