☰

为什么默认 nginx 访问日志显示 access.log > /dev/stdout

tag-icon • tag-icon linux nginx logging
为什么默认 nginx 访问日志显示 access.log > /dev/stdout

我在本地运行 nginx。无需向 添加任何显式日志配置，在 下为nginx.conf添加了符号链接：/var/log/nginxaccess.log

/var/log/nginx # ls -l

lrwxrwxrwx    1 root     root            11 Sep  9  2021 access.log -> /dev/stdout

如果我添加一个明确的配置，如下nginx.conf所示：

http {

    access_log /var/log/nginx/access2.log;

然后我得到一个常规日志文件/var/log/nginx并且日志记录工作正常：

-rw-r--r--    1 root     root         11934 Aug  4 00:57 access2.log

我的理解是，这/var/log/nginx是 nginx 日志的默认输出目标。链接到 的目的是什么/dev/stdout？我是否遗漏了日志数据应该如何持久化的内容？记录到 syslog 的描述如下 -https://docs.nginx.com/nginx/admin-guide/monitoring/logging/，并有助于将日志数据发送到不同的源以进行持久保存。/dev/stdout默认日志记录的符号链接的用途是什么？为什么需要它？

我知道它/dev/stdout充当输出设备，但我不完全理解这里发生了什么。access.log符号链接是否只是某种允许通过/dev/stdout设备输出日志的机制，然后需要通过 nginx 配置提供实际的日志定义？

答案1

每个软件都不同，但所有软件都会或至少应该能够生成某种形式的诊断日志。由于服务管理软件init（例如 systemd）和码头工人无法轻松提供最佳界面每一个这类软件，你经常会将其简化为最小公分母：每个程序都以 stdin/stdout/stderr 句柄开头已分配索引 0/1/2。在大多数系统中，以下该公约，人们可以通过某种方式知道一个程序期望打开要使用的文件路径/dev/stdout（或更详细地说/proc/self/fd/1：），它将获取索引 1 处已有的内容 - 启动时配备的标准输出句柄。

这似乎就是这里发生的事情。Docker 创建了一些接口，它想在其中接受或存储您的日志。在最简单的情况下，它会打开一个文件 - 而不是将该文件放在里面容器，它只需在决定使用哪个 stdout 启动容器时指定打开的句柄。现在 Nginx 在其 stdout 槽中有了该句柄，所缺少的只是澄清它应该在那里写入。当 Nginx 期望文件路径，而不是句柄索引，稍微特殊的路径进来，这样当 Nginx 像处理任何其他常规文件一样处理该路径时，它会返回其启动时的内容。这样，docker 不需要了解 Nginx 内部，Nginx 也不需要了解 docker 内部。它们可以做最基本的 unix 事情之一：将文本行写入文件。

现在这并不理想，因为Nginx做说话更具表现力语言而不仅仅是文件，这样您就可以将其日志立即划分为设施和严重性。我猜想文本行对于该容器的目的来说已经足够好了 - 或者更可靠。

相关内容