ウェブサービスのログ設計についてメモ
ログの設計について、ググっても断片的にしか見つからなかったのでメモ。
ログの目的
- 不具合の原因を特定するため
- 不正利用の検出
- 利用統計の取得
ログレベル
- fatal
サービス全体の提供が不可能な状態になる状態。DBに接続できないとか、syntaxエラーがある場合など。このレベルのログが出るとインフラ担当の人達にメールが飛んだりする。
- error
全体が止まるほどではないが、ユーザーの一部の処理が完了しないような場合が該当する。エラーページが表示されるような場合はこのレベル。
- warn
言語自体のwarningや処理フロー上来ることがない値がかえって来た場合などはこのレベル。(例えばユーザーが不正にAPIを叩いてブロックされた時とか) 状況によってはerror相当なので場合によりけり。
- info
このレベルから下は開発者の胃を傷めないログレベル。アクセスログなど。hadoopでコネコネしたりして企画担当が利用したりする。
- debug
これ以下は開発時に欲しい情報。本番環境では出力しない。
- trace
println("ここまで処理が来た")
何をログとして残すか
例えばユーザーの行動についてなら
- [いつ]アクセス日時
- [誰が]ユーザ情報(ID)/ホスト/ポート/ユーザーエージェント
- [何をした] ログファイルを切り替えてファイル名で表現する(例)login_failure.log
異なるファイルにログを出力するのは重要。特定のログに素早くアクセスでき、かつログの種類によって保存期間や閲覧権限を変えたりできる。機能とユーザー数が増えるほどその恩恵にあずかれる。
ログをどれだけの期間保存するか。
ログの重要度と書き込み頻度によって決める。
(容量肥大対策の一例)
ログを一日ごとのログローテーションで記録し、３０日間保存する場合、前日のログはすぐアクセスできるようにファイル圧縮して同じディレクトリにおき、それ以前はバックアップサーバーに送って30日前まで保存するようにするなど。
ログのドキュメントに何を書くか。
ドキュメントを整備・保守しつづけないと、「どこで使用されているかわからないので消せないログ出力」が生まれてコードのエントロピーが増大する。
ログに何を書いてはいけないか
メールアドレスなどの特に重要な個人情報をログに残さないようにする。
ログに書くこと
- 作成者
- 出力条件
(例)認証キー発行APIを実行した時
- 利用目的
(例)不正利用がないか記録を残します
- フォーマット
- ログの例
ログ設計について何かよい資料があったら誰か教えてください。
