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

大家好，我是煎鱼。

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

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

日志好不好用，就成了重要的诉求了。

标准库 log 很痛

思考一个问题：平时你在写 Go 工程时，是否很少直接使用官方标准库 log？

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

这问题出在了哪里？主要集中在以下方面：

• 没有日志分级。不便于分类、定位、排查问题，例如：Error、Warn、Info、Debug 等。
• 没有结构化日志。只提供格式化日志，不提供结构化，不便于程序读取、解析，例如：Json 格式。
• 没有扩展性，灵活度差。标准库 log 的日志输出都是固定格式，没有一个 Logger 接口规范，让大家都遵守，以至于现在社区纯自然演进，难互相兼容。

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

为什么不早点解决

你可能会想，标准库 log 作为 Go 生态里的核心库，为什么不早点解决？

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

如下图：

g/golang-dev/c/F3l9Iz1JX4g/m/t0J0loRaDQAJ

继续摆烂，再鸽几年。

救星 slog 库诞生

讨论和目标

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

如下图：

discussions/54763

提案（含讨论）的目标是：

• 使用方便。对现有 Logger 库的调查说明，开发人员更想要一个简洁且易懂的日志 API。
• 高性能。新的 API 希望做到最大限度的减少内存分配和锁定。
• 与运行时跟踪集成。Go 团队正在开发和改进运行时跟踪系统，基于新 Logger 库的日志将可以无缝衔接到这个跟踪系统中，开发人员能够实现程序操作与运行时的行为相关联。

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

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

快速 Demo

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

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

如下代码：

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，因此会在此输出。

程序运行结果如下：

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

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

默认的 logfmt 消息格式：

foo=bar a=14 baz="hello kitty" cool%story=bro f %^asdf

如果想调整为 JSON 格式，可进行设置：

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

会使用 JSON 格式输出：

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

设计思路

作者将 slog 库的设计分为：前端、后端。

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

如下方法：

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

如下 Handler 接口：

type Handler interface {
  // 启用记录的日志级别
 Enabled(Level) bool
  // 具体的处理方法，需要 Enabled 返回 true
 Handle(r Record) error

 WithAttrs(attrs []Attr) Handler

 WithGroup(name string) Handler
}

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

如下代码：

type Record struct {
 Time time.Time

 Message string

 Level Level

 Context context.Context
}

新的 slog 的内部流程如下：

1. 前端方法（例如：Info）将所传属性封装为 Record 类型的变量。
2. 将 Record 类型的变量传递给后端方法（例如：Handle）。
3. 后端 Handle 方法根据所得 Record，进行对应的格式化、方法调用、日志输出等具体日志动作。

与其他 Logger 交互

那回到最开始的问题？

如果我们现在要写一个私有的 Logger，或是复用 Zap。要怎么做？

后端方法，有两条路：

1. 要不走 Record，调用 NewRecord 将其包装成 Record 类型的变量，再往下传。
2. 要不走 Handle，将处理逻辑写到自定义 Handle 中去完成。

其实两者是同一条路。

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

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

上下文注入

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

如下代码：

func FromContext(ctx context.Context) Logger
    FromContext returns the Logger stored in ctx by NewContext, or the default
    Logger if there is none.

func NewContext(ctx context.Context, l Logger) context.Context
    NewContext returns a context that contains the given Logger. Use FromContext
    to retrieve the Logger.

具体的 Demo：

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

还是比较方便的。

总结

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

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

你觉得这个新库能在未来统一乱象吗？

参考资料

[1]

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

[2]

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

[3]

TextHandler: https://cs.opensource.google/go/x/exp/+/c99f073a:slog/text_handler.go

[4]

JSONHandler: https://cs.opensource.google/go/x/exp/+/c99f073a:slog/json_handler.go

关注和加煎鱼微信，

获取一手业内消息和知识，拉你进交流群👇

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

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