ログおじさん

23時に寝て3時半に起きて眠れそうになかったからそのまま5時からオフィスで作業してた。

システム構成の検討⌗

コンサルタントから顧客要件のヒアリングを行い、プロダクトを提供するインフラのシステム概要を mermaid で書いた。オンプレとクラウド環境のそれぞれを同じコンテナアプリケーションで動かすための構成を検討した。クラウド環境の一例として aws の構成を考えていて、https と http のプロトコル変換のようなことをするには api gateway を経由しないといけないと考えていたら、alb に証明書を設定して api gateway なくてもいけるとはらさんに教えてもらった。昔からできたそうで、なぜか私が長い間ずっと勘違いしていた。また時間があるときに自分でもやってみようと思う。

• AWS Certificate Managerを使用してインターネットからELBへの通信をHTTPS化してみた

Logger の再実装⌗

プロダクトのコアな部分の実装は私がみた方がよいだろうと考えていて、そのうちの1つ Logger の設計がよくなかったので私が作り直した。といっても cybozu-go/log を使った薄いラッパーを設けただけ。チームメンバーからどこでエラーが起きているか追跡しにくいという声があったのでログ出力したところのソースコードの情報を出力しようと考えた。ググればたくさん出てくる。スタックフレームにアクセスする標準パッケージとして runtime を使うとできる。runtime.Caller と runtime.Callers は似て非なる関数のようでファイル名と行番号だけでよければ Caller を使った方がシンプルになると思う。関数名もほしかったら Callers を使ったスタックフレーム自体から取得する必要がある。

func Trace(skip int) (file string, funcName string) {
  pc := make([]uintptr, 15)
  n := runtime.Callers(skip, pc)
  frames := runtime.CallersFrames(pc[:n])
  frame, _ := frames.Next()
  _file := frame.File[strings.Index(frame.File, sourceRepositoryPath)+8:]
  file = fmt.Sprintf("%s:%d", _file, frame.Line)
  return file, frame.Function
}

この情報を cybozu-go/log の map に追加するようなログ関数を提供するようにした。cybozu-go/log は標準の log パッケージに足りないところだけを追加していて、そのシンプルさと拡張性の高さを私は気に入ってよく使っている。私が気に入っているのでもっと有名になってほしい。

前のお手伝いでもログ基盤を含めて Logger を作っていて、またいまも Logger を作り直していて、気付いたら私は Logger やログ出力に一家言あるような、ログおじさんになりつつある。