エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント6件
- 注目コメント
- 新着コメント
![xorphitus xorphitus](https://cdn.profile-image.st-hatena.com/users/xorphitus/profile.png)
![Mint0A0yama Mint0A0yama](https://cdn.profile-image.st-hatena.com/users/Mint0A0yama/profile.png)
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
Dockerのログ出力先 - めもおきば
ツイートしてて自己完結してしまったので記録のために。 あーそういや今更だけど、stdoutとstderrはまと... ツイートしてて自己完結してしまったので記録のために。 あーそういや今更だけど、stdoutとstderrはまとめてlogging driverに渡されちゃうのか。どちらなのかはdriverには渡っているのでfluentdに出せばラベル付いてるので、ログのことだけ考えれば仕組み的にはどちらに出しても扱うこと自体には問題が無さそう。 — Aki (@nekoruri) June 22, 2019 デーモンアプリケーションで想定外のエラーが出うるのであれば、構造化ログをstdoutという分離は全然ありうると思う。 — Aki (@nekoruri) June 22, 2019 でもそうしちゃうとエコシステムから外れちゃうので、やっぱり最大公約数としてはparseableなテキストでstdout/stderrかなあという気がしてきた。やはりDockerにfile descripterの概念が欲しい
2019/07/01 リンク