看网上很多例子,日志统一输出到 os.Stderr 。
当然也有 os.Stdout 的。
想请教下,在实际环境上,这两者的不同。
1
msg7086 2023-01-28 11:54:13 +08:00
生产的时候哪个都不用,走日志库发送到中央日志系统。
|
2
jifengg 2023-01-28 11:56:01 +08:00 5
个人觉得,看软件的输出类型。
比如你的程序是服务型的(比如一个 http 服务),不靠控制台做输出或不输出管道,则 stdout 或 stderr 都可以。 如果是工具型的(比如 grep 、ffmpeg ),通过控制台输出结果的,那么日志就应该输出到 stderr ,避免和正常的 stdout 混淆了。 |
3
plko345 2023-01-28 11:59:31 +08:00
stdout 吧, 基本都是这么做的吧, 而且现在容器化, 也都是这么做的
|
4
julyclyde 2023-01-28 12:51:07 +08:00 1
|
6
ql562482472 2023-01-28 13:09:55 +08:00
stdout 啊
|
7
guanzhangzhang 2023-01-28 16:46:53 +08:00
最优雅的还是 env 或者配置文件支持类似 DSN 那样的配置,支持 stdout 也支持远端集中日志,以及 format 是 json 还是 line 啥的
|
8
tool2d 2023-01-28 17:37:51 +08:00
推荐 os.Stdout ,这样还可以用管道,让别的程序实时二次加工 /过滤你的 log 内容。
|
9
nightwitch 2023-01-28 17:45:30 +08:00 via Android
生产环境下一般往 socket 或者 file
|
10
feelinglucky 2023-01-28 19:32:38 +08:00
@julyclyde 让日志库去实现好了,应用只是调用不关心细节
|
11
GopherDaily 2023-01-28 19:57:26 +08:00
stdout ,逻辑分层,输出日志就输出日志,后续的收集、分类存储没必要耦合
|
12
MrKrabs 2023-01-28 20:47:22 +08:00
看心情
|
13
soulsxd 2023-01-29 10:05:59 +08:00
统一 stdout ,然后日志打印加上日志级别用于过滤
|
14
hellojukay 2023-01-29 11:50:33 +08:00
系统正常日志,输出到 os.Stdout, 系统错误日志输出到 os.Stderr , linux 上命令行程序的日志都是这个规则。
|
15
mxalbert1996 2023-01-29 12:01:24 +08:00 via Android
@tool2d stderr 也可以,加个 2>&1 就行
|
16
libook 2023-01-29 12:02:14 +08:00
这其实就是个约定问题,你可以看一下为什么系统要设计 stdout 和 stderr 两个通道,然后再看一下自己项目的设计如何利用这两个通道。
|
17
jim9606 2023-01-29 13:05:38 +08:00 via Android
如果你打算用 systemd 、docker 等管理服务日志,用 stdout 问题不大
如果本身有 CLI 交互的就得换 stderr 了 |
18
tairan2006 2023-02-07 10:12:47 +08:00
stdout 啊,因为 go 的 panic 会输出到 stderr ,你需要单独捕获 panic 的日志的话,就不要向 stderr 里面输出任何业务信息。
|
19
lotusgrm 2023-07-27 22:42:27 +08:00
1 、如果服务是容器化的,建议将容器的日志输出到 stdout 和 stderr ,这里主要有这么 2 个原因吧:( 1 )方便日志的集中管理。将容器日志输出 stdout 和 stderr 可以很方便的通过管道重定向到其它的日志管理平台,这样一来的话所有容器的日志可以集中存储和分析 ( 2 )容器化标准化。将日志输出 stdout 和 stderr 有助于将容器设计为只负责应用程序进程本身,而不用关心日志的具体实现,比如我们可以通过 sidecar 的方式收集封装服务日志
2 、具体是输出 stdout 还是 stderr ,我个人觉得可以根据日志级别来决定,比如 nginx 中有两类很重的日志:access.log 、error.log ,前者表示正常的访问日志,后者表示错误日志,一般情况我觉得我们的业务系统可以参考 nginx 的设计建立这两类日志 |