Systemd. Служба логирования journald
В systemd
используется принципиально иной подход к записи логов, по сравнению с традиционным инструментом syslog
. Специализированный компонент journal
cобирает все системные сообщения — от ядра, различных служб и приложений. Специально настраивать отправку логов не нужно — приложения могут просто писать в stdout
и stderr
. Все сообщения сохраняются в бинарном виде, что существенно упрощает систематизацию и поиск.
Хранение логов в бинарных файлах позволяет избежать сложностей с использованием парсеров для разных видов логов. Но при необходимости логи можно конвертировать в другие форматы. Journal
может работать как совместно с syslog
, так и полностью заменить его. Для просмотра логов используется утилита journalctl
.
Хранение логов
Логи могут храниться в оперативной памяти (в директории /var/log/journal
) или в файловой ситеме на диске (в директории /run/log/journal
) — это задается директивой Storage
файла конфигурации. При хранении логов в оперативной памяти — для просмотра будут доступны только логи с момента последней загрузки.
$ sudo nano /etc/systemd/journald.conf
[Journal] Storage=persistent
$ sudo systemctl restart systemd-journald.service
Просмотр логов
Если ввести команду journalсtl
без каких-либо аргументов, на консоль будет выведен огромный список
$ journalctl -- Logs begin at Wed 2019-11-13 15:01:02 MSK, end at Sat 2020-03-14 09:11:42 MSK ноя 13 15:01:02 web-server kernel: Linux version 5.0.0-23-generic (buildd@lgw01 ноя 13 15:01:02 web-server kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.0.0 ноя 13 15:01:02 web-server kernel: KERNEL supported cpus: ..........
Фильтрация логов
Логи с момента последней загрузки
С помощью опции -b
можно просмотреть все логи, собранные с момента последней загрузки системы:
$ journalctl -b -- Logs begin at Wed 2019-11-13 15:01:02 MSK, end at Sat 2020-03-14 09:12:15 MSK мар 14 09:03:09 web-server kernel: Linux version 5.3.0-40-generic (buildd@lcy01- мар 14 09:03:09 web-server kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.3.0- мар 14 09:03:09 web-server kernel: KERNEL supported cpus: мар 14 09:03:09 web-server kernel: Intel GenuineIntel мар 14 09:03:09 web-server kernel: AMD AuthenticAMD мар 14 09:03:09 web-server kernel: Hygon HygonGenuine мар 14 09:03:09 web-server kernel: Centaur CentaurHauls
Просмотр логов предыдущих сессий
Можно просматривать информацию о предыдущих сессиях работы в системе. Получаем список предыдущих загрузок:
$ journalctl --list-boots -46 6ab45fd4f20b4c688367749c5a319c36 Wed 2019-11-13 15:01:02 MSK—Wed 2019-11-13 15:02:54 MSK -45 483b31301b0f49e781cf8441aaf209af Wed 2019-11-13 15:04:38 MSK—Wed 2019-11-13 15:06:14 MSK -44 ea2435c1f0aa4b6eb6ad5f0efd7bb779 Wed 2019-11-13 15:06:26 MSK—Wed 2019-11-13 15:24:00 MSK .......... -2 304d7cadb64a46e185fad345f732ec0b Mon 2020-03-02 10:55:49 MSK—Mon 2020-03-02 16:48:21 MSK -1 c0ed77121b1c4e53a01e78c3666a4389 Fri 2020-03-06 14:52:51 MSK—Fri 2020-03-06 18:18:19 MSK 0 49f60c5b2dbe48a1955e892db356ec66 Sat 2020-03-14 09:03:09 MSK—Sat 2020-03-14 09:17:37 MSK
В первой колонке указывается порядковый номер загрузки, во второй — её идентификатор, в третьей — дата и время. Чтобы просмотреть лог для конкретной загрузки, можно использовать идентификаторы как из первой, так и из второй колонки:
$ journalctl -b -1
$ journalctl -b c0ed77121b1c4e53a01e78c3666a4389
Фильтрация по дате и времени
Для этого используются опции since
и until
. Например, нам нужно просмотреть логи, начиная с 14 часов 55 минут 6 марта 2020 года:
$ journalctl --since "2020-03-06 14:55:00"
Можно воспользоваться и вот такими человекопонятными конструкциями:
$ journalctl ---since yesterday $ journalctl --since 09:00 --until now $ journalctl --since 10:00 --until "1 hour ago"
Фильтрация по приложениям и службам
Для просмотра логов конкретного приложения или службы:
$ journalctl -u mysql.service
$ journalctl -u mysql.service --since yesterday
Фильтрация по процессам, пользователям и группам
Просмотреть логи для какого-либо процесса можно, указав его идентификатор:
$ journalctl _PID=655
$ pstree -p systemd(1)─┬─ModemManager(542)─┬─{ModemManager}(572) │ └─{ModemManager}(576) ├─NetworkManager(527)─┬─dhclient(715) │ ├─{NetworkManager}(587) │ └─{NetworkManager}(591) ├─accounts-daemon(533)─┬─{accounts-daemon}(539) │ └─{accounts-daemon}(545) ├─acpid(494) ├─apache2(655)─┬─apache2(4385)─┬─{apache2}(4415) │ │ ├─{apache2}(4416) │ │ ├─{apache2}(4417) │ │ ├─{apache2}(4418) │ │ └─{apache2}(4440) │ └─apache2(4386)─┬─{apache2}(4389) │ ├─{apache2}(4390) │ ├─{apache2}(4391) │ ├─{apache2}(4392) │ └─{apache2}(4414)
Для просмотра логов процессов, запущенных от имени определённого пользователя или группы, используются фильтры _UID
и _GID
соответственно. Предположим, у нас есть веб-сервер, запущенный от имени пользователя www-data
. Определим сначала идентификатор этого пользователя:
$ id -u www-data 33
Теперь можно просмотреть логи всех процессов, запущенных от имени этого пользователя:
$ journalctl _UID=33
Просмотр сообщений ядра
Для просмотра сообщений ядра используется опция -k
или --dmesg
:
$ journalctl -k
Приведённая команда покажет все сообщения ядра для текущей загрузки. Чтобы просмотреть сообщения ядра для предыдущих сессий, нужно воспользоваться опцией -b
:
$ journalctl -k -b -2
Фильтрация по уровню ошибки
Во время диагностики и исправления неполадок в системе нередко требуется просмотреть логи и выяснить, есть ли в них сообщения о критических ошибках.
$ journalctl -p err -b 0
Приведённая команда покажет все сообщения об ошибках, имевших место в системе, с момента последней загрузки. В journal
используется такая же классификация уровней ошибок, как и в syslog
:
emerg
— система неработоспособнаalert
— требуется немедленное вмешательствоcrit
— критическое состояниеerr
— ошибкаwarning
— предупреждениеnotice
— следует обратить вниманиеinfo
— информационное сообщениеdebug
— отладочные сообщения
Выбор формата вывода
C помощью опции -o
можно преобразовывать данные логов в различные форматы, что облегчает их парсинг и дальнейшую обработку, например:
$ journalctl -u apache2.service -o json
Объект json
можно представить в более структурированном и человекочитаемом виде, указав формат json-pretty
:
$ journalctl -u apache2.service -o json-pretty
{ "__CURSOR" : "s=39af8c988a2447198f83abd4ba184866;i=48cc;b=2ebfbe0d4ea74da7969703dd4409beeb...", "__REALTIME_TIMESTAMP" : "1577868308021968", "__MONOTONIC_TIMESTAMP" : "509869391", "_BOOT_ID" : "2ebfbe0d4ea74da7969703dd4409beeb", "PRIORITY" : "6", "SYSLOG_FACILITY" : "3", "SYSLOG_IDENTIFIER" : "systemd", "_TRANSPORT" : "journal", "_PID" : "1", "_UID" : "0", "_GID" : "0", "_COMM" : "systemd", "_EXE" : "/lib/systemd/systemd", "_CMDLINE" : "/sbin/init splash", "_CAP_EFFECTIVE" : "3fffffffff", "_SELINUX_CONTEXT" : "unconfined\n", "_SYSTEMD_CGROUP" : "/init.scope", "_SYSTEMD_UNIT" : "init.scope", "_SYSTEMD_SLICE" : "-.slice", "_MACHINE_ID" : "82c67903ca0f4f43b9b0083895c9505e", "CODE_FILE" : "../src/core/unit.c", "CODE_LINE" : "1718", "CODE_FUNC" : "unit_status_log_starting_stopping_reloading", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_HOSTNAME" : "web-server", "MESSAGE" : "Starting The Apache HTTP Server...", "UNIT" : "apache2.service", "INVOCATION_ID" : "0c74ebdfcbf04d57a23fd40df88859cc", "_SOURCE_REALTIME_TIMESTAMP" : "1577868308021921" }
Помимоjson
данные логов могут быть преобразованы в следующие форматы:
cat
— только сообщения из логов без служебных полейexport
— бинарный формат, подходит для резервного копирования логовshort
— формат выводаsyslog
short-iso
— формат выводаsyslog
с метками времени в формате ISO 8601short-monotonic
— формат выводаsyslog
c метками монотонного времениshort-precise
— формат выводаsyslog
с метками точного времениverbose
— максимально подробный формат представления данных
Прочие возможности
Опция -n
используется для просмотра информации о недавних событиях в системе
$ journalctl -n
По умолчанию выводится информация о последних 10 событиях, но можно указать число событий
$ journalctl -n 20
Для просмотра логов в режиме реального времени используется опция -f
:
$ journalctl -f
По умолчанию для вывода используется утилита less
. В этом случае невозможно применять стандартные команды для обработки текстовых данных. Это можно отменить с помощью опции --no-pager
.
$ journalctl --no-pager
Ротация логов по размеру и времени
Если журнал сохраняется при перезагрузке, его размер по умолчанию ограничен значением в 10% от объема соответствующей файловой системы (и максимально может достигать 4 ГиБ). Например, для каталога /var/log/journal
, расположенном на корневом разделе в 20ГиБ, максимальный размер журналируемых данных составит 2ГиБ. На разделе же 50ГиБ журнал сможет занять до 4ГиБ. Узнать объём имеющихся на текущий момент логов можно с помощью опции --disk-usage
.
$ journalctl --disk-usage Journals take up 18.0M on disk.
Настройка ротации логов осуществляется с помощью опций --vacuum-size
и --vacuum-time
. Первая из них устанавливает максимальный размер логов, а вторая — предельный срок хранения.
$ sudo journalctl --vacuum-size=1G
$ sudo journalctl --vacuum-time=2weeks
Настройки ротации логов можно также прописать в конфигурационном файле /etc/systemd/journald.conf
:
$ sudo nano /etc/systemd/journald.conf
[Journal] # максимальный объём, который логи могут занимать на диске SystemMaxUse=1G
Для применения изменений нужно перезапустить службу journald
$ sudo systemctl restart systemd-journald.service
Файлы конфигурации
Все настройки journald
находятся в файле /etc/systemd/journald.conf
и других конфигурационных файлах из директории /etc/systemd/journald.conf.d
. По умолчанию все директивы в файле /etc/systemd/journald.conf
закомментированы — это сообщает, какие значения используются по умолчанию. Значение директивы, установленное в файле /etc/systemd/journald.conf
может быть переопределено в одном из файлов в директории /etc/systemd/journald.conf.d
.
# This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it under the # terms of the GNU Lesser General Public License as published by the Free # Software Foundation; either version 2.1 of the License, or (at your option) # any later version. # # Entries in this file show the compile time defaults. Local configuration # should be created by either modifying this file, or by creating "drop-ins" in # the journald.conf.d/ subdirectory. The latter is generally recommended. # Defaults can be restored by simply deleting this file and all drop-ins. # # Use 'systemd-analyze cat-config systemd/journald.conf' to display the full config. # # See journald.conf(5) for details. [Journal] #Storage=auto #Compress=yes #Seal=yes #SplitMode=uid #SyncIntervalSec=5m #RateLimitIntervalSec=30s #RateLimitBurst=10000 #SystemMaxUse= #SystemKeepFree= #SystemMaxFileSize= #SystemMaxFiles=100 #RuntimeMaxUse= #RuntimeKeepFree= #RuntimeMaxFileSize= #RuntimeMaxFiles=100 #MaxRetentionSec= #MaxFileSec=1month #ForwardToSyslog=yes #ForwardToKMsg=no #ForwardToConsole=no #ForwardToWall=yes #TTYPath=/dev/console #MaxLevelStore=debug #MaxLevelSyslog=debug #MaxLevelKMsg=notice #MaxLevelConsole=info #MaxLevelWall=emerg #LineMax=48K #ReadKMsg=yes #Audit=no
Директива Storage
Определяет, где хранить логи и может принимать значения none
, volatile
, persistent
и auto
. Значение none
— не вести журнал, значение volatile
— хранить в оперативной памяти (в директории /run/log/journal
), значение persistent
— хранить на диске (в директории /var/log/journal
). Значение по умолчанию auto
аналогично persistent
, но директория /var/log/journal
не создается автоматически. Если директория существует — логи сохраняются на диск, если директория не существует — логи сохраняются в памяти.
Директива Compress
Сжимать или нет сообщения перед записью в журнал, может принимать значения yes
, no
.
Директива Seal
Включить или нет защиту Forward Secure Sealing (FSS), которая позволяет накладывать криптографические отпечатки на журнал системных логов.
Директива SplitMode
Определяет доступ к журналу пользователям, может принимать значения uid
— есть доступ у всех пользователей, login
— только сообщения своего сеанса, none
— нет доступа.
Директива SyncIntervalSec
Таймаут, после которого происходит синхронизация и запись журнала на диск. Относится только к уровням err
, warning
, notice
, info
, debug
. Сообщения уровня emerg
, alert
, crit
сразу записываются на диск.
Директивы RateLimitInterval и RateLimitBurst
Настройки ограничения скорости генерации сообщений для каждой службы. Если в интервале времени RateLimitInterval
получено больше сообщений, чем указано в RateLimitBurst
— все дальнейшие сообщения отбрасываются, пока интервал не закончится. При этом генерируется сообщение о количестве отброшенных сообщений. Единицы измерения — s
, min
, h
, ms
, us
. Чтобы выключить ограничение скорости — нужно установить оба значения в ноль.
Директива MaxRetentionSec
Максимальное время хранения записей журнала. Единицы измерения — year
, month
, week
, day
, h
или m
.
Директива MaxFileSec
Максимальное время хранения записей в одном файле журнала, после которого он переводится в следующий.
Директивы ForwardToSyslog, ForwardToKMsg, ForwardToConsole, ForwardToWall
Определяют, куда направлять сообщения — в системный журнал Syslog, в буфер журнала ядра (kmsg), на системную консоль, или на стену, чтобы было видно всем пользователям. Если переадресация на Syslog включен, но Syslog демон не работает, соответствующий параметр не имеет никакого эффекта. По умолчанию включена только отправка сообщений на стену с помощью команды wall
.
Директива TTYPath
Назначает консоль TTY, для вывода сообщений, если установлена директива ForwardToConsole=yes
. По умолчанию используется /dev/console
, чтобы вывести на 12-ю консоль — устанавливаем TTYPath=/dev/tty12
.
Директивы MaxLevelStore, MaxLevelSyslog, MaxLevelKMsg, MaxLevelConsole, MaxLevelWall
Определяет максимальный уровень сообщений, который — сохраняется в журнал, выводится в журнал Syslog, буфер журнала ядра (kmsg), консоль или стену. Значения — emerg
, alert
, crit
, err
, warning
, notice
, info
, debug
или цифры от 0 до 7 (соответствуют уровням).
Директивы ротации логов
Единицы измерения — K
, M
, G
, T
, P
, E
.
SystemMaxUse
— максимальный объём, который логи могут занимать в файловой системе на дискеSystemKeepFree
— объём свободного места, которое должно оставаться в файловой системе на дискеSystemMaxFileSize
— объём файла лога, по достижении которого он должен быть удален с дискаRuntimeMaxUse
— максимальный объём, который логи могут занимать в файловой системе/run
RuntimeKeepFree
— объём свободного места, которое должно оставаться в файловой системе/run
RuntimeMaxFileSize
— объём файла лога, по достижении которого он должен быть удален из/run
Journald вместе с rsyslog
События журнала могут быть переданы демону rsyslog
двумя способами
- Перенаправлять все сообщения
systemd
в сокет/run/systemd/journal/syslog
, где их может читать демонrsyslog
. Это контролируется опциейForwardToSyslog
файла конфигурацииjournald.conf
. - Демон
rsyslog
ведет себя как обычный клиент журнала и считывает сообщения из сокета/dev/log
аналогичноjournald
. Этот метод доступен только в том случае, если опцияStorage
не равнаnone
.
Демон rsyslog
по умолчанию использует второй способ, поэтому важна опция Storage
, а не ForwardToSyslog
. При этом /dev/log
на самом деле является символической ссылкой на /run/systemd/journal/dev-log
.
- Управление службами Systemd. Часть 3 из 3
- Управление службами Systemd. Часть 1 из 3
- Утилита rcync: синхронизация директорий и backup-ы
- Настройка SFTP-сервера в Ubuntu 18.04 LTS
- Монтирование NFS на сервере Ubuntu 18.04 LTS
- Создание SSH-туннеля. Часть 4 из 4
- Установка vnc4server на Ubuntu Server 18.04 LTS
Поиск: CLI • Linux • Systemd • Команда • Настройка • Сервер • Файл • journalctl • syslog • Лог • Служба • Service