List of Logger [text.Baldanders.info]

Go 1.21.0 がリリースされた

2023-08-09T04:58:32+00:00

予定通り8月に Go 1.21.0 がリリースされた。

お気づきだろうか。今回のバージョン番号は 1.21 ではなく 1.21.0 なのですよ。これからは2月8月の初期リリースでも後ろにちゃんと 1.xx.0 って付けるんだってさ。これで Go の機械的なバージョン管理がしやすくなると思う。

Windows 7, 8, Server 2008, Server 2012 サポート終了のお知らせ

1.21 からは Windows 10 および Windows Server 2016 が最低要件となる。それより前の Windows バージョンに対応するには 1.20 系が必要。それでも2024年2月でサポートが終わるんだよな。

log/slog パッケージ

個人的に最大のトピックはこれ。 log/slog 構造化ログパッケージが追加されたこと。これでサードパーティの logger も log/slog パッケージの下に統合されることを期待したい。

ログなんて「詳細」ですよ。偉い人には分からんのです。

min/max 組み込み関数

多分，他の言語の人には「今までなかったんかい！」ってツッコまれるんだろうなぁ。マジでなかったんスよ。つか，いわゆる Generics が導入されてようやく実現したというか。

slices, maps, cmp パッケージ

slices, maps, cmp 各パッケージの追加も Generics 導入の恩恵だよね。何せ，今までは配列要素の反転（reverse）でさえ自前で

func reverse(s []int) {
    for i, j := 0, len(s)-1; i < j; i, j = i+1, j-1 {
        s[i], s[j] = s[j], s[i]
    }
}

プログラミング言語Goより

てな感じに書いてたんだぜ。クールだろ（笑）

こうやって Go の標準ライブラリのイケてないところが徐々に解消されていくといいねぇ。 math/rand/v2 のプロポーザルとか見てても，着々と Go 2 に進んでる気がする。

例によって…

Ubuntu の APT で管理している Go コンパイラは古いので，ダウンロードページからバイナリ（go1.21.0.linux-amd64.tar.gz）を取ってきてインストールすることを強く推奨する。以下は完全手動での作業例。

$ cd /usr/local/src
$ sudo curl -L "https://go.dev/dl/go1.21.0.linux-amd64.tar.gz" -O
$ cd ..
$ sudo unlink go # 以前の Go が入っている場合
$ sudo tar xvf src/go1.21.0.linux-amd64.tar.gz
$ sudo mv go go1.21.0
$ sudo ln -s go1.21.0 go
$ go version # /usr/local/go/bin にパスが通っている場合
go version go1.21.0 linux/amd64

Windows は Scoop 経由で OK

複数バージョンの Go コンパイラを扱いたい場合は

$ go install golang.org/dl/go1.21.0@latest
$ go1.21.0 download
$ go1.21.0 version
go version go1.21.0 linux/amd64

てな感じで導入できる。

アップデートは計画的に。

ブックマーク

（随時追加予定）

公式の構造化 Logger (になるかもしれない) slog パッケージ

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

著者のひとりは（あの「バイブル」とも呼ばれる）通称 “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

初めてのGo言語 ―他言語プログラマーのためのイディオマティックGo実践ガイド: Jon Bodner (著), 武舎広幸 (翻訳); オライリージャパン 2022-09-26; 単行本（ソフトカバー）; 4814400047 (ASIN), 9784814400041 (EAN), 4814400047 (ISBN); 評価

2021年に出た “Learning Go” の邦訳版。私は版元で PDF 版を購入。 Go 特有の語法（idiom）を切り口として Go の機能やパッケージを解説している。 Go 1.19 対応。

reviewed by Spiegel on 2022-10-11 (powered by PA-APIv5)

実用 Go言語 ―システム開発の現場で知っておきたいアドバイス: 渋川よしき (著), 辻大志郎 (著), 真野隼記 (著); オライリージャパン 2022-04-22; 単行本（ソフトカバー）; 4873119693 (ASIN), 9784873119694 (EAN), 4873119693 (ISBN); 評価

版元のデジタル版を購入。 Go で躓きやすい点を解説していくのが最初の動機らしい。「◯◯するには」を調べる際にこの本を調べるといいかも。

reviewed by Spiegel on 2022-10-26 (powered by PA-APIv5)

Go言語による並行処理: Katherine Cox-Buday (著), 山口能迪 (翻訳); オライリージャパン 2018-10-26; 単行本（ソフトカバー）; 4873118468 (ASIN), 9784873118468 (EAN), 4873118468 (ISBN); 評価

Eブック版もある。感想はこちら。 Go 言語で並行処理を書くならこの本は必読書になるだろう。

reviewed by Spiegel on 2020-01-13 (powered by PA-APIv5)

Go言語による分散サービス ―信頼性、拡張性、保守性の高いシステムの構築: Travis Jeffery (著), 柴田芳樹 (翻訳); オライリージャパン 2022-08-03; 単行本（ソフトカバー）; 4873119979 (ASIN), 9784873119977 (EAN), 4873119979 (ISBN); 評価

版元でデジタル版を購入。読書会の課題図書。ハンズオンぽい構成でコードがたくさん書かれているのがよい。

reviewed by Spiegel on 2022-08-03 (powered by PA-APIv5)

Goならわかるシステムプログラミング第2版: 渋川よしき (著), ごっちん (イラスト); ラムダノート 2022-03-23; 単行本（ソフトカバー）; 4908686122 (ASIN), 9784908686122 (EAN), 4908686122 (ISBN); 評価

第1版はとてもためになる内容だったので第2版も PDF 版で確保しておく。

reviewed by Spiegel on 2022-10-08 (powered by PA-APIv5)

デベロッパーゴースーパーゴラン Tシャツ: Geek Go Super Golang Tees; ウェア&シューズ; B09C2XBC2F (ASIN); 評価

ついカッとなってポチった。反省はしない

reviewed by Spiegel on 2022-04-10 (powered by PA-APIv5)

Zap と go-log を試す

2023-05-20T09:14:08+00:00

最近 Bluesky で遊んでいるのだが，これの公式 Go パッケージってのがあって

bluesky-social/indigo: Go source code for Bluesky’s atproto services. NOT STABLE (yet)

中を見ると logger として ipfs/go-log パッケージを使ってるみたいなのね。 ipfs/go-log パッケージは zap のラッパーになっていて，特にログ出力周りの取り回しが楽になるよう設計されているっぽい。

zap は高速な構造化ロギングを謳っている人気のログ・パッケージである。といっても，ベンチマークを見る限り

Package Time Time % to zap Objects Allocated

zap 1744 ns/op +0% 5 allocs/op

zap (sugared) 2483 ns/op +42% 10 allocs/op

zerolog 918 ns/op -47% 1 allocs/op

go-kit 5590 ns/op +221% 57 allocs/op

slog 5640 ns/op +223% 40 allocs/op

apex/log 21184 ns/op +1115% 63 allocs/op

logrus 24338 ns/op +1296% 79 allocs/op

log15 26054 ns/op +1394% 74 allocs/op

Package	Time	Time % to zap	Objects Allocated
zap	1744 ns/op	+0%	5 allocs/op
zap (sugared)	2483 ns/op	+42%	10 allocs/op
zerolog	918 ns/op	-47%	1 allocs/op
go-kit	5590 ns/op	+221%	57 allocs/op
slog	5640 ns/op	+223%	40 allocs/op
apex/log	21184 ns/op	+1115%	63 allocs/op
logrus	24338 ns/op	+1296%	79 allocs/op
log15	26054 ns/op	+1394%	74 allocs/op

via uber-go/zap: Blazing fast, structured, leveled logging in Go.

スピードだけなら rs/zerolog のほうがだいぶ速いように見えるのだが… まぁ，でも， gRPC や分散システムなんかでは事実上の標準みたいな感じになってるし，柔軟なカスタマイズができるためクラウドのログ管理サービスとかとも相性がいいらしい。

私個人は rs/zerolog 推しだが indigo を使うなら zap & go-log も使えるようになっておこうというわけで試してみることにした。今回は特に拙作の goark/errs との相性という観点で評価してみる。

Zap を試してみる

いきなりサンプルコードから。

package main

import (
    "os"

    "github.com/goark/errs"
    "go.uber.org/zap"
)

func checkFileOpen(path string) error {
    file, err := os.Open(path)
    if err != nil {
        return errs.New(
            "file open error",
            errs.WithCause(err),
            errs.WithContext("path", path),
        )
    }
    defer file.Close()

    return nil
}

func main() {
    logger := zap.NewExample()
    defer logger.Sync()

    path := "not-exist.txt"
    if err := checkFileOpen("not-exist.txt"); err != nil {
        logger.Error("error in checkFileOpen function", zap.Error(err), zap.String("file", path))
    }
}

これを実行すると

$ go run sample1.go | jq .
{
  "level": "error",
  "msg": "error in checkFileOpen function",
  "error": "file open error: open not-exist.txt: no such file or directory",
  "errorVerbose": "{\"Type\":\"*errs.Error\",\"Err\":{\"Type\":\"*errors.errorString\",\"Msg\":\"file open error\"},\"Context\":{\"function\":\"main.checkFileOpen\",\"path\":\"not-exist.txt\"},\"Cause\":{\"Type\":\"*fs.PathError\",\"Msg\":\"open not-exist.txt: no such file or directory\",\"Cause\":{\"Type\":\"syscall.Errno\",\"Msg\":\"no such file or directory\"}}}",
  "file": "not-exist.txt"
}

案の定 zap.Error() ではエラーメッセージを吐き出すだけのようだ。 errorVerbose 項目は Error() メソッドを %+v 書式で出力してる感じなのだろうか。でも，テキストとして出力してるんじゃ「構造化」とは言えない。困ったね。

zapcore.ObjectMarshaler

Zap には zap.Object() 関数があって，これを使えば内部構造を出力することができるのだが，そのためには対象のオブジェクトが zapcore.ObjectMarshaler 型の interface を満たす必要がある。

type ObjectMarshaler interface {
    MarshalLogObject(ObjectEncoder) error
}

一瞬 errs.Error 型にこのメソッドを生やすことも考えたのだが，汎用エラー構造体が特定のサードパーティ・パッケージに依存するのは面白くない。

zapobject モジュールを作った

というわけで，新たに goark/errs/zapobject モジュールを作った。

zapobject.New(err)

という感じにエラーインスタンスをラップして使う。

ちなみに errs と zapobject は同一リポジトリにあるが，モジュールを分けている。 errs は zapobject に依存しないため errs の依存関係を汚さずに zap.Object() 関数に対応できる。ついでに言うと， errs.Error 型以外の error 型についても zapobject.New() でラップすれば Unknown() メソッドの挙動に従って可能な限り構造化して出力できるようにしている。

では，先程のコードを書き換えよう（一部省略している）。

package main

import (
    "os"

    "github.com/goark/errs"
    "github.com/goark/errs/zapobject"
    "go.uber.org/zap"
)

func checkFileOpen(path string) error {
    ...
}

func main() {
    logger := zap.NewExample()
    defer logger.Sync()

    path := "not-exist.txt"
    if err := checkFileOpen("not-exist.txt"); err != nil {
        logger.Error("error in checkFileOpen function", zap.Object("error", zapobject.New(err)), zap.String("file", path))
    }
}

これを実行すると

$ go run sample2.go | jq .
{
  "level": "error",
  "msg": "error in checkFileOpen function",
  "error": {
    "type": "*errs.Error",
    "msg": "file open error: open not-exist.txt: no such file or directory",
    "error": {
      "type": "*errors.errorString",
      "msg": "file open error"
    },
    "cause": {
      "type": "*fs.PathError",
      "msg": "open not-exist.txt: no such file or directory",
      "cause": {
        "type": "syscall.Errno",
        "msg": "no such file or directory"
      }
    },
    "context": {
      "function": "main.checkFileOpen",
      "path": "not-exist.txt"
    }
  },
  "file": "not-exist.txt"
}

となった。うんうん。ちゃんとエラー構造が出力されているね。

ipfs/go-log を試してみる

Zap で拙作の errs.Error 型の構造を出力できるようになったので，次は ipfs/go-log を試してみる。こちらもいきなりサンプルコードから。

package main

import (
    "os"

    "github.com/goark/errs"
    "github.com/goark/errs/zapobject"
    "github.com/ipfs/go-log/v2"
)

func checkFileOpen(path string) error {
    ...
}

func main() {
    logger := log.Logger("sample")

    path := "not-exist.txt"
    if err := checkFileOpen("not-exist.txt"); err != nil {
        logger.Errorw("error in checkFileOpen function", "error", zapobject.New(err), "file", path)

    }
}

log.Logger() 関数で生成される logger の中身はは以下のようになっている。

// ZapEventLogger implements the EventLogger and wraps a go-logging Logger
type ZapEventLogger struct {
    zap.SugaredLogger
    // used to fix the caller location when calling Warning and Warningf.
    skipLogger zap.SugaredLogger
    system     string
}

見ての通り中身は zap.SugaredLogger 型になっている。このため構造化ログを出力する場合は Errorw() などのメソッドを使う必要がある。 zap.SugaredLogger はちょっと… というのであれば Deshugar() すればよい。

logger.Desugar().Error("error in checkFileOpen function", zap.Object("error", zapobject.New(err)), zap.String("file", path))

さて，これを実行してみる。

$ go run sample3.go | jq .
2023-05-20T17:04:40.794+0900    ERROR    sample    sample3/sample3.go:30    error in checkFileOpen function    {"error": {"type": "*errs.Error", "msg": "file open error: open not-exist.txt: no such file or directory", "error": {"type": "*errors.errorString", "msg": "file open error"}, "cause": {"type": "*fs.PathError", "msg": "open not-exist.txt: no such file or directory", "cause": {"type": "syscall.Errno", "msg": "no such file or directory"}}, "context": {"function": "main.checkFileOpen", "path": "not-exist.txt"}}, "file": "not-exist.txt"}

おぅふ orz

ipfs/go-log は出力先や出力フォーマットを環境変数で制御する。主な環境変数は以下の通り

環境変数	値
`GOLOG_LOG_LEVEL`	`debug`, `info`, `warn`, `error`, `dpanic`, `panic`, `fatal`
`GOLOG_FILE`	ファイルに出力する場合はパスをセットする
`GOLOG_OUTPUT`	`stdout`, `stderr`, `file`
`GOLOG_LOG_FMT`	`color`, `nocolor`, `json`

GOLOG_LOG_LEVEL はシステムごとに指定できる。

export GOLOG_LOG_LEVEL="error,subsystem1=info,subsystem2=debug"

GOLOG_OUTPUT は複数の出力先を指定できる。 + で区切って指定すればよい。

export GOLOG_FILE="/path/to/my/file.log"
export GOLOG_OUTPUT="stderr+file"

というわけで，環境変数を指定して改めて起動してみる。

$ export GOLOG_LOG_FMT="json"

$ export GOLOG_OUTPUT="stdout"

$ go run sample3.go | jq .
{"level":"error","ts":"2023-05-20T17:35:29.669+0900","logger":"sample","caller":"sample3/sample3.go:30","msg":"error in checkFileOpen function","error":{"type":"*errs.Error","msg":"file open error: open not-exist.txt: no such file or directory","error":{"type":"*errors.errorString","msg":"file open error"},"cause":{"type":"*fs.PathError","msg":"open not-exist.txt: no such file or directory","cause":{"type":"syscall.Errno","msg":"no such file or directory"}},"context":{"function":"main.checkFileOpen","path":"not-exist.txt"}},"file":"not-exist.txt"}
{
  "level": "error",
  "ts": "2023-05-20T17:35:29.669+0900",
  "logger": "sample",
  "caller": "sample3/sample3.go:30",
  "msg": "error in checkFileOpen function",
  "error": {
    "type": "*errs.Error",
    "msg": "file open error: open not-exist.txt: no such file or directory",
    "error": {
      "type": "*errors.errorString",
      "msg": "file open error"
    },
    "cause": {
      "type": "*fs.PathError",
      "msg": "open not-exist.txt: no such file or directory",
      "cause": {
        "type": "syscall.Errno",
        "msg": "no such file or directory"
      }
    },
    "context": {
      "function": "main.checkFileOpen",
      "path": "not-exist.txt"
    }
  },
  "file": "not-exist.txt"
}

んー。何故か標準エラー出力にも出るなぁ。まぁ，とりあえず標準出力に JSON 形式で出力できた。

環境変数ではなくコードで設定したい場合もあるだろう。この場合は

func main() {
    cfg := log.GetConfig()
    cfg.Format = log.JSONOutput
    cfg.Stderr = false
    cfg.Stdout = true
    cfg.Level = log.LevelDebug
    log.SetupLogging(cfg)
    logger := log.Logger("sample")

    path := "not-exist.txt"
    if err := checkFileOpen("not-exist.txt"); err != nil {
        logger.Desugar().Error("error in checkFileOpen function", zap.Object("error", zapobject.New(err)), zap.String("file", path))
    }
}

という感じに設定できる。

“caller” は要らん

zap.NewExample() で logger を生成したときには気づかなかったが，実際にはログ出力に既定で "caller" 項目が付くんだねぇ。ファイル名と行番号が付くのはちょっと… と思って外し方を探してみたが

logger := log.Logger("sample").Desugar().WithOptions(zap.WithCaller(false))

という感じに Desugar() した上で WithOptions() を使って明示的に外さないといけないみたい。んー。そこまでするのはなぁ。 logger の型が変わっちゃうし。

いや

logger := log.Logger("sample")
logger.SugaredLogger = *(logger.Desugar().WithOptions(zap.WithCaller(false)).Sugar())

って感じにすればいいのかな。これで動かしてみよう。

$ go run sample3b.go | jq .
{
  "level": "error",
  "ts": "2023-05-20T18:01:52.106+0900",
  "logger": "sample",
  "msg": "error in checkFileOpen function",
  "error": {
    "type": "*errs.Error",
    "msg": "file open error: open not-exist.txt: no such file or directory",
    "error": {
      "type": "*errors.errorString",
      "msg": "file open error"
    },
    "cause": {
      "type": "*fs.PathError",
      "msg": "open not-exist.txt: no such file or directory",
      "cause": {
        "type": "syscall.Errno",
        "msg": "no such file or directory"
      }
    },
    "context": {
      "function": "main.checkFileOpen",
      "path": "not-exist.txt"
    }
  },
  "file": "not-exist.txt"
}

おー。消えた消えた。

まぁ，既に zap をバリバリにカスタマイズして使ってる人には ipfs/go-log はあまりメリットなさそうだけど，これから zap を簡易に使いたいって人にはアリな選択肢かも知れない。

じゃぁ，自作ツールの logger を載せ換えますかね。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

初めてのGo言語 ―他言語プログラマーのためのイディオマティックGo実践ガイド: Jon Bodner (著), 武舎広幸 (翻訳); オライリージャパン 2022-09-26; 単行本（ソフトカバー）; 4814400047 (ASIN), 9784814400041 (EAN), 4814400047 (ISBN); 評価

reviewed by Spiegel on 2022-10-11 (powered by PA-APIv5)

公式の構造化 Logger (になるかもしれない) slog パッケージ

2022-11-12T12:26:57+00:00

今日の「第4回『Go言語による分散サービス』オンライン読書会」で構造化ログについて話題になったのだが（ちなみに『Go言語による分散サービス』のサンプルコードでは構造化ロガーとして zap を利用している），その中で公式の構造化 logger がプロポーザルとして上がってるという話を聞く。どうもこれのことらしい。

この slog パッケージについて解説記事も見つけたので，これも参考にしながら少し遊んでみようと思う。

2022年10月末時点で，このパッケージについては

In late August 2022, Jonathan Amsterdam of the Go team initiated a discussion with the community about adding structured, log-level support for logging packages to the Go standard library, and formed a consensus proposal.

Jonathan Amsterdam has named the structured logging package slog and plans to put it under log/slog. He also gave the initial implementation of slog under golang.org/x/exp, and the Proposal is officially in review these days. It is not known when it will be officially implemented in the official version of Go.

via slog: Golang's official structured logging package - SoByte

という感じらしい。実際に design doc が公開されレビューが行われているということなら多少は期待してもいいかもしれない。公式になるといいな。

試しに簡単なコードを書いてみよう。

package main

import (
    "os"

    "golang.org/x/exp/slog"
)

func main() {
    slog.SetDefault(slog.New(slog.NewTextHandler(os.Stderr)))
    slog.Info("hello world")
}

これを実行すると

$ go run sample1.go 
time=2022-11-12T19:00:27.704+09:00 level=INFO msg="hello world"

という感じに KEY=VALUE スタイルのログを出力する。またバックエンド側のハンドラを

package main

import (
    "os"

    "golang.org/x/exp/slog"
)

func main() {
    slog.SetDefault(slog.New(slog.NewJSONHandler(os.Stderr)))
    slog.Info("hello world")
}

と差し替えることで

$ go run sample2.go 
{"time":"2022-11-12T19:45:51.816529605+09:00","level":"INFO","msg":"hello world"}

と JSON スタイルの出力に切り替えることもできる。この出力ハンドラは自作することもでき，たとえば zap や zerolog といったサードパーティの logger に接続することもできるらしい。

via slog: Golang's official structured logging package - SoByte

もう少し遊んでみよう。 error 値を出力するコードを書いてみる。

package main

import (
    "context"
    "os"

    "github.com/goark/errs"
    "golang.org/x/exp/slog"
)

func checkFileOpen(path string) error {
    file, err := os.Open(path)
    if err != nil {
        return errs.Wrap(
            err,
            errs.WithContext("path", path),
        )
    }
    defer file.Close()
    return nil
}

func main() {
    logger := slog.New(slog.NewJSONHandler(os.Stderr)).WithContext(context.TODO())
    logger.Enabled(slog.DebugLevel)

    if err := checkFileOpen("not-exist.txt"); err != nil {
        logger.Error("open error", err)
    } else {
        logger.Info("no error")
    }
}

これを実行すると

$ go run sample3.go 
{"time":"2022-11-12T20:32:38.775783665+09:00","level":"ERROR","msg":"open error","err":"open not-exist.txt: no such file or directory"}

となる。まぁ，予想通り。

でも，拙作の errs パッケージは errs.Error.MarshalJSON() メソッドを持っているので JSON 形式で出力して欲しい。苦肉の策で

logger.Error("open error", err)

を

logger.Error("open error", err, slog.Any("info", err))

としてみたが，結果は

$ go run sample4.go 
{"time":"2022-11-12T20:54:04.358245853+09:00","level":"ERROR","msg":"open error","info":"open not-exist.txt: no such file or directory","err":"open not-exist.txt: no such file or directory"}

となる。ソースコードを見ると fmt.Sprint(v.any) なる記述が見れるので error 型は問答無用で Error() メソッドが出力する文字列に変換されてしまうようだ。ふむむー。ひょっとしたら slog.JSONHandler を参考に独自のハンドラを組めばどうにかなるかもしれんが，今回は止めておこう。ホンマに公式になるかどうか分からんし（笑）

ともかく，公式の構造化 logger が登場すればログ周りのシーンはかなり変わるだろう。楽しみなことである。

ブックマーク

参考図書

Go言語による分散サービス ―信頼性、拡張性、保守性の高いシステムの構築: Travis Jeffery (著), 柴田芳樹 (翻訳); オライリージャパン 2022-08-03; 単行本（ソフトカバー）; 4873119979 (ASIN), 9784873119977 (EAN), 4873119979 (ISBN); 評価

版元でデジタル版を購入。読書会の課題図書。ハンズオンぽい構成でコードがたくさん書かれているのがよい。

reviewed by Spiegel on 2022-08-03 (powered by PA-APIv5)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

初めてのGo言語 ―他言語プログラマーのためのイディオマティックGo実践ガイド: Jon Bodner (著), 武舎広幸 (翻訳); オライリージャパン 2022-09-26; 単行本（ソフトカバー）; 4814400047 (ASIN), 9784814400041 (EAN), 4814400047 (ISBN); 評価

reviewed by Spiegel on 2022-10-11 (powered by PA-APIv5)

Java 製 Logger “Log4j” の脆弱性について

2021-12-11T06:22:43+00:00

私の Twitter TL では 2021-12-10 あたりからちらほら見かけるようになったが Java 製の事実上の標準 logger である Apache Log4j に脆弱性があったそうで，最新版 2.15.0 のアナウンスが出ている。ちょっと大事になりそうな気がするので，この記事で覚え書きとして残しておく。

CVE-2021-44228

Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default.

via Log4j – Apache Log4j Security Vulnerabilities

ちょっと分かりにくいかもしれないので，以下の解説記事も参考にどうぞ。

今回問題となっているのはJndi Lookupだ。これはJavaのJava Naming and Directory Interfaceによる変数名の置換で、ネットワーク越しに変数に相当する値を検索することができる。その中にLDAPも含まれる。例えば"${jndi:ldap://someremoteclass}"のようになる。

問題は、このURLに.を含めることにより、lg4jは任意のリモートのLDAPサーバーからjava classファイルをダウンロードして読み込んでしまうのだ。

なので悪意あるjava classファイルとそれをホストするLDAPサーバーを用意して、ターゲットとなるJavaで動きlog4jを使っているプログラムに"${jndi:ldap://URL}"の形でログ出力されるようにすれば、任意のコード実行が可能になる。

log4jの脆弱性についてより

ここまで言及されれば今回の脆弱性のヤバさが分かるだろう。サービス側にログが吐かれるだけでこの脆弱性が発火する可能性があるのだ。これは私達が目にしている各種サービスだけではなく，たとえばバックエンドで外部の Web API サービスを利用しているのならそちらも考慮する必要がある。あるいは，もしかしたら組込み製品でアプリケーションを Java で組んでいるかもしれない。

Apache Log4j はこの脆弱性の CVSS 評価値を

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
深刻度: 緊急 (Score: 10)

基本評価基準	評価値
攻撃元区分	ネットワーク
攻撃条件の複雑さ	低
必要な特権レベル	不要
ユーザ関与レベル	不要
スコープ	変更あり
機密性への影響	高
完全性への影響	高
可用性への影響	高

と見積もっている。

一応，サービス側の緩和措置も示されているので「すぐに対応できないよー」という場合は参考にするといいだろう。

In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

via Log4j – Apache Log4j Security Vulnerabilities

とりあえずシステム・プロパティまたは環境変数で対応って感じかねぇ。

アップデートは計画的に。

【2021-12-15 追記】 CVE-2021-44228

リリースした 2.15.0 に不備があったため 2.16.0 がリリースされている。

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration such as to set the system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific vulnerability.

via Log4j – Apache Log4j Security Vulnerabilities

Apache Log4j はこの脆弱性の CVSS 評価値を

CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
(CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L から大幅に引き上げた模様【2021-12-18 追記】)
深刻度: 緊急 (Score: 9)

基本評価基準	評価値
攻撃元区分	ネットワーク
攻撃条件の複雑さ	高
必要な特権レベル	不要
ユーザ関与レベル	不要
スコープ	変更あり
機密性への影響	高
完全性への影響	高
可用性への影響	高

と見積もっている。

前節で示した緩和策は使えないらしい。 2.16.0 以降に上げられないのであれば

Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

via Log4j – Apache Log4j Security Vulnerabilities

と class ファイルを削除する必要がある。

【2021-12-20 追記】 CVE-2021-45105

先日リリースされた 2.16.0 には以下の脆弱性があり，これを緩和する 2.17.0 がリリースされた。

Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack.

via Log4j – Apache Log4j Security Vulnerabilities

Apache Log4j はこの脆弱性の CVSS 評価値を

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
深刻度: 重要 (Score: 7.5)

基本評価基準	評価値
攻撃元区分	ネットワーク
攻撃条件の複雑さ	低
必要な特権レベル	不要
ユーザ関与レベル	不要
スコープ	変更なし
機密性への影響	なし
完全性への影響	なし
可用性への影響	高

と見積もっている。

また別の緩和手順として

In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).

Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.

via Log4j – Apache Log4j Security Vulnerabilities

を挙げている。

【2021-12-15 追記】 Logback にも脆弱性（の可能性）あり

Logback バージョン 1.2.8 がリリースされている。このバージョンでは LOGBACK-1591 に絡む対応が行われている。ただし，これが脆弱性として発火するとしても以下の前提条件が必要となる。

write access to logback.xml

use of versions < 1.2.8

reloading of poisoned configuration data, which implies application restart or scan="true" set prior to attack

via News

LOGBACK-1591 は現時点（2021-12-15）ではまだ確定的ではないが，予防措置として log4j と同じく JNDI lookup コードを削除することにしたようだ。

ブックマーク

Minecraft では既に影響が出ている模様：

Critical RCE exploit discovered on all Minecraft
Java versions from 1.7 to 1.18, clients and servers. (Log4j2 2.0.0 - 2.14.1 vuln)
Fix it w:
- Use -Dlog4j2.formatMsgNoLookups=true
- Update Fabric Loader to 0.12.9
- Upgrade Paper server to latest 1.18
- Wait for mojang patches
— Minecraft@Home (@minecraftathome) December 10, 2021

参考図書

Spring Data JPAプログラミング入門: 溝口賢司 (著); 秀和システム 2017-08-03 (Release 2018-04-23); Kindle版; B07CKHR8C1 (ASIN); 評価

JPA のお勉強用に購入。紙のほうはプレミアが付いてるっぽいが Kindle で買えるよ。固定レイアウトだからブラウザの Kindle Cloud Reader で読めるし。真面目に基本を押さえて書いていて分かりやすい。

reviewed by Spiegel on 2021-08-26 (powered by PA-APIv5)

Effective Java 第3版: Joshua Bloch (著), 柴田芳樹 (翻訳); 丸善出版 2018-10-30; 単行本（ソフトカバー）; 4621303252 (ASIN), 9784621303252 (EAN), 4621303252 (ISBN); 評価

再勉強中。 Kindle 版のほうがちょっと安いが，勤務先でも使いたかったので紙の本にした。

reviewed by Spiegel on 2021-03-17 (powered by PA-APIv5)

Spring Boot 2 入門: 基礎から実演まで: 原田けいと (著), 竹田甘地 (著), Robert Segawa (著); 2020-05-22 (Release 2020-05-22); Kindle版; B0893LQ5KY (ASIN); 評価

Spring Boot を勉強することになって急遽買った本。めっさ分かりやすかった。 PDF 版が欲しいくらい（笑） Spring Boot 3.2 対応にアップデートされていた。素敵！

reviewed by Spiegel on 2024-03-20 (powered by PA-APIv5)

Java言語で学ぶデザインパターン入門第3版: 結城浩 (著); SBクリエイティブ 2021-11-12 (Release 2021-11-13); Kindle版; B09HK66P5X (ASIN); 評価

なんと！結城浩さんのデザパタ本の第3版が出た。古典的なデザインパターン23個はそのままに，最近の Java の言語仕様に合わせてコードが一新されている。

reviewed by Spiegel on 2021-11-13 (powered by PA-APIv5)

Writers パッケージを作ってみた

2020-03-28T11:40:05+00:00

Twitter で

できればLogレベルでファイル分割したいところですが、Goの情報はなかなか見つからなかった...。

Trace/Debug/Info/Warning
Error/Fatal
とかいう好きな単位でログファイルを切り替えられれば、別ツイのtail -f時のノイズ削減になりそう。https://t.co/MTyoOqyvgQ
(分割について記載なすび)
— SIG (@sig_246) March 26, 2020

というのを見かけたので，試しに作ってみた。

spiegel-im-spiegel/writers: Filtering Writer

いや tee および grep コマンドを組み合わせれば出力の分割はできるんだけどね¹。まぁ，言語的に面白いトピックはないし，手遊びということで。

たとえば，拙作の logf パッケージを使ってこんなログ出力を考えてみる。

package main

import (
    "os"

    "github.com/spiegel-im-spiegel/logf"
)

func main() {
    logf.SetOutput(os.Stdout)
    for i := 0; i < 6; i++ {
        logf.SetMinLevel(logf.TRACE + logf.Level(i))
        logf.Tracef("Traceing: No. %d\n", i+1)
        logf.Debugf("Debugging: No. %d\n", i+1)
        logf.Printf("Information: No. %d\n", i+1)
        logf.Warnf("Warning: No. %d\n", i+1)
        logf.Errorf("Erroring: No. %d\n", i+1)
        logf.Fatalf("Fatal Erroring: No. %d\n", i+1)
    }
}

これを実行すると，こんな感じになる。

$ go run sample.go
2020/03/28 14:44:44 [TRACE] Traceing: No. 1
2020/03/28 14:44:44 [DEBUG] Debugging: No. 1
2020/03/28 14:44:44 [INFO] Information: No. 1
2020/03/28 14:44:44 [WARN] Warning: No. 1
2020/03/28 14:44:44 [ERROR] Erroring: No. 1
2020/03/28 14:44:44 [FATAL] Fatal Erroring: No. 1
2020/03/28 14:44:44 [DEBUG] Debugging: No. 2
2020/03/28 14:44:44 [INFO] Information: No. 2
2020/03/28 14:44:44 [WARN] Warning: No. 2
2020/03/28 14:44:44 [ERROR] Erroring: No. 2
2020/03/28 14:44:44 [FATAL] Fatal Erroring: No. 2
2020/03/28 14:44:44 [INFO] Information: No. 3
2020/03/28 14:44:44 [WARN] Warning: No. 3
2020/03/28 14:44:44 [ERROR] Erroring: No. 3
2020/03/28 14:44:44 [FATAL] Fatal Erroring: No. 3
2020/03/28 14:44:44 [WARN] Warning: No. 4
2020/03/28 14:44:44 [ERROR] Erroring: No. 4
2020/03/28 14:44:44 [FATAL] Fatal Erroring: No. 4
2020/03/28 14:44:44 [ERROR] Erroring: No. 5
2020/03/28 14:44:44 [FATAL] Fatal Erroring: No. 5
2020/03/28 14:44:44 [FATAL] Fatal Erroring: No. 6

これを出発点とする。

出力を多重化するには io.MultiWriter() 関数を使うとよい。こんな感じ。

package main

import (
    "fmt"
    "io"
    "os"

    "github.com/spiegel-im-spiegel/logf"
)

func main() {
    file, err := os.Create("log.txt")
    if err != nil {
        fmt.Printf("%#v\n", err)
        return
    }
    defer file.Close()

    ws := io.MultiWriter(
        file,
        os.Stdout,
    )
    logf.SetOutput(ws)
    for i := 0; i < 6; i++ {
        logf.SetMinLevel(logf.TRACE + logf.Level(i))
        logf.Tracef("Traceing: No. %d\n", i+1)
        logf.Debugf("Debugging: No. %d\n", i+1)
        logf.Printf("Information: No. %d\n", i+1)
        logf.Warnf("Warning: No. %d\n", i+1)
        logf.Errorf("Erroring: No. %d\n", i+1)
        logf.Fatalf("Fatal Erroring: No. %d\n", i+1)
    }
}

これで標準出力と log.txt ファイルに全く同じ内容が出力される。

次に，標準出力には [ERROR] と [FATAL] のログのみ出力したい。そこでこんな型を考える。

package writers

//FilterWriter type is Writer with filter
type FilterWriter struct {
    word   []byte
    writer io.Writer
}

この型に対して以下の Write() メソッド

//Write function writes bytes data.
func (w *FilterWriter) Write(b []byte) (int, error) {
    if w.match(b) {
        return w.writer.Write(b)
    }
    return len(b), nil
}

func (w *FilterWriter) match(b []byte) bool {
    if len(b) == 0 {
        return false
    }
    if w.word == nil {
        return true
    }
    return bytes.Contains(b, w.word)
}

を組み込めば，設定したキーワードを含んでいる場合のみ書き込みを行うようになる。

writers.FilterWriter を使って先程のコードを書き換えてみよう。こんな感じ。

package main

import (
    "fmt"
    "io"
    "os"

    "github.com/spiegel-im-spiegel/logf"
    "github.com/spiegel-im-spiegel/writers"
)

func main() {
    file, err := os.Create("log.txt")
    if err != nil {
        fmt.Printf("%#v\n", err)
        return
    }
    defer file.Close()

    ws := io.MultiWriter(
        file,
        writers.Filter(os.Stdout, []byte("[ERROR]")),
		writers.Filter(os.Stdout, []byte("[FATAL]")),
    )
    logf.SetOutput(ws)
    for i := 0; i < 6; i++ {
        logf.SetMinLevel(logf.TRACE + logf.Level(i))
        logf.Tracef("Traceing: No. %d\n", i+1)
        logf.Debugf("Debugging: No. %d\n", i+1)
        logf.Printf("Information: No. %d\n", i+1)
        logf.Warnf("Warning: No. %d\n", i+1)
        logf.Errorf("Erroring: No. %d\n", i+1)
        logf.Fatalf("Fatal Erroring: No. %d\n", i+1)
    }
}

これで標準出力が

$ go run sample.go
2020/03/28 14:44:44 [ERROR] Erroring: No. 1
2020/03/28 14:44:44 [FATAL] Fatal Erroring: No. 1
2020/03/28 14:44:44 [ERROR] Erroring: No. 2
2020/03/28 14:44:44 [FATAL] Fatal Erroring: No. 2
2020/03/28 14:44:44 [ERROR] Erroring: No. 3
2020/03/28 14:44:44 [FATAL] Fatal Erroring: No. 3
2020/03/28 14:44:44 [ERROR] Erroring: No. 4
2020/03/28 14:44:44 [FATAL] Fatal Erroring: No. 4
2020/03/28 14:44:44 [ERROR] Erroring: No. 5
2020/03/28 14:44:44 [FATAL] Fatal Erroring: No. 5
2020/03/28 14:44:44 [FATAL] Fatal Erroring: No. 6

となった。

単純な比較のみだと複雑なパターンを構成し辛いので，正規表現バージョンも作ってみた。

//RegexpWriter type is Writer with regular expression filter
type RegexpWriter struct {
    re     *regexp.Regexp
    writer io.Writer
}

//WriteString function writes string.
func (w *RegexpWriter) Write(b []byte) (int, error) {
    if w.match(b) {
        return w.writer.Write(b)
    }
    return len(b), nil
}

func (w *RegexpWriter) match(b []byte) bool {
    if len(b) == 0 {
        return false
    }
    if w.re == nil {
        return true
    }
    return w.re.Match(b)
}

これを使えば，先程のコードはこんな感じにできる。

package main

import (
    "fmt"
    "io"
    "os"
    "regexp"

    "github.com/spiegel-im-spiegel/logf"
    "github.com/spiegel-im-spiegel/writers"
)

func main() {
    file, err := os.Create("log.txt")
    if err != nil {
        fmt.Printf("%#v\n", err)
        return
    }
    defer file.Close()

    ws := io.MultiWriter(
        file,
        writers.FilterRegexp(os.Stdout, regexp.MustCompile(`\[(ERROR|FATAL)\]`)),
    )
    logf.SetOutput(ws)
    for i := 0; i < 6; i++ {
        logf.SetMinLevel(logf.TRACE + logf.Level(i))
        logf.Tracef("Traceing: No. %d\n", i+1)
        logf.Debugf("Debugging: No. %d\n", i+1)
        logf.Printf("Information: No. %d\n", i+1)
        logf.Warnf("Warning: No. %d\n", i+1)
        logf.Errorf("Erroring: No. %d\n", i+1)
        logf.Fatalf("Fatal Erroring: No. %d\n", i+1)
    }
}

これで同じ結果が得られる。

今回はベースの Writer に出力多重化やらフィルタやらの機能を被せているだけなので，色々と応用が効くだろう。効くといいな（笑）

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

ちなみに Go の標準パッケージにも io.TeeReader() 関数ってのがあって tee コマンドと同等のことができる。 ↩︎

構造化エラーをログ出力する

2019-11-24T05:30:43+00:00

Go 1.13 のリリースに合わせて spiegel-im-spiegel/errs パッケージを公開したのだが，このパッケージで構成した構造化エラーをログ出力することを考える。

まぁ標準の log パッケージでエラーメッセージを出力してもいいのだが，せっかく JSON 形式で出力できるようにしたんだから，ログ出力も JSON 形式にしたいよね。

ちうわけで，今回はこれを使います。てってれー

rs/zerolog: Zero Allocation JSON Logger

まずは準備として以下の関数を考える。

import (
    "os"

    "github.com/spiegel-im-spiegel/errs"
)

func checkFileOpen(path string) error {
    file, err := os.Open(path)
    if err != nil {
        return errs.Wrap(
            err,
            errs.WithContext("path", path),
        )
    }
    defer file.Close()

    return nil
}

ファイルをオープンするだけの関数で，オープンに失敗すると error を返す。 spiegel-im-spiegel/errs パッケージの使い方は

Go 言語用エラーハンドリング・パッケージ

を参考にしてね。

この関数を使った main() 関数を書いてみよう。まずは標準出力に対して書式 %+v を指定して普通に

func main() {
    if err := checkFileOpen("not-exist.txt"); err != nil {
        fmt.Printf("%+v\n", err)
    }
}

と出力する。これの実行結果は

$ go run sample1.go | jq .
{
  "Type": "*errs.Error",
  "Err": {
    "Type": "*os.PathError",
    "Msg": "open not-exist.txt: no such file or directory",
    "Cause": {
      "Type": "syscall.Errno",
      "Msg": "no such file or directory"
    }
  },
  "Context": {
    "function": "main.checkFileOpen",
    "path": "not-exist.txt"
  }
}

てな感じになる。うむうむ。

で，ここからが本題。

fmt.Printf() の部分を rs/zerolog によるログ出力に置き換えてみよう。とりあえず logger インスタンスの生成はこんな感じかな。

logger := zerolog.New(os.Stdout).Level(zerolog.DebugLevel).With().
    Timestamp().
    Str("role", "logger-sample").
    Logger()

まずは普通に error インスタンスをログ出力してみる。

func main() {
    logger := zerolog.New(os.Stdout).Level(zerolog.DebugLevel).With().
        Timestamp().
        Str("role", "logger-sample").
        Logger()

    if err := checkFileOpen("not-exist.txt"); err != nil {
        logger.Error().Err(err).Send()
    }
}

これの実行結果は以下の通り。

$ go run sample2.go
{"level":"error","role":"logger-sample","error":"open not-exist.txt: no such file or directory","time":"2009-11-10T23:00:00Z"}

更に jq コマンドを噛ませるとこんな感じになる。

$ go run sample.go | jq .
{
  "level": "error",
  "role": "logger-sample",
  "error": "open not-exist.txt: no such file or directory",
  "time": "2009-11-10T23:00:00Z"
}

見ての通り zerolog.Event.Err() メソッドでは単純なエラーメッセージしか出力されない（当たり前だが）。通常の error ならこれで十分だが errs.Wrap() 関数でラップした error では不十分である。

そこで zerolog.Event.Interface() メソッドのほうを使ってみる。

func main() {
    logger := zerolog.New(os.Stdout).Level(zerolog.DebugLevel).With().
        Timestamp().
        Str("role", "logger-sample").
        Logger()

    if err := checkFileOpen("not-exist.txt"); err != nil {
        logger.Error().Interface("error", err).Send()
    }
}

これでログ出力は

$ go run sample3.go | jq .
{
  "level": "error",
  "role": "logger-sample",
  "error": {
    "Type": "*errs.Error",
    "Err": {
      "Type": "*os.PathError",
      "Msg": "open not-exist.txt: no such file or directory",
      "Cause": {
        "Type": "syscall.Errno",
        "Msg": "no such file or directory"
      }
    },
    "Context": {
      "function": "main.checkFileOpen",
      "path": "not-exist.txt"
    }
  },
  "time": "2009-11-10T23:00:00Z"
}

てな感じになった。よーし，うむうむ，よーし。

rs/zerolog はパフォーマンスもよく使い勝手のいいパッケージで，しかも JSON 出力できるので加工しやすいだろう。オススメである。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

gpgpdump v0.3.9 他をリリースした

2019-02-11T07:42:15+00:00

いやぁ，この3連休は捗ったよ。

spiegel-im-spiegel/gocli v0.9.1 のリリースについては前回お知らせしたが，続けて以下のツールおよび Go 言語パッケージをリリースした。

これらは特に機能追加はないが lint を golangci-lint に替えたので golangci-lint の指摘を参考にリファクタリングというかデバッグを行った。特に gpgpdump については結構ヤバい潜在バグも見つかったので golangci-lint サマサマという感じである。やっぱ（たとえ網羅的でなくても書けるところまででも）テストは書いておくべきだよね。

そうそう。 mklink の対話モードは gocli/prompt パッケージで全面的に書き換えた。

Flickr の写真を photo.Baldanders.info へ移転するための内部ツールも完成し，とりあえずここのブログの写真（へのリンク）は全部貼り替えた。これでいよいよ本家サイトの改造に取り掛かれるな。その前に Go 言語コンパイラ v1.12 のリリースがあるが。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

Logf Package v0.2.1 Released

2018-03-03T11:11:38+00:00

レベル付き logger パッケージ spiegel-im-spiegel/logf v0.2.1 をリリースした。

spiegel-im-spiegel/logf: Simple leveled logging package by Golang

標準の log パッケージをラップする形で実装している。以下のように lestrrat-go/file-rotatelogs のようなローテーション機能付きの Writer と組み合わせて使うといい感じになる。

package main

import (
	rotatelogs "github.com/lestrrat-go/file-rotatelogs"
	"github.com/spiegel-im-spiegel/logf"
)

func main() {
	rl, err := rotatelogs.New("./log.%Y%m%d%H%M.txt")
	if err != nil {
		logf.Fatal(err)
		return
	}
	logger := logf.New(
		logf.WithFlags(logf.LstdFlags|logf.Lshortfile),
		logf.WithPrefix("[Sample] "),
		logf.WithWriter(rl),
		logf.WithMinLevel(logf.INFO),
	)
	logger.Print("Information")
	//Output:
	//[Sample] 2009/11/10 23:00:00 sample.go:20: [INFO] Information
}

本当は JSON 形式の構造化ログに挑戦しようと思ったのだが，既に出来のいいパッケージが存在したので止めた。

rs/zerolog: Zero Allocation JSON Logger

なので，これ以上 spiegel-im-spiegel/logf を弄ることはないと思う。

ブックマーク

Log パッケージで遊ぶ

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

Log パッケージで遊ぶ

2018-02-26T16:32:43+00:00

今回は Go 言語の標準パッケージに含まれる log について。

log パッケージは，名前の通り，ログ出力を行うパッケージである。例えば以下のように書ける。

package main

import (
    "log"
)

func main() {
    log.Println("Hello, World")
}

これを実行すると以下のフォーマットで標準エラー出力に出力される。

2009/11/10 23:00:00 Hello, World

Log パッケージの中身

具体的に log パッケージを見てみよう。

// A Logger represents an active logging object that generates lines of
// output to an io.Writer. Each logging operation makes a single call to
// the Writer's Write method. A Logger can be used simultaneously from
// multiple goroutines; it guarantees to serialize access to the Writer.
type Logger struct {
    mu     sync.Mutex // ensures atomic writes; protects the following fields
    prefix string     // prefix to write at beginning of each line
    flag   int        // properties
    out    io.Writer  // destination for output
    buf    []byte     // for accumulating text to write
}

// Printf calls l.Output to print to the logger.
// Arguments are handled in the manner of fmt.Printf.
func (l *Logger) Printf(format string, v ...interface{}) {
    l.Output(2, fmt.Sprintf(format, v...))
}

// Output writes the output for a logging event. The string s contains
// the text to print after the prefix specified by the flags of the
// Logger. A newline is appended if the last character of s is not
// already a newline. Calldepth is used to recover the PC and is
// provided for generality, although at the moment on all pre-defined
// paths it will be 2.
func (l *Logger) Output(calldepth int, s string) error {
    now := time.Now() // get this early.
    var file string
    var line int
    l.mu.Lock()
    defer l.mu.Unlock()
    if l.flag&(Lshortfile|Llongfile) != 0 {
        // Release lock while getting caller info - it's expensive.
        l.mu.Unlock()
        var ok bool
        _, file, line, ok = runtime.Caller(calldepth)
        if !ok {
            file = "???"
            line = 0
        }
        l.mu.Lock()
    }
    l.buf = l.buf[:0]
    l.formatHeader(&l.buf, now, file, line)
    l.buf = append(l.buf, s...)
    if len(s) == 0 || s[len(s)-1] != '\n' {
        l.buf = append(l.buf, '\n')
    }
    _, err := l.out.Write(l.buf)
    return err
}

ログ出力時は log.Logger 内部のバッファを使って整形するため，複数の goroutine から非同期に呼ばれる可能性を考慮し， sync.Mutex を使って排他的に処理している。

Log のカスタマイズ

log パッケージではログの出力先や出力フォーマットをある程度カスタマイズできる。たとえば，こんな感じ。

package main

import (
    "log"
    "os"
)

func main() {
    log.SetFlags(log.LstdFlags | log.Lmicroseconds | log.Lshortfile)
    log.SetOutput(os.Stdout)
    log.SetPrefix("[Hello] ")

    log.Println("Hello, World")
}

この場合，以下の形式で標準出力に出力される。

[Hello] 2009/11/10 23:00:00.000000 main.go:13: Hello, World

また log.New() 関数で新たな log.Logger インスタンスを作成することもできる。

package main

import (
    "log"
    "os"
)

func main() {
    l := log.New(os.Stdout, "[Hello] ", log.LstdFlags|log.Lmicroseconds|log.Lshortfile)

    l.Println("Hello, World")
}

このコードのログ出力は先ほどと同じになる。

出力レベルとフィルタリング

log パッケージの欠点は出力のフィルタリングができないことである。ログメッセージ毎に ERROR, WARN, INFO, DEBUG といった出力レベルの設定を行い，あらかじめ指定したレベル以下のメッセージについてはフィルタリングできる仕掛けが欲しいところである。

サードパーティーではフィルタリング機能を持つ logger が色々あるが，せっかく log パッケージが「できる子」なんだから，なるべく生かした形で実装を考えてみる。

フィルタリング付き Writer

まずは，出力時にフィルタリングを行う Writer を考えてみる。有り難いことに既にこの機能を持ったパッケージが存在する。

hashicorp/logutils: Utilities for slightly better logging in Go (Golang).

これは log.Logger インスタンスにセットする Writer をラップしてフィルタリング機能を付加するものである。こんな感じで使うらしい。

package main

import (
    "log"
    "os"

    "github.com/hashicorp/logutils"
)

func main() {
    filter := &logutils.LevelFilter{
        Levels:   []logutils.LogLevel{"DEBUG", "WARN", "ERROR"},
        MinLevel: logutils.LogLevel("WARN"),
        Writer:   os.Stderr,
    }
    log.SetOutput(filter)

    log.Print("[DEBUG] Debugging")         // this will not print
    log.Print("[WARN] Warning")            // this will
    log.Print("[ERROR] Erroring")          // and so will this
    log.Print("Message I haven't updated") // and so will this
}

これを実行するとこんな感じになる。

2009/11/10 23:00:00 [WARN] Warning
2009/11/10 23:00:00 [ERROR] Erroring
2009/11/10 23:00:00 Message I haven't updated

あらかじめキーワード（"DEBUG" など）を決めておいて，ログ出力する文字列にこのキーワードを埋め込むことで出力レベルの設定とフィルタリングを行うようだ。実際には埋め込むキーワードの typo を防ぐために何らかの仕掛けを作る必要があると思うが，とてもシンプルな作りなので，気軽に導入できそうである。

Logger に渡す前にフィルタリングする

hashicorp/logutils は Writer への書き込み時にフィルタリングを行うものだったが，別のアプローチで log.Logger に渡す前にフィルタリングすることを考えてみる。というわけで作ってみた。

spiegel-im-spiegel/logf: Simple logging package by Golang

logf.Logger はこんな感じで log.Logger インスタンス（へのポインタ）を内部に持つ。

//Logger is logger class
type Logger struct {
    lg   *log.Logger // logger
    mu   sync.Mutex  // ensures atomic writes; protects the following fields
    flag int         // properties
    min  Level
}

実際の出力はこんな感じにしてみた。

//Output writes the output for a logging event.
func (l *Logger) Output(lv Level, calldepth int, s string) error {
    if lv >= l.min {
        if (l.flag & Llevel) != 0 {
            return l.lg.Output(calldepth, fmt.Sprintf("[%v] %s", lv, s))
        }
        return l.lg.Output(calldepth, s)
    }
    return nil
}

出力レベルのチェック時に排他処理を行っていないが，値の参照だけで状態を変えるわけではないので，まぁいいかなと。

これを使ってログ出力のコードを書いてみる。

package main

import (
    "os"

    "github.com/spiegel-im-spiegel/logf"
)

func main() {
    logf.SetOutput(os.Stdout)
    logf.SetMinLevel(logf.WARN)

    logf.Debug("Debugging")   // this will not print
    logf.Print("Information") // this will not print
    logf.Warn("Warning")      // this will
    logf.Error("Erroring")    // and so will this
}

これを実行するとこんな感じになる。

2009/11/10 23:00:00 [WARN] Warning
2009/11/10 23:00:00 [ERROR] Erroring

んー。杜撰なコードだが，取り敢えずこんな感じかな。

【追記】ログファイルの分割とローテーション

もうひとつ log パッケージにない機能としてログファイルの分割とローテーション機能がある。たとえば Apache HTTP Server の rotatelogs のような機能があると便利である。

と思って探したらありましたよ。

lestrrat-go/file-rotatelogs: Port of perl5 File::RotateLogs to Go ¹

rotatelogs パッケージと先ほどの logf パッケージを組み合わせれば，こんな感じに書ける。

package main

import (
    rotatelogs "github.com/lestrrat-go/file-rotatelogs"
    "github.com/spiegel-im-spiegel/logf"
)

func main() {
    logf.SetMinLevel(logf.WARN)
    rl, err := rotatelogs.New("./log.%Y%m%d%H%M.txt")
    if err != nil {
        logf.Fatal(err)
        return
    }
    logf.SetOutput(rl)

    logf.Debug("Debugging")   // this will not print
    logf.Print("Information") // this will not print
    logf.Warn("Warning")      // this will
    logf.Error("Erroring")    // and so will this
}

よーし，うむうむ，よーし。

ブックマーク

構造化ログ

rs/zerolog: Zero Allocation JSON Logger : JSON 形式でログを吐く。おススメ
hnakamur/ltsvlog: a minimalist LTSV logging library in Go : LTSV 形式でログを吐く
- GoでLTSV形式でログ出力するライブラリを書いた
- zerologを参考にしてltsvlogを改良してみた

その他

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

lestrrat-go/file-rotatelogs パッケージは Perl の File::RotateLogs から Go 言語へのポーティングのようだ。 ↩︎