個人開発しているアプリケーションで、ログの設計を見直した経験をZennにまとめました。
きっかけは、Fargateで動かしていた処理をSQSとLambdaを使う構成に変えた後、うまく動かない処理の原因を調べようとしたことです。エラーが起きていることは分かっても、調査に必要なログがほとんど残っていませんでした。
以前、AIのレビューをきっかけにログへ出してはいけない情報を隠す対策を入れていましたが、その内容を十分に理解できていませんでした。出さないことには意識が向いていても、調査のために何を残すかまでは考えられていなかったのです。
そこで、機能ごとにログへ出してよい項目と、その値をどう扱うかを定義する形に見直しました。実装では、辞書や配列の内側の検査や、例外に含まれる入力値の扱いなど、思っていた以上に考えることがありました。
今回の経験を通して、デプロイした後に問題が起きたとき、原因を調べられる状態まで考えることの大切さを実感しました。具体的な設計と、実装で苦労した点を記事にしています。
https://zenn.dev/yook/articles/logging-policy-for-incident-investigation
