Очистка логов Linux: 5 безопасных способов и команд

Зачем очищать логи в Linux и когда это необходимо

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

Чистка требуется в нескольких случаях:

• свободное место на разделе /var подходит к нулю;
• нужно разобрать инцидент, а старые записи мешают;
• настроена ротация, но она не срабатывает должным образом;
• готовитесь к аудиту или передаче оборудования.

Регулярная проверка объёма журналов — хорошая привычка. Она избавляет от авральных ситуаций и сохраняет нервы. Лучше потратить пять минут на профилактику, чем потом разбираться с отказавшей службой из-за переполненного диска.

Признаки переполнения логов и риски для системы

Когда журналы разрастаются до десятков гигабайт, это заметно не сразу. Первый звоночек — медленная работа файлового сервера или ошибки записи на диск. Если inode исчерпаны, система может отказывать даже в создании временных файлов, что приводит к сбоям приложений.

Типичная картина переполнения:

• Свободное место на разделе /var стремится к нулю;
• Процесс journald или syslogd нагружает процессор на 100%;
• В консоли появляются сообщения о невозможности записи в /var/log/messages.

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

Какие логи можно удалять без последствий, а какие лучше сохранить

Не все записи одинаково полезны. Временные файлы из-под /var/log, вроде старых архивов с расширением .gz, обычно можно сносить смело — они не влияют на работу системы. А вот содержимое auth.log или syslog лучше не трогать: там следы авторизаций и работы ядра, которые пригодятся при разборе инцидентов. Если место совсем критично, просто усеките эти файлы до нуля командой truncate, сохранив права доступа.

Способы очистки логов Linux: от простых к продвинутым

Когда системный журнал разрастается до десятков гигабайт, вопрос очистки логов linux становится насущным. Начнём с базовых приёмов, доступных даже новичку, и постепенно перейдём к автоматизированным решениям.

Самый прямолинейный вариант — обнулить содержимое файла через truncate или перенаправление потока. Команда truncate -s 0 /var/log/syslog мгновенно освобождает место, не трогая права доступа и атрибуты. Альтернатива — cat /dev/null > файл, но такой подход требует осторожности с активными журналами.

Для выборочной зачистки удобно использовать find с фильтрами по времени модификации. Например, удалить записи старше 30 дней:

find /var/log -name "*.log" -mtime +30 -delete

Продвинутый уровень — настройка logrotate. Эта утилита автоматически ротирует, сжимает и удаляет устаревшие файлы по расписанию. Конфигурация лежит в /etc/logrotate.conf, а отдельные правила — в /etc/logrotate.d/. Вот типовой блок:

/var/log/nginx/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
}

Сравним основные методы в таблице:

Метод	Скорость	Автоматизация	Риск для системы
truncate	Мгновенно	Нет	Низкий
find + delete	Средне	Через cron	Средний
logrotate	По расписанию	Полная	Минимальный

Важно помнить: перед массовым удалением стоит проверить, не пишет ли какой-то процесс в очищаемый файл. Иначе можно потерять данные, необходимые для диагностики сбоев.

Очистка логов через truncate и /dev/null

Самый быстрый способ освободить место — обнулить файл, не удаляя его. Команда truncate -s 0 /var/log/syslog мгновенно сбрасывает содержимое до нуля байт. Альтернатива — перенаправить пустоту: cat /dev/null > /var/log/auth.log. Оба варианта сохраняют права доступа и не требуют перезапуска служб. Однако учтите: процесс, держащий файл открытым, продолжит писать в старый inode, поэтому для активных журналов лучше использовать logrotate.

Удаление лог-файлов с помощью команды rm и find

Когда накопившиеся записи мешают, проще всего применить rm для точечного сноса конкретного файла. Но если нужно зачистить всё, что старше определённой даты, на помощь приходит find с опцией -delete или -exec. Например, поиск по маске *.log с фильтром по времени модификации -mtime +30 удалит данные за месяц. Однако помните: rm не спрашивает разрешения, поэтому перед массовой зачисткой стоит проверить список через ls.

Автоматическая очистка логов через logrotate

Стандартный инструмент logrotate входит в дистрибутивы Linux и запускается по расписанию через cron. Его конфигурация хранится в /etc/logrotate.conf, а отдельные правила — в каталоге /etc/logrotate.d. Утилита умеет сжимать старые файлы, менять их имена и удалять записи старше заданного срока.

Пример базового правила для nginx:

/var/log/nginx/*.log {
    weekly
    rotate 4
    compress
    delaycompress
    missingok
    notifempty
    create 640 www-data adm
    postrotate
        systemctl reload nginx
    endscript
}

Здесь задано еженедельное вращение, хранение четырёх архивов, сжатие gzip и перезапуск службы после обработки. Для проверки синтаксиса используют команду logrotate -d /etc/logrotate.conf, а принудительный запуск выполняют с флагом -f.

Настройка logrotate для регулярной очистки

Демон logrotate — стандартный инструмент для ротации журналов в большинстве дистрибутивов. Он запускается по расписанию через cron и обрабатывает файлы согласно конфигурации в /etc/logrotate.conf и каталоге /etc/logrotate.d/. Указав параметры rotate 4 и weekly, вы ограничите число хранимых архивов четырьмя неделями. Для немедленного применения изменений выполните sudo logrotate -vf /etc/logrotate.conf.

Конфигурация logrotate: ротация по размеру и дате

Настройка утилиты сводится к правке файла /etc/logrotate.conf и отдельных сценариев в каталоге /etc/logrotate.d/. Для ротации по дате указывают директиву daily или weekly, а для ограничения объёма — параметр size, например size 100M. Эти условия можно комбинировать: тогда сработает то, что наступит раньше.

Пример базового блока:

/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
}

Здесь журналы будут пересоздаваться каждые сутки, храниться две недели и сжиматься в gz. Если нужно резать по достижении определённого размера, добавьте size 50M — тогда файл будет усекаться при превышении лимита, даже если день ещё не закончился. Проверить корректность конфигурации помогает команда logrotate -d.

Сжатие старых логов и удаление архивов по расписанию

Когда файлы журналов перестают быть актуальными, их обычно упаковывают в архивы, чтобы сэкономить место на диске. Для этого удобно применять утилиту logrotate — она умеет не только ротировать записи, но и сжимать их в gzip или bzip2. В конфигурации достаточно указать директиву compress, и старые версии будут превращаться в архивы автоматически.

Однако со временем накапливается и множество устаревших архивов. Чтобы они не засоряли хранилище, настраивают их удаление по расписанию. Например, через планировщик cron запускают команду, которая ищет файлы старше определённого срока и стирает их. Вот типичный пример для поиска и очистки:

find /var/log -name "*.gz" -mtime +30 -delete

Эта строка удалит все сжатые файлы, которые не менялись больше месяца. Для более гибкого контроля можно использовать скрипт с проверкой возраста каждого архива.

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

Важно помнить: настройки сжатия и очистки лучше проверять в тестовом режиме, чтобы случайно не стереть нужные данные. Для этого запускают logrotate -d — он покажет, что произойдёт, без реальных изменений.

Очистка логов systemd и journalctl

Журнал systemd-journald накапливает данные в бинарном формате, и его размер со временем растёт. Для контроля объёма применяют утилиту journalctl с флагом --vacuum-size, которая удаляет самые старые записи до достижения указанного лимита. Например, journalctl --vacuum-size=200M оставит только свежие данные общим весом до 200 мегабайт.

Альтернативный способ — ограничение по времени хранения:

• journalctl --vacuum-time=7d — стирает всё, что старше недели;
• journalctl --vacuum-files=5 — сохраняет лишь пять последних файлов журнала.

Чтобы предотвратить разрастание в будущем, отредактируйте конфигурационный файл /etc/systemd/journald.conf, задав параметры SystemMaxUse и MaxRetentionSec. После изменений перезапустите службу командой systemctl restart systemd-journald.

Очистка логов journalctl по времени и размеру

Журнал systemd накапливает данные стремительно, особенно при активной работе служб. Удалить старые записи можно двумя основными способами: по дате или по суммарному объёму файлов. Для первого варианта подойдёт команда journalctl --vacuum-time=7d — она сотрёт всё, что старше недели. Второй метод ограничивает хранилище размером, например, 500 МБ: journalctl --vacuum-size=500M. Указанные параметры применяются к уже существующим данным.

Чтобы предотвратить разрастание в будущем, отредактируйте конфигурационный файл /etc/systemd/journald.conf. Найдите строку SystemMaxUse= и задайте лимит, скажем, 300M. После изменений перезапустите демон: systemctl restart systemd-journald. Действие не затронет активные записи, только ограничит рост.

Ограничение максимального объёма журнала systemd

Чтобы журнал не разрастался бесконечно, в systemd предусмотрены лимиты. Они задаются в файле /etc/systemd/journald.conf параметрами SystemMaxUse и SystemMaxFileSize. Первый ограничивает суммарный объём всех записей, второй — размер одного файла. После правки конфигурации перезапустите службу командой systemctl restart systemd-journald. Для временного сброса накопленных данных используйте journalctl --vacuum-size=200M — это сократит архив до указанного значения.

Очистка логов популярных сервисов и приложений

У каждого демона свои привычки хранения данных. Например, веб-сервер Nginx пишет обращения в access.log, а ошибки — отдельно. Почтовый сервер Postfix и вовсе способен разрастись до десятков гигабайт при активной переписке. Для таких случаев удобно настроить ротацию через logrotate, указав в конфиге нужный размер и количество архивов. Если же нужно быстро освободить место, достаточно обнулить файл командой truncate -s 0, не останавливая службу. Для системного журнала journald действует свой механизм: лимит задаётся в /etc/systemd/journald.conf параметром SystemMaxUse. После правки не забудьте перезапустить демон.

Очистка логов nginx и apache

Для веб-серверов характерен быстрый рост файлов access.log и error.log. Удалять их вручную нецелесообразно: проще настроить ротацию по дате или размеру через logrotate. Конфигурация для nginx и Apache практически идентична — отличается лишь путь к каталогу с журналами. Если нужно освободить место немедленно, используйте команду truncate, которая обнуляет файл, не требуя перезапуска службы. Такой подход сохраняет права доступа и не прерывает запись.

Очистка логов MySQL, PostgreSQL и других БД

СУБД тоже накапливают историю операций, и она способна разрастись до десятков гигабайт. Для MySQL актуальна ротация через logrotate с конфигом в /etc/logrotate.d/mysql. У PostgreSQL достаточно периодически выполнять pg_ctl logrotate или настроить logging_collector с суточным разбиением файлов. Не забывайте про журнал медленных запросов — его чистят отдельно, иначе диск заполнится незаметно.

Для прочих систем (например, Redis или MongoDB) действует тот же принцип: проверяйте каталоги /var/log и /var/lib на предмет устаревших записей. Удобно использовать утилиту ncdu, чтобы быстро найти крупные файлы перед их удалением.

Мониторинг и профилактика переполнения логов

Чтобы не доводить систему до критического состояния, стоит настроить наблюдение за ростом журналов. Проще всего следить за размером каталога /var/log с помощью утилиты du или ncdu. Для автоматизации подойдёт cron-задание, которое будет запускать проверку ежедневно и отправлять отчёт на почту администратору.

Полезно также обратить внимание на logrotate — он ротирует файлы по расписанию, сжимает старые копии и удаляет их через заданный период. Правильная конфигурация этого инструмента решает большинство проблем с диском заранее. Для контроля свободного места можно использовать простой скрипт, который предупредит о заполнении раздела на 80% и выше.

Регулярная проверка логов не только спасает от неожиданного заполнения диска, но и помогает вовремя заметить сбои в работе служб. Иногда достаточно раз в неделю просматривать свежие записи, чтобы понять, что происходит с сервером.

Проверка размера логов и поиск самых тяжёлых файлов

Прежде чем что-либо удалять, стоит оценить масштаб. Быстрый способ — команда du с сортировкой по убыванию. Например, du -ah /var/log | sort -rh | head -20 покажет двадцать самых объёмных записей. Удобно также заглянуть в journalctl --disk-usage, чтобы понять, сколько места занимает системный журнал. Для наглядности можно свести данные в таблицу:

Путь	Размер	Что это
/var/log/syslog	1,2 ГБ	Общий системный журнал
/var/log/kern.log	800 МБ	Сообщения ядра

Такой подход помогает выявить виновника быстро, не перебирая всё подряд.

Настройка уведомлений о заполнении диска логами

Чтобы не доводить систему до критического состояния, полезно заранее узнавать о росте журналов. Проще всего следить за свободным местом через cron, запуская проверку каждые 10–15 минут. Скрипт сравнивает текущий объём с порогом (например, 85%) и при превышении шлёт письмо администратору.

Альтернативный путь — systemd-таймеры. Они удобнее классического планировщика: запускаются точно по расписанию и не требуют отдельного демона. Для почтовых оповещений подойдёт утилита mailx или curl с запросом к API мессенджера.

Вот минимальный пример проверки:

df -h /var | awk 'NR==2 {print $5}' | sed 's/%//'

Если полученное число больше лимита — срабатывает уведомление. Такой подход избавляет от ручного мониторинга и позволяет вовремя провести очистку.