Ограничение размера логов linux

Настройка Logrotate

В Linux, большинство сервисов и программ, которые работают в фоне, таких как Apache, Nginx, Postfix и других записывают информацию о своем состоянии, результатах работы и ошибках в лог файлы. Стандартное расположение логов или как их еще называют — журналов — в папке /var/log.

С помощью анализа логов вы можете понять что работает не так, почему произошла ошибка и как решить возникшую проблему. Но тот кроется одна проблема. Размер логов постоянно растет и они занимают все больше и больше места на диске, поэтому необходимо вовремя чистить логи и удалять устаревшие записи, чтобы они не мешали нормально работать. Это можно делать вручную время от времени или настроить скрипты Cron, но есть еще более простой вариант — утилита logrotate. В этой статье будет рассмотрена настройка logrotate и ее использование.

Как работает Logrotate?

Утилита Logrotate предназначена для автоматизации обработки журналов. Она может выполнять с ними необходимые действия в зависимости от определенных условий и правил соответствия. Например, можно сжимать журналы в архив или отправлять на другой сервер когда они достигают определенного размера, возраста, или других параметров.

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

Настройка Logrotate

Logrotate — это популярная утилита, поэтому в большинстве дистрибутивов она поставляется по умолчанию. Вы можете убедиться, что программа установлена в вашем дистрибутиве, попытавшись ее установить. Например, в CentOS:

sudo yum install logrotate

Или в Ubuntu и основанных на ней дистрибутивах:

sudo apt install logrotate

Теперь, даже если утилита не была установлена, вы ее установите. Все основные настройки программы находятся в файле /etc/logrotate.conf, дополнительные настройки, касаемо правил и других возможностей могут быть размещены в папке /etc/logroate.d/. Вы можете размещать все настройки logroatae прямо в основном конфигурационном файле, будет более правильно, если настройки для каждого отдельного сервиса будут находиться в отдельном файле, в папке /etc/logrotate.d/.

Чтобы конфигурационные файлы из этой папки загружались программой, необходимо добавить в основной конфигурационный файл такую строчку:

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

  • hourly — каждый час;
  • daily — каждый день;
  • weekly — каждую неделю;
  • monthly — каждый месяц;
  • yearly — каждый год.

Основные директивы управления и обработки логов:

  • rotate — указывает сколько старых логов нужно хранить, в параметрах передается количество;
  • create — указывает, что необходимо создать пустой лог файл после перемещения старого;
  • dateext — добавляет дату ротации перед заголовком старого лога;
  • compress — указывает, что лог необходимо сжимать;
  • delaycompress — не сжимать последний и предпоследний журнал;
  • extension — сохранять оригинальный лог файл после ротации, если у него указанное расширение;
  • mail — отправлять Email после завершения ротации;
  • maxage — выполнять ротацию журналов, если они старше, чем указано;
  • missingok — не выдавать ошибки, если лог файла не существует;
  • olddir — перемещать старые логи в отдельную папку;
  • postrotate/endscript — выполнить произвольные команды после ротации;
  • start — номер, с которого будет начата нумерация старых логов;
  • size — размер лога, когда он будет перемещен;

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

Читайте также:  У вас есть права суперпользователя kali linux

адрес_файла_лога <
директивы
>

Теперь давайте создадим файл rsyslog.conf в папке /etc/logrotate.d/ и поместим в него настройки для ротации этого лога:

/var/log/messages <
daily
rotate 3
size 10M
compress
delaycompress
>

Эти настройки означают, что ротация журналов будет выполняться ежедневно, и мы будем хранить три последних журнала, более старые копии будут автоматически удаляться. Минимальный размер для ротации — 10 мегабайт, ротация не будет выполнена, если лог не занимает более 10 мегабайт. Будет использоваться сжатие, для всех журналов кроме последнего и предпоследнего. Точно по такому же принципу вы можете настроить ротацию логов для любого из журналов. Нужно создать такую секцию для каждого из логов, которыми вы хотите управлять.

Теперь осталось протестировать как работает наша конфигурация. Для этого запустим утилиту logrotate с опцией -d. Она выведет все, что планируется сделать, но не будет изменять файлы на диске. У нас есть файл /var/log/messages, размером 40 Мегабайт, посмотрим что будет делать утилита:

logrotate -d /etc/logrotate.d/rsyslog.conf

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

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

Выводы

В этой статье мы рассмотрели как выполняется настройка logrotate centos или в любом другом дистрибутиве Linux. Работа утилиты не сильно отличается в зависимости от дистрибутивов. Если у вас есть сервер с большой нагрузкой, вам обязательно необходимо настроить ротацию логов. Надеюсь, эта информация была полезной для вас. На завершение видео, о том как выполняется ротация логов в Ubuntu от LPIC:

И еще одно на английском:

Источник

Как ограничить размер journal

Размер папки /var/log/journal по умолчанию ограничен значением в 10% от объема соответствующей файловой системы.
И это очень много. Решил значительно ограничить размер журнала.
Максимальный объем постоянного журнала можно контролировать при помощи значения SystemMaxUse в конфигурационном файле /etc/systemd/journald.conf в секции [Journal].
Я установил значение — SystemMaxUse=50M (строка, конечно, раскомментирована).
Заглянул как-то в эту папку и был удивлен — размер около 1 Гб.
Почистил, понаблюдал — размер журнала никак не желает ограничиваться в 50Мб.
Может кто сталкивался с подобной проблемой и уже решил? Только что проверил. SystemMaxUse=100M, размер директории с файлами журнала 400М, из них половина — резервные копии. Это мы не правильно маны читаем или правда бага? Думаю, это явно баг, если «journalctl —disk-usage» выдает этот размер. Периодически вопрос по ограничению размеров журнала всплывает то там, то там. Systemd еще достаточно сырой местами. На нас «обкатывают», видимо.
Я сейчас не буду искать ссылки на подобные треды. Кому интересно — гугл с нетерпением ждет. Но, насколько я помню из прочитанного, резервные файлы (с тильдой (

) на конце) журналов вообще никак системой не учитываются в подсчете занятого места.
Кроме того, есть еще более коварный баг: если использовать ограничение хранения записей по времени с помощью параметра «MaxRetentionSec=», то при достижении времени, когда надо уже выкидывать устаревшие записи, процесс «systemd-journald» начинает грузить процессор на 100% (хорошо, если проц не один), сыпя одновременно в лог огромное количество записей вида

мар 19 00:48:00 fox systemd-journald[163]: Sleeping for 1020877907 ms

Есть мысль, что systemd считает «сегодняшний» кусок всем логом. Соответственно и размеры считает и выдаёт для него. А «вчерашние» куски не учитывает.

как его правильно чистить?
или просто rm ? Начитался о технике создания journal и меня особенно впечатлило то, что каждой записи в журнале (что такое запись. — отдельный лог. ) будет сопоставлен хэш, который по цепочке будет охватывать хэши предыдущих записей.
. выдержка. из http://fap.sbras.ru/node/2610 .
Ключевой особенностью Journal является использование криптографических средств для гарантирования неизменности и целостности накопленных логов. Как правило, первым делом после взлома злоумышленники пытаются замести следы и вычистить из системных логов записи, выдающие их активность. Используемые в настоящее время реализации службы syslog беспомощны перед такими действиями. В Journal для решения данной задачи планируется задействовать средства обеспечения целостности, похожие на те, что используются в Git. Каждой записи в журнале будет сопоставлен хэш, который по цепочке будет охватывать хэши предыдущих записей. Используя отдельно сохранённый эталонный начальный хэш, который недоступен атакующему (без этого хэша нет возможности воссоздать всю цепочку подтверждений), можно легко проверить неизменность всего лога.
.
А если имеется такая передача хэша и эталонный начальный хэш, то возможно ли вообще автоматическое удаление записей? — в ручную да, возможно.
Читайте также:  Как проверить владельца файла linux
kurych — Думаю, это явно баг, если «journalctl —disk-usage» выдает этот размер.

А как понимать это:
sudo journalctl —disk-usage
[sudo] password for .
Journals take up 1.1M on disk.

Размер папки в свойствах — 96,6МБ

«journalctl —disk-usage» похоже показывает размер временного journal (похоже,на данную сессию, до перезагрузки) в /run/systemd/journal — его размер 1,6МБ (уже немного увеличился)

Имеется параметр «Storage=» в journald.conf
Про него написано:
Определяет куда сохранять данные. Значения: volatile, persistent, auto и none.
— volatile — сохраняет только в памяти, то есть принадлежит иерархии /run/log/journal.
— persistent — данные сохраняются предпочтительно на диск, то есть принадлежат иерархии каталогов /var/log/journal с обратной связью на /run/log/journal, для логирования ранней загрузки, пока на диск еще не разрешена запись.
— auto подобно persistent но директория /var/log/journal не создается если нет необходимости, таким образом контролируется куда отправляются данные.
none — отключает логирование. Все полученные данные отбрасываются. Касательно других служб, таких как консоль, лог буфера ядра или же демон syslog, они как и прежде продолжают работать.
По умолчанию значение auto.

То есть если установить значение «Storage=volatile», то правильно ли я понимаю, что писаться в /var/log/journal не будет.
PS — или логичнее поставить «none» — демон syslog будет работать по прежнему. А этого мне и достаточно.

vasek
А как понимать это:
sudo journalctl —disk-usage
[sudo] password for .
Journals take up 1.1M on disk.

Размер папки в свойствах — 96,6МБ

# du -sh /var/log/journal/0e9e2cd8ec9662bf3df276ef000031cb/
92M /var/log/journal/0e9e2cd8ec9662bf3df276ef000031cb/
#
# journalctl —disk-usage
Journals take up 91.9M on disk.

© 2006-2021, Русскоязычное сообщество Arch Linux.
Название и логотип Arch Linux ™ являются признанными торговыми марками.
Linux ® — зарегистрированная торговая марка Linus Torvalds и LMI.

Источник

Centos / Linux настройка logrotate на максимальный размер файла для всех журналов

мы используем logrotate, и он работает ежедневно . теперь у нас были некоторые ситуации, когда журналы значительно выросли (читай: gigbaytes) и убили наш сервер. Поэтому сейчас мы хотели бы установить максимальный размер журналов .

могу ли я просто добавить это в logrotate.конф?

и будет ли он применяться ко всем файлам журнала? Или мне нужно установить это на основе журнала?

или любой другой совет?

(ps. Я поймите, что если вы хотите получать уведомления, журнал растет, как описано, и то, что мы хотим сделать, не идеально — но это лучше, чем не иметь возможности войти в систему больше, потому что нет свободного места)

2 ответов

он определяет размер лог-файл для запуска вращения. Например size 50M вызовет вращение журнала, как только размер файла будет 50 Мб или больше. Можно использовать суффикс M за мегабайт k в килобайтах и G для гигабайт. Если суффикс не используется, он будет означать байты. Вы можете проверить пример в конце. Существует три директивы size , maxsize и minsize . В соответствии с manpage:

вот объяснение для обоих файлов /var/log/httpd/access.log и /var/log/httpd/error.log . Они поворачиваются всякий раз, когда он растет более 100k в размере, и старые файлы журналов отправляются по почте (несжатые) в www@my.org после прохождения 5 оборотов, а не удаляются. The sharedscripts означает, что postrotate скрипт будет выполняться только один раз (после сжатия старых журналов), а не один раз для каждого журнала, который вращается. Обратите внимание, что двойные кавычки вокруг первого имени файла в начале этого раздела позволяют logrotate вращать журналы с пробелами в имени. Нормальные правила цитирования оболочки применяются, с , и \ символы поддерживаются.

Читайте также:  Leaving windows open in winter

как упоминалось Zeeshan, параметры logrotate size , minsize , maxsize триггеры для вращения.

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

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

для файлов журналов, которые создаются очень быстро (например, в сотнях МБ в день), если вы не хотите, чтобы они были очень большими, вам нужно будет часто вызывать logrotate! это очень важно.

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

на Ubuntu вы можете легко переключиться на почасовое вращение, переместив скрипт / etc / cron.ежедневно / logrotate к / etc / cron.почасовой/у logrotate

в файл/etc / crontab. Запускать каждые 5 минут.

на size опция игнорирует ежедневные, еженедельные, ежемесячные параметры времени. Но minsize & maxsize учитывают это.

man-страница немного сбивает с толку. Вот мой объяснение.

minsize вращается только тогда, когда файл достиг соответствующего размера и установленный период времени прошел. например minsize 50MB + ежедневно Если файл достигает 50 МБ до ежедневного времени, он будет продолжать расти до следующего дня.

maxsize будет вращаться, когда журнал достигнет установленного размера или прошло соответствующее время. например, maxsize 50MB + ежедневно. Если файл 50MB, и мы не на на следующий день журнал будет повернут. Если файл составляет всего 20 МБ, и мы переходим на следующий день, то файл будет повернут.

size будет вращаться, когда размер журнала>. Независимо от того, указан ли почасовой / ежедневный / еженедельный / ежемесячный. Итак, если у вас есть размер 100M — это означает, что когда ваш файл журнала > 100M, журнал будет повернут, если logrotate запущен, когда это условие истинно. После его поворота основной журнал будет равен 0, а последующий запуск будет ничего не делать.

так в случае op. Specficially 50MB max я бы использовал что-то вроде следующего:

что означает, что он создаст 8hrs журналов max. И было бы 8 из них не более 50 МБ каждый. Поскольку он говорит, что он получает несколько гигабайт каждый день и предполагает, что они накапливаются с довольно постоянной скоростью, и используется maxsize, он в конечном итоге будет близок к максимуму, достигнутому для каждого файла. Таким образом, они, вероятно, будут близки к 50MB каждый. Учитывая том, который они строят, ему нужно будет убедиться, что logrotate запускается достаточно часто, чтобы соответствовать целевому размеру.

так как я поставил там ежечасно, нам понадобится logrotate, чтобы работать как минимум каждый час. Но так как они накапливаются, чтобы сказать 2 гигабайта в день, и мы хотим 50MB. предполагая постоянную скорость, которая составляет 83MB в час. Таким образом, вы можете себе представить, что если мы будем запускать logrotate каждый час, несмотря на установку maxsize в 50, в этом случае мы получим журнал 83MB. Поэтому в этом случае установите запуск на каждые 30 минут или меньше должно хватить.

убедитесь, что logrotate запускается каждые 30 минут.

Источник

Оцените статью