2022.10.28インフラWebアプリケーションのログ出力について指針を考えてみたshimoこんにちは、下條です。最近、Webアプリケーションのログ出力の指針について改めて考えてみる機会がありました。弊社ではインフラはほぼAWSを利用していることから、多少汎用的でない記述もありますが、ある程度まとまってきたことからひとつの指針として公開いたします。はじめにシステム開発をする際、ログ設計は非常に重要な工程です。ログというものは実運用に入って障害などがあってからようやく役に立ってくるもので、開発時には意識が向きにくいという部分があるのも事実です。ログを適切に出力し、最大限に活用することで、障害時の調査コスト減、システム運用コストを抑えたり、よりよいサービスを提供する手掛かりにもなります。アプリケーションや開発言語・フレームワークなどにより例外もあると思いますので本ドキュメントはあくまでサンプルとしてご利用ください。本ドキュメントはサーバサイドWebアプリケーションを想定しています。以下のいずれかに永続化することが望ましい。(Fluentdなどにより転送)ただし、何かしらの事情により上記が難しい場合はディスクへの出力のみでもかまわない。その場合、ログでディスク圧迫しないようローテーションや圧縮などの対応を実施する。ログレベル当然ながらできるかぎり詳細なログがあったほうが望ましい。本番環境などではログの出力コストが発生するため、ログレベルを分類し、環境によって適切にログを出し分ける。本来発生せず調査が必要な事象について用いる。非推奨となったAPIの使用、APIの不適切な使用、エラーに近い事象など。即時調査が必要ではないが完全に正常とも異なる事象について用いる。本番環境で最低限必要なレベル。外部API呼び出しのパラメータ・復帰値など。発行されるSQL文やデバッグ用ログ。開発環境ではDEBUG以上、ステージング環境ではDEBUGもしくはINFO以上、本番環境ではINFO以上を出力することを基本とする。ERRORレベルはログ出力する他、Slack等で通知し、即時に異常を検知できるようにする。例外がある言語の場合、予期せぬ例外が発生した場合、例外内容を出力する。(ERRORレベル)HTTPのリクエストパラメータは基本的に全て出力する。パスワードなどの機密情報や個人情報は出力しない。Railsなどフレームワーク側でマスキング機能を提供してくれているものもあるが、そうでない場合はがんばる。(INFOレベル)外部APIをコールする場合、障害時の原因切り分けを容易にするためエンドポイント・リクエスト内容・レスポンス内容を出力する。(INFOレベル)OSコマンドを実行する場合、障害時の原因切り分けを容易にするためコマンドをパラメータ含め全て出力、復帰値を出力する。(INFOレベル)発行したSQLを全て出力する。ログローテーションディスクにログを保存する場合にはディスク容量の枯渇を防ぐためログローテーションの仕組みを導入する。フレームワークで機能が提供されていない場合は、logrotateを用いることを基本とする。ログに出力すべきでない情報について最近、Twitter社でパスワードがログに平文で保存されていたというニュースが話題になった。施行となり、個人情報の保護の重要性は増している。以下はログに出すべきでない情報である。パスワードがログに残らないよう、パスワードはマスキングもしくはログ出力しない。個人情報もマスキングもしくはログに出力しないようにする。経済産業省を参照のこと。個人情報はSQL文含めて注意すること。ELBのログELBはログ出力を有効に設定すること。(デフォルトでは無効なので注意。)おわりに他にもいろいろとあると思いますので、さらにブラッシュアップしてまた後日公開できたらと思います。本ドキュメントが少しでも開発者の皆様のお役に立てば幸いです。ウェブサービス株式会社(DWS)公式ブログ記事URLをコピーしました。