対象者
- 未経験からエンジニアを目指したい！と考えている方
- 経験の浅いエンジニアの方
はじめに
こんにちは。
株式会社メディアテックの和田です。
先日開発チームでログに関する勉強会を行いました。
そこで考えたこと・発見について記載します。
前提
- Webアプリケーション開発を行うチームです
- 発足して2年足らずの比較的若いチームです
開発チームの現状は？
- ログの種類って何があるの？
- 障害発生時に追いかけるのが大変、欲しい情報がない！
ログのベストプラクティスを読んでみた！
正しいログレベルについて
| レベル | 内容 |
|---|---|
| INFO | 障害やエラーを表示しない情報メッセージ |
| WARN | 潜在的な問題があるが、ユーザーエクスペリエンスに影響しないことを示す |
| ERROR | ユーザーエクスペリエンスにいくらか影響する重大な問題であることを示す |
| FATAL | ユーザーエクスペリエンスに大きく影響する致命的なエラーであることを示す |
| DEBUG | アプリの開発者を対象としてデバッグに使用される |
ログ出力が必須である場合
- アプリケーションエラー
- 入力および出力の検証の失敗
- 認証の成功と失敗
- 承認の失敗
- セッション管理の失敗
- 特権の昇格の成功と失敗
- その他のリスクの高いイベント (データのインポートやエクスポートなど)
- ログ記録の初期化
- オプトイン (サービス利用規約など)
ログ出力の検討が必要な場合
- トラブルシューティング
- 監視とパフォーマンスの向上
- テスト
- ユーザー行動の理解
- セキュリティと監査
前職での経験を持ち寄ってみた
- ERRORをログを必要以上に出しすぎて怒られたことがある
- FATAlログを使ったことがある（DB周り）が、そもそもFATALログを使用するような実装をすべきではないのでは？
- IF文を使用してDEBUGログが開発環境のみ出るようにしていた
今後のログとの付き合い方
- サーバーアクションの実行時間が延びることを考慮して、検知するためにWARNログを出してもよさそう
- ログ集計ツールの導入もありかも。現状はExcelに出力して必要なときだけ見ている。
- 障害発生時に必要な情報は都度考慮が必要なので、開発時にログ設計のプロセスを追加してみる（試運転中…）