Question

我正在尝试将程序的输出（日志）传递到Go程序，该程序将聚合/压缩输出并上传到S3。运行程序的命令是“ / program1 | / logShipper”。 logShipper是用Go编写的，只需从os.Stdin中读取并写入本地文件即可。本地文件将由另一个goroutine处理，并定期上传到S3。现有一些docker日志驱动程序，但是我们在完全托管的提供程序上运行容器，并且日志处理费用非常昂贵，因此我们想绕过现有解决方案并仅上传到S3。

logShipper的主要逻辑只是从os.Stdin中读取并写入某些文件。在本地计算机上运行时，它可以正常工作，但在docker中运行时，goroutine在reader.ReadString（'\ n'）处阻塞，并且永远不会返回。

go func() {
    reader := bufio.NewReader(os.Stdin)
    mu.Lock()
    output = openOrCreateOutputFile(&uploadQueue, workPath)
    mu.Unlock()
    for {
    text, _ := reader.ReadString('\n')
    now := time.Now().Format("2006-01-02T15:04:05.000000000Z")
    mu.Lock()
    output.file.Write([]byte(fmt.Sprintf("%s %s", now, text)))
    mu.Unlock()
     }
}()

我在网上做了一些研究，但是找不到为什么它不起作用。我想的一种可能是docker可能会将stdout重定向到某个地方，以使PIPE不能以与Linux机器上相同的方式工作？（看起来它无法从program1中读取任何内容）欢迎提供任何帮助或建议，以使其不起作用。谢谢。

编辑：经过更多研究后，我意识到以这种方式处理日志是一种不好的做法。我应该更多地依赖docker的日志驱动程序来处理日志的汇总和发送。但是，我仍然有兴趣找出为什么它没有从PIPE源程序中读取任何内容。

Answer 1

我不确定Docker处理输出的方式，但是我建议您使用os.Stdin.Fd()提取文件描述符，然后使用golang.org/x/sys/unix软件包，如下所示：

// Long way, for short one jump
// down straight to it.
//
// retrieve the file descriptor
// cast it to int, because Fd method
// returns uintptr
fd := int(os.Stdin.Fd())

// extract file descriptor flags
// it's safe to drop the error, since if it's there
// and it's not nil, you won't be able to read from
// Stdin anyway, unless it's a notice
// to try again, which mostly should not be 
// the case
flags, _ := unix.FcntlInt(fd, unix.F_GETFL, 0)

// check if the nonblocking reading in enabled
nb := flags & unix.O_NONBLOCK != 0

// if this is the case, just enable it with
// unix.SetNonblock which is also a
// -- SHORT WAY HERE --
err = unix.SetNonblock(fd, true)

长距离和short way之间的区别在于，如果问题出在非阻塞状态，那么长距离肯定会告诉您。

如果不是这种情况。那我个人没有其他想法。

当在Docker中将PEPI输出时从OS.Stdin读取时被阻止

1 个答案: