Системный журнал linux centos

Содержание

ИТ База знаний
Полезно
Навигация
Серверные решения
Телефония
Корпоративные сети
Как найти и читать логи в Linux
Как просматривать логи Linux
Важные системные логи Linux
Системные логи
Демон системных логов
Логи приложений
Логи не в удобочитаемом формате
Графические интерфейсы для просмотра файлов логов Linux
Как настроить файлы логов в Ubuntu и CentOS
Выполнить ротацию лога
Итоги
Логи в Linux часть 1. rsyslog, journald и logrotate
Понимание логирования
Понимание ролей rsyslogd и journald
Чтение лог-файлов
Понимание содержимого лог-файла
Команда logger
Настройка rsyslogd
Секции rsyslog.conf
Объекты, приоритеты, и места назначения
Ротация лог-файлов
Работаем с journald
Использование journalctl для поиска событий
Сохранение журнала systemd

ИТ База знаний

Курс по Asterisk

Полезно

— Узнать IP — адрес компьютера в интернете

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

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Как найти и читать логи в Linux

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

Большинство файлов логов Linux хранятся в простом текстовом файле ASCII и находятся в каталоге и подкаталоге /var/log . Логи создаются системным демоном логов Linux, syslogd или rsyslogd .

Онлайн курс по Linux

Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps

В этом руководстве вы узнаете, как находить и читать файлы логов Linux, а также настраивать демон ведения системных логов.

Как просматривать логи Linux

1. Сначала откройте терминал Linux как пользователь root. Это позволит получить root-права.

2. Используйте следующую команду для просмотра папки где находятся файлов логов:

3. Чтобы просмотреть логи, введите следующую команду:

Команда отображает все файлы логов Linux, такие как kern.log и boot.log . Эти файлы содержат необходимую информацию для правильного функционирования операционной системы.

Доступ к файлам логов осуществляется с использованием привилегий root. По определению, root — это учетная запись по умолчанию, которая имеет доступ ко всем файлам Linux.

Используйте следующий пример строковой команды для доступа к соответствующему файлу:

Эта команда отображает временную шкалу всей информации, относящейся к этой операции.

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

zcat — Отображает все содержимое logfile.gz
zmore — Просмотр файла по страницам, не распаковывая файлы
zgrep — Поиск внутри сжатого файла
grep — Найти все вхождения поискового запроса в файле или отфильтровать файл логов
tail — Выводит последние несколько строк файлов
head — Просмотр самого начала текстовых файлов
vim — Просмотр при помощи текстового редактора vim
nano — Просмотр при помощи текстового редактора nano

Важные системные логи Linux

Логи могут многое рассказать о работе системы. Хорошее понимание каждого типа файла поможет различать соответствующие логи.

Большинство каталогов можно сгруппировать в одну из четырех категорий:

Системные логи (System Logs)
Логи событий (Event Logs)
Логи приложений (Application Logs)
Логи обслуживания (Service Logs)

Многие из этих логов могут быть расположены в подкаталоге var/log .

Системные логи

Файлы логов необходимы для работы Linux. Они содержат значительный объем информации о функциональности системы. Наиболее распространенные файлы логов:

/var/log/syslog : глобальный системный журнал (может быть в /var/log/messages )
/var/log/boot.log : лог загрузки системы, где хранится вся информация, относящаяся к операциям загрузки
/var/log/auth.log : логи аутентификации, который хранит все логи аутентификации, включая успешные и неудачные попытки (может быть в /var/log/secure )
/var/log/httpd/ : логи доступа и ошибок Apache
/var/log/mysqld.log : файл логов сервера базы данных MySQL
/var/log/debug : логи отладки, который хранит подробные сообщения, связанные с отладкой, и полезен для устранения неполадок определенных системных операций
/var/log/daemon.log : логи демона, который содержит информацию о событиях, связанных с запуском операции Linux
/var/log/maillog : логи почтового сервера, где хранится информация, относящаяся к почтовым серверам и архивированию писем
/var/log/kern.log : логи ядра, где хранится информация из ядра Linux
/var/log/yum.log : логи команд Yum
/var/log/dmesg : логи драйверов
/var/log/boot.log : логи загрузки
/var/log/cron : логи службы crond

Демон системных логов

Логирование осуществляется при помощи демона syslogd

Программы отправляют свои записи журнала в syslogd, который обращается к конфигурационному файлу /etc/syslogd.conf или /etc/syslog и при обнаружении совпадения записывает сообщение журнала в нужный файл журнала. Каждый файл состоит из селектора и поля ввода действия. Демон syslogd также может пересылать сообщения журнала. Это может быть полезно для отладки. Этот файл выглядит приерно так:

Логи приложений

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

Файлы логов, которые попадают в эту категорию, включают логи системы печати CUPS, лог Rootkit Hunter, логи HTTP-сервера Apache, логи SMB-сервера Samba и лог сервера X11.

Логи не в удобочитаемом формате

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

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

Графические интерфейсы для просмотра файлов логов Linux

System Log Viewer — это графический интерфейс, который можно использовать для отслеживания системных логов.

Интерфейс предоставляет несколько функций для управления логами, включая отображение статистики лога. Это удобный графический интерфейс для мониторинга логов.

В качестве альтернативы можно использовать Xlogmaster, который может отслеживать значительное количество файлов логов.

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

Как настроить файлы логов в Ubuntu и CentOS

Начнем с примера CentOS. Чтобы просмотреть пользователей, которые в настоящее время вошли на сервер Linux, введите команду who от имени пользователя root:

Читайте также: Canary mail mac os

Здесь также отображается история входа в систему пользователей. Для просмотра истории входа системного администратора введите следующую команду:

Чтобы просмотреть информацию о последнем входе в систему, введите:

Выполнить ротацию лога

Файлы логов, в конце которых добавлены нули, являются повернутыми файлами. Это означает, что имена файлов логов были автоматически изменены в системе.

Целью ротации логов является сжатие устаревших логов, занимающих место. Ротацию лога можно выполнить с помощью команды logrotate . Эта команда вращает, сжимает и отправляет системные логи по почте.

logrotate обрабатывает системы, которые создают значительные объемы файлов логов. Эта команда используется планировщиком cron и считывает файл конфигурации logrotate /etc/logrotate.conf . Он также используется для чтения файлов в каталоге конфигурации logrotate.

Чтобы включить дополнительные функции для logrotate, начните с ввода следующей команды:

Он сжимает и изменяет размер желаемого файла логов.

Команды выполняют следующие действия:

missingok — сообщает logrotate не выводить ошибку, если файл логов отсутствует.
notifempty — не выполняет ротацию файла логов, если он пуст. Уменьшает размер файла лога с помощью gzip
size — гарантирует, что файл логов не превышает указанный размер, и поворачивает его в противном случае
daily — меняет файлы журналов по ежедневному расписанию. Это также можно делать по недельному или ежемесячному расписанию.
create — создает файл логов, в котором владелец и группа являются пользователем root

Итоги

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

Онлайн курс по Linux

Источник

Логи в Linux часть 1. rsyslog, journald и logrotate

Понимание логирования

Понимание ролей rsyslogd и journald

journald (который реализуется демоном systemd-journald) предоставляет усовершенствованную систему управления логами. journald собирает сообщения из ядра, всей процедуры загрузки и сервисов и записывает эти сообщения в журнал событий. Этот журнал событий хранится в двоичном формате, и его можно запросить с помощью команды journalctl.

Поскольку журнал, который пишет journald, не является постоянным между перезагрузками, сообщения также перенаправляются в службу rsyslogd. rsyslogd записывает сообщения в разные файлы в каталоге /var/log.

rsyslogd предлагает функции, которых нет в journald, такие как централизованное ведение журнала и фильтрация сообщений с использованием модулей. В текущем состоянии journald не является заменой rsyslogd; это просто еще один способ регистрации информации. journald тесно интегрирован с systemd и поэтому регистрирует всё, что делает ваш сервер. rsyslogd добавляет к нему некоторые сервисы. В частности, он заботится о записи данных журнала в определенные файлы (которые будут постоянными между перезагрузками) и позволяет настраивать удаленные журналы и серверы журналов.

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

Файлы в /var/log, которые пишутся rsyslogd, должны контролироваться.
Команда journalctl может использоваться для получения более подробной информации из журнала.
Для краткого обзора последних значимых событий, которые были зарегистрированы модулями systemd через journald, администраторы могут использовать команду systemctl status . Эта команда показывает состояние сервисов, а также последние пару строк, которые были логированы. В листинге 1 показан пример, в котором эта команда четко указывает, что пошло не так при запуске сервиса.

Листинг 1

Чтение лог-файлов

Помимо сообщений, которые записываются journald и которые можно прочитать с помощью команды journalctl, в системе Linux вы также найдете различные лог-файлы в каталоге /var/log. Эти файлы могут быть прочитаны, например, с помощью less.

Точное количество файлов в каталоге /var/log будет меняться в зависимости от конфигурации сервера и сервисов, работающих на этом сервере. Однако некоторые файлы существуют в большинстве случаев, и, как администратор, вы должны знать, какие это файлы и какое содержимое можно ожидать в этих файлах.

В таблице 1 представлен обзор некоторых стандартных файлов, созданных в этом каталоге.

Таблица 1

log-файл

/var/log/messages

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

/var/log/dmesg

/var/log/secure

Содержит сообщения, связанные с аутентификацией.

/var/log/boot.log

Сообщения, связанные с запуском системы.

/var/log/audit/audit.log

Содержит сообщения аудита. SELinux пишет в этот файл.

/var/log/maillog

/var/log/samba

Предоставляет файлы журналов для сервиса Samba. Обратите внимание, что по умолчанию Samba не управляется через rsyslog, а записывается непосредственно в каталог /var/log.

/var/log/sssd

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

/var/log/cups

Содержит сообщения, сгенерированные службой печати CUPS.

/var/log/httpd/

Каталог, содержащий лог-файлы, которые записываются веб-сервером Apache. Обратите внимание, что Apache пишет сообщения в эти файлы напрямую, а не через rsyslog.

Понимание содержимого лог-файла

Как администратор, вы должны уметь интерпретировать содержимое лог-файлов. Например, в листинге 2 показан частичный контент из файла /var/log/messages.

Листинг 2
Как видно из листинга 2, каждая записываемая строка имеет определенные элементы:

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

Чтобы прочитать содержимое лог-файла, вы можете использовать, например less, или вы можете в реальном времени наблюдать за тем, что там происходит с помощью команды tail -f. Например: tail -f /var/log/messages.

Команда logger

Большинство сервисов самостоятельно записывают информацию в лог-файлы. Команда logger позволяет пользователям записывать сообщения в rsyslog из командной строки. Использовать эту команду просто. Просто введите logger, и затем сообщение, которое вы хотите записать в логи. Таким образом, утилита logger предлагает удобное решение для написания сообщений из скриптов. Это позволит вам записывать скрипт в syslog, если что-то пойдёт не так.

При использовании logger вы также можете указать приоритет и что вы хотите логировать. Команда logger -p kern.err my_message записывает my_message в объект kern, например, используя приоритет error. Эта опция позволит проверить работу конкретных rsyslog объектов.

Настройка rsyslogd

Чтобы убедиться, что информация, которая должна быть залогирована, записана в то место, где вы хотите ее найти, вы можете настроить сервис rsyslogd в файле /etc/rsyslog.conf. В этом файле вы найдете различные разделы, которые позволяют указать, где и как должна быть записана информация.

Секции rsyslog.conf

Файл rsyslog.conf используется для указания того, что должно быть зарегистрировано и где это должно быть зарегистрировано. Для этого вы найдете различные разделы в файле конфигурации:

■ #### MODULES ####: rsyslogd является модульным. Модули включены для улучшения поддерживаемых функций в rsyslogd.

■ #### GLOBAL DIRECTIVES ####: Этот раздел используется для указания глобальных параметров, таких как место, где записываются вспомогательные файлы, или формат метки времени по умолчанию.

■ #### RULES ####: Это самая важная часть файла rsyslog.conf. Он содержит правила, которые определяют, какая информация должна быть залогирована и в каком месте.

Объекты, приоритеты, и места назначения

Чтобы указать, какая информация должна логироваться и в каком месте назначения, rsyslogd использует объект (Facility), приоритет (Priority) и место назначения (Destination):

■ Объект определяет категорию информации, которая логируется. Rsyslogd использует фиксированный список объектов, который не может быть расширен. Это связано с обратной совместимостью с устаревшей службой syslog.

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

■ Назначение определяет, куда должно быть записано сообщение. Типичными адресатами являются файлы, но модули rsyslog также могут использоваться в качестве места назначения для дальнейшей обработки через модуль rsyslogd.

В листинге 3 приведен пример раздела RULES в rsyslog.

Листинг 3
В листинге 3 вы можете увидеть, как различные объекты и приоритеты используются для определения местоположений, в которые можно логировать информацию. Доступные объекты и приоритеты являются фиксированными и не могут быть добавлены. Таблица 2 показывает, какие объекты доступны, а таблица 3 показывает список всех приоритетов.

При указании назначения часто используется файл. Если имя файла начинается с дефиса (как -/var/log/maillog), сообщения не будут немедленно переданы в файл, а будут буферизированы для повышения эффективности записи. Файлы устройств также могут быть использованы, как /dev/console. Если используется устройство, сообщения записываются в режиме реального времени на консоль. На современных серверах это не имеет смысла, поскольку администраторы часто входят в систему удаленно и не видят, что происходит на консоли сервера.

Для расширения функциональности rsyslogd могут использоваться модули для дальнейшей обработки сообщений. Если это требуется, имя модуля может быть указано как :имя_модуля:.

Таблица 2

Объект
auth / authpriv	Сообщения, связанные с аутентификацией.
cron	Сообщения, сгенерированные сервисом crond.
daemon	Универсальный объект, который можно использовать для неопределенных демонов.
kern	Сообщения ядра.
lpr	Сообщения, сгенерированные через систему печати.
mail	Сообщения, связанные с электронной почтой.
mark	Специальный объект, который можно использовать для периодической записи маркера.
news	Сообщения, генерируемые системой новостей NNTP.
security	То же, что и auth / authpriv. Не должен больше использоваться.
syslog	Сообщения, генерируемые системой syslog.
user	Сообщения генерируемые в пространстве пользователя.
uucp	Сообщения, сгенерированные устаревшей системой UUCP.
local0-7	Резервные объекты, которые необходимы для использования тех объектов, которые отсутствуют в этой таблице.

Объекты syslog были определены в 1980-х годах, и для обеспечения обратной совместимости никакие новые объекты не могут быть добавлены. В результате все еще существуют некоторые объекты, которые в основном больше не используются, а некоторые сервисы, которые стали актуальными на более позднем этапе, не имеют своего собственного объекта. Как решение, два конкретных типа объекта могут быть использованы. Объект daemon — это общий объект, который может использоваться любым демоном. И могут быть использованы объекты local0 — local7.

Если есть сервисы, которые не имеют своих собственных объектов rsyslogd, которым необходимо в любом случае записывать сообщения в определенный лог-файл, эти сервисы можно настроить для использования любого из объектов от local0 до local7. Затем вы должны настроить сервисы для использования этих объектов. Процедура, которой вы пользуетесь, зависит от используемого вами сервиса. Затем вам нужно добавить правило в файл rsyslog.conf, чтобы отправлять сообщения, поступающие через этот объект, в определенный флог-файл. Упражнение 2 показывает, как вы можете это сделать.

Чтобы определить, какие типы сообщений должны логироваться, в строках rsyslog.conf могут использоваться разные уровни серьезности. Эти серьезности являются syslog-приоритетами. В таблице 3 представлен обзор доступных приоритетов в порядке возрастания.

Таблица 3

Приоритет	Используется для
debug	Отладочные сообщения, которые дадут как можно больше информации о работе сервиса.
info	Информационные сообщения о нормальной работе сервиса.
notice	Используется для информационных сообщений об элементах, которые позже могут стать проблемой.
warning / warn	Что-то не оптимальное, но ошибки пока нет.
err /error	Произошла некритическая ошибка.
crit	Произошла критическая ошибка.
alert	Используется, когда сервис перестал быть доступен.
emerg / panic	Сообщение генерируется, когда доступность сервиса прекращается.

Когда используется определенный приоритет, все сообщения с этим приоритетом и выше логируются в соответствии со спецификациями, используемыми в этом конкретном правиле. Если вам необходимо детально настроить логирование, когда сообщения с разными приоритетами отправляются в разные файлы, вы можете указать приоритет со знаком равенства (=) перед ним, как в следующем файле конфигурации, который будет отправлять все отладочные сообщения cron в файл с именем /var/log/cron.debug. Обратите внимание на использование дефиса (-) перед именем файла, который гарантирует, что сообщения буферизуются и не записываются немедленно на диск (что хорошо для производительности диска).

Рассмотрим следующую строку, где все сообщения cron только с приоритетом отладки записываются в определенный файл. Обратите внимание на — перед строкой, который буферизует записи, чтобы информация логировалась более эффективным способом:

Упражнение 2. Изменение правил в rsyslog.conf
В этом упражнении вы узнаете, как изменить rsyslog.conf. Вы настроите сервис Apache для логирования сообщений через syslog и создадите правило, которое записывает сообщения отладки в определенный файл.

1. По умолчанию сервис Apache не логируется через rsyslog, но ведет собственное логирование. Вы измените это. Для начала установите Apache командой yum install -y httpd.

2. После установки Apache откройте его файл конфигурации /etc/http/conf/httpd.conf и добавьте в него следующую строку:
3. Введите systemctl restart httpd.

4. Теперь создайте строку в файле rsyslog.conf, которая будет отправлять все сообщения, которые он получает для объекта local1 (который теперь используется сервисом httpd), в файл /var/log/httpd-error.log. Для этого включите следующую строку:
5. Скажите rsyslogd перезагрузить его конфигурацию, выполнив команду systemctl restart httpd.

6. Все сообщения об ошибках Apache теперь будут записываться в файл httpd-error.log.

7. В браузере Firefox перейдите по адресу http://localhost/nowhere. Так как страницы, к которой вы пытаетесь получить доступ, не существует, она будет записана в журнал ошибок Apache.

8. Теперь давайте создадим snap-in файл, который также записывает сообщения отладки в определенный файл. Для этого введите echo «*.debug /var/log/messages/messages-debug» > /etc/rsyslogd/debug.conf.

9. Снова перезапустите rsyslogd с помощью systemctl restart rsyslogd.

10. Выполните tail -f /var/log/messages-debug, чтобы открыть трассировку для вновь созданного файла.

11. Введите logger -p daemon.debug «Daemon Debug Message». Вы увидите сообщение отладки.

Ротация лог-файлов

Чтобы syslog сообщения не заполняли вашу систему, сообщения можно ротировать. Это означает, что когда будет достигнут определенный порог,
старый лог-файл закроется и откроется новый. Утилита logrotate периодически запускается через сервис crond, чтобы позаботиться о ротации лог-файлов.

Когда лог-файл ротируется, старый файл копируется в файл с датой ротации. Таким образом, если /var/log/messages ротируется 3 ноября 2019 года, то ротируемое имя файла будет /var/log/messages-20191103. По умолчанию в системе хранятся четыре старых лог-файлов. Файлы старше этого периода удаляются из системы автоматически.

Настройки по умолчанию для ротации логов хранятся в файле /etc/logrotate.conf

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

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

Работаем с journald

Сервис systemd-journald хранит лог-сообщения в журнале в двоичном виде, который хранится в файле /run/log/journal. Этот файл можно просмотреть с помощью команды journalctl.

Использование journalctl для поиска событий

Самый простой способ использовать journalctl — просто набрать команду. Он показывает последние события, которые были записаны в журнал с момента последнего запуска вашего сервера. Обратите внимание, что результат этой команды отображается в меньшем количестве страниц, и по умолчанию вы увидите начало журнала.

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

Вы также можете ввести journalctl и нажать кнопку G (заглавная буква) , чтобы перейти к концу журнала. Также обратите внимание, что в выводе journalctl работают параметры поиска / и ?. В листинге 4 показан частичный вывод journalctl.

Листинг 4
Что делает journalctl гибкой командой, так это то, что ее многочисленные опции фильтрации позволяют вам показать именно то, что вам нужно. Упражнение 3 показывает некоторые из наиболее интересных вариантов.

Упражнение 3
В этом упражнении вы узнаете, как работать с различными оциями journalctl.

1. Введите journalctl. Вы увидите содержимое журнала с момента последнего запуска сервера, начиная с начала журнала. Содержимое отображается в меньшем количестве, поэтому вы можете использовать, например, less для просмотра файла.

2. Введите q, чтобы выйти из пейджера. Теперь введите journalctl —no-pager. Эта опция показывает содержимое журнала без использования пейджера.

3. Введите journalctl -f. Эта опция открывает режим просмотра в реальном времени, который позволяет видеть новые сообщения в режиме реального времени.

4. Введите journalctl и дважды нажмите клавишу Tab. Будут показаны конкретные опции, которые можно использовать для фильтрации. Выполните, например, journalctl _UID=0.

5. Введите journalctl -n 20. Опция -n 20 отображает последние 20 строк журнала (так же, как tail -n 20).

6. Теперь введите journalctl -p err. Эта команда показывает только ошибки.

7. Если вы хотите просмотреть сообщения журнала, записанные за определенный период времени, вы можете использовать команды —since и —until. Оба варианта принимают параметр времени в формате ГГГГ-ММ-ДД чч:мм:сс. Кроме того, вы можете использовать yesterday, today и tomorrow в качестве опций. Итак, введите journalctl —since yesterday, чтобы показать все сообщения, которые были написаны со вчерашнего дня.

8. journalctl позволяет комбинировать различные варианты. Итак, если вы хотите показать все сообщения с приоритом err, которые были написаны со вчерашнего дня, то используйте journalctl —since yesterday -p err.

9. Если вам нужно как можно больше подробностей, используйте journalctl -o verbose.

В предыдущем упражнении вы ввели journalctl -o verbose, чтобы показать подробный вывод.
В листинге 5 приведен пример подробного вывода. Вы можете увидеть, что вывод предоставляет подробную информацию для всех элементов, которые были логированы, в том числе PID, идентификатор связанный с учетной записью пользователя и группы и многое другое.

Сохранение журнала systemd

По умолчанию журнал хранится в файле /run/log/journal. Весь каталог /run используется только для информации о текущем состоянии процесса, что означает, что журнал очищается при перезагрузке системы. Чтобы сделать журнал постоянным между перезагрузками системы, вы должны убедиться, что существует каталог /var/log/journal.

Даже если журнал записывается в постоянный файл в /var/log/journal, это не означает, что журнал сохраняется вечно. Журнал имеет встроенную ротацию логов, которая будет использоваться ежемесячно. Кроме того, максимальный размер журнала ограничен 10% размера файловой системы, и он также прекратит расти, если менее 15% файловой системы все еще свободно. Если это произойдет, самые старые сообщения из журнала автоматически удаляются, чтобы освободить место для новых сообщений. Чтобы изменить эти настройки, вы можете изменить файл /etc/systemd/journald.conf. Вы увидите, что в этом файле также можно установить некоторые другие параметры (Листинг 6).

Сделать журнал постоянным не сложно. Упражнение 4 показывает, как это сделать.

Упражнение 4
В этом упражнении вы узнаете, как сделать журнал journald постоянным.

1. Войдите под root и введите mkdir /var/log/journal.

2. Прежде чем journald сможет записать журнал в этот каталог, вы должны установить владельца. Введите chown root:systemd-journal /var/log/journal, а затем chmod 2755 /var/log/journal.

3. Затем вы можете либо перезагрузить систему (недостаточно перезапустить службу systemd-journald), либо воспользоваться командой killall -USR1 systemd-journald.

4. Журнал systemd теперь сохраняется при перезагрузках. Если вы хотите просмотреть сообщения журнала с момента последней перезагрузки, используйте journalctl -b.