Ограничение размера файлов .log и журнала
Введение
Файлы журналов и журнал systemd делают одно и то же, но по-разному. Они ведут запись всего, что происходит в вашей системе. Это позволяет понять что работает правильно, а что - нет. Например, если ваша система подверглась ssh-атаке - это может быть отобажено в логе/журнале. Таким образом, эти журналы полезны не только для отслеживания проблем с оборудованием, драйверами, плохо написанным кодом сетевого менеджера или множества других проблем, с которыми приходится сталкиваться сложной и динамичной системе GNU/Linux.
Эти журналы - настоящее спасение, поскольку не все системы имеют их, и те администраторы серверов, у которых они есть, должны быть очень благодарны, поскольку они могут быть хлебом и маслом для их работы.
Как правило, только администраторы серверов используют журналы, хранящиеся в течение длительного времени. Лишь немногие пользователи дистрибутивов на настольных компьютерах, ноутбуках, нетбуках и подобных машинах, нуждаются в хранении таких огромных файлов журналов или историй за многие месяцы или даже годы. Они занимают много места, а также делают просмотр журналов более сложным.
В первой теме на этой странице будет кратко рассмотрен журнал systemd
Журнал systemd занял место файлов журналов, хотя он прекрасно работает параллельно с файлами журналов стандартного типа. Они по-прежнему создаются и поддерживаются по умолчанию в Arch и Manjaro. Если вы удалите syslog-ng и все файлы /var/log/*log, то при перезагрузке обнаружите что некоторые файлы логов будут созданы снова автоматически. На моей машине после удаления syslog-ng и всех файлов /var/log/*.log (за исключением Xorg.0.log), моя машина теперь имеет следующее содержимое (wtmp и btmp создаются при загрузке файлом /etc/logrotate.conf) в /var/log/:
journal/ squid/ Xorg.0.log Xorg.0.log.old btmp faillog lastlog pacman.log wtmp
Вторая тема будет посвящена работе с файлами журналов
Эта тема будет более глубокой - в ней мы рассмотрим использование команды logrotate, logrotate.conf, /etc/cron.daily cron.weekly cron.monthly cron.yearly и некоторые способы запуска созданных скриптов, а также упомянем метод запуска скрипта crontab. Я постараюсь сделать этот раздел доступным для как можно большего числа людей, а это означает что страница будет довольно длинная.
Журнал и логи дублируют одну и ту же информацию
Вы можете читать текст файлов логов в текстовом редакторе или с помощью команд cat, more, less и подобных, как и для любого другого текстового файла. Журнал же требует команды journalctl для доступа к его содержимому. Ниже приведен хороший способ чтения журнала:
sudo journalctl
Прочитайте это - это важно
man journald.conf
Когда пакетам необходимо настроить конфигурацию - они могут установить фрагменты конфигурации в /usr/lib/systemd/*.conf.d/. Файлы в /etc/ зарезервированы для локального администратора, который может использовать эту логику для переопределения конфигурационных файлов, установленных пакетами вендора. Главный конфигурационный файл читается перед любым из каталогов конфигурации и имеет наименьший приоритет; записи в файле в любом каталоге конфигурации переопределяют записи в единственном файле конфигурации. Файлы в подкаталоге конфигурации *.conf.d/ сортируются по имени файла в лексикографическом порядке, независимо от того, в каком из подкаталогов они находятся. Если в нескольких файлах указана одна и та же опция, приоритет имеет запись в файле с самым лексикографически последним именем. Рекомендуется снабжать все имена файлов в этих подкаталогах двузначным числом и тире для упрощения упорядочивания файлов.
Это означает, что вы можете создавать конфигурационные файлы .conf в каталоге /etc/systemd/journald.conf.d/ с подходящими именами по вашему выбору. Содержимое этих файлов имеет приоритет над любыми другими настройками или конфигурациями в systemd. Пожалуйста, имейте это в виду, когда будете читать следующее. В своей многословной манере я попытался сделать все это слишком очевидным...
Как установить ограничение на максимальный размер журнала
Обычно нет необходимости вмешиваться в максимальный размер журнала, так как он создан для мониторинга количества свободного места на разделе, где он существует, и будет самостоятельно удалять самые старые записи, когда этого потребует нехватка места.
Используйте ваш любимый текстовый редактор с привилегиями root (запустите его с помощью sudo).
С помощью текстового редактора создайте файл под названием size.conf в следующем месте /etc/systemd/journald.conf.d/size.conf. Следующий файл устанавливает максимальный размер файла в 50 МБ для /var/log/journal . (SystemMaxUse=250M предназначено для использования с logrotate, рассматриваемыми во втором разделе этой страницы. Поговорите с papajoke на форуме если вам нужна помощь с logrotate и systemd.)
[Journal] SystemMaxUse=250M SystemMaxFileSize=50M
Вы также можете ограничить содержимое журнала, указав уровень данных, добавляемых в журнал. Это делается путем создания и редактирования файла /etc/systemd/journald.conf.d/level.conf.
Примечание: файл level.conf создается пользователем.
[Journal] # не сохранять все уровни, а только от 0 до 4 MaxLevelStore=warning
Команда Journalctl - краткое руководство [1]
Вы не должны использовать "sudo" с journalctl
Добавьте вашего пользователя в группу adm. Это даст вашему <пользователю> полное право использовать команду journalctl. Больше не нужно использовать sudo. Поменяйте "handy" на ваше имя пользователя в следующих строках:
# usermod -a -G adm handy
Посмотреть всю строку вывода journalctl
Вы можете передать вывод journalctl в файл или в инструмент отображения текста, например, "More" или "Less", следующим образом:
$ journalctl -b -p err|less
Это позволит избежать усечения вывода, которое может наблюдаться в некоторых конфигурациях дисплеев.
Используйте альяс ~/.bashrc чтобы сделать это проще
Я использую следующий альяс ~/.bashrc:
alias errors="journalctl -b -p err|less"
При вводе errors в терминале, все ошибки или проблемы с момента последней загрузки отправляются (передаются) в инструмент отображения текста в терминале под названием Less, который оборачивает текстовый вывод команды journalctl. Помимо этого, он делает ошибки более удобочитаемыми для тех, кто будет читать их на форуме!
Введите q (в верхнем или нижнем регистре) чтобы закрыть "Less".
Доступ к полному журналу, содержащему информацию о системе и пользователях:
$ journalctl
Просмотр в реальном времени - показывает последние 10 строк журнала и все содержимое по мере того как он пополняется:
$ journalctl -f
Основная фильтрация:
Показывает весь вывод в журнал с момента последней загрузки:
$ journalctl -b
Показывает весь вывод с уровнем приоритета ERROR и выше с момента последней загрузки:
$ journalctl -b -p err
Ниже приведена команда, вывод которой отправляется в файл с именем -ERRORS в каталоге /home/<user>. Наличие символа - в начале имени должно привести к тому, что файл будет отображаться в самом начале списка файлов при просмотре содержимого вашего каталога ~/ (/home/<user>). Эта команда позволяет легко скопировать содержимое файла -ERRORS, а затем вставить его на форум. Это дает нам возможность отобразить ВЕСЬ вывод команды, а не только вырезать и вставлять усеченные строки из терминала:
$ Journalctl -b -p err > -ERRORS
Фильтрация по времени:
Со вчерашнего дня:
$ journalctl --since=yesterday
Указать конкретный период времени:
$ journalctl --since=2012-10-15 --until="2011-10-16 23:59:59"
Выбрать конкретную службу и период времени:
$ journalctl -u httpd --since=00:00 --until=9:30
Указать journalctl на определенные устройства, сервисы, двоичные файлы
Просмотр конкретного устройства:
$ journalctl /dev/sdc
Проверка бинарного файла:
$ journalctl /usr/sbin/vpnc
Проверка взаимосвязанного вывода двух характеристик:
$ journalctl /usr/sbin/vpnc /usr/sbin/dhclient
Показать все модули systemd, запущенные в вашем журнале:
$ journalctl -F _SYSTEMD_UNIT
Затем вы можете опросить журнал, указав любой из этих модулей.
Резюмируя
Журнал Systemd способен выполнять расширенные функции, выходящие за рамки того, что было упомянуто здесь. Вышеизложенное является очень хорошей пищей для размышлений людям, задающимся вопросом, нужно ли им запускать syslog-ng или что-то подобное, создающее множество файлов /var/log/*log в их системах.
Экспериментируя с приведенными выше командами, можно принять обоснованное решение, хотя, как уже упоминалось в начале раздела "Журнал", Arch и, соответственно, Manjaro все еще работают параллельно с новым журналом systemd и файловой системой журналов старого стиля. Поэтому, если вы считаете файлы /var/log/*log избыточными и хотите избавиться от них - эффективными будут различные методы.
На данный момент я запускаю свою систему с удаленным syslog-ng (и его зависимостью). Я удалил все файлы журналов из каталога /var/log (оставив тоько находящиеся в собственных подкаталогах), кроме Xorg.0.log, Xorg.0.old, lastlog, btmp и wtmp, (pacman.log появлялся при использовании pacman, в зависимости от того, что у вас установлено в системе, у вас могут быть приложения, создающие свои собственные журналы - которые можно отключить).
Управление файлами /var/log/*
Представляем Logrotate и друзей
Что такое Logrotate? [2] logrotate - это мощный инструмент, используемый для управления лог-файлами, создаваемыми системными процессами. Его можно настроить на автоматическое сжатие, переименование различными способами, удаление журналов, на выполнение всего этого и многого другого таким образом, чтобы максимально повысить удобство использования журналов и сэкономить ресурсы системы. Пользователям доступно огромное количество средств контроля, включая запуск скриптов на ваших ротируемых файлах.
Проблема, с которой я столкнулся пытаясь сделать эту статью о logrotate как можно более простой, заключается в том, что logrotate можно вызвать очень многими способами и эти способы не являются взаимоисключающими.
Например, logrotate может быть вызван для запуска файла или нескольких файлов в любой комбинации или кратности ежечасно (hourly), ежедневно (daily), еженедельно (weekly), ежемесячно (monthly) и ежегодно (yearly), через скрипты, размещенные в /etc/ в уже существующих каталогах hourly daily weekly monthly (каталог yearly может быть добавлен при необходимости). crontab [3] можно использовать для запуска logrotate или настолько сложных скриптов, насколько это необходимо. logrotate можно комбинировать с другими инструментами, которые пользователь может придумать для обработки этих ротируемых файлов в любое время и с любой частотой.
Область применения данной статьи
Тем не менее, большая часть возможностей logrotate предназначена для администраторов серверов и не будет рассматриваться ниже. Хотя то, что мы рассмотрим, может быть использовано не только для файлов журналов. Мы можем использовать logrotate для резервного копирования любых других файлов по своему усмотрению. Я расскажу об этом позже.
/etc/logrotate.conf и /etc/logrotate.d
Файл конфигурации logrotate.conf в значительной степени определяет поведение logrotate - он содержит глобальные настройки, но большая часть работы, которую выполняет logrotate, осуществляется с помощью файлов сценариев, хранящихся в каталоге /etc/logrotate.d, имеющими приоритет над глобальными настройками, содержащимися в logrotate.conf.
Такие приложения, как Apache, MySQL, Cups и другие, помещают скрипты в каталог /etc/logrotate.d для управления своими лог-файлами.
Если вы вручную запустите команду sudo logrotate - вам будет представлен шаблон ее использования. logrotate требует указать путь к скрипту, который вы хотите использовать, включая файл logrotate.conf, который, как можно подумать из-за его названия, будет автоматически прочитан, но это не так.
Для запуска logrotate и файла logrotate.conf используется следующая команда:
logrotate /etc/logrotate.conf
Могу ли я хранить и запускать свои файлы скриптов в другом месте?
В logrotate.conf есть строка, указывающая logrotate запускать все скрипты, существующие в /etc/logrotate.d
include /etc/logrotate.d
Мы можем использовать команду include в logrotate.conf для добавления других каталогов или использовать другой каталог вместо logrotate.d, если есть на то причины. Будьте осторожны в своих действиях, так как в каталог logrotate.d могут быть помещены файлы, созданные другими программами.
Мои настройки в logrotate.conf не влияют на все .log файлы?
Файлы сценариев, вызываемые через файл logrotate.conf, имеют приоритет над глобальными настройками в logrotate.conf. Это означает, что если вы вызываете скрипт из logrotate.conf, находящийся в каталоге /etc/logrotate.d, то этот скрипт будет более приоритетным, чем любые глобальные настройки в logrotate.conf .
Я использую скрипт /etc/logrotate.d/rotate.logs, настроенный на работу со всеми *.log файлами, и он работает. Два неротируемых файла называются faillog и lastlog, кроме того, что у них нет расширения log, эти два файла не являются обычными файлами журнала, доступ к ним осуществляется через одноименные команды терминала.
Могу ли я хранить свои скрипты где хочу?
Некоторые приложения, такие как Apache или cups, помещают скрипты в /etc/logrotate.d, чтобы помочь в их самообслуживании. Мы можем использовать для этих или других скриптов любое место по своему усмотрению. Мы просто должны указать путь к нему в файле /etc/logrotate.conf, как показано в следующем примере:
include /home/handy/.config/mylogrotate
Помимо добавления собственных скриптов в /etc/logrotate.d (или по любому другому пути, который мы выбрали), мы также можем добавить скрипты в любой из ранее упомянутых каталогов /etc/ cron.hourly cron.daily cron.weekly cron.monthly. ИЛИ мы можем добавить скрипт в любой из этих каталогов, подходящих для наших нужд, запускающий команду logrotate /etc/logrotate.conf, которая будет имея файл logrotate.conf, направлять logrotate в каталог по умолчанию /etc/logrotate.d, где у нас есть наш скрипт(ы). ИЛИ в другой каталог, где находится наш скрипт, и вложенный (через include) в logrotate.conf. Вот это да!
Как видите, существует множество способов вызова logrotate (не говоря уже об его использовании).
Некоторые варианты использования Logrotate
Например, приведенный ниже блок сценария выполняет следующие действия, перечисленные построчно:
- /var/log/*.log { указывает файл или файлы, так как в данном примере используется подстановочный знак, указывающий на все файлы, заканчивающиеся на .log , { начинает список команд, которые будут использоваться для только что указанного файла (файлов).
- daily - здесь мы говорим о ежедневном цикле выполнения этих команд, мы также можем использовать еженедельно (weekly), ежемесячно (monthly), ежегодно (yearly) (или указать другое время с помощью crontab)[4].
- size здесь мы можем установить ограничение на размер, которое приведет к ротации файла. В примере я установил ограничение размера 1M, т.е. в один мегабайт.
- dateext помещает дату ротации на новую копию, так что она будет использовать такой формат: <имя_файла>.log-20221219
- rotate 7 означает сохранение 7 ежедневных (в данном сценарии) резервных копий и удаление самой старой, когда она становится 8-й.
- compress очевиден - использовать gzip по умолчанию и добавлять расширение .gz к файлу, в результате чего он будет выглядеть следующим образом: <имя_файла>.log.1.gz. Вы можете выбрать другие методы сжатия, я не буду вдаваться в подробности.
- delaycompress указывает logrotate на сжатие только что ротированного файла в следующем цикле. Это имеет преимущества в простоте доступа, а также если файл все еще записывается процессом после того, как он был ротирован.
- copytruncate - отличный вариант, так как он копирует содержимое файла в новый файл <имя_файла>.log.1 и затем удаляет содержимое исходного файла. При таком способе не возникнет проблем с разрешениями.
- notifempty ничего не делать если файл пуст, что имеет логический смысл.
- missingok - если файл не существует, то не выдавать ошибку.
- } эта фигурная скобка закрывает блок команд.
/var/log/*.log {
daily
size 1M
dateext
rotate 7
compress
delaycompress
copytruncate
notifempty
missingok
}
Приведенный выше скрипт можно использовать как есть - его не нужно делать исполняемым, его просто нужно поместить в место, которое logrotate будет видеть (в данном примере) каждый день.
Мы можем использовать приведенный выше блок сценария в качестве шаблона, легко удаляя части и изменяя его относительно простые настройки. Он может быть продублирован в сценарии с каждым блоком, определяющим индивидуальные настройки для отдельных файлов.
Пример, который вы можете изменить в соответствии с требованиями
Я покажу как настроена моя система (на момент написания данной статьи), вы можете использовать информацию уже приведенную на этой странице и другую, доступную в Интернете, чтобы точно настроить свою систему в соответствии с вашими потребностями (если у вас вообще есть такая необходимость).
Во-первых - Убедитесь, что этот файл находится здесь /etc/cron.daily/logrotate
#!/bin/sh
# приятности варьируются от -20 (наиболее благоприятное расписание) до 19 (наименее благоприятное)
NICE=19
# 0 - нет, 1 - в реальном времени, 2 - в лучшем режиме, 3 - в режиме ожидания
IONICE_CLASS=2
# 0-7 (только для IONICE_CLASS 1 и 2), 0=высокий, 7=низкий
IONICE_PRIORITY=7
CMD_LOGROTATE="/usr/bin/logrotate /etc/logrotate.conf"
if [ -x /usr/bin/nice ]; then
CMD_LOGROTATE="/usr/bin/nice -n ${NICE:-19} ${CMD_LOGROTATE}"
fi
if [ -x /usr/bin/ionice ]; then
CMD_LOGROTATE="/usr/bin/ionice -c ${IONICE_CLASS:-2} -n ${IONICE_PRIORITY:-7} ${CMD_LOGROTATE}"
fi
${CMD_LOGROTATE}
exit 0
Во-вторых - Создайте /etc/logrotate.d/rotate.logs, используя следующее
## ротировать все файлы /var/log с именами, заканчивающимися на log
/var/log/*log {
## выполнять эти команды один раз в день
daily
## сохранять результаты 7 циклов
rotate 7
## использовать gzip для сжатия каждого ротированного (скопированного) файла журнала
compress
## сжимать файл на следующем цикле
delaycompress
## скопировать содержимое файла журнала в новый файл <имя>.log.1
## и затем удалить содержимое исходного файла
copytruncate
## ничего не делать с пустыми файлами
notifempty
## не выдавать ошибок если файл отсутствует
missingok
## после того, как файлы будут ротированы, выполнить следующую команду
}
Краткое изложение приведенного выше примера на данный момент
Первый шаг помещает файл в /etc/cron.daily, что является простым способом добавить скрипт в ежедневное задание cron. Это означает, что скрипт будет выполняться каждый день.
По сути, он выполняет эту команду:
logrotate /etc/logrotate.conf
Когда logrotate.conf проходит через свой список команд - он вызывает эту команду:
include /etc/logrotate.d
Это означает что все скрипты, находящиеся внутри /etc/logrotate.d, также будут запущены.
Это подводит нас ко второму шагу (выше), где мы создали /etc/logrotate.d/rotate.logs. Этот скрипт будет выполняться каждый день. Комментарии, которые я добавил к файлу rotate.logs, дают общее представление о том, что он делает. Вы можете удалять, изменять и дополнять этот скрипт, но делайте это с осторожностью.
Эффект от ежедневного запуска /etc/logrotate.d/rotate.logs
Это означает, что любой файл в /var/log, имеющий log в конце своего имени, будет обработан командами скрипта rotate.logs. Это приведет к резервному копированию этих файлов в новый файл <имя>.log.1 и очистке содержимого исходного файла. Все предыдущие копии с <имя>.log.<номер> будут иметь номера, увеличенные на единицу до дня, когда им будет присвоена цифра 8, то есть до дня, когда они будут удалены.
Помимо ротации (копирования) и переименования файлов, все файлы будут сжаты в формате gzip при следующей ротации. Это означает, что в /var/log всегда есть текущий файл и файл вчерашнего дня в несжатом формате.
Пустые файлы обрабатываться не будут, а отсутствующий файл не вызовет ошибок.