大家好，我是煎魚(yú)。

在日常工作中，打日志是很常見(jiàn)的動(dòng)作。畢竟不打日志，從內(nèi)部來(lái)講，一旦出問(wèn)題，定位、排查都會(huì)變的非常困難。誰(shuí)也不想大半夜在那靠猜解決問(wèn)題。

在其他方面，對(duì)日志的存儲(chǔ)的內(nèi)容、時(shí)長(zhǎng)、安全均有不同程度的合規(guī)要求，應(yīng)對(duì)客戶訴求和提單上門(mén)的事件。

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

標(biāo)準(zhǔn)庫(kù) log 很痛

思考一個(gè)問(wèn)題：平時(shí)你在寫(xiě) Go 工程時(shí)，是否很少直接使用官方標(biāo)準(zhǔn)庫(kù) log？

在正式項(xiàng)目中，大多是優(yōu)先使用幾個(gè)爆款第三方庫(kù)，例如：Logrus、Zap、zerolog，畢竟又快又猛。而標(biāo)準(zhǔn)庫(kù) log，在臨時(shí)調(diào)試，屏幕輸出的場(chǎng)景居多，占比較少。

這問(wèn)題出在了哪里？主要集中在以下方面：

• 沒(méi)有日志分級(jí)。不便于分類、定位、排查問(wèn)題，例如：Error、Warn、Info、Debug 等。
• 沒(méi)有結(jié)構(gòu)化日志。只提供格式化日志，不提供結(jié)構(gòu)化，不便于程序讀取、解析，例如：Json 格式。
• 沒(méi)有擴(kuò)展性，靈活度差。標(biāo)準(zhǔn)庫(kù) log 的日志輸出都是固定格式，沒(méi)有一個(gè) Logger 接口規(guī)范，讓大家都遵守，以至于現(xiàn)在社區(qū)純自然演進(jìn)，難互相兼容。

除此之外，在用戶場(chǎng)景上，有著不包含上下文（context）信息、性能不夠強(qiáng)勁、無(wú)法引入自定義插件等擴(kuò)展訴求?；旧系谌綆?kù)均有實(shí)現(xiàn)的，基本都用戶的痛點(diǎn)之一。

為什么不早點(diǎn)解決

你可能會(huì)想，標(biāo)準(zhǔn)庫(kù) log 作為 Go 生態(tài)里的核心庫(kù)，為什么不早點(diǎn)解決？

實(shí)際上在 2017 年時(shí)，有在社區(qū)進(jìn)行了大規(guī)模討論，可惜放棄了。原因是：“我們還沒(méi)有找到足夠多的導(dǎo)入和使用具體 Logger 的 Go 庫(kù)，因此沒(méi)有理由繼續(xù)開(kāi)展這項(xiàng)工作”。

如下圖：

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

繼續(xù)擺爛，再鴿幾年。

救星 slog 庫(kù)誕生

討論和目標(biāo)

在 2022 年 8 月，Go 團(tuán)隊(duì)的 @ Jonathan Amsterdam 發(fā)起了 discussion: structured, leveled logging[1] 的討論，試圖與這個(gè)亂象再度一決雌雄。

如下圖：

discussions/54763

提案（含討論）的目標(biāo)是：

• 使用方便。對(duì)現(xiàn)有 Logger 庫(kù)的調(diào)查說(shuō)明，開(kāi)發(fā)人員更想要一個(gè)簡(jiǎn)潔且易懂的日志 API。
• 高性能。新的 API 希望做到最大限度的減少內(nèi)存分配和鎖定。
• 與運(yùn)行時(shí)跟蹤集成。Go 團(tuán)隊(duì)正在開(kāi)發(fā)和改進(jìn)運(yùn)行時(shí)跟蹤系統(tǒng)，基于新 Logger 庫(kù)的日志將可以無(wú)縫銜接到這個(gè)跟蹤系統(tǒng)中，開(kāi)發(fā)人員能夠?qū)崿F(xiàn)程序操作與運(yùn)行時(shí)的行為相關(guān)聯(lián)。

目標(biāo)涵蓋了前文背景中提到的痛點(diǎn)。我關(guān)注到上述的第三點(diǎn)，來(lái)自 Go 團(tuán)隊(duì)自己的需求，果然最優(yōu)先要做的需求都是自己想要 PUSH 的需求？霧了霧了。

畢竟已經(jīng) 10 年了，本討論中得到了許多人的建議和推進(jìn)，成功孵化。

快速 Demo

該庫(kù)目前已經(jīng)經(jīng)過(guò) “石錘” 階段，非常快速地進(jìn)入了實(shí)驗(yàn)庫(kù)，導(dǎo)入地址是：golang.org/x/exp/slog，推薦大家試用。

我們先上手新日志庫(kù) 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))
}

如果不設(shè)置 slog.SetDefault? 將會(huì)默認(rèn)輸出到標(biāo)準(zhǔn)輸出。由于上述程序設(shè)置了 os.Stderr，因此會(huì)在此輸出。

程序運(yùn)行結(jié)果如下：

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"

我們看到了日志分級(jí)（Level）、自定義字段追加、設(shè)置輸出地等特性。在輸出格式上，新的 slog 庫(kù)，將會(huì)采取與 logfmt[2] 庫(kù)類似的方式來(lái)實(shí)現(xiàn)，內(nèi)置至少兩種格式，也可以自定義實(shí)現(xiàn)。

默認(rèn)的 logfmt 消息格式：

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

如果想調(diào)整為 JSON 格式，可進(jìn)行設(shè)置：

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

會(huì)使用 JSON 格式輸出：

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

設(shè)計(jì)思路

作者將 slog 庫(kù)的設(shè)計(jì)分為：前端、后端。

前端，slog 認(rèn)為你常用且能看得見(jiàn)的 API 都是前端，例如：Info、Debug 等日志分級(jí)的，設(shè)置上下文內(nèi)容的 Context 和自定義字段注入等都包含在前端的范疇內(nèi)。

如下方法：

后端，slog 認(rèn)為實(shí)際干具體業(yè)務(wù)邏輯的 Handler 是后端，并將其抽象成了 Handler 接口，只需要實(shí)現(xiàn) Handler 接口，就可以注入自定義 Handler。

如下 Handler 接口：

type Handler interface {
  // 啟用記錄的日志級(jí)別
 Enabled(Level) bool
  // 具體的處理方法，需要 Enabled 返回 true
 Handle(r Record) error

 WithAttrs(attrs []Attr) Handler

 WithGroup(name string) Handler
}

其中你可以看到 Handle 函數(shù)有一個(gè) Record 屬性，它是一個(gè)核心的數(shù)據(jù)結(jié)構(gòu)。

如下代碼：

type Record struct {
 Time time.Time

 Message string

 Level Level

 Context context.Context
}

新的 slog 的內(nèi)部流程如下：

• 前端方法（例如：Info）將所傳屬性封裝為 Record 類型的變量。
• 將 Record 類型的變量傳遞給后端方法（例如：Handle）。
• 后端 Handle 方法根據(jù)所得 Record，進(jìn)行對(duì)應(yīng)的格式化、方法調(diào)用、日志輸出等具體日志動(dòng)作。

與其他 Logger 交互

那回到最開(kāi)始的問(wèn)題？

如果我們現(xiàn)在要寫(xiě)一個(gè)私有的 Logger，或是復(fù)用 Zap。要怎么做？

后端方法，有兩條路：

• 要不走 Record，調(diào)用 NewRecord 將其包裝成 Record 類型的變量，再往下傳。
• 要不走 Handle，將處理邏輯寫(xiě)到自定義 Handle 中去完成。

其實(shí)兩者是同一條路。

如果是想在前端方法來(lái)處理，很遺憾，Go 沒(méi)有計(jì)劃將 slog 前端開(kāi)放。確保了前端穩(wěn)態(tài)，后端可變可擴(kuò)展的靈活性。我個(gè)人覺(jué)得有利有弊了。

如果有興趣了解如何實(shí)現(xiàn)自定義 Handle，可以查看 TextHandler[3] 和 JSONHandler[4] 即可，是官方最佳實(shí)踐。

上下文注入

經(jīng)典的 context 場(chǎng)景，slog 庫(kù)直接內(nèi)置了相關(guān)的函數(shù)進(jìn)行支持。

如下代碼：

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) ...
}

還是比較方便的。

總結(jié)

在此刻，Go 社區(qū)中的 log 庫(kù)們已經(jīng)基本成熟，格局已定的 7788。此時(shí) Go 官方的 slog 庫(kù)推出，很明顯吸取了前者的大量豐富經(jīng)驗(yàn)（提案有聲明）。

我相信在未來(lái) slog 庫(kù)，會(huì)和更多的 Go 生態(tài)的工具鏈打通，提供更豐富的關(guān)聯(lián)場(chǎng)景。解決 Go 沒(méi)有一個(gè)靠譜 log 庫(kù)的痛點(diǎn)。

你覺(jué)得這個(gè)新庫(kù)能在未來(lái)統(tǒng)一亂象嗎？

參考資料

[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