大家好，我是煎魚。

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

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

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

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

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

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

這問題出在了哪里？主要集中在以下方面：

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

除此之外，在用戶場景上，有著不包含上下文（context）信息、性能不夠強勁、無法引入自定義插件等擴展訴求。基本上第三方庫均有實現(xiàn)的，基本都用戶的痛點之一。

為什么不早點解決

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

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

如下圖：

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

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

救星 slog 庫誕生

討論和目標(biāo)

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

如下圖：

discussions/54763

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

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

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

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

快速 Demo

該庫目前已經(jīng)經(jīng)過 “石錘” 階段，非常快速地進(jìn)入了實驗庫，導(dǎo)入地址是：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))
}

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

程序運行結(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"

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

會使用 JSON 格式輸出：

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

設(shè)計思路

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

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

如下方法：

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

如下 Handler 接口：

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

 WithAttrs(attrs []Attr) Handler

 WithGroup(name string) Handler
}

其中你可以看到 Handle 函數(shù)有一個 Record 屬性，它是一個核心的數(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)行對應(yīng)的格式化、方法調(diào)用、日志輸出等具體日志動作。

與其他 Logger 交互

那回到最開始的問題？

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

后端方法，有兩條路：

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

其實兩者是同一條路。

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

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

上下文注入

經(jīng)典的 context 場景，slog 庫直接內(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 庫們已經(jīng)基本成熟，格局已定的 7788。此時 Go 官方的 slog 庫推出，很明顯吸取了前者的大量豐富經(jīng)驗（提案有聲明）。

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

你覺得這個新庫能在未來統(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