Поиск по сайту:

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


Введение

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

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

Главная идея

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

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

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

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

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

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

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

Во-первых, посмотрите, какие часовые пояса доступны с параметром list-timezones:

  1. timedatectl list-timezones

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

  1. sudo timedatectl set-timezone zone

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

  1. timedatectl status
Output
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) для просмотра. Самые старые записи будут вверху:

  1. journalctl
Output
-- 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:

  1. journalctl --utc

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

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

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

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

  1. journalctl -b

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

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

Output
. . . -- Reboot -- . . .

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

Прошлые сапоги

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

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

  1. sudo mkdir -p /var/log/journal

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

  1. sudo nano /etc/systemd/journald.conf

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

. . .
[Journal]
Storage=persistent

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

journalctl --list-boots
Output
-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. Если вам нужна абсолютная ссылка, идентификатор загрузки находится во втором столбце. Вы можете указать время, к которому относится сеанс загрузки, с помощью двух спецификаций времени, перечисленных ближе к концу.

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

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

  1. journalctl -b -1

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

  1. journalctl -b caf0524a1d394ce0bdbcff75b94444fe

Окна времени

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

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

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

  1. YYYY-MM-DD HH:MM:SS

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

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

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

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

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

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

  1. journalctl --since yesterday

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

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

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

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

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

По единицам

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

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

  1. journalctl -u nginx.service

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

  1. journalctl -u nginx.service --since today

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

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

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

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

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

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

  1. journalctl _PID=8088

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

  1. id -u www-data
Output
33

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

  1. journalctl _UID=33 --since today

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

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

  1. man systemd.journal-fields

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

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

  1. journalctl -F _GID
Output
32 99 102 133 81 84 100 0 124 87

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

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

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

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

  1. journalctl /usr/bin/bash

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

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

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

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

  1. journalctl -k

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

  1. journalctl -k -b -5

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

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

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

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

  1. journalctl -p err -b

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

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

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

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

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

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

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

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

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

  1. journalctl --no-full
Output
. . . 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:

  1. journalctl -a

Выход на стандартный выход

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

Это можно сделать с помощью параметра --no-pager:

  1. journalctl --no-pager

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

Выходные форматы

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

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

  1. journalctl -b -u nginx -o json
Output
{ "__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:

  1. journalctl -b -u nginx -o json-pretty
Output
{ "__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 завернуты, чтобы сделать добавление события, отправленного сервером, совместимым
  • short: вывод в стиле syslog по умолчанию
  • short-iso: формат по умолчанию расширен для отображения временных меток настенных часов ISO 8601.
  • короткий-монотонный: формат по умолчанию с монотонными отметками времени.
  • short-precise: формат по умолчанию с точностью до микросекунды.
  • Подробный: показывает все поля журнала, доступные для записи, включая те, которые обычно скрыты внутри.

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

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

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

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

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

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

  1. journalctl -n

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

  1. journalctl -n 20

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

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

  1. journalctl -f

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

Ведение журнала

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

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

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

  1. journalctl --disk-usage
Output
Archived and active journals take up 8.0M in the file system.

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

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

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

  1. sudo journalctl --vacuum-size=1G

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

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

  1. sudo journalctl --vacuum-time=1years

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

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

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

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

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

Заключение

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