настроить ротацию логов linux
Ротация логов в Linux и FreeBSD с помощью logrotate
С помощью утилиты logrotate можно настроить автоматическое удаление (чистку) лог-файлов. В противном случае, некоторые логи могут заполнить все дисковое пространство, что приведет к проблемам в работе операционной системы.
Установка
Чаще всего, в Linux данная утилита установлена по умолчанию. Если это не так, установка выполняется следующими командами.
Ubuntu / Debian:
apt-get install logrotate
CentOS / Red Hat:
yum install logrotate
FreeBSD:
pkg install logrotate
Утилита не работает как служба, поэтому нет необходимости в ее запуске или перезагрузке (logrotate start или logrotate restart делать не нужно).
Настройка
Для приложение, ротация логов настраивается в отдельных файлах, расположенных по пути /etc/logrotate.d/ (во FreeBSD — /usr/local/etc/logrotate.d/).
К примеру, нам необходимо настроить ротацию лога для logstash-forwarder. Создаем файл со следующим содержимым:
/var/log/logstash-forwarder/* <
rotate 30
size=10M
missingok
notifempty
daily
compress
delaycompress
maxage 30
create 0644 root root
postrotate
/usr/bin/systemctl restart logstash-forwarder
endscript
>
* /var/log/logstash-forwarder/* — путь к файлу, который нужно ротировать. * указывает, что нужно чистить все файлы, которые расположены в каталоге /var/log/logstash-forwarder.
* напомню, что во FreeBSD, путь будет /usr/local/etc/logrotate.d/logstash.
При настройке необходимо проверять работу сервиса после ротации лога. Некоторые службы могут перестать работать без лог-файла. В данном случае, необходимо создавать новый (create). Также, в некоторых случаях, сервис необходимо перезапускать, так как при создании нового файла меняется его дескриптор.
Запуск вручную
Запуск выполняется со следующим синтаксисом:
Автоматический запуск
Задание на автоматический запуск создается по умолчанию в файле /etc/cron.daily/logrotate. Если изучить его содержимое, мы увидим, что идет запуск logrotate, который читает все файлы в директории /etc/logrotate.d/ и выполняющий для каждого из них ротацию.
Если для какого-то приложения необходимо выполнять ротацию лога по особому расписанию, узнаем полный путь до утилиты logrotate:
* в моем случае, это было /usr/sbin/logrotate.
Получив путь, создаем правило в cron:
* в данном примере в 00:00 будет запускаться logrotate и чистить логи с нашей настройкой для logstash-forwarder.
Установка и настройка Logrotate в Linux
Директория /var/log – одна из наиболее интересных (и, возможно, наиболее важных) директорий в Linux. В соответствии со стандартом иерархии файловых систем, данные о работе большинства запущенных в системе служб сохраняются в файлы в этой директории или одной из ее поддиректорий.
Такие файлы называются журналами или логами, и они являются ключом к анализу работы системы (и того, как она работала раньше). Логи также являются первым источником информации для администраторов и инженеров при устранении неполадок.
Зачем нужна ротация логов
Если посмотреть содержимое /var/log в различных дистрибутивах Linux, мы увидим следующие файлы и поддиректории. У вас они могут отличаться в зависимости от запущенных в вашей системе служб и времени их работы.
Если бы логи хранились вечно, в какой-то момент они бы заполнили всю файловую систему, где находится /var/log. Чтобы этого не произошло, можно воспользоваться полезной утилитой под названием logrotate для периодической очистки (ротации) логов.
Другими словами, logrotate переименовывает или сжимает файл лога при выполнении определенных условий (мы рассмотрим их чуть ниже), а следующее событие записывается в пустой файл. Кроме того, она удаляет «старые» файлы логов и сохраняет только более новые. Естественно, мы сами определяем критерии «старости» и периодичность очистки.
Установка logrotate
Для установки logrotate просто воспользуйтесь менеджером пакетов.
В CentOS, RHEL и Fedora
В дальнейших примерах мы для большей упорядоченности будем придерживаться именно этого подхода настройки logrotate.
Примеры настроек Logrotate
Logrotate – очень многофункциональный инструмент. Он располагает большим разнообразием опций для определения того, когда и как будет выполняться ротация логов и какие действия будут выполняться с ними в дальнейшем.
Вставьте в файл /etc/logrotate.d/httpd следующие строки (скорее всего, этот файл будет создан при установки):
Рассмотрим назначение каждой из них.
Первая строка показывает, что директивы в данном блоке применяются ко всем логам в директории /var/log/apache2.
weekly — означает еженедельную ротацию логов. Другие возможные значения – daily (ежедневно) и monthly (ежемесячно).
rotate 3 — задает сохранение только 3 прошедших ротацию логов. Таким образом, при четвертом запуске самый старый файл будет удален.
size=10M — устанавливает минимальный размер файла для ротации равным 10 мегабайт. Другими словами, ротация не будет выполняться, пока лог не достигнет размера в 10 Мб
compress и delaycompress — используются для того, чтобы задать сжатие всех сохраненных логов кроме самого последнего.
Вместо сжатия логов их можно переименовывать в соответствии с датой ротации. Для этого используется директива dateext. Для использования формата даты, отличного от ГГГГММДД можно указать желаемый формат.
Мы также можем исключить ротацию лога, если он пустой, воспользовавшись опцией notifempty. Кроме того, зададим отправку заполненных логов системному администратору по электронной почте (в данном случае admin@mydomain.com), для этого в системе должен быть настроен почтовый сервер.
В следующем примере настроим файл конфигурации /etc/logrotate.d/squid с использованием описанных выше параметров для ротации лога /var/log/squid/access.log:
Как мы видим, ротация этого лога не требуется. Однако, при выполнении условия по размеру (size=1M), лог будет переименован в access.log-25022019 (если ротация была произведена 25 февраля 2019 года), и будет создан новый файл access.log с правами доступа 0644, и владельцем root. Когда наберется 6 логов, самый старый из них будет отправлен на admin@mydomain.com.
Теперь допустим, что при выполнении ротации вам требуется запуск собственной команды. Для этого пропишите строку с этой командой между директивами postrotate и endscript. Например, если требуется уведомлять root-пользователя по электронной почте о каждой ротации логов в директории /var/log/myservicegets, добавьте в блок три последних строки:
Важно помнить, что в случае конфликтов параметры в файлах конфигурации, расположенных в директории /etc/logrotate, имеют приоритет перед параметрами в основном файле конфигурации.
Logrotate и Cron
По умолчанию после установки logrotate в директории /etc/cron.daily создается файл crontab с именем logrotate. Как и в случае с другими файлами crontab в этой директории, он будет выполняться ежедневно в соответствиями с настройками в /etc/crontab.
Заключение
В системе, где ведется множество логов, их администрирование может быть существенно упрощено при помощи logrotate. Как было рассмотрено в данном руководстве, данная утилита будет автоматически выполнять ротацию, сжимать, удалять логи и отправлять их по электронной почте с заданной периодичностью или при достижении файлом определенного размера. Просто убедитесь, что для запуска logrotate есть соответствующая задача cron, и все станет гораздо проще. Для более подробной информации обратитесь к соответствующей man-странице.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
🐧 Как настроить и управлять ротацией логов с помощью Logrotate на Linux
Один из самых интересных (и, возможно, один из самых важных) каталогов в системе Linux – это /var/log.
Согласно Стандарту иерархии файловой системы, активность большинства служб, работающих в системе, записывается в файл внутри этого каталога или одного из его подкаталогов.
Такие файлы известны как логи и являются ключом к изучению того, как работает система (и как она вела себя в прошлом).
Логи, они же ж урналы также являются первым источником информации, куда администраторы и инженеры обращаются при устранении неполадок.
Если мы посмотрим на содержимое /var/log в CentOS/RHEL/Fedora и Debian/Ubuntu (для разнообразия), мы увидим следующие файлы логов и подкаталоги.
Обратите внимание, что результат может несколько отличаться в вашем случае в зависимости от служб, запущенных в вашей системе (ах), и времени, в течение которого они были запущены.
На RHEL / CentOS и Fedora
На Debian и Ubuntu, Kali Linux и т.д
Это не стандартное поведение по умолчанию, основанное на выбранном дистрибутиве, ведь оно может быть изменено по желанию с помощью директив в файлах конфигурации, как мы увидим в этой статье.
Если бы логи хранились вечно, они в конечном итоге заполнили бы файловую систему, в которой находится /var/log.
Чтобы предотвратить это, системный администратор может использовать полезную утилиту logrotate для периодической очистки журналов.
Вкратце, logrotate переименовывает или сжимает основной журнал при выполнении условия (подробнее об этом через минуту), чтобы следующее событие было записано в пустой файл.
Кроме того, он удалит «старые» файлы журналов и сохранит самые свежие.
Конечно, мы должны решить, что означает «старый» и как часто мы хотим, чтобы logrotate очищал журналы за нас.
Установка Logrotate на Linux
Чтобы установить logrotate, просто используйте свой менеджер пакетов:
Это будет так, если и только если следующая строка существует и не закомментирована:
Настройка Logrotate на Linux
Будучи очень универсальным инструментом, logrotate предоставляет множество директив, которые помогают нам его настроить, когда и как будут ратироваться журналы, а также что должно произойти сразу после этого.
Давайте вставим следующее содержимое в /etc/logrotate.d/apache2.conf (обратите внимание, что, скорее всего, вам придется создать этот файл) и исследуем каждую строку.
Вместо сжатия журналов мы могли бы переименовать их по дате, когда они были ратированы.
Для этого воспользуемся директивой dateext.
Если наш формат даты отличается от формата по умолчанию yyyymmdd, мы можем указать его с помощью dateformat.
Обратите внимание, что мы можем даже предотвратить ротацию, если журнал пуст с помощью notifempty.
Кроме того, давайте укажем logrotate отправлять обновленный лог системному администратору (в данном случае admin@mydomain.com) для его справки (для этого потребуется настроить почтовый сервер, что выходит за рамки этого статья).
На этот раз мы будем использовать /etc/logrotate.d/squid.conf только для ратации /var/log/squid/access.log:
Заключение
В системе, которая генерирует много логов, администрирование таких файлов можно значительно упростить с помощью logrotate.
Как мы объясняли в этой статье, он будет автоматически ратировать, сжимать, удалять и отправлять логи по почте на периодической основе или когда файл достигает заданного размера.
Чтение и настройка логов Linux в Ubuntu и Centos
Администраторам Linux часто нужно заглядывать в лог-файл для устранения неполадок. По сути, это действие первой необходимости для любого админа.
Система Linux и ее приложения могут создавать разные типы сообщений, которые записываются в различные журналы. Linux использует набор конфигурационных файлов, каталогов, программ, команд и демонов для создания, хранения и повторного использования таких сообщений. Поэтому зная, где система хранит свои журналы и как воспользоваться определенными командами, можно сэкономить драгоценное время во время устранения неполадок.
Данное руководство рассматривает различные части механизма журналирования Linux.
Примечание: Команды данного руководства были протестированы на простых установках CentOS 6.4, Ubuntu 12 и Debian 7.
Стандартные логи
По умолчанию журналы в Linux хранятся в /var/log.
В системе CentOS это выглядит так:
Просмотр логов
В каталоге /var/log находится несколько общих журналов:
Файлы wtmp и utmp отслеживают пользователей, вошедших и покинувших систему. Содержимое данных журналов нельзя читать с помощью простой команды «cat», для этого есть специальные команды, с которыми теперь нужно ознакомиться.
Чтобы узнать, кто в текущий момент находится на сервере Linux, нужно использовать команду «who». Она извлекает информацию из /var/run/utmp (в CentOS и Debian) или из /run/utmp (в Ubuntu).
Это пример ее работы в CentOS:
]# who
root tty1 2013-12-09 10:44
root pts/0 2013-12-09 10:29 (10.0.2.2)
sysadmin pts/1 2013-12-09 10:31 (10.0.2.2)
joeblog pts/2 2013-12-09 10:39 (10.0.2.2)
Команда «sysadmin» выводит историю входа пользователей:
В данном примере нужно было получить историю входа пользователя sysadmin. Как можно видеть, было пару случаев, когда он приводил к сбою системы.
Чтобы узнать время последней перезагрузки системы, используйте следующую команду:
Результат имеет примерно такой вид:
Чтобы узнать время последнего входа в систему, используйте lastlog:
Результат на CentOS выглядит примерно так:
Username Port From Latest
root tty1 Mon Dec 9 10:44:30 +1100 2013
bin **Never logged in**
daemon **Never logged in**
adm **Never logged in**
lp **Never logged in**
sync **Never logged in**
shutdown **Never logged in**
halt **Never logged in**
mail **Never logged in**
uucp **Never logged in**
operator **Never logged in**
games **Never logged in**
gopher **Never logged in**
ftp **Never logged in**
nobody **Never logged in**
vcsa **Never logged in**
saslauth **Never logged in**
postfix **Never logged in**
sshd **Never logged in**
sysadmin pts/1 10.0.2.2 Mon Dec 9 10:31:50 +1100 2013
dbus **Never logged in**
joeblog pts/2 10.0.2.2 Mon Dec 9 10:39:24 +1100 2013
Для просмотра содержимого текстовых журналов можно использовать команды «cat», «head» или «tail».
В приведенном ниже примере просматриваются последние 10 строк журнала /var/log/messages на Debian:
$ sudo tail /var/log/messages
Демон rsyslog
Центром механизма журналирования является демон rsyslog. Данный сервис отвечает за прослушивание зарегистрированных сообщений различных частей системы Linux и маршрутизацию сообщения к соответствующему журналу в каталоге /var/log. Он также может передавать зарегистрированные сообщения другому серверу Linux.
Конфигурационный файл rsyslog
Демон rsyslog получает конфигурации из файла «rsyslog.conf», который находится в каталоге /etc.
В основном, файл rsyslog.conf говорит демону, где хранить сообщения. Данная информация имеет вид серии строк, состоящих из двух частей.
Этот файл можно найти в rsyslog.d/50-default.conf в Ubuntu.
Под двумя частями строк подразумеваются селектор и действие (selector и action). Они разделяются пробельным символом.
Селектор указывает на источник и важность сообщения, а действие говорит, что нужно сделать с данным сообщением.
Сам селектор также разделен на 2 части символом точки (.). Часть перед символом точки называется объектом (источник сообщения), а часть за символом называется приоритетом (степень важности сообщения).
Комбинация объекта-приоритета и действия говорит rsyslog, что делать, если сообщение соответствует указанным параметрам.
Вот отрывок из файла rsyslog.conf на CentOS:
Чтобы понять, что все это значит, нужно рассмотреть типы объектов, которые распознает Linux:
Ниже приведен список приоритетов по возрастанию:
Изучите следующую строку из файла:
Она говорит rsyslog сохранять все сообщения, приходящие от демона cron, в файле /var/log/cron. Звездочка (*) поле точки значит, что зарегистрированы будут сообщения всех приоритетов. Аналогичным образом, если объект был определен звездочкой, это объединяет все источники.
Объекты и приоритеты могут быть связаны в несколькими способами.
Вид по умолчанию, когда после точки указан только один приоритет, значит, что будут охвачены все сообщения с таким или высшим уровнем приоритета. Таким образом, данное указание регистрирует все сообщения, приходящие от почтовой подсистемы с приоритетом «warn» и выше в специальном файле в /var/log:
Такие параметры будут регистрировать все сообщения с таким же или высшим, чем warn, приоритетом и пропускать все остальное. То есть, сообщения с приоритетом err, crit, alert и emerg также будут внесены в файл.
Знак равности (=) после точки указывает регистрировать только сообщения с указанным приоритетом. То есть, если нужно регистрировать только сообщения от почтовой подсистемы с приоритетом info, указание будет таким:
Опять же, если нужно регистрировать все сообщения почтовой подсистемы, кроме сообщений с приоритетом info, строка будет выглядеть так:
В первом случае файл mail.info содержал бы все сообщения с приоритетом ниже info. Во втором случае он содержал бы все сообщения с приоритетом выше info.
Несколько объектов в одной строке нужно разделить запятой.
Несколько селекторов в одной строке также разделяются запятой.
Отмеченное звездочкой действие объединяет всех пользователей.
К примеру, об этом говорит запись в файле rsyslog.conf на CentOS:
# Everybody gets emergency messages
*.emerg *
По возможности проверьте, что говорит rsyslog.conf на других системах Linux. Вот отрывок из Debian:
Как можно видеть, Debian сохраняет сообщения безопасности/авторизации всех уровней в /var/log/auth.log, в то время как CentOS делает это в /var/log/secure.
Конфигурации для rsyslog могут исходить также от других пользовательских файлов. Эти файлы пользовательских конфигураций, как правило, расположены в разных каталогах в /etc/rsyslog.d. Файл rsyslog.conf включает эти каталоги, используя директиву «$IncludeConfig».
Так это выглядит в Ubuntu:
# Default logging rules can be found in /etc/rsyslog.d/50-default.conf
.
.
$IncludeConfig /etc/rsyslog.d/*.conf
Содержимое каталога /etc/rsyslog.d выглядит так:
-rw-r—r— 1 root root 311 Mar 17 2012 20-ufw.conf
-rw-r—r— 1 root root 252 Apr 11 2012 21-cloudinit.conf
-rw-r—r— 1 root root 1655 Mar 30 2012 50-default.conf
Теперь сохранять сообщение в журнал необязательно; сообщение можно переслать консоли пользователя. В таком случае, поле действия будет содержать имя пользователя. Если сообщение нужно отправить нескольким пользователям, их имена нужно разделить запятыми. Если же сообщение нужно распространить между всеми пользователями, в поле действия вносится символ *.
Будучи частью сетевой операционной системы, демон rsyslog может не только хранить зарегистрированные сообщения локально, но и передавать их на другие серверы Linux, а также действовать как репозиторий для других систем. Демон прослушивает сообщения через UDP-порт 514. В приведенном ниже примере он пересылает критические сообщения ядра на сервер под названием «texas»:
Создание и тестирование сообщений
Теперь попробуйте сами создать сообщение.
Для этого нужно будет сделать следующее:
В следующем примере внесены две строки в файл rsyslog.conf на CentOS. Как видите, обе они исходят от объекта local4 и имеют разные приоритеты.
]# vi /etc/rsyslog.conf
.
.
# New lines added for testing log message generation
local4.crit /var/log/local4crit.log
local4.=info /var/log/local4info.log
Затем нужно перезапустить сервис, чтобы обновить данные файла:
]# /etc/init.d/rsyslog restart
Shutting down system logger: [ OK ] Starting system logger: [ OK ] [root@TestLinux
Теперь нужно вызвать приложение logger, чтобы создать сообщение:
Каталог /var/log показывает два новых сообщения:
.
.
-rw——- 1 root root 0 Dec 9 11:21 local4crit.log
-rw——- 1 root root 72 Dec 9 11:22 local4info.log
Размер local4info.log не равен нулю, а это значит, что сообщение было записано:
]# cat /var/log/local4info.log
Dec 9 11:22:32 TestLinux root: This is a info message from local 4
Ротация лог-файлов
Со временем журналы становятся больше, поскольку в них появляется новая информация. Это создает потенциальную проблему производительности. Кроме того, управление файлами становится затруднительным.
Linux использует понятие «ротации» журналов вместо их очистки или удаления. При ротации создается новый каталог, а старый переименуется и при необходимости сжимается. Таким образом, журналы имеют несколько старых версий. Эти файлы будут возвращаться в течение определенного периода времени в виде так называемых backlog-ов. Как только будет получено определенное количество backlog-ов, новая ротация удалит самый старый журнал.
Ротация выполняется при помощи утилиты «logrotate».
Конфигурационный файл logrotate
Как и rsyslog, logrotate зависит от конфигурационного файла по имени logrotate.conf, который находится в /etc.
Вот что находится в данном файле на Debian:
По умолчанию журналы ротируются еженедельно, оставляя 4 backlog-а. При запуске программы создается новый пустой журнал, а старые при необходимости будут сжаты.
Файлы wtmp и btmp являются исключениями. wtmp отслеживает вход в систему, а btmp содержит информацию о неудавшихся попытках входа. Эти журнальные файлы ротируются каждый месяц, и ошибки не возвращаются, если можно найти один из предыдущих файлов wtmp или btmp.
Пользовательские конфигурации ротации журналов содержатся в каталоге «etc/logrotate.d». также они включены в logrotate.conf с помощью директивы include. К примеру, Debian показывает такое содержание данного каталога:
Содержание rsyslog показывает, как вернуть логи в исходное состояние:
$ cat /etc/logrotate.d/rsyslog
/var/log/syslog
<
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
invoke-rc.d rsyslog reload > /dev/null
endscript
>
/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
<
rotate 4
weekly
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
invoke-rc.d rsyslog reload > /dev/null
endscript
>
Как видите, файл «syslog» будет повторно инициализирован каждый день. Другие журнальные файлы ротируются каждую неделю.
Также стоит упомянуть директив postrotate. Она указывает действие, которое происходит после того, как ротация журналов завершена.
Тестирование ротации
Logrotate можно запустить вручную для ротации одного или нескольких файлов. Чтобы это сделать, нужно просто указать соответствующий конфигурационный файл как аргумент.
Чтобы продемонстрировать, как это работает, ниже приведен неполный список журнальных файлов в каталоге /var/log на CentOS:
Неполное содержимое файла logrotate.conf выглядит так:
]# cat /etc/logrotate.conf
# see «man logrotate» for details
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
.
.
Затем запустите команду logrotate:
Сообщения прокручиваются при создании новых файлов, обнаружении ошибок и т.д. Затем попробуйте проверить новые журнальные файлы почты, безопасности и сообщений:
Как можно видеть, все три новых журнала были созданы. Почтовый журнал и журнал безопасности все еще пусты, но новый журнал сообщений уже содержит некоторые данные.
Заключение
Надеемся, данное руководство дало вам некоторое представление о журналировании Linux. Попробуйте заглянуть в собственные разработки или проверки систем, чтобы иметь более полное понятие. Получив глубокие знания о расположении журнальных файлов, а также ознакомившись с их параметрами конфигураций, можно использовать их для поддержки производительности системы.