Как использовать Journalctl для просмотра и управления журналами Systemd

Введение

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

Журнал реализован с помощью демона journald, который обрабатывает все сообщения, создаваемые ядром, initrd, службами и т.д. В этом руководстве мы обсудим, как использовать утилиту journalctl, которая может использоваться для доступа и управления данными, хранящимися в журнале.

Общая идея

Одним из стимулов создания журнала systemd является централизация управления логами независимо от того, откуда исходят сообщения. Поскольку большая часть процесса загрузки и управления сервисами осуществляется процессом systemd, целесообразно стандартизировать способ сбора и доступа к логам. Демон journald собирает данные из всех доступных источников и сохраняет их в бинарном формате для удобной и динамической обработки.

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

Хранение логов в бинарном формате также означает, что данные могут быть отображены в произвольных форматах вывода в зависимости от того, что вам нужно в данный момент. Например, для ежедневного управления логами вы можете привыкнуть просматривать логи в стандартном формате syslog, но если позже вы решите построить график прерываний сервиса, вы можете вывести каждую запись в виде объекта JSON, чтобы сделать её доступной для вашего сервиса построения графиков. Поскольку данные не записываются на диск в виде обычного текста, конвертация не требуется, когда вам нужен другой формат по требованию.

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

Настройка системного времени

Одним из преимуществ использования бинарного журнала для ведения логов является возможность просматривать записи журнала в UTC или местном времени по желанию. По умолчанию systemd будет отображать результаты в местном времени.

Из-за этого перед тем, как мы начнем с журнала, мы убедимся, что часовой пояс настроен правильно. На самом деле комплект systemd поставляется с инструментом под названием timedatectl, который может в этом помочь.

Сначала посмотрите, какие часовые пояса доступны, с помощью опции list-timezones:

timedatectl list-timezones

Это отобразит доступные в вашей системе часовые пояса. Когда вы найдете тот, который соответствует местоположению вашего сервера, вы можете установить его, используя опцию set-timezone:

sudo timedatectl set-timezone zone

Чтобы убедиться, что на вашем компьютере сейчас используется правильное время, используйте команду timedatectl самостоятельно или с опцией status. Отображение будет одинаковым:

timedatectl status

               Local time: Fri 2021-07-09 14:44:30 EDT
           Universal time: Fri 2021-07-09 18:44:30 UTC
                 RTC time: Fri 2021-07-09 18:44:31
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Первая строка должна отображать правильное время.

Просмотр базового журнала

Чтобы просмотреть журналы, собранные демоном journald, используйте команду journalctl.

Когда используется самостоятельно, каждая запись журнала, находящаяся в системе, будет отображаться в просмотрщике страниц (обычно less), чтобы вы могли просматривать её. Самые старые записи будут вверху:

journalctl

-- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).
Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  8 users, 102 roles, 4976 types, 294 bools, 1 sens,
Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  83 classes, 104131 rules

. . .

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

Формат будет знаком тем, кто привык к стандартному ведению логов syslog. Однако на самом деле он собирает данные из большего числа источников, чем способны традиционные реализации syslog. Он включает логи из раннего процесса загрузки, ядра, initrd, а также стандартного вывода и ошибок приложений. Всё это доступно в журнале.

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

Если вы хотите отображать временные метки в формате UTC, вы можете использовать флаг --utc:

journalctl --utc

Фильтрация журнала по времени

Хотя доступ к такому большому объему данных определенно полезен, такое огромное количество информации может быть трудно или невозможно проверить и обработать вручную. По этой причине одной из самых важных функций journalctl являются его возможности фильтрации.

Отображение журналов текущей загрузки

Самый базовый из этих, который вы можете использовать ежедневно, это флаг -b. Он покажет вам все записи журнала, собранные с момента последней перезагрузки.

journalctl -b

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

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

. . .

-- Reboot --

. . .

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

Прошлые ботинки

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

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

sudo mkdir -p /var/log/journal

Или вы можете отредактировать файл конфигурации журнала:

sudo nano /etc/systemd/journald.conf

В разделе [Journal] установите параметр Storage= в значение «persistent», чтобы включить постоянное журналирование:

. . .
[Journal]
Storage=persistent

Когда на вашем сервере включено сохранение предыдущих загрузок, journalctl предоставляет несколько команд, которые помогут вам работать с загрузками как с единицей деления. Чтобы увидеть загрузки, о которых знает journald, используйте опцию --list-boots с journalctl:

journalctl --list-boots

-2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
-1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
 0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC

Это отобразит строку для каждой загрузки. Первый столбец — это смещение для загрузки, которое можно использовать для простого обращения к загрузке с помощью journalctl. Если вам нужна абсолютная ссылка, ID загрузки находится во втором столбце. Вы можете определить время, к которому относится сессия загрузки, с помощью двух указаний времени, приведённых ближе к концу.

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

Например, чтобы просмотреть журнал с предыдущей загрузки, используйте относительный указатель -1 с флагом -b:

journalctl -b -1

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

journalctl -b caf0524a1d394ce0bdbcff75b94444fe

Временные окна

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

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

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

YYYY-MM-DD HH:MM:SS

Например, мы можем увидеть все записи с 10 января 2015 года в 17:15, введя:

journalctl --since "2015-01-10 17:15:00"

Если какие-либо компоненты указанного выше формата опущены, будут применены некоторые значения по умолчанию. Например, если дата пропущена, будет принята текущая дата. Если компонент времени отсутствует, будет подставлено «00:00:00» (полночь). Поле секунд также можно опустить, чтобы использовать значение по умолчанию «00»:

journalctl --since "2015-01-10" --until "2015-01-11 03:00"

Журнал также понимает некоторые относительные значения и именованные ярлыки. Например, вы можете использовать слова «вчера», «сегодня», «завтра» или «сейчас». Вы можете задавать относительное время, добавляя «-» или «+» перед числовым значением или используя слова вроде «назад» в конструкции предложения.

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

journalctl --since yesterday

Если вы получили сообщения о прекращении работы сервиса, начавшемся в 9:00 утра и продолжавшемся до часа назад, вы могли бы написать:

journalctl --since 09:00 --until "1 hour ago"

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

Фильтрация по интересу к сообщениям

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

По единице

Возможно, самым полезным способом фильтрации является фильтрация по интересующему вас подразделению. Мы можем использовать опцию -u, чтобы фильтровать таким образом.

Например, чтобы увидеть все журналы одного блока Nginx в нашей системе, мы можем набрать:

journalctl -u nginx.service

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

journalctl -u nginx.service --since today

Этот тип фокусировки становится исключительно полезным, когда вы используете возможность журнала перемежать записи из различных модулей. Например, если ваш процесс Nginx подключен к модулю PHP-FPM для обработки динамического контента, вы можете объединить записи из обоих в хронологическом порядке, указав оба модуля:

journalctl -u nginx.service -u php-fpm.service --since today

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

По процессу, пользователю или идентификатору группы

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

Для этого мы можем фильтровать, указав поле _PID. Например, если нас интересует PID 8088, мы можем ввести:

journalctl _PID=8088

В другие моменты вы можете захотеть показать все записи, созданные конкретным пользователем или группой. Это можно сделать с помощью фильтров _UID или _GID. Например, если ваш веб-сервер работает под пользователем www-data, вы можете узнать идентификатор пользователя, набрав:

id -u www-data

После этого вы можете использовать возвращённый идентификатор для фильтрации результатов журнала:

journalctl _UID=33 --since today

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

Начальное подчёркивание указывает на то, что поле _PID относится к последнему типу. Журнал автоматически записывает и индексирует PID процесса, который ведёт лог, для дальнейшей фильтрации. Вы можете узнать обо всех доступных полях журнала, набрав:

man systemd.journal-fields

Мы обсудим некоторые из них в этом руководстве. Пока что мы рассмотрим еще одну полезную опцию, связанную с фильтрацией по этим полям. Опция -F может использоваться для отображения всех доступных значений для данного поля журнала.

Например, чтобы узнать, для каких идентификаторов групп в журнале systemd есть записи, вы можете ввести:

journalctl -F _GID

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

По пути компонента

Мы также можем фильтровать, указывая путь.

Если путь ведет к исполняемому файлу, journalctl отобразит все записи, которые касаются данного исполняемого файла. Например, чтобы найти те записи, которые касаются исполняемого файла bash, вы можете ввести:

journalctl /usr/bin/bash

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

Отображение сообщений ядра

Сообщения ядра, которые обычно можно найти в выводе dmesg, также можно получить из журнала.

Чтобы отображать только эти сообщения, мы можем добавить к нашей команде флаги -k или --dmesg:

journalctl -k

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

journalctl -k -b -5

По приоритету

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

Вы можете использовать journalctl, чтобы отображать только сообщения указанного приоритета или выше, используя опцию -p. Это позволяет отфильтровывать сообщения с более низким приоритетом.

Например, чтобы показать только записи, зарегистрированные на уровне ошибки или выше, вы можете ввести:

journalctl -p err -b

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

0: возникнуть
1: предупреждение
2: крит
3: ошибка
4: предупреждение
5: уведомление
6: информация
7: отладка

Указанные выше номера или имена можно использовать взаимозаменяемо с опцией -p. Выбор приоритета будет отображать сообщения, помеченные на указанном уровне и выше.

Изменение отображения журнала

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

Сократить или расширить вывод

Мы можем настроить отображение данных journalctl, указав ему сжимать или расширять вывод.

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

Если вы предпочитаете, чтобы вывод был усечённым, с вставкой многоточия там, где информация была удалена, вы можете использовать опцию --no-full:

journalctl --no-full

. . .

Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot

Вы также можете пойти в противоположном направлении и сказать journalctl, чтобы он отображал всю свою информацию, независимо от того, содержит ли она непечатаемые символы. Мы можем сделать это с помощью флага -a:

journalctl -a

Вывод в стандартный поток

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

Вы можете сделать это с помощью опции --no-pager:

journalctl --no-pager

Это можно сразу направить в утилиту обработки или перенаправить в файл на диске, в зависимости от ваших потребностей.

Форматы вывода

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

Например, вы можете вывести записи журнала в формате JSON, введя:

journalctl -b -u nginx -o json

{ "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }

. . .

Это полезно для анализа с помощью утилит. Вы можете использовать формат json-pretty, чтобы лучше понять структуру данных перед передачей их потребителю JSON:

journalctl -b -u nginx -o json-pretty

{
	"__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
	"__REALTIME_TIMESTAMP" : "1422990364739502",
	"__MONOTONIC_TIMESTAMP" : "27200938",
	"_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
	"PRIORITY" : "6",
	"_UID" : "0",
	"_GID" : "0",
	"_CAP_EFFECTIVE" : "3fffffffff",
	"_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
	"_HOSTNAME" : "desktop",
	"SYSLOG_FACILITY" : "3",
	"CODE_FILE" : "src/core/unit.c",
	"CODE_LINE" : "1402",
	"CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
	"SYSLOG_IDENTIFIER" : "systemd",
	"MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
	"_TRANSPORT" : "journal",
	"_PID" : "1",
	"_COMM" : "systemd",
	"_EXE" : "/usr/lib/systemd/systemd",
	"_CMDLINE" : "/usr/lib/systemd/systemd",
	"_SYSTEMD_CGROUP" : "/",
	"UNIT" : "nginx.service",
	"MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
	"_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
}

. . .

Для отображения могут использоваться следующие форматы:

cat: Отображает только само поле сообщения.
экспорт: Двоичный формат, подходящий для передачи или резервного копирования.
json: Стандартный JSON с одной записью на строку.
json-pretty: JSON отформатирован для лучшей читаемости человеком
json-sse: Вывод в формате JSON, оформленный так, чтобы быть совместимым с серверными событиями
короткий: Вывод в стиле syslog по умолчанию
short-iso: Формат по умолчанию, дополненный для отображения временных меток по стандарту ISO 8601.
short-monotonic: Формат по умолчанию с монотонными временными метками.
коротко-точно: Формат по умолчанию с точностью до микросекунд
подробно: Показывает все поля журнала, доступные для записи, включая те, которые обычно скрыты внутри.

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

Активный мониторинг процессов

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

Отображение последних журналов

Чтобы отобразить заданное количество записей, вы можете использовать опцию -n, которая работает точно так же, как tail -n.

По умолчанию будут отображаться последние 10 записей:

journalctl -n

Вы можете указать количество записей, которые вы хотите увидеть, с помощью числа после -n:

journalctl -n 20

Следующие журналы

Чтобы активно отслеживать записи в логах по мере их записи, вы можете использовать флаг -f. Снова же, это работает так, как вы могли бы ожидать, если у вас есть опыт использования tail -f:

journalctl -f

Чтобы выйти из этой команды, нажмите CTRL+C.

Обслуживание журнала

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

Определение текущего использования диска

Вы можете узнать, сколько места журнал в данный момент занимает на диске, используя флаг --disk-usage:

journalctl --disk-usage

Archived and active journals take up 8.0M in the file system.

Удаление старых журналов

Если вы хотите уменьшить размер вашего журнала, вы можете сделать это двумя разными способами (доступно в версии systemd 218 и позже).

Если вы используете опцию --vacuum-size, вы можете уменьшить журнал, указав размер. Это удалит старые записи до тех пор, пока занимаемое журналом место на диске не достигнет указанного размера:

sudo journalctl --vacuum-size=1G

Другой способ уменьшить размер журнала — указать время отсечки с помощью опции --vacuum-time. Все записи после этого времени удаляются. Это позволяет сохранять записи, созданные после определенного времени.

Например, чтобы сохранить записи с прошлого года, вы можете ввести:

sudo journalctl --vacuum-time=1years

Ограничение расширения журнала

Вы можете настроить ваш сервер так, чтобы ограничить объем пространства, которое может занимать журнал. Это можно сделать, отредактировав файл /etc/systemd/journald.conf.

Следующие элементы могут быть использованы для ограничения роста журнала:

SystemMaxUse=: Указывает максимальный объем дискового пространства, который может использоваться журналом в постоянном хранилище.
SystemKeepFree=: Указывает количество пространства, которое журнал должен оставлять свободным при добавлении записей журнала в постоянное хранилище.
SystemMaxFileSize=: Управляет тем, насколько большими могут становиться отдельные журнальные файлы в постоянном хранилище, прежде чем они будут перемещены/обновлены.
RuntimeMaxUse=: Указывает максимальный объём дискового пространства, который может быть использован во временном хранилище (в файловой системе /run).
RuntimeKeepFree=: Указывает количество пространства, которое следует зарезервировать для других нужд при записи данных в временное хранилище (внутри файловой системы /run).
RuntimeMaxFileSize=: Указывает объем пространства, которое может занимать отдельный журнал на временном хранилище (в файловой системе /run) до его ротации.

Установив эти значения, вы можете контролировать, как journald потребляет и сохраняет место на вашем сервере. Имейте в виду, что SystemMaxFileSize и RuntimeMaxFileSize будут ориентироваться на архивные файлы для достижения указанных лимитов. Это важно помнить при интерпретации количества файлов после операции очистки (vacuuming).

Заключение

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