看网上很多例子，日志统一输出到 os.Stderr 。
当然也有 os.Stdout 的。
想请教下，在实际环境上，这两者的不同。
This topic created in 1382 days ago, the information mentioned may be changed or developed.
 |
msg7086Jan 28, 2023
1
生产的时候哪个都不用，走日志库发送到中央日志系统。
|
 |
2
个人觉得，看软件的输出类型。
比如你的程序是服务型的（比如一个 http 服务），不靠控制台做输出或不输出管道，则 stdout 或 stderr 都可以。 如果是工具型的（比如 grep 、ffmpeg ），通过控制台输出结果的，那么日志就应该输出到 stderr ，避免和正常的 stdout 混淆了。 |
5 |
plko345Jan 28, 2023
3
stdout 吧, 基本都是这么做的吧, 而且现在容器化, 也都是这么做的
|
 |
4
|
 |
ql562482472Jan 28, 2023
6
stdout 啊
|
 |
guanzhangzhangJan 28, 2023
7
最优雅的还是 env 或者配置文件支持类似 DSN 那样的配置，支持 stdout 也支持远端集中日志，以及 format 是 json 还是 line 啥的
|
 |
tool2dJan 28, 2023
8
推荐 os.Stdout ，这样还可以用管道，让别的程序实时二次加工 /过滤你的 log 内容。
|
 |
nightwitchJan 28, 2023 via Android
9
生产环境下一般往 socket 或者 file
|
 |
feelingluckyJan 28, 2023
10
@julyclyde 让日志库去实现好了，应用只是调用不关心细节
|
 |
GopherDailyJan 28, 2023
11
stdout ，逻辑分层，输出日志就输出日志，后续的收集、分类存储没必要耦合
|
 |
MrKrabsJan 28, 2023
12
看心情
|
 |
soulsxdJan 29, 2023
13
统一 stdout ，然后日志打印加上日志级别用于过滤
|
 |
NexoraJan 29, 2023
14
系统正常日志，输出到 os.Stdout, 系统错误日志输出到 os.Stderr , linux 上命令行程序的日志都是这个规则。
|
 |
mxalbert1996Jan 29, 2023 via Android
15
@tool2d stderr 也可以，加个 2>&1 就行
|
 |
libookJan 29, 2023
16
这其实就是个约定问题，你可以看一下为什么系统要设计 stdout 和 stderr 两个通道，然后再看一下自己项目的设计如何利用这两个通道。
|
 |
jim9606Jan 29, 2023 via Android
17
如果你打算用 systemd 、docker 等管理服务日志，用 stdout 问题不大
如果本身有 CLI 交互的就得换 stderr 了 |
 |
keenkillerFeb 7, 2023
18
stdout 啊，因为 go 的 panic 会输出到 stderr ，你需要单独捕获 panic 的日志的话，就不要向 stderr 里面输出任何业务信息。
|
 |
lotusgrmJul 27, 2023
19
1 、如果服务是容器化的，建议将容器的日志输出到 stdout 和 stderr ，这里主要有这么 2 个原因吧：（ 1 ）方便日志的集中管理。将容器日志输出 stdout 和 stderr 可以很方便的通过管道重定向到其它的日志管理平台，这样一来的话所有容器的日志可以集中存储和分析 （ 2 ）容器化标准化。将日志输出 stdout 和 stderr 有助于将容器设计为只负责应用程序进程本身，而不用关心日志的具体实现，比如我们可以通过 sidecar 的方式收集封装服务日志
2 、具体是输出 stdout 还是 stderr ，我个人觉得可以根据日志级别来决定，比如 nginx 中有两类很重的日志:access.log 、error.log ，前者表示正常的访问日志，后者表示错误日志，一般情况我觉得我们的业务系统可以参考 nginx 的设计建立这两类日志 |
Select Language