日志应该统一输出到 os.Stdout，还是 os.Stderr？？

[1800x]

看网上很多例子，日志统一输出到 os.Stderr 。
当然也有 os.Stdout 的。

想请教下，在实际环境上，这两者的不同。

[msg7086]

生产的时候哪个都不用，走日志库发送到中央日志系统。

[jifengg]

个人觉得，看软件的输出类型。
比如你的程序是服务型的（比如一个 http 服务），不靠控制台做输出或不输出管道，则 stdout 或 stderr 都可以。
如果是工具型的（比如 grep 、ffmpeg ），通过控制台输出结果的，那么日志就应该输出到 stderr ，避免和正常的 stdout 混淆了。

[plko345]

stdout 吧, 基本都是这么做的吧, 而且现在容器化, 也都是这么做的

[julyclyde]

https://12factor.net/logs

[julyclyde]

@msg7086 我觉得应用程序亲自发到中心有点不太好。调试的时候还需要抑制这个行为

[ql562482472]

stdout 啊

[guanzhangzhang]

最优雅的还是 env 或者配置文件支持类似 DSN 那样的配置，支持 stdout 也支持远端集中日志，以及 format 是 json 还是 line 啥的

[tool2d]

推荐 os.Stdout ，这样还可以用管道，让别的程序实时二次加工 /过滤你的 log 内容。

[nightwitch]

生产环境下一般往 socket 或者 file

[feelinglucky]

@julyclyde 让日志库去实现好了，应用只是调用不关心细节

[GopherDaily]

stdout ，逻辑分层，输出日志就输出日志，后续的收集、分类存储没必要耦合

[MrKrabs]

看心情

[soulsxd]

统一 stdout ，然后日志打印加上日志级别用于过滤

[hellojukay]

系统正常日志，输出到 os.Stdout, 系统错误日志输出到 os.Stderr , linux 上命令行程序的日志都是这个规则。

[mxalbert1996]

@tool2d stderr 也可以，加个 2>&1 就行

[libook]

这其实就是个约定问题，你可以看一下为什么系统要设计 stdout 和 stderr 两个通道，然后再看一下自己项目的设计如何利用这两个通道。

[jim9606]

如果你打算用 systemd 、docker 等管理服务日志，用 stdout 问题不大
如果本身有 CLI 交互的就得换 stderr 了

[tairan2006]

stdout 啊，因为 go 的 panic 会输出到 stderr ，你需要单独捕获 panic 的日志的话，就不要向 stderr 里面输出任何业务信息。

[lotusgrm]

1 、如果服务是容器化的，建议将容器的日志输出到 stdout 和 stderr ，这里主要有这么 2 个原因吧：（ 1 ）方便日志的集中管理。将容器日志输出 stdout 和 stderr 可以很方便的通过管道重定向到其它的日志管理平台，这样一来的话所有容器的日志可以集中存储和分析 （ 2 ）容器化标准化。将日志输出 stdout 和 stderr 有助于将容器设计为只负责应用程序进程本身，而不用关心日志的具体实现，比如我们可以通过 sidecar 的方式收集封装服务日志

2 、具体是输出 stdout 还是 stderr ，我个人觉得可以根据日志级别来决定，比如 nginx 中有两类很重的日志:access.log 、error.log ，前者表示正常的访问日志，后者表示错误日志，一般情况我觉得我们的业务系统可以参考 nginx 的设计建立这两类日志