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