Dockerのログ出力先 - めもおきば

ツイートしてて自己完結してしまったので記録のために。 あーそういや今更だけど、stdoutとstderrはまとめてlogging driverに渡されちゃうのか。どちらなのかはdriverには渡っているのでfluentdに出せばラベル付いてるので、ログのことだけ考えれば仕組み的にはどちらに出しても扱うこと自体には問題が無さそう。 — Aki (@nekoruri) June 22, 2019 デーモンアプリケーションで想定外のエラーが出うるのであれば、構造化ログをstdoutという分離は全然ありうると思う。 — Aki (@nekoruri) June 22, 2019 でもそうしちゃうとエコシステムから外れちゃうので、やっぱり最大公約数としてはparseableなテキストでstdout/stderrかなあという気がしてきた。やはりDockerにfile descripterの概念が欲しい

[shiba_yu36]

“コンソールアプリならstderr、デーモンアプリケーションならstdoutに構造化ログ(JSON)を出してlogging driverで振り分けてparse、stderrは想定外の非構造化エラーログに備える”

[xorphitus]

チャンネル2つじゃ足りない感はあるがDockerの思想と相反するのも筋が悪いので、さて。例えばRailsだとRailsのログ、Unicornログ2種類、何ならNewRelicのログ等あるんだが、この場合はJSONにしてラベル付けたstdoutが正解なのか…

[odan3240]

"デーモンアプリケーションならstdoutに構造化ログ(JSON)を出してlogging driverで振り分けてparse、stderrは想定外の非構造化エラーログに備える"

[Mint0A0yama]

そもそも「stdoutかstderrかはdriverには渡っている」のは初めて知った。awslogsってその辺区別できてない認識だったんだけど…。nginxとか、「JSONでパースできる」か「できないか」でフィルターしている…。

[kencharos]

dockerコンテナのログは何となくstdout でいいかと思ってたけど、その根拠が示されててとても良かった。

[Songmu]

まさしく同様の思考経路を辿っていた