Системный журнал в Linux: Syslog и Journald

Системный журнал в Linux: Syslog и Journald

Приветствую!

Сегодня теоретическая заметка🗒️. Поговорим про системный журнал (он же лог) в Linux, узнаем кто такие syslog и journald, а также чем они отличаются + коротко про их преимущества и недостатки. Будет познавательно😉.

Подписывайтесь на наш телеграм @r4ven_me📱, чтобы не пропустить новые публикации на сайте😉. А если есть вопросы или желание пообщаться по тематике – заглядывайте в Вороний чат @r4ven_me_chat🧐.

Введение

Любая сложная система имеет в своем арсенале инструменты журналирования/логирования событий, связанных с работой внутренних сервисов⚙️. Сюда же входит запись вывода (stdout, stderr) пользовательских приложений🧑‍💻.

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

  • Системные события (загрузка/остановка ОС, ошибки ядра);
  • События служб (работа и сбои демонов);
  • Сетевые события (подключения, ошибки);
  • Аутентификация (входы, выходы, попытки доступа);
  • Приложения (сообщения от программ и скриптов);
  • Аппаратные события (ошибки дисков, проблемы с устройствами);
  • и др

В подавляющем большинстве современных Linux дистрибутивов задачу журналирования решают две популярные службы (они же демоны): Syslog (rsyslog, syslog-ng) и Journald из проекта Systemd. Рассмотрим их по порядку✍️.

Syslog

Syslog — это стандартный протокол и система для сбора, обработки и хранения логов в Linux и других Unix-подобных операционных системах. Он используется для централизованного сбора и управления логами.

Syslog Daemon — это фоновая служба, которая собственно выполняет всю работу. Ранее в качестве такого демона чаще всего использовался syslogd, но в современных Linux’ах вы скорее всего увидите его современные аналоги: rsyslog или syslog-ng. Часто в сообществе их именуют общим термином — Syslog.

Располагаются журналы Syslog в директории /var/log/. Например, системный журнал в DEB системах может называться /var/log/syslog, а в RPM /var/log/messages.

По умолчанию логи в Syslog имеют следующий формат: <Дата и время> <Имя хоста> <Процесс/приложение>: <Сообщение>. Пример записи журнала:

Oct 5 12:34:56 myhost sshd[1234]: Failed password for root from 192.168.1.1 port 22 ssh2

Syslog классифицирует свои журналы по уровням важности:

  • 0 | emerg (Emergency)
  • 1 | alert (Alert)
  • 2 | crit (Critical)
  • 3 | error (Error)
  • 4 | warn (Warning)
  • 5 | notice (Notice)
  • 6 | info (Informational)
  • 7 | debug (Debug)

А также разделяет их по категориям (facilities):

  • auth
  • cron
  • daemon
  • kern
  • mail
  • user
  • и другие.

Весь список смотрите тут.

Как и многие сервисы в Linux, Syslog настраивается с помощью конфигурационных файлов. В случае rsyslog это /etc/rsyslog.conf или файлы в каталоге /etc/rsyslog.d/. В них определяются правила, куда и как записывать логи.

Очевидным последствием работы системы журналирования является создание большого количества объемных файлов. Для решения этой задачи служба Syslog часто используется в связке с утилитой ротации логов (сжатие и удаления старых записей): logrotate. Конфигурируется logrotate с помощью файлов /etc/logrotate.conf и /etc/logrotate.d/*.

На сегодняшний день Syslog не потерял своей актуальности в мире Linux, но его однозначно потеснила система журналирования под названием Journald☝️.

Journald

Journald — это система управления логами, которая является частью комбайна системы инициализации Systemd. В отличие от традиционного Syslog, Journald предлагает более современный и интегрированный подход к сбору, хранению и управлению логами.

В качестве демона выступает программа с именем systemd-journald. Если Syslog собирает и хранит логи в текстовом формате, то Journald — в бинарном. Т.к. Journald тесно интегрирован в Systemd, он является системой журналирования по умолчанию во многих современных дистрибутивах Linux: Debian, Ubuntu, Arch Linux, Fedora, RHEL, CentOS.

Формат записей похож на Syslog:

feb 08 18:22:52 myhost sshd[1777]: Server listening on 0.0.0.0 port 39178.

Файлы журналов Journald располагаются в /var/log/journal/.

Настройки поведения демона задаются в файле /etc/systemd/journald.conf.

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

Что еще стоит отметить про Journald:

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

Коротко про преимущества и недостатки

К преимуществам Syslog можно отнести его универсальность (поддержка всеми Unix-системами и различными сетевыми устройства), текстовый формат логов для удобного чтения и обработки, а также независимость от Systemd. Из недостатков: отсутствие структурированных данных, меньшая производительность при больших объемах и сложная настройка.

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

Как работает журналирование на примере Linux Mint

Ранее я упоминал, что в современных системах Linux, чаще всего за процесс журналирования отвечает демон Journald.

Чтобы понять, какая система используется у вас, выполните:

pgrep -af 'syslog|journald'

Команда pgrep ищет запущенные процессы по указанному шаблону в имени команды процесса.

В обычном Debian ожидаемо используется Journald:

В Linux Mint 22 или LMDE6 используется:

И rsyslog и systemd-journald?

К слову, Journald и Syslog могут работать совместно, осуществляя взаимодействие, например, через systemd сокеты. Предположу, что у разработчиков Linux Mint была необходимость в такой конфигурации🤷‍♂️.

Давайте копнем чуть глубже. Rsyslogd традиционно использует сокет /dev/log для приёма лог-сообщений от приложений. Но в системах с Systemd по этому адресу расположена символьная ссылка на сокет Systemd: /run/systemd/journal/dev-log, что позволяет systemd-journald перехватывать сообщения, отправленные в /dev/log и сохранять их в своём журнале:

ls -l /dev/log

Если заглянуть в содержимое файла-юнита systemd-journald.service:

systemctl cat systemd-journald.service

То в списке Sockets мы и увидим тот самый /run/systemd/journal/dev-log:

[Unit]
Requires=systemd-journald.socket

[Service]
Sockets=systemd-journald.socket systemd-journald-dev-log.socket systemd-journald-audit.socket

Казалось бы, на этом все, но нет. Заглянем в юнит файл сервиса rsyslog.service:

systemctl cat rsyslog.service

Видим, что он требует запущенного юнита syslog.socket и имеет алиас syslog.service:

[Unit]
Requires=syslog.socket

[Install]
Alias=syslog.service

Смотрим далее syslog.socket:

systemctl cat syslog.socket

Тут видим, что сервис Syslog использует специальный сокет Systemd /run/systemd/journal/syslog:

[Socket]
ListenDatagram=/run/systemd/journal/syslog

systemd-journald предоставляет этот сокет для передачи собранных логов другим системам логирования, таким как rsyslogd. В случае Linux Mint rsyslogd настроен на чтение сообщений из этого сокета.

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

Теперь пара слов о том, как отправлять данные в системный журнал. Чаще всего для этого используется утилита logger, которая пишет в традиционный сокет /dev/log и который обычно слушает Syslog. Но в случае Linux Mint данные перенаправляются в сокет Systemd. В итоге при выполнении команды:

logger "Это тестовое сообщение"

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

Данные попадут и в Syslog и Journald. Проверим:

grep $(date +"%F") /var/log/syslog | grep 'тестовое'

journalctl --since $(date +"%F") --grep 'тестовое'

В команде выше конструкция $(date +"%F") подставляет текущую дату в формате 2025-03-07.

Если предпочитаете нативный способ передачи данных в Journald, воспользуйтесь командой systemd-cat:

echo "Это второе тестовое сообщение" | systemd-cat

journalctl --since $(date +"%F") --grep 'второе тестовое'

Напоследок, посмотрим, какие сервисы задействуют рассмотренные выше сокеты с помощью команды lsof (list open files):

sudo lsof /run/systemd/journal/syslog /run/systemd/journal/dev-log

Обратите внимание, что для выполнения команды выше необходимы привилегированные права sudo.

Сегодня +1 термин в наш словарик линуксоида😉
Спасибо, что читаете. Всех благ!

Полезные материалы

Подписаться
Уведомить о
0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии