了解 Linux 中的日志记录

Question

据我了解，Linux 内核会记录到/proc/kmsg文件（主要是与硬件相关的消息）和/dev/log套接字吗？还有其他地方吗？其他应用程序是否也能够向/proc/kmsg或发送消息/dev/log？最后但并非最不重要的，我是正确的，这是系统日志守护程序（rsyslog现在，syslog-ng的），该检查的消息来自这两个地方，然后分发到那些像各种文件/var/log/messages或者/var/log/kern.log甚至是中央系统日志服务器？

Answer 1

简单地说，它或多或少是这样的：

内核将消息（使用该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)-ed 消息可能最终被写入其他套接字， fi 到/var/named/dev/log。当然，对于发送这些日志的应用程序并syslogd(8)就这些套接字的位置达成一致是必不可少的。由于这些原因，syslogd(8)可以配置为侦听除标准之外的其他套接字/dev/log。

最后，该syslog协议只是一个数据报协议。没有什么可以阻止应用程序将系统日志数据报发送到任何 UNIX 域套接字（前提是它的凭据允许它打开套接字），完全绕过该syslog(3)功能libc。如果数据报格式正确，则syslogd(8)可以使用它们，就像消息是通过syslog(3).

当然，以上仅涵盖“经典”测井理论。其他守护进程（如你提到的rsyslogand syslog-ng）可以替换普通的syslogd(8)，并做各种漂亮的事情，比如通过加密的 TCP 连接向远程主机发送消息，提供高分辨率的时间戳等等。还有systemd，它正在慢慢吞噬 Linux 的 UNIX 部分。 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.

Answer 2

正如作者所说，另一个答案解释了 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首先尝试。）应用程序当然可以有自己的代码来直接执行此操作。毕竟，库函数只是在应用程序自己的进程上下文中执行的代码（用于打开、连接、写入和关闭套接字）。

如果正在侦听机器上的AF_INET/AF_INET6数据报套接字，应用程序还可以通过 UDP 将 RFC 5424 消息发送到本地 RFC 5426 服务器。

由于过去 20 年来自 daemontools 世界的压力，许多守护进程支持在不使用 GNU syslog()C 库函数或 UDP 套接字的模式下运行，而只是将他们的日志数据吐出到标准错误中普通的Unix时尚。

使用 nosh 和 daemontools 系列进行日志管理

使用 daemontools 系列工具集，日志记录具有很大的灵活性。但总的来说，整个家族的想法是每个“主要”守护进程都有一个关联的“记录”守护进程。“主”守护进程就像非守护进程一样工作，并将它们的日志消息写入标准错误（或标准输出），服务管理子系统安排通过管道连接（它保持打开状态，以便日志数据不会丢失）服务重新启动）到“日志记录”守护程序的标准输入。

所有“记录”守护进程都运行一个记录某处的程序。通常，该程序类似于multilog或cyclog从其标准输入读取并在严格限制大小、自动旋转、独占写入的目录中写入（纳秒时间戳）日志文件。一般来说，这些守护进程也都在个人专用的非特权用户帐户的支持下运行。

所以最终会得到一个很大程度上分布式的日志系统，每个服务的日志数据都是单独处理的。

一个可以运行类似klogd或syslogd或rsyslogd下一个daemontools的家庭服务管理。但是 daemontools 世界多年前就意识到，带有“日志记录”守护程序的服务管理结构非常适合以更简单的方式做事。无需将所有日志流散布到一个巨大的混搭中，解析日志数据，然后将流散开以分离日志文件；然后（在某些情况下）在侧面固定一个不可靠的外部原木旋转机构。daemontools-family 结构作为其标准日志管理的一部分已经进行了日志轮换、日志文件写入和流分离。

此外：使用所有服务通用的工具删除权限的链式加载模型意味着日志程序不需要超级用户权限；UCSPI 模型意味着他们只需要关心诸如流与数据报传输之类的差异。

nosh 工具集就是一个例子。虽然可以rsyslogd在它下运行，但开箱即用，只需/run/log以旧方式管理内核、UDP 日志输入；它也提供了记录这些东西更多的“本土daemontools的”方式：

• 一klogd，从读取的服务/proc/kmsg，只是该日志流写入到其标准错误。这是由一个名为 的简单程序完成的klog-read。相关的日志守护进程将其标准输入上的日志流提供给/var/log/sv/klogd日志目录。
• 一local-syslog-read，从读取数据报服务/dev/log（/run/log在BSD系统），并简单地认为日志流写入到其标准错误。这是由名为 的程序完成的syslog-read。相关的日志守护进程将其标准输入上的日志流提供给/var/log/sv/local-syslog-read日志目录。
• 一个udp-syslog-read服务的UDP的syslog端口上侦听，读它发送给它的，只是该日志流写入到其标准错误。再次，该程序是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内核日志数据。
• 它从 GNU C 库的函数中读取应用程序日志数据/dev/log（指向 的符号链接/run/systemd/journal/dev-log）syslog()。
• 它在AF_LOCAL流套接字上侦听/run/systemd/journal/stdout来自 systemd 管理的服务的日志数据。
• 它在AF_LOCAL数据报套接字上侦听/run/systemd/journal/socket来自使用 systemd 特定日志协议（即sd_journal_sendv()等人）的程序的日志数据。
• 它将所有这些混合在一起。
• 它写入一组系统范围和每个用户的日志文件，在/run/log/journal/或 中/var/log/journal/。
• 如果它可以（作为客户端）连接到AF_LOCAL数据报套接字，/run/systemd/journal/syslog它会在那里写入日志数据，如果配置了转发到 syslog。
• 如果配置，它使用可写/dev/kmsg机制将日志数据写入内核缓冲区。
• 如果已配置，它还会将日志数据写入终端和控制台设备。

如果此程序崩溃或服务停止，系统范围内就会发生不好的事情。

systemd 本身安排将（某些）服务的标准输出和错误附加到/run/systemd/journal/stdout套接字。因此，以正常方式记录到标准错误的守护进程将其输出发送到日志。

这完全取代了 klogd、syslogd、syslog-ng 和 rsyslogd。

这些现在需要特定于 systemd。在 systemd 系统上，它们不会成为/dev/log. 相反，他们采取以下两种方法之一：

• 它们成为 的服务器端/run/systemd/journal/syslog，它（如果你还记得的话）systemd-journald尝试连接和写入日志数据。几年前，人们会配置 rsyslogd 的imuxsock输入法来执行此操作。
• 它们直接从 systemd 日志中读取，使用特定于 systemd 的库，该库了解二进制日志格式，并且可以监视日志文件和目录以查找添加的新条目。现在，人们配置 rsyslogd 的imjournal输入法来做到这一点。