@ Карта сайта News Автора!

Bog BOS: syslog - сетевой системный журнал

apache inn MySQL nntpcache Cyrus IMAP exim Squid ssh syslog tacacs ProFTPD wu-ftpd xntpd

Последние изменения:
2024.11.22: sysadmin: systemd-journald (централизованное хранение)
2024.11.11: sysadmin: Linux: пространства имён
2024.11.06: sysadmin: настройка TCP/IP в Linux: виртуальный интерфейс и виртуальный мост
2024.10.25: sysadmin: Linux VFS, атрибуты, расширенные атрибуты, ACL

Последнее изменение файла: 2024.11.22
Скопировано с www.bog.pp.ru: 2024.11.23

Bog BOS: syslog - сетевой системный журнал

Протокол syslog и программные средства поддержки обеспечивают запись информации о событиях в системный журнал (журналы, системную консоль), а также передачу их на сервер журнализации по сети, сортировку и обработку в зависимости от источника и важности сообщений. В статье описывается протокол syslog, его реализация в Solaris и Linux (syslogd), Cisco IOS, а также вспомогательные средства: logrotate, logwatch. Первый стандарт (RFC 3164) был сформулирован через 10 лет практического использования.

Оглавление:

Архитектура системы журнализации

Компонентами системы являются генератор сообщений (устройство или процесс, device), протокол обмена, коллектор сообщений (collector, syslog server), релей (relay, принимает сообщения от одного или нескольких генераторов и передает одному или нескольким коллекторам или следующим релеям). Генератор (или релей при передаче) не знает является ли приемник релеем или коллектором, может передавать одно сообщение нескольким приемникам, может обрабатывать сообщение самостоятельно (например, записывая в файл).

Протокол syslog (RFC 3164) не содержит никаких средств защиты от подделок сообщений. Хуже того, использование протокола UDP позволяет злоумышленникам посылать сообщения от имени любого хоста. Локальная сеть должна быть защищена экраном (IOS ACL, iptables) от приема пакетов с поддельными локальными адресами (хотя это не помешает посылать поддельные сообщения изнутри локальной сети) и от приема пакетов снаружи на порт 514/udp. Известны случаи переполнения диска ложными сообщениями.

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

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

Если при настройке генератора сообщений указать неправильный адрес коллектора или релея, то никаких сообщений об ошибке не будет - сообщения будут удаляться (или записываться в чужой журнал ;).

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

RFC 3195 (2001 год) предлагает новый протокол над TCP (порт 601 - syslog-conn), обеспечивающий гарантированную доставку в правильной последовательности. Чудовищная смесь XML, команд и кодов возврата в стиле SMTP и заголовков MIME (BEEP), в которую заворачиваются сообщения стандартного формата syslog. Используется два режима - RAW (аналог нынешнего UDP протокола) и COOKED (сообщения структурированы по полям). BEEP позволяет обеспечить аутентификацию, целостность и конфиденциальность (SASL, TLS).

Проект RFC syslog-sign предлагает обеспечить аутентификацию, упорядоченность, целостность сообщений и обнаружение пропавших сообщений за счет генерации специальных сообщений, содержащих цифровую подпись (signature) блока предыдущих сообщений с сохранением стандартного протокола и формата syslog и использованием UDP. Используется SHA1, OpenPGP DSA.

В 2009 году вышел RFC 5424 (The Syslog Protocol, UTF-8, структурированные данные, время) и его дополнения:

В том же 2009 году вышли RFC, привязывающие syslog к SNMP:

В 2010 вышли RFC, усиливающие безопасность передачи:

В 2012 отчаявшись перевести всех на RFC 5424/RFC 5425 была описана сложившаяся практика использования TCP без TLS в виде RFC 6587.

Протокол syslog (RFC 3164)

Для приема сообщений используется порт 514/UDP. Рекомендуется также использовать исходный порт 514 для передачи сообщений. Сообщение представляет собой текстовую строку и не может иметь длину более 1024 байт, в противном случае его разрешается обрезать или даже выбрасывать. Даже неправильно сформированное сообщение, посланное на 514 порт, должно рассматриваться как сообщение syslog. Однако, если релей передает сообщение дальше, то он должен добавить к нему стандартные заголовки (при этом, возможно обрезав его до 1024 байт) - USER, NOTICE, свое локальное время и простое имя источника сообщения.

Сообщение начинается с поля PRI, которое в закодированном виде содержит информацию об источнике сообщения (facility) и уровне серьезности (Severity level) сообщения. Сразу за ним идёт заголовок (HEADER), содержащий время (TIMESTAMP), пробел, имя или IP адрес хоста в десятичной записи (HOSTNAME). За заголовком идёт пробел и тело сообщения (MSG), произвольный текст в US-ASCII (0x20 - 0x7e).

Источник сообщения кодируется числом от 0 до 23:

Уровень серьезности кодируется числом от 0 до 7:

Номер источника умножается на 8 и складывается с уровнем серьезности, получившееся число в ASCII заключается в угловые скобки и образует поле PRI.

Время (местное!) записывается в формате: Feb 13 21:12:06. Если номер дня является однозначным числом, то перед ним ставится дополнительный пробел (не 0!). Заметьте отсутствие года и зоны в дате, что необходимо учесть при долговременном хранении. Для того, чтобы время в сообщении было правильным, устройство должно быть синхронизовано (например, по NTP).

Имя хоста (простое по STD 13 (RFC 1034 и RFC 1035), не FQDN!) записывается так, как оно известно генератору сообщения. Если устройство имеет несколько интерфейсов с различными IP-адресами, то в качестве имени или адреса хоста может быть использовано любое из них.

Текст сообщения (MSG) обычно содержит этикетку (TAG), указывающую на программу или процесс, выдавшую это сообщение и тело сообщения (CONTENT) в ASCII-7. Этикетка может содержать латинские буквы и цифры. Начало тела сообщения определяется по первому специальному символу - обычно двоеточие или открывающая квадратная скобка. Например, Cisco IOS в качестве этикетки использует последовательный номер сообщения и двоеточие, а Unix - простое имя программы (тело сообщения начинается с номера процесса в квадратных скобках и двоеточия).

Релей не должен прверять достоверность заголовка (время и хост).

Релей должен добавлять отметку времени и имя хоста в пересылаемое сообщение, если не обнаружил отметку времени.

Релей должен добавлять PRI равный 13 и заголовок в пересылаемое сообщение, если не обнаружил PRI во входящем сообщении.2

Год рекомендуется заносить в содержимое сообщения.

FQDN и IP рекомендуется заносить в содержимое сообщения.

Протокол syslog-conn (RFC 3195)

RFC 3195 использует ту же архитектуру, что и RFC 3164 (источники, релеи, коллекторы) и фреймворк протоколов BEEP (Blocks Extensible Exchange Protocol) для описания асинхронных соединений (TCP/601, syslog-conn), профили:

Возможно использование алгоритма DNS SRV для автоматического получения адреса коллектора (сервис syslog, протокол tcp).

Протокол syslog (RFC 5424)

RFC 5424 замещает RFC 3164. Отдельно описывает формат сообщений, отдельно - механизм транспортировки. Стандарт поделён на слои:

В дополнение к генератору сообщений (originator), коллектору (collector) и релею (relay) определяются транспортный отправитель (transport sender) и транспортный получатель (transport receiver), которые передают (получают) сообщения в транспортный протокол.

Подтверждения не предусмотрены, исчезновения сообщения никто не заметит.

Защиты от повторного проигрывания не предусмотрена.

Защита цельности сообщений не предусмотрена, всё на откуп транспортому механизму.

Защита приватности не предусмотрена, всё на откуп транспортому механизму.

Защита от ошибок настройки, в частности, от циклов маршрутизации не предусмотрена.

Сообщение состоит из заголовка (HEADER), пробела, структурированных данных, пробела и тела сообщения (MSG).

Максимальная длина определяется транспортным механизмом, но не менее 480 октетов. Слишком длинные сообщения обрезаются или отбрасываются.

Заголовок состоит из

Отметка времени - "-" или "ГОД-МЕСЯЦ-ДЕНЬ"||"T"||"ЧАС:МИНУТА:СЕКУНДА"||"."||"МИКРОСЕКУНД"||"СМЕЩЕНИЕ" (где ГОД - 4 цифры, МЕСЯЦ - 2 цифры, ДЕНЬ - 2 цифры, микросекунды - до 6 цифр - опциональны, СМЕЩЕНИЕ - "Z" (UTC) или "{+|-}ЧАСОВ:МИНУТ").

Стуктурированные данные - "-" или последовательность SD элементов (без пробелов!), где SD элемент - это '[ИМЯ-SD ИМЯ-ПАРАМЕТРА="ЗНАЧЕНИЕ" ...]', где ЗНАЧЕНИЕ - это строка UTF-8. SD делятся на

Тело сообщения - BOM (0xEFBBBF) и строка UTF-8 или произвольная последовательность октетов (байт).

Транспортные протоколы описываются отдельными RFC:

RFC 5848 (syslog-sign) описывает возможность обеспечить аутентификацию, неизменяемость, устойвость к повторным передачам, упорядоченность и обнаружение пропавших сообщений за счёт посылки подписантом (signer) выделенных сообщений, содержащих блок подписи (Signature Block) для ранее посланных сообщений (Signature Group). Подписант может совпадать или не совпадать с генератором (отправителем) сообщений. Подписантов может быть много. Дополнительно посылается блок с сертификатами (Certificate Blocks), позволяющими проверить подписи. Используется механизм структурированных данных (элементы ssign и ssign-cert).

syslogd - "стандартная" реализация протокола syslog (RFC 3164) в Unix

syslogd осуществляет прием сообщений с порта 514/UDP и от местных источников (сокет /dev/log), их маршрутизацию в зависимости от источника сообщений и уровня серьезности. Позволяет выводить сообщения в журнал, выводить на консоль, на терминал, посылать на другой сервер. Вводится дополнительный тип источника MARK (регулярные отметки, info)

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

Параметры запуска:

Используемые файлы:

Реакция на сигналы:

Запускается с правами root. Не меняет права доступа к файлам. Если вынужден создавать файл, то делает его с правами 644. При необходимости ограничить доступ к журналу, соответствующий файл надо создать вручную (или поменять права доступа). Особые проблемы создает logrotate.

Настройка syslog.conf

Представляет собой набор правил маршрутизации сообщений. Комментарии начинаются с символа '#'. Обратная косая черта в конце строки означает продолжение правила на следующей строке. Каждое правило состоит из селектора и действия, которые разделяются табуляциями (в старых системах - Solaris 5) или пробелами (Linux). Получив сообщение для записи в журнал (от klogd, от локальной или удаленной программы), syslogd для каждого правила проверяет не подходит ли сообщение под шаблон, определяемый селектором. Если подходит, то выполняется указанное в правиле действие. Для одного сообщения м.б. выполнено произвольное количество действий (т.е. обработка сообщения не прекращается при первом успехе).

Селектор состоит из двух частей, разделенных точкой: источник сообщения и уровень серьезности. Прописные и строчные буквы не различаются. Можно также использовать числа (см. /usr/include/syslog.h). Кроме определенных в syslog(3) источников, можно указывать mark (регулярные временные метки), security (устаревший синоним для auth). Кроме определенных в syslog.h уровней серьезности можно использовать warn (синоним для warning), error (синоним для err), panic (синоним для emerg). Сообщения с уровнем, равным или выше указанного в селекторе, и источником, равным указанному в селекторе, считается подходящим. Звездочка перед точкой соответствует любому источнику (кроме daemon и syslog!), после точки - любому уровню. Слово none после точки - никакому уровню для данного источника. Можно указывать несколько источников в одном селекторе (через запятую). В этом случае приоритет можно указывать только для последнего источника. В одной строке можно указывать несколько селекторов через ';'. Семантика не ясна: если использовать позитивные селекторы, то выполняется логическое ИЛИ, если негативные (none и восклицательный знак), то логическое И.

В новом syslogd (linux) перед уровнем можно поставить знак равенства - селектору будут соответствовать только сообщения с указанным уровнем (но не с высшим); восклицательный знак - не будут соответствовать сообщения с уровнем равным или большим; восклицательный знак и равенство - не будут соответствовать сообщения с уровнем, равным указанному.

В качестве действия можно указывать:

Особенности syslogd в Linux

Включен в состав пакета sysklogd (RH 6.2: sysklogd-1.3.31-16, RH 7.0: sysklogd-1.3.33-8, RH 7.2: sysklogd-1.4.1-4). Также в этот пакет входит klogd.

Процедура запуска, остановки, перезапуска (syslogd и klogd): /etc/rc.d/init.d/syslog (символьные ссылки на нее из директорий /etc/rc.d/rc?.d/). Ключи запуска считывает из файла /etc/sysconfig/syslog (начиная с RH 7.2). Статус определяется по наличию файла /var/lock/subsys/syslog. Номер процесса хранится в /var/run/syslogd.pid.

Особенности syslogd в Solaris

При разборе файла конфигурации syslogd сравнивает адрес loghost (определяется в /etc/hosts, не через DNS) с адресом своего компьютера и при совпадении определяет переменную LOGHOST. После этого syslog.conf пропускается через макропроцесссор m4(1). В основном, это используется для того, чтобы один и тот же конфигурационный файл можно было использовать на клиентских и серверном (с точки зрения syslog) хостах.

Процедура запуска и остановки: /etc/init.d/syslog (ссылки на нее из директорий /etc/rc?.d). Номер процесса хранится в /etc/syslog.pid.

Использование syslog в Cisco IOS

Использование syslog в Cisco IOS.

klogd - журнализация сообщений ядра

klogd читает сообщения ядра (либо через /proc/kmsg, либо с помощью системных вызовов), определяет уровень, преобразует адреса команд в имена программ и передает сообщение syslogd.

Параметры запуска:

Уровни сообщений ядра (определяется по цифре в угловых скобках и преобразуется в уровень серьезности syslog, при выводе в файл не изменяется):

Реакция на сигналы:

Номер процесса хранится в /var/run/klogd.pid.

Слит в sysklog. Заменён в rsyslog.

logger - утилита записи в журнал

logger - запись сообщения в журнал из командной строки (sh, bash и др.). Входит в состав пакета util-linux. Параметры:

syslog API

Инициализация записи в журнал: openlog - указывается стандартный префикс, добавляемый ко всем последующим сообщениям (обычно имя программы, номер процесса в квадратных скобках и двоеточие); источник и опции. closelog - завершить запись в журнал. syslog - запись в журнал (указывается источник, уровень серьезности и формат строки как в printf).

logrotate или "что делать со старыми журналами?"

logrotate (версия 3.2-1/3.3.2-1/3.5.9/3.6.9/3.7.1/3.8.6) - борьба с растущими журналами: ротация (создание версий), сжатие, удаление и отправка по почте. Запускается ежедневно cron-ом (/etc/cron.daily/logrotate) и позволяет обрабатывать журналы, если они превысили указанный размер или с указанным временным интервалом. Позволяет обрабатывать не только журналы syslog, но и любых других программ. Параметры:

Конфигурационный файл определяет глобальные параметры (по одному на строке), задающие параметры по умолчанию для всех журналов. Для каждой серии обрабатываемых журналов задаются локальные параметры: указывается базовое имя файла, а затем в фигурных скобках локальные параметры по одному на строке. Имя файла может быть заключено в кавычки по правилам shell, если оно содержит пробелы и другие специальные символы. Можно указывать несколько имен файлов или шаблонов имен файлов через пробел (шаблоны также по правилам shell). Обработка каждой секции рассматривается как единое действие. Строки, начинающиеся с символа "#" являются комментариями. Параметры, указанные в следующем конфигурационном файле перекрывают значение параметров, указанных в предыдущем файле. Локальные параметры имеют приоритет над глобальными. Порядок файлов в конфигурационной директории не определен.

Параметры:

В поставке RH /etc/logrotate.conf описывает глобальные параметры и параметры для /var/log/wtmp и /var/log/lastlog и ссылается на директорию /etc/logrotate.d, в которую каждый пакет записывает локальные параметры для своих журналов.

Пример для центрального сервера syslog (текущий журнал в /var/log/syslog/current, архив в /var/log/syslog/old): 

/var/log/syslog/alltext {
    create
    daily
    dateext
    compress
    compresscmd /usr/bin/xz
    compressoptions "-T0"
    compressext .xz
    nodelaycompress
    olddir /var/log/syslog/old
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
    rotate 28
    sharedscripts
}
/var/log/syslog/current/host/*.log {
    weekly
    dateext
    compress
    compresscmd /usr/bin/xz
    compressoptions "-T0"
    compressext .xz
    nodelaycompress
    olddir /var/log/syslog/old/host
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
    rotate 4
    sharedscripts
}
/var/log/syslog/current/*.log {
    create
    weekly
    dateext
    compress
    compresscmd /usr/bin/xz
    compressoptions "-T0"
    compressext .xz
    nodelaycompress
    olddir /var/log/syslog/old/
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
    rotate 4
    sharedscripts
}
/var/log/syslog/current/backup/*.log {
    weekly
    dateext
    compress
    compresscmd /usr/bin/xz
    compressoptions "-T0"
    compressext .xz
    nodelaycompress
    olddir /var/log/syslog/old/backup
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
    rotate 4
    sharedscripts
}
...

logwatch или "как извлечь полезную информация из кучи мусора?"

logwatch представляет собой платформу (framework) для написания программ (называемых фильтрами) извлечения полезной информации из многочисленных, больших и разноформатных журналов (не только syslog) и формирования отчётов с указанной детализацией за указанный период времени, посылаемых по email.

Фильтры могут быть написаны на любом языке программирования, но автор пакета предпочитает perl 5.8 и новее. Фильтры должны быть написаны так, что читают данные с stdin и выводят результат на stdout. Перед вызовом фильтра устанавливаются переменные окружения: LOGWATCH_DATE_RANGE, LOGWATCH_DETAIL_LEVEL, LOGWATCH_TEMP_DIR, LOGWATCH_DEBUG. Основная программа также написана на perl: /usr/share/logwatch/scripts/logwatch.pl (ранее - до версии 7 - /etc/log.d/scripts/logwatch.pl, /etc/log.d/logwatch и /usr/sbin/logwatch и /etc/cron.daily/0logwatch (или /etc/cron.daily/00-logwatch) - это символьные ссылки на нее).

Каталог /usr/share/logwatch/default.conf/logfiles (ранее /etc/log.d/conf/logfiles/) содержит конфигурационные файлы групп журналов, в которых хранятся записи обслуживаемых сервисов. Каждая группа журналов описывается отдельным файлом имя-группы.conf, в котором задаются:

Каталог /usr/share/logwatch/dist.conf/logfiles/ содержит изменения настроек групп журналов для дистрибутива (пусто в RHEL7).

Каталог /etc/logwatch/conf/logfiles (ранее /etc/log.d/conf/logfiles/) содержит локальные изменения настроек групп журналов.

Каталог /usr/share/logwatch/default.conf/services/ (ранее /etc/log.d/conf/services/) содержит конфигурационные файлы сервисов, чьи записи в журналах logwatch будет обрабатывать. Каждый сервис описывается отдельным файлом имя-сервиса.conf, в котором задаются:

Каталог /usr/share/logwatch/dist.conf/services/ содержит изменения настроек сервисов для дистрибутива (пусто в RHEL7).

Каталог /etc/logwatch/conf/logfiles (ранее /etc/log.d/conf/logfiles/) содержит локальные изменения настроек сервисов.

Каталог /usr/share/logwatch/scripts/logfiles/ (ранее /etc/log.d/scripts/logfiles/) содержит фильтры обработки групп журналов: при обработке группы журналов все файлы в каталоге /usr/share/logwatch/scripts/logfiles/имя-группы используются как фильтры.

Каталог /usr/share/logwatch/scripts/services/ содержит фильтры обработки записей конкретных сервисов.

Каталог /usr/share/logwatch/scripts/shared/ содержит общие фильтры, используемые в конфигурационных файлах групп журналов:

Параметры по умолчанию хранятся в файле /usr/share/logwatch/default.conf/logwatch.conf (параметры от разработчика), /usr/share/logwatch/dist.conf (параметры дистрибутива, пусто в RHEL) и /etc/logwatch/conf/logwatch.conf (локальные параметры, ранее /etc/log.d/conf/logwatch.conf, /etc/log.d/logwatch.conf есть символьная ссылка на него):

В дополнение к logwatch.conf каждый из 3 каталогов содержит подкаталоги services и logfiles, которые позволяют задать параметры для конкретных групп файлов (имя-группы-журналов.conf) и сервисов (имя-сервиса.conf), а также ignore.conf (содержит регулярные выражения, описывающие строки, которые не должны появиться в отчётах) и override.conf.

Ключи запуска:

Основной способ использования состоит во включении файла 00-logwatch или 0logwatch (начинается с "00", чтобы выполняться до logrotate) в каталог /etc/cron.daily, что вызывает ежедневное выполнение logwatch с параметрами по умолчанию.

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

Местные особенности

Все журналы ведутся на одном компьютере (если есть параноидальные наклонности, то можно записывать журналы сразу на двух серверах).

Соответствие между формальным именем источника и реальным устройством или программой:

На сервере должен быть открыт экран для порта 514/udp (можно ограничить исходные адреса пакетов, но это поможет только от случайностей). Запуск syslogd (параметры в /etc/rc.d/init.d/syslog или /etc/sysconfig/syslog) должен быть с ключами "-r -m 0" (и еще "-x", если на этом же компьютере работает сервер DNS). Запуск klogd с ключами "-2 -c 1". Настройка syslog.conf:

На клиентских компьютерах настраиваем syslog так, чтобы все сообщения передавались на сервер syslog, сообщения об ошибках дублировались в /var/log/syslog, сообщения о критическом состоянии дублировались на консоль, терминалы пользователей. На компьютерах с linux также сбрасывать в локальный файл сообщения о загрузке (local7, boot.log). Запасной сервер syslog должен принимать сообщения критического уровня из сети и записывать их в файл (дырка в экране, ключ запуска "-r").

logrotate: хранить вечно, менять версии по возможности реже (ежемесячно, кроме squid), сбрасывать в отдельные директории (кроме squid) и сжимать (в отложенном режиме, кроме ftpd, linuxconf, sendfax), [ошибки и удаляемые файлы посылать мне]. Привести в соответствие параметры для файла syslog.

Настроить /etc/logwatch/scripts и /usr/share/logwatch/.

systemd-journald

Для сбора журналов в условиях systemd используется сервис systemd-journald, для просмотра и управления утилита journalctl. systemd-journald собирает сообщения ядра (kmsg), сообщения syslog, структурированные сообщения journal (sd_journal_print.3), сообщения сервисов (которые по умолчанию выводятся на stdout и stderr, настройки юнитов StandardOutput и StandardError), сообщения аудита ядра, вывод команды с использованием systemd-cat. Не более 4096 источников одновременно. Сообщения сервисов продолжают поступать в systemd-journald после "systemct restart" (дескрипторы файлов передаются), но прерывается после "systemctl stop". Может копировать сообщения на syslog, kmsg, консоль и терминалы (wall).

Журналы хранятся постоянно в /var/log/journal/, если каталог существует во время загрузки ("mkdir -p /var/log/journal; systemd-tmpfiles --create --prefix /var/log/journal": см. /usr/lib/tmpfiles.d/systemd.conf: chgrp systemd-journal /var/log/journal/; chmod o-rwx /var/log/journal; chmod g+s /var/log/journal, ...), или временно до первой перезагрузки в /run/log/journal/идентификатор-сервера/system.journal (tmpfs), выбор настраивается в /etc/systemd/journald.conf. Журналы ротируются, старые архивы удаляются. Доступен на чтение пользователям группы systemd-journal, adm и wheel с помощью ACL, главный каталог имеет set-group-ID. Для каждого зашедшего пользователя в /var/log/journal/ будет создан свой набор журналов (без права записи, право чтения также обеспечивается ACL). Журналы хранятся в двоичном формате, с индексами по всем полям (увеличивает объём в 4 раза относительно простого сжатого текста), возможно со сжатием (сжатие по полям, т.е. очень плохо - zstd жмёт пожатый .journal в 7.5 раз; разработчики в курсе; автор говорит, что сжатие также мешает использовать mmap; положить несжатое на zfs (разногласие между представлением SystemMaxUse и MaxFileSize)?; компактный (вдвое?) формат хранения в systemd 252 (SYSTEMD_JOURNAL_COMPACT, RHEL9); xz или LZ4 (zstd в версии 246; "journalctl --header | grep COMPRESS|uniq" выдаёт COMPRESSED-LZ4 на RHEL8 и COMPRESSED-XZ на RHEL7)) и защитой от модификации. Место в файле выделяется большими кусками (8 MiB?) и хранится с дырками (sparse). Имеются дополнительные форматы для экспорта ("journalctl -o export", текстовый, без индексов) и работы с JSON.

Настройки в /etc/systemd/journald.conf (/etc/systemd/journald.conf.d/*.conf, /run/systemd/journald.conf.d/*.conf, /usr/lib/systemd/journald.conf.d/*.conf), какой файл прочитали последним (в лексиграфическом порядке по именам файлов невзирая на имена каталогов), тот и прав. Формат файла аналогичен systemd, все настройки в секции "[Journal]", умолчания закоментированы:

Параметры командной строки ядра:

Обрабатываемые systemd-journald сигналы:

Юниты systemd сервиса systemd-journald:

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

При настройках по умолчанию запись в журнал (в новых системах - RHEL8 - и в syslog) прекращается при недостатке памяти. И бездарно тратися 4ГБ ОП. Переделываем /etc/systemd/journald.conf: 

Storage=persistent
Compress=64
SplitMode=none
RateLimitBurst=20000
SystemMaxUse=1G
и перезапуск (журнал частично переписывается из /run/log/journal в /var/log/journal) 
mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal

systemctl stop rsyslog
systemctl restart systemd-journald
systemctl start rsyslog

Утилита systemd-cat позволяет записать свой входной поток (stdin) или вывод (stdout и stderr) указанной команды в журнал. Ключи:

Утилита systemd-journal-gatewayd и построенный на её основе сервис (systemd-journal-gatewayd.socket слушает порт 19531, используется в sockets.target; юнит systemd-journal-gatewayd требует systemd-journal-gatewayd.socket, запускает systemd-journal-gatewayd) реализует HTTP/HTTPS сервер для сообщений журнала, обслуживаемые запросы: /browse, /entries[?опция1&опция2=значение...] (опции - follow, boot, ключ=шаблон), /machine, /fields/имя_поля. Также может быть использован для передачи сообщений журнала по сети (systemd-journal-remote, application/vnd.fdo.journal). Ключи:

Утилита systemd-journal-remote и построенный на её основе сервис (systemd-journal-remote.socket слушает порт 19532, используется в sockets.target; юнит systemd-journal-remote.service требует systemd-journal-remote.socket, PrivateNetwork=yes (прощай DNS?), запускает systemd-journal-remote --listen-https=-3 --output=/var/log/journal/remote/, системный журнал сразу начинает писаться в /var/log/journal) позволяет принимать сообщения журнала возможно из нескольких потоков в формате экспорта по HTTP[S] от systemd-journal-gatewayd или systemd-journal-upload или в "сыром" формате от ? и записывать их в журнал. systemd-journal-remote может работать в режиме запроса (имена файлов или '-' задаются в качестве позиционных параметров) или режиме ожидания. Ключи:

Настройки в /etc/systemd/journal-remote.conf (/etc/systemd/journal-temote.conf.d/*.conf, /run/systemd/journal-temote.conf.d/*.conf, /usr/lib/systemd/journal-remote.conf.d/*.conf), какой файл прочитали последним (в лексиграфическом порядке по именам файлов невзирая на имена каталогов), тот и прав. Формат файла аналогичен systemd, все настройки в секции "[Remote]", умолчания закоментированы:

Запуск 2 серверов централизованного сбора журналов: 

lvcreate --name remotelogs -L 100G SSD
# super_super2 не даст увеличивать размер без размонтирования
mkfs.ext4 -L remotelogs -v -E nodiscard,lazy_itable_init=1 -O 64bit,dir_index,extent,ext_attr,filetype,flex_bg,has_journal,huge_file,large_file,metadata_csum,metadata_csum_seed,sparse_super,uninit_bg /dev/SSD/remotelogs
mkdir /var/log/remotelogs
в /etc/fstab
  LABEL=remotelogs        /var/log/remotelogs     ext4    data=ordered,nodiratime,relatime,journal_checksum,delalloc,rw,nosuid,nodev,noexec,auto,nouser,nodiscard 1 2
systemctl daemon-reload
mount /var/log/remotelogs
mkdir /var/log/remotelogs/{journald,syslog}
chown systemd-journal-remote:systemd-journal-remote /var/log/remotelogs/journald

vim /etc/systemd/journald.conf
Storage=volatile
Compress=64
RateLimitBurst=20000
SystemMaxUse=100G
SystemMaxFileSize=1000M
SystemMaxFiles=100000
MaxRetentionSec=1y

systemctl restart systemd-journald.service
cp -a /usr/lib/systemd/system/systemd-journal-remote.service /etc/systemd/system/systemd-journal-remote.service

vim /etc/systemd/system/systemd-journal-remote.service
[Service]
ExecStart=/usr/lib/systemd/systemd-journal-remote --listen-http=-3 --output=/var/log/remotelogs/journald --split-mode=none --compress=yes
LogsDirectory=remotelogs/journald

systemctl daemon-reload
systemctl start systemd-journal-remote
systemctl status systemd-journal-remote
systemctl enable systemd-journal-remote

смотреть с помощью
journalctl -D /var/log/remotelogs/journald [_HOSTNAME=полное-доменное-имя] ...

Файлы журнала занимают очень много места (в systemd v252 уменьшено вдвое). Кладём их в файловую систему со сжатием (): 

mkdir /var/log/remotelogs
zfs create bigpool/remotelogs -v \
-o aclinherit=passthrough -o aclmode=passthrough -o acltype=posix -o xattr=sa \
-o atime=on -o relatime=on \
-o checksum=sha256 \
-o compression=zstd-12 \
-o dedup=off \
-o devices=off \
-o dnodesize=legacy \
-o overlay=off \
-o primarycache=metadata -o secondarycache=metadata \
-o recordsize=16777216 \
-o redundant_metadata=none \
-o sharenfs=off -o sharesmb=off \
-o snapdir=visible \
-o special_small_blocks=0 \
-o sync=disabled -o logbias=throughput \
-o mountpoint=/var/log/remotelogs

mkdir /var/log/remotelogs/{syslog,journald}
chown systemd-journal-remote:systemd-journal-remote /var/log/remotelogs/journald

vim /etc/systemd/journald.conf
Storage=volatile
Compress=64
SplitMode=none
RateLimitBurst=20000
SystemMaxUse=1000G
SystemMaxFileSize=1000M
SystemMaxFiles=100000
MaxRetentionSec=1y

systemctl restart systemd-journald.service # копировать старые данные с persistent в volatile не умеет
cp -a /usr/lib/systemd/system/systemd-journal-remote.service /etc/systemd/system/systemd-journal-remote.service

vim /etc/systemd/system/systemd-journal-remote.service
[Unit]
Requires=var-log-remotelogs.mount
...

[Service]
...
ExecStart=/usr/lib/systemd/systemd-journal-remote --listen-http=-3 --output=/var/log/remotelogs/journald/remote.journal --split-mode=none --compress=no
LogsDirectory=remotelogs/journald
...

systemctl daemon-reload
systemctl start systemd-journal-remote
systemctl status systemd-journal-remote
systemctl enable systemd-journal-remote

смотреть с помощью
journalctl -D /var/log/remotelogs/journald [_HOSTNAME=полное-доменное-имя] ...

сжимает около 10 раз, но читается невыносимо медленно, нужен
-o primarycache=all

Утилита systemd-journal-upload и построенный на её основе сервис (--save-state, пакет systemd-journal-gateway в RHEL7 или пакет systemd-journal-remote в RHEL8) позволяет передавать сообщения читаемых журналов в формате экспорта по HTTP[S] (принимающая сторона - systemd-journal-remote). Ключи:

Настройки в /etc/systemd/journal-upload.conf (/etc/systemd/journal-upload.conf.d/*.conf, /run/systemd/journal-upload.conf.d/*.conf, /usr/lib/systemd/journal-upload.conf.d/*.conf), какой файл прочитали последним (в лексиграфическом порядке по именам файлов невзирая на имена каталогов), тот и прав. Формат файла аналогичен systemd, все настройки в секции "[Upload]", умолчания закоментированы:

Запуск очередного клиента: 

cp -a /usr/lib/systemd/system/systemd-journal-upload.service /etc/systemd/system/systemd-journal-upload1.service
cp -a /usr/lib/systemd/system/systemd-journal-upload.service /etc/systemd/system/systemd-journal-upload2.service
vim /etc/systemd/system/systemd-journal-upload1.service
ExecStart=/usr/lib/systemd/systemd-journal-upload --save-state=/var/lib/systemd/journal-upload/state1 --url=http://journal1 --directory=/var/log/journal

vim /etc/systemd/system/systemd-journal-upload2.service
ExecStart=/usr/lib/systemd/systemd-journal-upload --save-state=/var/lib/systemd/journal-upload/state2 --url=http://journal2 --directory=/var/log/journal

mkdir -p /var/lib/systemd/journal-upload
chown systemd-journal-upload:systemd-journal-upload /var/lib/systemd/journal-upload

systemctl daemon-reload
systemctl start systemd-journal-upload1
systemctl status systemd-journal-upload1
systemctl start systemd-journal-upload2
systemctl status systemd-journal-upload2
systemctl enable systemd-journal-upload1
systemctl enable systemd-journal-upload2

Утилита journalctl используется для просмотра и управления журналом. По умолчанию выводит все записи журнала с использованием less, важность выделяется цветом, яркостью и жирностью. Аргументы утилиты используются для фильтрации вывода (журнал индексирован, что позволяет делать это быстро), каждый параметр задаёт значение метаданных в виде "имя=значение", по умолчанию используется операция ИЛИ для одинаковых метаданных, операция И для разных метаданных, символ '+' используется для явного задания операции ИЛИ. Указание абсолютного имени файла позволяет сократить написание фильтров для _EXE=, _COMM=, _KERNEL_DEVICE=. Ключи:

Утилита journalctl использует переменные окружения:

journald и rsyslog мешаются при доступе к файлам, поэтому перед изменением настроек journald необходимо остановить rsyslog, а после - запустить вновь. При наличии каталога /var/log/journal rsyslog читает из него, невзирая на настройки journald.

Ссылки
@ Карта сайта News Автора!

Bog BOS: syslog - сетевой системный журнал

apache inn MySQL nntpcache Cyrus IMAP exim Squid ssh syslog tacacs ProFTPD wu-ftpd xntpd

Последние изменения:
2024.11.22: sysadmin: systemd-journald (централизованное хранение)
2024.11.11: sysadmin: Linux: пространства имён
2024.11.06: sysadmin: настройка TCP/IP в Linux: виртуальный интерфейс и виртуальный мост
2024.10.25: sysadmin: Linux VFS, атрибуты, расширенные атрибуты, ACL
Copyright © 1996-2024 Sergey E. Bogomolov; www.bog.pp.ru