Ведение журнала системы
Общие сведения
Если не брать в расчет systemd-journald (о котором мы поговорим на следующем уроке), то ведение журналов традиционно осуществлялось с помощью трех основных специализированных сервисов: syslog, syslog-ng (новое поколение syslog) и rsyslog («реактивная система обработки журналов»). rsyslog привнес важные улучшения (например, поддержку протокола RELP) и стал самым популярным решением на сегодняшний день.
Каждый из этих сервисов собирает сообщения от других сервисов и программ и сохраняет их в лог-файлах, обычно в папке /var/log. Однако некоторые сервисы ведут собственные журналы (например, веб-сервер Apache HTTPD или система печати CUPS). Аналогичным образом ядро Linux использует кольцевой буфер в оперативной памяти для хранения сообщений журнала.
RELP Расширяет функциональность протокола системного журнала Reliable Event Logging Protocol и обеспечивает надежную доставку сообщений.
rsyslog использует клиент-серверную модель. Клиент и сервер могут находиться на одном хосте или на разных машинах
Сообщения отправляются и принимаются в определенном формате и могут храниться на централизованных rsyslog серверах в IP-сетях
Демон rsyslog — rsyslogd — работает вместе с klogd (который управляет сообщениями ядра).
Демон — это служба, работающая в фоновом режиме. Обратите внимание на последний символ d в названиях демонов: klogd или rsyslogd.
Поскольку логи представляют собой переменные данные, обычно они хранятся в /var/log. Грубо говоря, их можно разделить на системные логи и логи сервисов или программ.
Некоторые основные логи:
/var/log/auth.log Действия, связанные с процессами аутентификации: зарегистрированные пользователи, sudo информация, задания cron, неудачные попытки входа в систему и т. д. /var/log/syslog Централизованный файл практически со всеми журналами, собранными с помощью rsyslogd. Поскольку в нем содержится много информации, журналы распределяются по другим файлам в соответствии с конфигурацией, указанной в /etc/rsyslog.conf. /var/log/debug Отладочная информация из программ. /var/log/kern.log Сообщения ядра. /var/log/messages Информационные сообщения, связанные не с ядром, а с другими службами. Кроме того, это стандартное место назначения для журналов удаленных клиентов в реализации централизованного сервера журналов. /var/log/daemon.log Информация о демонах или службах, работающих в фоновом режиме. /var/log/mail.log Информация, связанная с почтовым сервером, например postfix. /var/log/Xorg.0.log Информация, связанная с видеокартой. /var/run/utmp и /var/log/wtmp Успешный вход в систему. /var/log/btmp Неудачные попытки входа в систему, например атака методом перебора через ssh. /var/log/faillog Неудачные попытки аутентификации. /var/log/lastlog Дата и время последнего входа пользователя в систему. /var/log/cups/ Каталог для журналов Common Unix Printing System. Обычно в него входят следующие файлы журналов по умолчанию: error_log, page_log и access_log. /var/log/apache2/ или /var/log/httpd Каталог для журналов веб-сервера Apache. Обычно в него входят следующие файлы журналов по умолчанию: access.log, error_log, и other_vhosts_access.log. /var/log/mysql Каталог для журналов системы управления реляционными базами данных MySQL. Обычно в него входят следующие файлы журналов по умолчанию: error_log, mysql.log и mysql-slow.log. /var/log/samba/ Каталог для журналов протокола Session Message Block (SMB). Обычно он включает в себя следующие файлы журналов по умолчанию: log., log.nmbd и log.smbd.Точное название и содержимое лог-файлов могут различаться в разных дистрибутивах Linux. Существуют также лог-файлы, характерные для определенных дистрибутивов, например /var/log/dpkg.log (содержащий информацию о dpkg пакетах) в Debian GNU/Linux и его производных.
syslog обычно выводит логи в следующем формате:
Временная метка Имя хоста, с которого было отправлено сообщение Название программы/службы, отправившей сообщение PID программы, отправившей сообщение Описание выполненного действия
Есть несколько примеров, когда логи представляют собой не текстовые, а двоичные файлы, и для их анализа необходимо использовать специальные команды:
/var/log/wtmp - Используйте who (или w):
/var/log/btmp - Используйте utmpdump или last -f:
/var/log/faillog - Использовать faillog
/var/log/lastlog - Использовать lastlog
Существуют также графические инструменты для чтения лог-файлов, например gnome-logs и KSystemLog.
grep "dhclient" /var/log/syslog
13 сентября 11:58:48 debian dhclient[448]: DHCPREQUEST с адреса 192.168.1.4 на enp0s3 на адрес 192.168.1.1, порт 67
Чтение журналов
less или more
zless или zmore - То же, что less и more, но используется для журналов, сжатых с помощью gzip (распространенная функция logrotate)
Как сообщения превращаются в логи
Приложения, службы и ядро записывают сообщения в специальные файлы (сокеты и буферы памяти), например /dev/log или /dev/kmsg.
rsyslogd получает информацию из сокетов или буферов памяти.
В зависимости от правил, указанных в /etc/rsyslog.conf и/или файлах в /etc/ryslog.d/, rsyslogd перемещает информацию в соответствующий файл журнала (обычно он находится в /var/log).
Сокет — это специальный файл, используемый для передачи информации между различными процессами. Чтобы вывести список всех сокетов в вашей системе, используйте команду systemctl list-sockets --all
Возможности, приоритеты и действия
rsyslog Файл конфигурации находится в /etc/rsylog.conf (в некоторых дистрибутивах файлы конфигурации также можно найти в /etc/rsyslog.d/).
Обычно он состоит из трех разделов: MODULES, GLOBAL DIRECTIVES и RULES.
MODULES включает в себя поддержку модулей для ведения журнала, отправки сообщений и приема журналов по протоколам UDP/TCP:
#### МОДУЛИ ####
#################
module(load="imuxsock") # обеспечивает поддержку локального системного логирования
module(load="imklog") # обеспечивает поддержку логирования в ядре
#module(load="immark") # обеспечивает возможность отправки сообщений --MARK--
# обеспечивает прием системных журналов по протоколу UDP
#module(load="imudp")
#input(type="imudp" port="514")
# обеспечивает прием системного журнала по протоколу TCP
#module(load="imtcp")
#input(type="imtcp" port="514")
GLOBAL DIRECTIVES Это позволяет нам настраивать различные параметры, такие как журналы и права доступа к каталогу журналов:
#### ГЛОБАЛЬНЫЕ ДИРЕКТИВЫ ####
###########################
#
# Используйте традиционный формат временных меток.
# Чтобы включить высокоточные временные метки, закомментируйте следующую строку.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
#
# Установите разрешения по умолчанию для всех файлов журнала.
#
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
#
# Где размещать файлы очереди и состояния
#
$WorkDirectory /var/spool/rsyslog
#
# Включить все конфигурационные файлы в /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf
RULES Здесь используются средства, приоритеты и действия. Настройки в этом разделе указывают демону логирования, как фильтровать сообщения в соответствии с определенными правилами и записывать их в журнал или отправлять туда, куда нужно. Чтобы разобраться в этих правилах, сначала нужно объяснить, что такое rsyslog средства и приоритеты. Каждому сообщению журнала присваивается средство и ключевое слово, связанные с внутренней подсистемой Linux, которая генерирует сообщение:
Число Ключевое слово Описание
0 - kern - Сообщения ядра Linux
1 - user - Сообщения на уровне пользователя
2 - mail - Почтовая система
3 - daemon - Системные демоны
Кроме того, каждому сообщению присваивается уровень приоритета:
Код Серьезность Ключевое слово Описание
0 Чрезвычайная ситуация - emerg, panic - Система непригодна для использования
Вот отрывок из rsyslog.conf нашей системы Debian GNU/Linux 10 (buster), в котором приведены некоторые примеры правил:
#### ПРАВИЛА ####
###############
# Сначала несколько стандартных файлов журналов. Журналы по объектам.
#
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
демон.* -/var/log/daemon.log
kern.* -/var/log/kern.log
lpr.* -/var/log/lpr.log
почта.* -/var/log/mail.log
пользователь.* -/var/log/user.log
#
# Ведение журнала для почтовой системы. Разделите его так, чтобы
# было легко писать скрипты для разбора этих файлов.
#
mail.info -/var/log/mail.info
mail.warn -/var/log/mail.warn
mail.err /var/log/mail.err
#
# Несколько "универсальных" файлов журнала.
#
*.=debug;\
auth, authpriv.none;\
новости.нет;mail.нет -/var/log/debug
*.=информация;*.= уведомление;*.=предупредить;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none -/var/log/messages
Формат правила следующий:
Селектор
auth,authpriv.* /var/log/auth.log
Независимо от приоритета (*), все сообщения из объектов auth или authpriv будут отправлены в /var/log/auth.log.
*.*;auth,authpriv.none -/var/log/syslog
Все сообщения — независимо от их приоритета (*) — со всех объектов (*) — за исключением сообщений с auth или authpriv (отсюда суффикс .none), — будут записываться в /var/log/syslog (знак минуса (-) перед путем предотвращает чрезмерную запись на диск). Обратите внимание на точку с запятой (;) для разделения селектора и запятую (,) для объединения двух объектов в одном правиле (auth,authpriv).
mail.err /var/log/mail.err
mail.err /var/log/mail.err
Сообщения из объекта mail с уровнем приоритета error или выше (critical, alert или emergency) будут отправлены в /var/log/mail.err.
*.=debug;\
auth,authpriv.none;\
news.none;mail.none -/var/log/debug
Сообщения со всех объектов с приоритетом debug и без других (=) будут записываться в /var/log/debug — за исключением сообщений, поступающих с объектов auth, authpriv, news и mail (обратите внимание на синтаксис: ;\).
Ручное внесение записей в системный журнал: logger
Команда logger пригодится при написании скриптов для командной оболочки или при тестировании.
logger добавляет любое полученное сообщение к /var/log/syslog (или к /var/log/messages при ведении журнала на удаленном центральном сервере журналов)
rsyslog в качестве Центрального сервера ведения журнала
Настройка сервера:
# убедимся, что rsyslog работает
systemctl status rsyslog
#Редактировать конфигурационный файл
vim /etc/rsyslog.d/remote.conf
#раскомментировать строки, которые загружают модуль и запускают TCP-сервер на порту 514
$ ModLoad imtcp.so # модуль загрузки
$InputTCPServerRun 514 # Запускает TCP-сервер на выбранном порту
systemctl restart rsyslog
netstat -nltp | grep 514
По умолчанию логи клиента записываются в файл /var/log/messages на сервере — вместе с логами самого сервера. Однако мы создадим шаблон и условие фильтрации, чтобы логи нашего клиента хранились в отдельных каталогах. Для этого мы добавим в /etc/rsyslog.conf (или /etc/rsyslog.d/remote.conf):
$template RemoteLogs,"/var/log/remotehosts/%HOSTNAME%/%$NOW%.%syslogseverity-text%.log"
if $FROMHOST-IP=='192.168.1.4' then ?RemoteLogs & остановить
Директива шаблона ($template)
Имя шаблона (RemoteLogs)
Текст шаблона ("/var/log/remotehosts/%HOSTNAME%/%$NOW%.%syslogseverity-text%.log")
Параметры (необязательно)
Наш шаблон называется RemoteLogs, и его текст состоит из пути в /var/log. Все логи нашего удаленного хоста будут сохраняться в каталоге remotehosts, где будет создан подкаталог с именем хоста компьютера (%HOSTNAME%). Каждое имя файла в этом каталоге будет состоять из даты (%$NOW%), уровня серьезности (он же приоритет) сообщения в текстовом формате (%syslogseverity-text%) и суффикса .log Слова, заключенные в процентах, являются свойствами и позволяют получить доступ к содержимому сообщения журнала (дате, приоритету и т. д.). syslog Сообщение имеет ряд четко определенных свойств, которые можно использовать в шаблонах. Доступ к этим свойствам и возможность их изменения обеспечиваются так называемым замещателем свойств, который записывается между знаками процента.
Оставшиеся две строки соответствуют условию фильтрации и связанному с ним действию:
Фильтр на основе выражений (if $FROMHOST-IP=='192.168.1.4')
Действие (then ?RemoteLogs, & stop)
Первая строка проверяет IP-адрес удаленного хоста, отправляющего журнал, и, если он совпадает с IP-адресом нашего клиента Debian, применяет шаблон RemoteLogs . Последняя строка (& stop) гарантирует, что сообщения не будут отправляться одновременно в /var/log/messages (а только в файлы в каталоге /var/log/remotehosts).
Первая строка проверяет IP-адрес удаленного хоста, отправляющего журнал, и, если он совпадает с IP-адресом нашего клиента Debian, применяет шаблон RemoteLogs . Последняя строка (& stop) гарантирует, что сообщения не будут отправляться одновременно в /var/log/messages (а только в файлы в каталоге /var/log/remotehosts).
Чтобы узнать больше о шаблонах, свойствах и правилах, обратитесь к странице руководства по rsyslog.conf.
После обновления конфигурации мы снова перезапустим rsyslog и убедимся, что в remotehosts еще нет каталога /var/log:
systemctl restart rsyslog
ls /var/log/
Сервер настроен. Далее мы настроим клиент.
Опять же, мы должны убедиться, что rsyslog установлен и работает:
В нашем Debian-клиенте нет файла remote.conf в /etc/rsyslog.d/, поэтому мы применим наши настройки в /etc/rsyslog.conf. В конце файла мы добавим следующую строку:
*.* @@suse-server:514
systemctl restart rsyslog
Теперь вернемся к нашему suse-server компьютеру и проверим наличие remotehosts в /var/log:
The Log Rotation Mechanism
Утилита, отвечающая за ротацию (или циклическое обновление) журналов, — это logrotate
В ее задачи входит перемещение файлов журналов под новым именем, их архивирование и/или сжатие, иногда отправка их по электронной почте системному администратору и, наконец, удаление устаревших файлов. Существуют различные правила именования перемещаемых файлов журналов (например, добавление к имени файла суффикса с указанием даты), но чаще всего используется суффикс с целым числом.
logrotate запускается как автоматизированный процесс или задание cron ежедневно с помощью скрипта /etc/cron.daily/logrotate и считывает файл конфигурации /etc/logrotate.conf. Этот файл содержит некоторые глобальные параметры и снабжен подробными комментариями, в которых для каждого параметра приводится краткое описание его назначения:
#sudo less /etc/logrotate.conf
# подробнее см. в "man logrotate"
# еженедельно поворачивать файлы журналов
weekly
# хранить архивы за 4 недели
rotate 4
# создавать новые (пустые) файлы журналов после поворота старых
create
# раскомментируйте эту строку, если хотите, чтобы файлы журналов сжимались
#compress
# пакеты сбрасывают информацию о ротации журналов в этот каталог
include /etc/logrotate.d
айлы конфигурации /etc/logrotate.d для конкретных пакетов также включены. Эти файлы содержат — по большей части — локальные определения и указывают файлы журналов для ротации (помните, что локальные определения имеют приоритет над глобальными, а более поздние определения имеют приоритет над более ранними). Ниже приведен фрагмент определения из /etc/logrotate.d/rsyslog:
/var/log/messages
{
rotate 4
еженедельно
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
invoke-rc.d rsyslog rotate > /dev/null
endscript
}
rotate 4 Сохраняйте журналы за 4 недели. weekly Еженедельно меняйте местами файлы журналов. missingok Если файл журнала отсутствует, не выводите сообщение об ошибке, просто переходите к следующему. notifempty Не поворачивайте журнал, если он пуст. compress Сжимайте файлы журналов с помощью gzip (по умолчанию). delaycompress Отложить сжатие предыдущего файла журнала до следующего цикла ротации (эффективно только в сочетании с параметром compress). Полезно, если программе нельзя запретить закрывать файл журнала и она может продолжать запись в предыдущий файл журнала в течение некоторого времени. sharedscripts Связано со скриптами prerotate и postrotate. Чтобы скрипт не выполнялся несколько раз, запускайте его только один раз, независимо от того, сколько файлов журналов соответствует заданному шаблону (например, /var/log/mail/*). Однако скрипты не будут запускаться, если ни один из журналов, соответствующих шаблону, не требует ротации. Кроме того, если скрипты завершатся с ошибкой, оставшиеся действия не будут выполнены ни для одного из журналов. postrotate Укажите начало скрипта postrotate. invoke-rc.d rsyslog rotate > /dev/null Используйте /bin/sh для запуска invoke-rc.d rsyslog rotate > /dev/null после ротации журналов. endscript Укажите конец скрипта postrotate.
Полный список директив и пояснений приведен на странице руководства по logrotate.conf
Кольцевой буфер ядра
Поскольку ядро генерирует несколько сообщений до того, как rsyslogd становится доступным после загрузки, необходим механизм регистрации этих сообщений. Именно здесь в игру вступает кольцевой буфер ядра. Это структура данных фиксированного размера, поэтому по мере поступления новых сообщений самые старые будут исчезать.
Systemd
Среди его преимуществ можно выделить следующие: Простота настройки: юнит-файлы в отличие от скриптов SysV Init. Универсальное управление: помимо демонов и процессов, он также управляет устройствами, сокетами и точками подключения. Обратная совместимость с SysV Init и Upstart. Параллельная загрузка при запуске: службы загружаются параллельно, в отличие от Sysv Init, где они загружаются последовательно. В нем есть служба ведения журнала journal, которая обладает следующими преимуществами: Все логи хранятся в одном месте. Не требуется ротация логов. Логи можно отключить, загрузить в оперативную память или сделать постоянными.
systemd действует на юниты
Юнит — это любой ресурс, которым systemd можно управлять (например, сеть, Bluetooth и т.д.).
Юнит в свою очередь управляются файлами юнитов. Это обычные текстовые файлы, которые хранятся в /lib/systemd/system и включают параметры конфигурации — в виде разделов и директив — для конкретного ресурса, которым нужно управлять
Существует несколько типов юнитов: service, mount, automount, swap timer, device socket path, timer snapshotslice, scope target,,,,,,,,,,,,,,,,,,,,,,,,,,, и ,,. Таким образом, каждое имя модульного файла следует шаблону
Target — это особый тип юнита, напоминающий классические уровни выполнения SysV Init. Это связано с тем, что целевой юнит объединяет различные ресурсы для представления определенного состояния системы (например, graphical.target похож на runlevel 5 и т. д.).
Чтобы проверить текущий целевой юнит в вашей системе, используйте команду systemctl get-default:
systemctl get-default
graphical.target
Системный журнал: systemd-journald
systemd-journald Это системная служба, которая отвечает за получение логов из различных источников: сообщений ядра, простых и структурированных системных сообщений, стандартного вывода и стандартных ошибок служб, а также записей аудита из подсистемы аудита ядра (подробнее см. на странице руководства по systemd-journald). Ее задача — создание и ведение структурированного и индексированного журнала.
Файл конфигурации находится по адресу /etc/systemd/journald.conf и, как и в случае с любой другой службой, вы можете использовать команду systemctl для запуска, перезапуска, остановки службы или просто для проверки ее состояния
systemctl status systemd-journald
Также возможны файлы конфигурации типа journal.conf.d/*.conf, которые могут включать в себя конфигурации для конкретных пакетов
Журнал представляет собой не обычный текстовый файл, а двоичный. Поэтому для чтения его содержимого нельзя использовать инструменты для разбора текста, такие как less или more; вместо них используется команда journalctl
Запрос содержимого журнала
journalctl Это утилита, которую вы используете для запроса systemd journal. Для ее запуска нужно либо быть пользователем root, либо использовать sudo для вызова. Если запустить ее без параметров, она выведет весь журнал в хронологическом порядке (сначала самые старые записи)
#Сообщения в журнале будут публиковаться в обратном порядке:
journalctl -r
#выведет на экран самые последние сообщения из журнала
#будет продолжать выводить новые записи по мере их добавления в журнал — примерно так же, как tail -f:
journalctl -f
#Вывод последних 5 строк
journalctl -n 5
#Эквивалентно использованию команды dmesg:
sudo journalctl -k
Фильтрация данных журнала
Журнал позволяет фильтровать данные по различным критериям:
#Перечислить все загрузки
journalctl --list-boots
#все сообщения, полученные при текущей загрузке
sudo journalctl -b
#вывести сообщения, полученные при предыдущей загрузке
journalctl -b -1
#фильтровать сообщения по степени важности/приоритетности
journalctl -b -0 -p err
#печать только тех сообщений, которые были зарегистрированы в течение определенного периода времени
journalctl --since "19:00:00" --until "19:01:00"
#чтобы просмотреть сообщения, отправленные две минуты назад
journalctl --since "2 minutes ago"
#все сообщения, отправленные с полуночи до 21:00 сегодняшнего дня
journalctl --since "today" --until "21:00:00"
#Чтобы просмотреть сообщения журнала, связанные с определенным исполняемым файлом
journalctl /usr/sbin/sshd
#отображаются сообщения об указанном устройстве:
journalctl -u ssh.service
Чтобы узнать больше о различных синтаксисах указания времени, обратитесь к странице руководства systemd.time
Чтобы вывести список всех загруженных и активных модулей, используйте systemctl list-units;
чтобы просмотреть все установленные файлы модулей, используйте systemctl list-unit-files
Журнал также можно отфильтровать по определенным полям с помощью любого из следующих синтаксисов:
Журнал также можно отфильтровать по определенным полям с помощью любого из следующих синтаксисов:
=
_=_
__=
#Одно из восьми возможных значений приоритета syslog
journalctl PRIORITY=3
#того же результата можно было бы добиться с помощью команды
journalctl -p err
#просмотреть все сообщения пользовательского уровня:
journalctl SYSLOG_FACILITY=1
#просмотреть все сообщения, созданные с помощью systemd
journalctl _PID=1
#выделить сообщения, относящиеся к конкретной загрузке
sudo journalctl _BOOT_ID=83df3e8653474ea5aed19b41cdb45b78
#Показывать сообщения, полученные от определенного транспорта
journalctl _TRANSPORT=journal
_TRANSPORT
Показывать сообщения, полученные от определенного транспорта. Возможные значения: audit (подсистема аудита ядра), driver (генерируется внутренне), syslog (сокет системного журнала), journal (собственный протокол журнала), stdout (стандартный вывод служб или стандартная ошибка), kernel (кольцевой буфер ядра — то же, что dmesg, journalctl -k или journalctl --dmesg):
Объединение полей
Поля не являются взаимоисключающими, поэтому в одном запросе можно использовать несколько полей.
#будут показаны только те сообщения, которые соответствуют значениям обоих полей одновременно.
journalctl PRIORITY=4 SYSLOG_FACILITY=0
#Если только вы не используете разделитель + для объединения двух выражений по принципу логического ИЛИ:
journalctl PRIORITY=3 + SYSLOG_FACILITY=0
#Или указать два значения для одного и того же поля, и будут показаны все записи, соответствующие любому из них:
journalctl PRIORITY=1 PRIORITY=3
Поля журнала относятся к одной из следующих категорий: «Поля пользовательского журнала», «Доверенные поля журнала», «Поля журнала ядра», «Поля от имени другой программы» и «Адресные поля». Более подробную информацию по этой теме, включая полный список полей, можно найти на странице man для systemd.journal-fields(7).
Записи в системном журнале, сделанные вручную
Подобно тому, как команда logger используется для отправки сообщений из командной строки в системный журнал, команда systemd-cat выполняет аналогичную, но более универсальную функцию в отношении системного журнала. Она позволяет отправлять в журнал стандартный ввод (stdin), вывод (stdout) и сообщения об ошибках (stderr).
systemd-cat
Эта строка записывается в журнал.
^C
#вывод команды, передаваемой по конвейеру, также будет отправлен в журнал
echo "И эта строка тоже." | systemd-cat
#Если за командой следует другая команда, ее вывод также будет отправлен в журнал вместе с stderr (при наличии):
systemd-cat echo "И эта строка тоже."
#можно указать уровень приоритета с помощью опции -p:
systemd-cat -p emerg echo "Это не настоящая чрезвычайная ситуация."
#Чтобы увидеть последние четыре строки в журнале:
journalctl -n 4
Постоянное Хранилище журналов
Ведение журнала можно полностью отключить
Хранить журнал в памяти, что делает его энергозависимыми, будет удаляться при каждой перезагрузке системы. В этом случае будет создан и использован каталог /run/log/journal .
Можно сделать журнал постоянным, чтобы он записывал логи на диск. В этом случае сообщения журнала будут сохраняться в каталоге /var/log/journal .
По умолчанию используется следующее поведение: если /var/log/journal/ не существует, логи будут сохраняться в каталоге /run/log/journal/ в энергозависимой памяти и, следовательно, будут потеряны при перезагрузке. Имя каталога — /etc/machine-id — представляет собой шестнадцатеричную 32-символьную строку в нижнем регистре с символом новой строки в конце:
/run/log/journal/8821e1fdf176445697223244d1dfbd73/
Если /var/log/journal/ существует, логи будут сохраняться там постоянно. Если этот каталог будет удален, systemd-journald не создаст его заново, а будет записывать данные в /run/log/journal . Как только мы снова создадим /var/log/journal/ и перезапустим демон, постоянное ведение журнала возобновится.
Помимо того, о чем мы только что упомянули, способ хранения журналов в демоне journal можно изменить после установки, внеся изменения в его конфигурационный файл: /etc/systemd/journald.conf. Ключевой параметр — Storage= — может принимать следующие значения:
Storage=volatile Данные журнала будут храниться исключительно в памяти — в папке /run/log/journal/. Если папки нет, она будет создана. Storage=persistent По умолчанию данные журнала будут храниться на диске — в папке /var/log/journal/ — с резервным копированием в память (/run/log/journal/) на ранних этапах загрузки и в случае, если диск недоступен для записи. При необходимости будут созданы обе директории. Storage=auto auto Аналогично persistent, но при необходимости каталог /var/log/journal не создается. Это значение по умолчанию. Storage=none Все данные журнала будут удалены. Однако возможна переадресация на другие устройства, такие как консоль, буфер журнала ядра или сокет системного журнала.
#Проверить состояние журнала
systemctl status systemd-journald
Удаление старых данных журнала: размер журнала
systemd По умолчанию размер логов не превышает 10 % от размера файловой системы, в которой они хранятся. Например, на файловой системе объемом 1 ГБ они займут не более 100 МБ. По достижении этого предела старые логи начнут удаляться, чтобы их объем не превышал указанное значение.
Ограничением размера хранимых файлов журнала можно управлять, изменив ряд параметров конфигурации в /etc/systemd/journald.conf
SystemMaxUse=, RuntimeMaxUse=
определяют объем дискового пространства, которое может занимать журнал. По умолчанию он составляет 10 % от размера файловой системы, но его можно изменить (например, SystemMaxUse=500M), но не более чем на 4 ГиБ.
SystemKeepFree=, RuntimeKeepFree=
Они определяют объем дискового пространства, которое должно быть свободно для других пользователей. По умолчанию он составляет 15 % от размера файловой системы, но его можно изменить (например, SystemKeepFree=500M), но не более чем на 4 ГБ.
*MaxUse и *KeepFree, то systemd-journald удовлетворяет обоим условиям, используя меньшее из двух значений. Кроме того, следует помнить, что удаляются только архивированные (а не активные) файлы журнала.
SystemMaxFileSize=, RuntimeMaxFileSize=
Они определяют максимальный размер, до которого могут увеличиваться отдельные файлы журналов. По умолчанию он составляет 1/8 от *MaxUse. Уменьшение размера происходит синхронно. Значения можно указывать в байтах или с помощью K, M, G, T, P, E для килобайтов, мебибайтов, гибибайтов, тебибайтов, пебибайтов и экбибайтов соответственно.
SystemMaxFiles=, RuntimeMaxFiles= Они устанавливают максимальное количество отдельных и архивных файлов журнала для хранения (активные файлы журнала не учитываются). По умолчанию установлено значение 100.
Помимо удаления и ротации сообщений журнала в зависимости от их размера, systemd-journald также позволяет использовать критерии, основанные на времени, с помощью следующих двух параметров: MaxRetentionSec= и MaxFileSec=. Дополнительную информацию об этих и других параметрах можно найти на странице руководства по journald.conf .
Всякий раз, когда вы изменяете поведение systemd-journald по умолчанию, раскомментируя и редактируя параметры в /etc/systemd/journald.conf, необходимо перезапустить демон, чтобы изменения вступили в силу.
#узнать, сколько места на диске в данный момент занимают файлы журналов (как архивированные, так и активные)
journalctl --disk-usage
Vacuuming the Journal
--vacuum-time=
Эта опция, основанная на времени, удаляет все сообщения в файлах журнала, отметка времени которых старше указанного периода. Значения должны быть записаны с использованием любого из следующих суффиксов: s, m, h, days (или d), months, weeks (или w) и years (или y).
#удалить все сообщения в архивных файлах журнала старше 1 месяца
journalctl --vacuum-time=1months
#чтобы ограничить количество архивных файлов журнала до 10
journalctl --vacuum-files=10
Чтобы проверить внутреннюю целостность файла журнала, используйте journalctl с параметром --verify . По мере выполнения проверки вы будете видеть индикатор выполнения и возможные проблемы.
Извлечение данных журнала из системы восстановления
Как системный администратор, вы можете столкнуться с ситуацией, когда вам понадобится получить доступ к файлам журналов на жестком диске неисправного компьютера с помощью аварийной системы (загрузочного компакт-диска или USB-накопителя с дистрибутивом Linux).
journalctl ищет файлы журнала в /var/log/journal/
# -D , --directory=
Таким образом, необходимо подключить rootfs (/dev/sda1) неисправной системы к файловой системе системы восстановления и приступить к чтению файлов журнала следующим образом:
journalctl -D /media/carol/faulty.system/var/log/journal/
Другие варианты, которые могут быть полезны в этой ситуации: -m, --merge Он объединяет записи из всех доступных журналов в разделе /var/log/journal, включая удаленные. --file Он покажет записи в определенном файле, например: journalctl --file /var/log/journal/64319965bda04dfa81d3bc4e7919814a/user-1000.journal. --root В качестве аргумента передается путь к каталогу, то есть к корневому каталогу. journalctl будет искать там файлы журнала (например, journalctl --root /faulty.system/). Дополнительную информацию см. на странице journalctl man.
Пересылка данных журнала в традиционный syslog демон
Пересылка сообщений в файл сокета /run/systemd/journal/syslog для чтения syslogd . Эта функция доступна при наличии опции ForwardToSyslog=yes .
Наличие демона syslog, который ведет себя как journalctl, то есть считывает сообщения журнала непосредственно из файлов журнала. В данном случае используется параметр Storage; его значение должно отличаться от none.
Аналогичным образом вы можете перенаправлять сообщения журнала в другие места с помощью следующих параметров: ForwardToKMsg (буфер журнала ядра — kmsg), ForwardToConsole (системная консоль) или ForwardToWall (всем пользователям, вошедшим в систему, через wall). Для получения дополнительной информации обратитесь к справочной странице journald.conf.
Какие параметры нужно изменить в /etc/systemd/journald.conf так, чтобы сообщения пересылались в /dev/tty5? Какие значения должны быть у этих параметров?
ForwardToConsole=yes
TTYPath=/dev/tty5
Краткие сведения
Преимущества использования systemd в качестве системного и сервисного менеджера. Основы systemd юнитов и целей. Откуда systemd-journald получает данные для логирования. Параметры, которые можно передать systemctl для управления systemd-journald: start, status, restart и stop.
systemctl Управляйте системой systemd и диспетчером сервисов. journalctl Запросите systemd журнал.
#Печать записей ядра
journalctl -k или journalctl --dmesg
#Вывести сообщения о второй загрузке, начиная с начала журнала
journalctl -b 2
#Вывести сообщения о второй загрузке, начиная с конца журнала
journalctl -b -2 -r или journalctl -r -b -2
#Распечатайте последние сообщения в журнале и следите за появлением новых
journalctl -f
#С этого момента печатайте только новые сообщения и постоянно обновляйте вывод
journalctl --since "now" -f
#Вывести сообщения о предыдущей загрузке с приоритетом warning в обратном порядке
journalctl -b -1 -p warning -r
#Проверьте, сколько места на диске занимают файлы журналов:
journalctl --disk-usage
#Уменьшите объем памяти, выделенный для архивных файлов журнала, до 200 МБ:
journalctl --vacuum-size=200M
#только сообщения с приоритетами warning, error и critical
journalctl -p warning..crit
#or
journalctl -p 4..2
Печать сообщений, принадлежащих конкретному пользователю
_ID=
Распечатайте сообщения с хоста с именем debian
_HOSTNAME=debian
Печать сообщений, относящихся к определенной группе
_GID=
Печатать сообщения, принадлежащие root
_UID=0
В зависимости от пути к исполняемому файлу выведите sudo сообщений
_EXE=/usr/bin/sudo
В зависимости от названия команды выведите sudo сообщений
_COMM=sudo