ロギング

ロギングとは

ロギングは、アプリケーションの動作をログとして記録し、デバッグ、監視、監査に活用する仕組みである。オブザーバビリティの 3 本柱 (メトリクス、ログ、トレース) の 1 つ。

ログレベル

ログレベルを以下にまとめる。

レベル	用途	例
ERROR	エラー、障害	DB 接続失敗、未処理例外
WARN	警告、潜在的問題	リトライ発生、非推奨 API
INFO	正常な動作の記録	リクエスト処理完了
DEBUG	デバッグ情報	変数の値、処理の詳細

構造化ログ

構造化ログは JSON 形式でログを出力する手法で、CloudWatch Logs Insights などのツールでフィールド単位の検索・集計が可能になる。非構造化ログ (文字列連結) では正規表現に頼るしかなく、分析が困難になる。

// ❌ 非構造化ログ (検索・分析が困難)
console.log('Order processed: ' + orderId + ' in ' + duration + 'ms');

// ✅ 構造化ログ (JSON)
console.log(JSON.stringify({
  level: 'info',
  message: 'Order processed',
  orderId,
  duration,
  timestamp: new Date().toISOString(),
}));

CloudWatch Logs Insights

CloudWatch Logs Insights の例を示す。

-- エラーログを検索
fields @timestamp, @message
| filter level = "error"
| sort @timestamp desc
| limit 20

-- レイテンシの P99 を計算
filter level = "info"
| stats pct(duration, 99) as p99 by bin(1h)

パーセンタイルの関数名は pct であり、percentile という関数名は存在しない (書いてもクエリが通らない)。また filter の文字列比較は大文字と小文字を区別するため、出力側で level の値を小文字に統一していないと filter level = "info" は空振りする。ログレベルの表記ゆれは、検索結果が静かにゼロ件になるという最も気付きにくい形で跳ね返る。

ログの設計指針

ログは JSON 形式で構造化し、リクエストを追跡するための相関 ID を付与する。パスワードやトークンなどの機密情報はログに含めない。ERROR レベルを乱用せず適切なレベルを選択し、「何が起きたか」だけでなく「なぜ起きたか」のコンテキストも記録する。

環境ごとのログレベル

環境ごとのログレベルの例を示す。

Mappings:
  EnvConfig:
    dev:
      LogLevel: DEBUG
    stg:
      LogLevel: INFO
    prod:
      LogLevel: WARN

prod を WARN まで絞ると INFO の処理記録が残らず、相関 ID でリクエストを追跡する用途では使えなくなる。追跡が必要な系は prod も INFO を基本にし、量が問題なら出力対象を絞るか、サンプリングして削る。逆に DEBUG を本番で出す設定は、保存料と機密情報の混入の両面で避ける。

ログの保持期間

ログの保持期間を以下にまとめる。

環境	保持期間
dev	7 日
stg	30 日
prod	90〜365 日

CloudWatch Logs の保持期間は任意の日数を指定できるわけではなく、1・3・5・7・14・30・60・90・120・150・180・365・400・545・731 日と、それ以降の年単位の値 (最長 3653 日) からの選択になる。45 日にしたいと思っても選べず、30 日か 60 日に寄せることになる、という粒度である。さらに保持期間を設定しないロググループは無期限保存になり保存料が増え続けるため、ロググループを作る作業と保持期間を決める作業をひとまとめにしておく。

実務での活用方法は関連書籍にも詳しい。