Понимать ведение журнала в Linux

Как я понимаю, ядро ​​Linux регистрирует в /proc/kmsgфайл (в основном аппаратные сообщения) и /dev/logсокет? Где-нибудь еще? Могут ли другие приложения также отправлять сообщения /proc/kmsgили /dev/log? И последнее , но не в последнюю очередь, я правильно , что это системный журнал демон ( Rsyslog , Syslog-нг ) , который проверяет сообщения из этих двух мест , а затем распределяет их в различные файлы , таких как /var/log/messagesили /var/log/kern.logили даже центральный сервер системного журнала?

Упрощенно, это выглядит примерно так:

Ядро записывает сообщения (используя printk()функцию) в кольцевой буфер в пространстве ядра. Эти сообщения доступны для приложений пользовательского пространства двумя способами: через /proc/kmsgфайл (при условии, что /procон смонтирован) и через sys_syslogсистемный вызов.

Есть два основных приложения, которые читают (и в некоторой степени могут контролировать) кольцевой буфер ядра: dmesg(1)и klogd(8). Первый предназначен для запуска по требованию пользователей для печати содержимого кольцевого буфера. Последний - это демон, который читает сообщения /proc/kmsg(или звонки sys_syslog, если они /procне смонтированы) и отправляет их syslogd(8)на консоль или на нее. Это охватывает сторону ядра.

В пользовательском пространстве есть syslogd(8). Это демон, который прослушивает несколько сокетов домена UNIX (в основном /dev/log, но могут быть также настроены и другие), и, опционально, UDP-порт 514 для сообщений. Он также получает сообщения от klogd(8)( syslogd(8)не волнует /proc/kmsg). Затем он записывает эти сообщения в некоторые файлы /logили в именованные каналы или отправляет их на некоторые удаленные хосты (через syslogпротокол, на UDP-порт 514), как настроено в /etc/syslog.conf.

Приложения пользовательского пространства обычно используют эту libcфункцию syslog(3)для регистрации сообщений. libcотправляет эти сообщения в сокет домена UNIX /dev/log(где они читаются syslogd(8)), но если приложение chroot(2)выключено, сообщения могут в конечном итоге быть записаны в другие сокеты, например /var/named/dev/log. Разумеется, важно, чтобы приложения, отправляющие эти журналы, syslogd(8)согласовывали расположение этих сокетов. По этой причине syslogd(8)можно настроить прослушивание дополнительных сокетов помимо стандарта /dev/log.

Наконец, syslogпротокол - это просто протокол дейтаграмм. Ничто не мешает приложению отправлять дейтаграммы системного журнала в любой сокет домена UNIX (при условии, что его учетные данные позволяют ему открывать сокет), полностью обходя syslog(3)функцию libc. Если датаграммы правильно отформатированы, syslogd(8)можете использовать их, как если бы сообщения были отправлены syslog(3).

Конечно, вышесказанное охватывает только «классическую» теорию лесозаготовок. Другие демоны (такие как rsyslogи syslog-ng, как вы упомянули) могут заменить обычные syslogd(8)и выполнять всевозможные изящные операции, такие как отправка сообщений на удаленные хосты через зашифрованные соединения TCP, предоставление временных меток с высоким разрешением и т. Д. И есть также systemd, что медленно фагоцитирует UNIX часть Linux. systemdимеет свои собственные механизмы регистрации, но эту историю должен рассказать кто-то другой. :)

Отличия от мира * BSD:

В * BSD его нет klogd(8)и /procне существует (в OpenBSD), или он в основном устарел (в FreeBSD и NetBSD). syslogd(8)читает сообщения ядра с символьного устройства /dev/klogи dmesg(1)использует /dev/kmemдля декодирования имен ядра. Только OpenBSD имеет /dev/log. FreeBSD использует два сокета домена UNIX /var/run/logи var/rub/logprivвместо этого, и NetBSD имеет /var/run/log.

Другой ответ объясняет, как говорит его автор, «классическое ведение журнала» в Linux. В наши дни во многих системах это не так.

Ядро

Механизмы ядра изменились.

Ядро генерирует вывод в буфер в памяти. Прикладные программы могут получить доступ к этому двумя способами. Подсистема журналирования обычно обращается к ней как псевдо-FIFO с именем /proc/kmsg. Этот источник информации журнала не может быть полезен для читателей журнала, потому что он доступен для чтения. Если несколько процессов совместно используют его, каждый из них получает только часть потока данных журнала ядра. Это также только для чтения.

Другой способ получить к нему доступ - это новое /dev/kmsgсимвольное устройство. Это интерфейс чтения-записи, который может использоваться несколькими клиентскими процессами. Если несколько процессов совместно используют его, все они читают один и тот же полный поток данных, не затронутый друг другом. Если они открывают его для доступа на запись, они также могут вставлять сообщения в поток журнала ядра, как если бы они были сгенерированы ядром.

/proc/kmsgи /dev/kmsgпредоставить данные журнала в не RFC-5424 форме.

Приложения

Приложения изменились.

Функция библиотеки GNU C syslog()в основном пытается подключиться к AF_LOCALсокету дейтаграммы с именем /dev/logи записать в него записи журнала. (Функция библиотеки BSD C в syslog()настоящее время использует в /var/run/logкачестве имени сокета и пытается /var/run/logprivсначала.) Конечно, приложения могут иметь свой собственный код, чтобы сделать это напрямую. Функция библиотеки - это всего лишь код (для открытия, подключения, записи и закрытия сокета), в конце концов выполняющийся в собственном контексте процесса приложения.

Приложения также могут отправлять сообщения RFC 5424 через UDP на локальный сервер RFC 5426, если он прослушивает сокет AF_INET/ AF_INET6дейтаграммы на машине.

Благодаря давлению со стороны мира daemontools за последние два десятилетия, многие демоны поддерживают работу в режиме, в котором они не используют syslog()библиотечную функцию GNU C или UDP-сокеты, а просто выкладывают свои данные журнала в стандартную ошибку в обычная мода Unix.

управление журналами с nosh и семьей daemontools в целом

Семейство наборов инструментов daemontools обеспечивает большую гибкость ведения журналов. Но в целом по всей семье идея заключается в том, что у каждого «главного» демона есть связанный «протоколирующий» демон. «главные» демоны работают точно так же, как не-демонные процессы, и записывают свои сообщения журнала в стандартную ошибку (или стандартный вывод), которую подсистема управления службами организует для подключения через канал (который она остается открытой, чтобы данные журнала не терялись перезапуск службы) к стандартному вводу демона «logging».

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

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

Один может запустить что - то подобное klogdили syslogdили rsyslogdпод руководством службы Daemontools семьи. Но мир daemontools осознал много лет назад, что структура управления сервисами с «ведением журнала» вполне пригодна для более простых действий. Нет необходимости разделять все потоки журналов в одну гигантскую мешанину, анализировать данные журналов, а затем направлять потоки обратно в отдельные файлы журналов; а затем (в некоторых случаях) прикрутите ненадежный механизм вращения внешнего бревна сбоку. Структура семейства daemontools как часть стандартного управления журналами уже выполняет ротацию журналов, запись файлов журналов и разделение потоков.

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

Набор инструментов Nosh иллюстрирует это. В то время как под ним можно запускать « rsyslogdиз коробки» и просто управлять ядром /run/logи вводом журнала UDP по-старому; он также предоставляет больше "родных" daemontools способов регистрации этих вещей:

• klogdслужба , которая читает /proc/kmsgи пишет просто , что поток журнала в стандартной ошибки. Это делается с помощью простой программы с именем klog-read. Связанный демон ведения журнала подает поток журнала с его стандартного ввода в /var/log/sv/klogdкаталог журнала.
• local-syslog-readслужба , которая читает датаграммы /dev/log( /run/logна BSDs) и просто пишет , что поток журнала в стандартной ошибки. Это делается с помощью программы с именем syslog-read. Связанный демон ведения журнала подает поток журнала с его стандартного ввода в /var/log/sv/local-syslog-readкаталог журнала.
• udp-syslog-readсервис , который прослушивает порт UDP системного журнала, читает то , что он отправляется к нему и просто записывает поток , что лог его стандартной ошибки. Опять программа есть syslog-read. Связанный демон ведения журнала подает поток журнала с его стандартного ввода в /var/log/sv/udp-syslog-readкаталог журнала.
• (на BSD) local-priv-syslog-readслужба, которая читает дейтаграммы /run/logprivи просто записывает этот поток журнала в свою стандартную ошибку. Опять программа есть syslog-read. Связанный демон ведения журнала подает поток журнала с его стандартного ввода в /var/log/sv/local-priv-syslog-readкаталог журнала.

В набор инструментов также входит export-to-rsyslogинструмент, который может отслеживать один или несколько каталогов журналов (используя систему неинтрузивных курсоров журналов ) и отправлять новые записи в форме RFC 5424 по сети на назначенный сервер RFC 5426.

управление журналом с помощью systemd

systemd имеет единую монолитную программу управления журналами systemd-journald. Это работает как сервис, управляемый systemd.

• Он читает /dev/kmsgданные журнала ядра.
• Он читает /dev/log(символическую ссылку /run/systemd/journal/dev-log) для каротажных данных приложения из библиотеки GNU C в syslog()функции.
• Он прослушивает AF_LOCALпотоковый сокет at /run/systemd/journal/stdoutдля данных журнала, поступающих от управляемых системой сервисов.
• Он прослушивает AF_LOCALсокет дейтаграммы at /run/systemd/journal/socketдля данных журнала, поступающих от программ, которые используют протокол журнала, специфичный для systemd (т. sd_journal_sendv()Е. И др.).
• Это смешивает все это вместе.
• Он записывает в набор общесистемных и пользовательских файлов журнала, в /run/log/journal/или /var/log/journal/.
• Если он может подключиться (как клиент) к AF_LOCALсокету дейтаграммы, /run/systemd/journal/syslogон записывает туда данные журнала, если настроена пересылка в системный журнал.
• Если настроено, он записывает данные журнала в буфер ядра, используя /dev/kmsgмеханизм записи .
• Если он настроен, он записывает данные журнала в терминалы и на консольное устройство.

Плохие вещи случаются во всей системе, если эта программа падает или служба останавливается.

Сам systemd организует для стандартных выводов и ошибок (некоторых) сервисов, которые будут подключены к /run/systemd/journal/stdoutсокету. Таким образом, демонам, которые регистрируют стандартную ошибку в обычном порядке, отправляется вывод в журнал.

Это полностью заменяет klogd, syslogd, syslog-ng и rsyslogd.

Теперь они должны быть специфичными для systemd. В системе systemd они не становятся серверной частью /dev/log. Вместо этого они используют один из двух подходов:

• Они становятся серверной частью /run/systemd/journal/syslog, к которой (если вы помните) systemd-journaldпытается подключиться и записать данные журнала. Пару лет назад можно было бы настроить метод imuxsockввода rsyslogd для этого.
• Они читают напрямую из журнала systemd, используя специфичную для systemd библиотеку, которая понимает двоичный формат журнала и может отслеживать файлы журнала и каталог для добавления новых записей. В настоящее время для этого нужно настроить метод imjournalввода rsyslogd .