ログ設計ガイドライン

免責事項 有志で作成したドキュメントである。フューチャーには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された開発プロセスや高度な開発支援環境が存在する。本ガイドラインはフューチャーの全ての部署／プロジェクトで適用されているわけではなく、有志が観点を持ち寄って新たに整理したものである相容れない部分があればその領域を書き換えて利用することを想定している。プロジェクト固有の背景や要件への配慮は、ガイドライン利用者が最終的に判断すること。本ガイドラインに必ず従うことは求めておらず、設計案の提示と、それらの評価観点を利用者に提供することを主目的としている掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとする。掲載している情報は予告なく変更する場合がある 対象スコープアプリケーションが出力するログ（アプリログ）が対象AWS

[sora_h]

stdout/errログだけだった。入力以外もユーザーデータを無闇に出力すべきじゃない(運用者の目が焼けるし消すのが大変だから)とかいろいろあるけど、あんまりカバーされてないな

[Akaza]

やっぱフラットにした方がいいかなぁ

[yasuharu519]

フラットな構造で、構造化するの良さそう

[hiroomi]

フラットになってる印象

[superblueplanet]

“は”

[mkusaka]

OpenTelemetry準拠で構造化ログ(JSONLines)や共通スキーマ、severity.textやtrace_id等のキー設計を解説するガイドライン。

[xsde]

私の周りでは付加情報はAPMがつけてくれるのでSeverityとMessage以外は削除した。

[cyph]

現場の知見の積み上げって感じはあるがガイドラインって感じ薄いな。JMXは直接操作しないにしても想定しておいていいと思うけど。

[prograti]

自分だったらAsyncAppenderを使用する場合はneverBlockをtrueにして、監査ログ・決済ログとかだけ同期ログで出力するかな

[yarumato]

“ログキー命名規則 標準的な規約。　Java, Go, Pythonの構造化ロギングライブラリが利用するキー名称をまとめる。Apacheとnginxのアクセスログで利用される標準的なキー名。AWSとGoogle Cloudのログサービスの特別なキー名”

[nguyen-oi]

フューチャーのログ設計ガイド、相変わらずガチすぎる。全開発者が一度は読むべきレベルの完成度