通过FIFO登录，然后重定向到文件？

我有一个必须记录每个事务的应用程序。每条日志消息都会被刷新，因为我们需要记录导致崩溃的事件。我和我的同事很好奇如何在确保日志消息离开进程的同时实现缓冲的性能效果。

我们想到的是：

• 创建应用程序可以写入的FIFO，并且
• 通过重定向该FIFO的内容到常规文件cat。

也就是说，通常是：

app --logfile logfile.txt

就是现在：

mkfifo logfifo
cat logfifo &> logfile.txt &
app --logfile logfifo

这种方法有什么陷阱吗？在我们测试它时它可以工作，但是我们要绝对确保即使原始应用程序崩溃了，消息也能找到到达重定向文件的方式。

（我们没有应用程序的源代码，因此，编程解决方案是不可能的。此外，应用程序不会写入stdout，因此直接用管道传输到其他命令syslog是不可能的。因此，这是不可能的）

更新：我添加了赏金。接受的答案将不会涉及logger的原因很简单，logger是不是我所问。正如最初的问题所述，我只在使用FIFO时才发现问题。

请注意，在写入的数量可能超过读出的数量的编程中，通常需要fifo。

因此，fifo不会像您预期的那样完全顺畅地工作，但是会在引入另一个问题的同时解决您的主要问题。

有三个可能的警告。

1. 如果初始化时没有任何内容读取另一端，则无限期地禁止写入fifo。
2. fifo具有64K的固定宽度，如果该点被缓冲区填充，则该宽度将被阻止，直到读写器追上来之前，将进一步阻止写操作。
3. 如果读取器死亡或退出，则管道写入器将被SIGPIPE杀死。

这意味着您的问题（在非缓冲写入时模拟缓冲I / O）将得到解决。那是因为对FIFO的新“限制”实际上将成为任何实用程序将管道中的内容写入磁盘的速度（大概将被缓冲的I / O）。

但是，编写器将依赖您的日志读取器来运行。如果读者突然停止阅读，作家将被阻止。如果读取器突然退出（假设您的目标磁盘空间不足），则写入器将执行SIGPIPE并可能退出。

还要提到的另一点是，如果服务器紧急情况和内核停止响应，则可能会丢失该缓冲区中多达64k的数据。

解决此问题的另一种方法是将日志写入tmpfs（在Linux上为/ dev / shm），然后将输出拖到固定的磁盘位置。这样做对内存分配的限制较少（不是64K，通常是2G！），但如果编写器没有动态方式重新打开日志文件（您必须定期从tmpfs中清除日志），则可能对您不起作用。如果服务器在此方法中出现紧急情况，则可能会丢失更多数据。

mkfifo logfifo
cat logfifo &> logfile.txt &
app --logfile logfifo

当您的cat logfifo进程死亡，有人无意中将其杀死或有人将其意外指向错误的位置时，会发生什么？

我的经验是，app将很快阻塞并挂起。我已经在Tomcat，Apache和一些小型的自制应用程序中进行了尝试，但遇到了同样的问题。我从来没有做过很长的调查，因为logger或者简单的I / O重定向可以实现我想要的功能。我通常不需要日志记录完整性，而这正是您要追求的。正如您所说，您不需要记录器。

在Linux非阻塞fifo（按需记录）上对此问题进行了一些讨论。

您的选择受到应用程序的相当有限的限制，但是您所测试的内容仍然有效。

我们使用varnish和varnishncsa进行类似的操作，以获取对我们有用的日志。我们有一个fifo，只需使用syslog-ng从中读取，然后将其发送到需要的位置即可。我们可以处理大约50GB，到目前为止，这种方法还没有遇到问题

环境是CentOS，应用程序将写入文件...

而不是发送到常规文件，我将输出发送到syslog并确保将syslog消息发送到中央服务器以及本地。

您应该能够使用如下的shell脚本：

logger -p daemon.notice -t app < fifo

您也可以从管道中输入（至logger）：cattail -f

tail -f fifo | logger ...
cat fifo | logger ...

唯一的问题是，它不能根据日志消息的重要性来区分（一切都为NOTICE），但至少它会被记录并从主机发送到中央服务器。

配置syslog取决于您使用的服务器。有rsyslog和syslog-ng（两者都很有能力）。

编辑：从海报中获取更多信息后进行了修订。

你写：

此外，该应用程序将不会写入stdout...

您是否尝试登录到“文件” /dev/stdout？这可能使您能够执行以下操作：

app --logfile /dev/stdout | logger -t app

没有必要先写入fifo，然后再由另一个进程将其写入文件。只需正常地直接写入文件，一旦write()返回，就在内核手中。如果应用程序崩溃，它将仍然将其写入磁盘。