Go十年了，终于想起要统一log库了！

大家好&＃xff0c;我是煎鱼。

在日常工作中&＃xff0c;打日志是很常见的动作。毕竟不打日志&＃xff0c;从内部来讲&＃xff0c;一旦出问题&＃xff0c;定位、排查都会变的非常困难。谁也不想大半夜在那靠猜解决问题。

在其他方面&＃xff0c;对日志的存储的内容、时长、安全均有不同程度的合规要求&＃xff0c;应对客户诉求和提单上门的事件。

日志好不好用&＃xff0c;就成了重要的诉求了。

标准库 log 很痛

思考一个问题&＃xff1a;平时你在写 Go 工程时&＃xff0c;是否很少直接使用官方标准库 log&＃xff1f;

在正式项目中&＃xff0c;大多是优先使用几个爆款第三方库&＃xff0c;例如&＃xff1a;Logrus、Zap、zerolog&＃xff0c;毕竟又快又猛。而标准库 log&＃xff0c;在临时调试&＃xff0c;屏幕输出的场景居多&＃xff0c;占比较少。

这问题出在了哪里&＃xff1f;主要集中在以下方面&＃xff1a;

• 没有日志分级。不便于分类、定位、排查问题&＃xff0c;例如&＃xff1a;Error、Warn、Info、Debug 等。

• 没有结构化日志。只提供格式化日志&＃xff0c;不提供结构化&＃xff0c;不便于程序读取、解析&＃xff0c;例如&＃xff1a;Json 格式。

• 没有扩展性&＃xff0c;灵活度差。标准库 log 的日志输出都是固定格式&＃xff0c;没有一个 Logger 接口规范&＃xff0c;让大家都遵守&＃xff0c;以至于现在社区纯自然演进&＃xff0c;难互相兼容。

除此之外&＃xff0c;在用户场景上&＃xff0c;有着不包含上下文&＃xff08;context&＃xff09;信息、性能不够强劲、无法引入自定义插件等扩展诉求。基本上第三方库均有实现的&＃xff0c;基本都用户的痛点之一。

为什么不早点解决

你可能会想&＃xff0c;标准库 log 作为 Go 生态里的核心库&＃xff0c;为什么不早点解决&＃xff1f;

实际上在 2017 年时&＃xff0c;有在社区进行了大规模讨论&＃xff0c;可惜放弃了。原因是&＃xff1a;“我们还没有找到足够多的导入和使用具体 Logger 的 Go 库&＃xff0c;因此没有理由继续开展这项工作”。

如下图&＃xff1a;

继续摆烂&＃xff0c;再鸽几年。

救星 slog 库诞生

讨论和目标

在 2022 年 8 月&＃xff0c;Go 团队的 &＃64; Jonathan Amsterdam 发起了 discussion: structured, leveled logging^[1] 的讨论&＃xff0c;试图与这个乱象再度一决雌雄。

如下图&＃xff1a;

提案&＃xff08;含讨论&＃xff09;的目标是&＃xff1a;

• 使用方便。对现有 Logger 库的调查说明&＃xff0c;开发人员更想要一个简洁且易懂的日志 API。

• 高性能。新的 API 希望做到最大限度的减少内存分配和锁定。

• 与运行时跟踪集成。Go 团队正在开发和改进运行时跟踪系统&＃xff0c;基于新 Logger 库的日志将可以无缝衔接到这个跟踪系统中&＃xff0c;开发人员能够实现程序操作与运行时的行为相关联。

目标涵盖了前文背景中提到的痛点。我关注到上述的第三点&＃xff0c;来自 Go 团队自己的需求&＃xff0c;果然最优先要做的需求都是自己想要 PUSH 的需求&＃xff1f;雾了雾了。

毕竟已经 10 年了&＃xff0c;本讨论中得到了许多人的建议和推进&＃xff0c;成功孵化。

快速 Demo

该库目前已经经过 “石锤” 阶段&＃xff0c;非常快速地进入了实验库&＃xff0c;导入地址是&＃xff1a;golang.org/x/exp/slog&＃xff0c;推荐大家试用。

我们先上手新日志库 slog 的快速 Demo&＃xff0c;便于大家快速了解和熟悉。

如下代码&＃xff1a;

import "log/slog"func main() {slog.SetDefault(slog.New(slog.NewTextHandler(os.Stderr)))slog.Info("hello", "name", "Al")slog.Error("oops", net.ErrClosed, "status", 500)slog.LogAttrs(slog.ErrorLevel, "oops",slog.Int("status", 500), slog.Any("err", net.ErrClosed))
}

如果不设置 slog.SetDefault 将会默认输出到标准输出。由于上述程序设置了 os.Stderr&＃xff0c;因此会在此输出。

程序运行结果如下&＃xff1a;

time&＃61;2022-10-24T16:05:48.054-04:00 level&＃61;INFO msg&＃61;hello name&＃61;Al
time&＃61;2022-10-24T16:05:48.054-04:00 level&＃61;ERROR msg&＃61;oops status&＃61;500 err&＃61;"use of closed network connection"
time&＃61;2022-10-24T16:05:48.054-04:00 level&＃61;ERROR msg&＃61;oops status&＃61;500 err&＃61;"use of closed network connection"

我们看到了日志分级&＃xff08;Level&＃xff09;、自定义字段追加、设置输出地等特性。在输出格式上&＃xff0c;新的 slog 库&＃xff0c;将会采取与 logfmt^[2] 库类似的方式来实现&＃xff0c;内置至少两种格式&＃xff0c;也可以自定义实现。

默认的 logfmt 消息格式&＃xff1a;

foo&＃61;bar a&＃61;14 baz&＃61;"hello kitty" cool%story&＃61;bro f %^asdf

如果想调整为 JSON 格式&＃xff0c;可进行设置&＃xff1a;

slog.SetDefault(slog.New(slog.NewJSONHandler(os.Stderr)))

会使用 JSON 格式输出&＃xff1a;

{ "foo": "bar", "a": 14, "baz": "hello kitty", "cool%story": "bro", "f": true, "%^asdf": true }

设计思路

作者将 slog 库的设计分为&＃xff1a;前端、后端。

前端&＃xff0c;slog 认为你常用且能看得见的 API 都是前端&＃xff0c;例如&＃xff1a;Info、Debug 等日志分级的&＃xff0c;设置上下文内容的 Context 和自定义字段注入等都包含在前端的范畴内。

如下方法&＃xff1a;

后端&＃xff0c;slog 认为实际干具体业务逻辑的 Handler 是后端&＃xff0c;并将其抽象成了 Handler 接口&＃xff0c;只需要实现 Handler 接口&＃xff0c;就可以注入自定义 Handler。

如下 Handler 接口&＃xff1a;

type Handler interface {// 启用记录的日志级别Enabled(Level) bool// 具体的处理方法&＃xff0c;需要 Enabled 返回 trueHandle(r Record) errorWithAttrs(attrs []Attr) HandlerWithGroup(name string) Handler
}

其中你可以看到 Handle 函数有一个 Record 属性&＃xff0c;它是一个核心的数据结构。

如下代码&＃xff1a;

type Record struct {Time time.TimeMessage stringLevel LevelContext context.Context
}

新的 slog 的内部流程如下&＃xff1a;

1. 前端方法&＃xff08;例如&＃xff1a;Info&＃xff09;将所传属性封装为 Record 类型的变量。

2. 将 Record 类型的变量传递给后端方法&＃xff08;例如&＃xff1a;Handle&＃xff09;。

3. 后端 Handle 方法根据所得 Record&＃xff0c;进行对应的格式化、方法调用、日志输出等具体日志动作。

与其他 Logger 交互

那回到最开始的问题&＃xff1f;

如果我们现在要写一个私有的 Logger&＃xff0c;或是复用 Zap。要怎么做&＃xff1f;

后端方法&＃xff0c;有两条路&＃xff1a;

1. 要不走 Record&＃xff0c;调用 NewRecord 将其包装成 Record 类型的变量&＃xff0c;再往下传。

2. 要不走 Handle&＃xff0c;将处理逻辑写到自定义 Handle 中去完成。

其实两者是同一条路。

如果是想在前端方法来处理&＃xff0c;很遗憾&＃xff0c;Go 没有计划将 slog 前端开放。确保了前端稳态&＃xff0c;后端可变可扩展的灵活性。我个人觉得有利有弊了。

如果有兴趣了解如何实现自定义 Handle&＃xff0c;可以查看 TextHandler^[3] 和 JSONHandler^[4] 即可&＃xff0c;是官方最佳实践。

上下文注入

经典的 context 场景&＃xff0c;slog 库直接内置了相关的函数进行支持。

如下代码&＃xff1a;

func FromContext(ctx context.Context) LoggerFromContext returns the Logger stored in ctx by NewContext, or the defaultLogger if there is none.func NewContext(ctx context.Context, l Logger) context.ContextNewContext returns a context that contains the given Logger. Use FromContextto retrieve the Logger.

具体的 Demo&＃xff1a;

func handle(w http.ResponseWriter, r *http.Request) {rlogger :&＃61; slog.FromContext(r.Context()).With("method", r.Method,"url", r.URL,"traceID", getTraceID(r),)ctx :&＃61; slog.NewContext(r.Context(), rlogger)// ... use slog.FromContext(ctx) ...
}

还是比较方便的。

总结

在此刻&＃xff0c;Go 社区中的 log 库们已经基本成熟&＃xff0c;格局已定的 7788。此时 Go 官方的 slog 库推出&＃xff0c;很明显吸取了前者的大量丰富经验&＃xff08;提案有声明&＃xff09;。

我相信在未来 slog 库&＃xff0c;会和更多的 Go 生态的工具链打通&＃xff0c;提供更丰富的关联场景。解决 Go 没有一个靠谱 log 库的痛点。

你觉得这个新库能在未来统一乱象吗&＃xff1f;

参考资料

[1]

discussion: structured, leveled logging: https://github.com/golang/go/discussions/54763

logfmt: https://pkg.go.dev/github.com/kr/logfmt

TextHandler: https://cs.opensource.google/go/x/exp/&＃43;/c99f073a:slog/text_handler.go

JSONHandler: https://cs.opensource.google/go/x/exp/&＃43;/c99f073a:slog/json_handler.go

关注和加煎鱼微信&＃xff0c;

获取一手业内消息和知识&＃xff0c;拉你进交流群&＃x1f447;

你好&＃xff0c;我是煎鱼&＃xff0c;出版过 Go 畅销书《Go 语言编程之旅》&＃xff0c;再到获得 GOP&＃xff08;Go 领域最有观点专家&＃xff09;荣誉&＃xff0c;点击蓝字查看我的出书之路。

日常分享高质量文章&＃xff0c;输出 Go 面试、工作经验、架构设计&＃xff0c;加微信拉读者交流群&＃xff0c;和大家交流&＃xff01;