goとログまわりの調査メモ
標準パッケージlog
logとsyslogでAPIが違う
いまどきsyslogも無いから別に良いかも
とはいえsyslog使うことになるときもある
ログレベルが無い
環境ごとにログレベル変えたい
本番ではWARNにして、DEBUGやINFOを出さないようにしたい
大量にリクエストが来るAPIでは、datadog logとかサービスの費用が怖い
複数箇所に吐き出したい
標準エラーとファイルの両方に変えたい
データとして保存したいログとアプリケーションログの吐き出し箇所を変えたい
データとして保存したいログ
広告の接触情報: imp/click/cv
記事の既読情報
記事のFav/Like
ゲームのユーザーアクション
アプリケーションログ
リクエストログ
エラー・パニックログ
ビジネスロジック・推定ロジックのエラーなど
その他のライブラリ
zap
はやい（らしい）
インターフェースだるい
SugaredLoggerつかえ
*zap.Loggerは複数インスタンスが想定されてない？
zap.NewProductionなどで複数つくるとos.Stdoutとos.Stderrで競合する
標準エラーというか同じファイルに複数のロガーが書き出すのがおかしいのか？
とはいえ、やりたいときもあるよな
zapcore.NewTee便利
ログレベルやフォーマットの違うログの書き出しをまとめられる
フィルターがほしい
ログレベルでしかできない
タグみたいなので分けたい
*zap.Loggerを分けるのがよさげだけど競合の話に戻る
タグによるルーティングしたい
zapcore.Coreをラップしてフィルタするのは厳しい
Withを呼ぶと予めEncoderで書き出されるので、あとからフィルターできない
同じログを別々のファイルに別のフォーマットで吐き出したい
標準エラーには視認しやすいフォーマット
ファイルにはJSON
自作するか？
io.Writerでは抽象化レイヤーとして足りない
logrus, go-kit/kit/log など
zapにはzapcore.Coreというinterfaceがある
io.MultiWriterによる多重化ではフォーマットを変えれない
ログライブラリは難しい
ログのパターンは多岐にわたる
速さと汎用性を両立したい
その他
os.Stdoutとos.Stderrの競合問題
*os.Fileはconcurrent safeじゃない
アプリケーションの責任で sync.Mutex で守らないとダメ
複数のログライブラリが混在すると危険
logパッケージはRedirectできる
goaはLogAdapterを差し込める
ログの書き出しに失敗時の対応
書き出しごとにfsyncする？
性能劣化が心配
DBじゃないんだし大げさじゃね？
書き込みエラーってそんな起きないよね
NFSだと心配かも
NFSがSPOFになりそう
ディスク死んだ系まで取り扱う？
ディスク死んだらアプリも死んでるだろ
サーバー死んだら書き込まれ無いかも
アプリでどこまでやる？
zapは標準エラーに通知してくれる
検知は大事