ログは『書く時』ではなく『見る時』を意識する
ログは障害解析と監査の主要素材ですが、設計が悪いと膨大なコストと検索困難を生みます。本記事では編集部の視点で、ログ管理を公開情報をもとに整理します。Observability 実践 もご参考に。
構造化ログが基本
(1) JSON 形式：パース容易・属性検索可能。(2) 共通フィールド：timestamp / level / message / trace_id。(3) サービス固有属性：user_id / request_id / endpoint。(4) 機密情報の除外：パスワード/トークン/個人情報。(5) 命名規約：snake_case / kebab-case の統一。
ログレベルの使い分け
(1) DEBUG：開発のみ、本番無効。(2) INFO：通常運用の主要イベント。(3) WARN：注意が必要だが復旧可能。(4) ERROR：機能停止級の問題。(5) FATAL/CRITICAL：プロセス停止・アラート発火。本番では INFO 以上が一般的です。
ログ集約の構成
(1) アプリ → stdout/stderr：12-factor 流。(2) コレクタ：Fluent Bit / Vector / Filebeat。(3) ストレージ：Loki / Elasticsearch / OpenSearch / CloudWatch Logs。(4) 可視化：Grafana / Kibana。(5) アラート：Prometheus Alertmanager / Datadog Monitor。Datadog 活用ガイド もご参考に。
保管ポリシー
(1) ホット (7日)：高速検索。(2) ウォーム (30日)：中速検索。(3) コールド (90日〜1年)：S3/GCS にアーカイブ。(4) 監査ログは長期保管：法令要件で7年等。(5) 個別判断：サービス特性と監査要件で。個別の法令要件は専門家にご相談ください。
コスト最適化
(1) DEBUG ログを本番出力しない：量で課金される。(2) サンプリング：高頻度ログを10%等に。(3) 圧縮：転送時/保管時に。(4) ホット/コールド分離：階層化で安価に。(5) 無料枠の活用：CloudWatch Logs Insights/ Loki セルフホスト。分散トレーシング も合わせて。
失敗しがちなパターン
(1) 非構造化ログのみ：grep でしか検索できない。(2) 個人情報の漏洩：監査対象に。(3) ログ量が爆発しコスト超過。(4) trace_id がない：障害解析で苦労。(5) 保管期間が無限：費用増+法的リスク。対策は、(1)JSON 出力、(2)マスキング、(3)サンプリング+階層化、(4)ミドルウェアでcontext伝播、(5)retention 設定、です。