クラウド時代のログ管理ベストプラクティス (AWS/GCP)

### このガイドの目的 クラウドネイティブ（Docker, K8s, Lambda）な環境において、レガシーな「ファイルにログを吐く」運用から脱却し、取りこぼしのないログ基盤を作るための設計指針です。 ### ベストプラクティス 3選 #### 1. 標準出力（Stdout/Stderr）への集約 **原則**: アプリケーションはログの「保存場所」を意識してはいけません。 **理由**: コンテナやLambdaは使い捨て（Ephemeral）です。コンテナ内のファイル `/var/log/app.log` に書いても、コンテナが死ねばログも消えます。 **実装**: 全てのログを `console.log` (Node) や `logging.StreamHandler` (Python) に流し、収集はDockerデーモンやFluent Bit（Sidecar）に任せましょう。これを「ログルーターパターン」と呼びます。 #### 2. 構造化ログ（JSON）の徹底 **原則**: `grep` ではなくクエリで検索できるようにする。 **NG例**: `[Info] 2024/02/06 User 123 login failed` (ただの文字列) **OK例**: `{"level": "info", "ts": "2024-02-06...", "user_id": 123, "event": "login_failed"}` **理由**: DatadogやCloudWatch Insightsで `user_id=123` と検索した時、JSONなら100%ヒットしますが、テキストgrepは誤検知やパースエラーの元です。分析コストが劇的に下がります。 #### 3. Trace IDによる分散トレーシング **原則**: リクエストの「一連の流れ」を追えるようにする。 **課題**: マイクロサービスでは、Frontendのエラーの原因が、Backendのその奥のDBにあることが多々あります。 **解決**: ロードバランサー（ALB）が付与する `X-Amzn-Trace-Id` や、OpenTelemetryのTrace IDを、アプリ内の全てのログ出力に含めてください。これにより、一つの検索IDでシステム全体を串刺し検索できます。 ### 構成例 (AWS) - **小規模**: CloudWatch Logs Agent (EC2) / FireLens (ECS) -> CloudWatch Logs - **中規模**: Fluent Bit -> Kinesis Firehose -> S3 (保存) + OpenSearch (検索) - **大規模**: Datadog Agent -> Datadog (サンプリング有効化) ### 次のアクション - [診断：監査ログ自己チェック](/diagnosis/audit-log-self-check/) で現状の構成を評価する。