大家好，我是煎魚。

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

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

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

標準庫 log 很痛

思考一個問題：平時你在寫 Go 工程時，是否很少直接使用官方標準庫 log？

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

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

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

除此之外，在用戶場景上，有著不包含上下文（context）信息、性能不夠強勁、無法引入自定義插件等擴展訴求?；旧系谌綆炀袑崿F的，基本都用戶的痛點之一。

為什么不早點解決

你可能會想，標準庫 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

該庫目前已經經過 “石錘” 階段，非?？焖俚剡M入了實驗庫，導入地址是：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 的內部流程如下：

• 前端方法（例如：Info）將所傳屬性封裝為 Record 類型的變量。
• 將 Record 類型的變量傳遞給后端方法（例如：Handle）。
• 后端 Handle 方法根據所得 Record，進行對應的格式化、方法調用、日志輸出等具體日志動作。

與其他 Logger 交互

那回到最開始的問題？

如果我們現在要寫一個私有的 Logger，或是復用 Zap。要怎么做？

后端方法，有兩條路：

• 要不走 Record，調用 NewRecord 將其包裝成 Record 類型的變量，再往下傳。
• 要不走 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