ログ取り込み過多

ルール ID: gcp.logging.ingestion.excess ・ カテゴリ: hygiene ・ 必要な読み取り: インベントリ + 利用メトリクス(権限が付くまで locked) 計画中

ログ課金の主因は「量」です。どの resource_type が取り込み量を押し上げているかを特定し、除外フィルタやサンプリングで読まれないログへの支払いを減らす提案をします。

このページは判定規範に従う予定仕様です。閾値・観測窓の根拠(出典)は実装時に付記します。

何を無駄とみなすか

参照されないまま大量に取り込まれ続けているログ。取り込み量に比例して課金されるため、使われないログの取り込みはそのまま無駄になります。

判定条件

• resource_type 別の月間取り込み量を集計し、取り込み量の大きい発生源を特定する
• 発生源に応じて、除外フィルタまたはサンプリングの適用を提案する(例: VPC Flow Logs の sampling を 1.0 → 0.1 にすると取り込み量を 90% 削減)
• 利用メトリクスの読み取り権限が付くまでは locked と表示し、判定しません

必須 facts

• resource_type 別の月間取り込み量
• 対象ログの現在の除外フィルタ・サンプリング設定

取得できない facts がある場合は「観測不能」と表示し、候補にしません(候補を捏造しない)。

誤検知・危険になり得る条件

• セキュリティ監査・コンプライアンスで全量保全が必要なログを除外してしまう
• 障害調査の際に必要なログがサンプリングで欠け、原因特定が難しくなる
• インシデントや移行に伴う一時的なスパイクを恒常的な取り込み量と誤認する

実行前の確認

• そのログの利用者(監視・監査・アラート・ダッシュボード)を洗い出し、除外・サンプリングの影響を確認する
• アラートポリシーが対象ログに依存していないか確認する
• IaC(Terraform 等)でログ設定が管理されていないか確認する

非破壊テストとロールバック

Safety Tier: medium(除外フィルタ・サンプリングは設定変更で、いつでも戻せます)

• 影響の小さいログ(明確に参照されていない resource_type)から段階的に適用します
• 適用中に取り込まなかったログは遡って取得できないため、適用前に利用者の確認を済ませます
• ロールバック: フィルタ・サンプリング設定を元に戻します

効果検証

削減の確定は、変更前ベースラインと変更後請求の比較で行います(Verify)。取り込み量の減少は翌月の請求から確認できます。