Журналы: единственное, что растёт, хотя никто этого не решал

Большую часть того, что заполняет ваш диск, добавили вы: виртуальные машины, резервные копии, установочные образы. Каждое из этого было решением.

Журналы, другое дело. Они растут потому, что система работает. Никто никогда не говорил «пусть этот файл станет больше».

Рост медленный, но без предела

Файл журнала может расти на пару килобайт в день. Месяцами это не привлекает внимания. Через год он всё ещё маленький.

Но у него нет потолка. А рост без потолка, каким бы медленным он ни был, становится бедой, если подождать достаточно долго.

Множитель, которого никто не ждёт: отказ ускоряет запись

Вот в чём настоящая суть статьи.

Здоровая система пишет мало. Если проверка выдаёт ошибку при каждом запуске, при каждом запуске в тот же файл падает строка. Для задачи, работающей каждые пятнадцать минут, это девяносто шесть строк в сутки, и это не прекращается.

То есть журнал растёт быстрее всего именно тогда, когда вам меньше всего до него: пока идёт отказ.

И худший вариант

Возникает беда, журналы ускоряются, диск заполняется. Заполненный диск порождает новые беды. Новые беды дают ещё журналов.

С этого момента найти исходную неисправность становится труднее, потому что большинство ошибок на экране, следствие не первой беды, а заполненного диска.

Правило: у всего, что пишет, должен быть потолок

«Потом почистим», это не план. Нужен механический предел, который работает без того, чтобы кто-то о нём помнил.

Правило относится не только к системным журналам: оно относится к любому файлу, который создают ваши службы, задачи по расписанию и сборщики.

Две ошибки при настройке ротации

Первая: правило ломается из-за файла, которого нет. Некоторые файлы появляются только тогда, когда используется соответствующая возможность. Правило надо написать так, чтобы оно не выдавало ошибку при отсутствии файла; иначе никогда не используемая возможность останавливает всю ротацию.

Вторая: неверный способ ротации. Переименовать файл и послать пишущей службе сигнал «открой заново», обычный способ, но он работает только при наличии долгоживущей службы. Если пишет короткоживущая задача, которая каждый раз открывает и закрывает, посылать сигнал некому; тогда верный способ, скопировать содержимое и опустошить файл на месте.

Оба, тихие отказы: правило стоит, файл продолжает расти, и никто не замечает, что правило не работает.

И вопрос уже установленной машины

Если написать правило ротации только в установочном сценарии, оно никогда не доберётся до машин, установленных до появления правила. Эти машины годами работают без него.

Верно писать правило при каждом запуске: так и старые установки получат его, перейдя на новую версию.

Что делает Atlas

Вся эта статья вышла из измерения, которое Atlas сделал сам над собой, поэтому рассказать её надо честно.

Atlas работает на машине клиента с правами root и пишет в несколько файлов журналов: сводку сторожа каждые пятнадцать минут, вывод плановых обновлений при каждом запуске, собственную запись самообновления. Было измерено, и ни один из них не ротировался, потому что установка нигде не писала правила ротации. На работающей машине журнал сторожа за тридцать два дня достиг ста восьмидесяти килобайт, и не было механизма его уменьшить.

Число выглядит маленьким, и в тот день это не было бедой. Бедой было то, что рост был беспредельным, плюс описанное выше ускорение. Журналы плановых обновлений при каждом запуске захватывают весь вывод менеджера пакетов, а это может доходить до мегабайт за запуск.

Теперь правило пишется, и обе ловушки выше обработаны намеренно: отсутствующие файлы допускаются, а ротация использует способ «скопировать, затем опустошить», потому что пишут короткоживущие процессы, запускаемые задачей по расписанию.

И правило пишется при запуске, а не в установочном сценарии. Причина, ровно тот вопрос выше: чтобы и ранее установленные машины получили правило, перейдя на новую версию.