Cloud Logging

解決する課題

ログ収集の仕組みを自前で構築・運用せずに、Google Cloud 全体のログを一元的に集めて調べられます。

• アプリやインフラのログが各所に散らばっていて 横断的に検索できない
• 障害時に 過去のログをさかのぼって原因を追いたい
• 監査やコンプライアンスのために ログを長期保管したい
• ログを BigQuery で分析したり、外部の SIEM へ流したい
• 特定のログパターンを 指標化してアラートにつなげたい

Cloud Logging は Google Cloud Observability（旧 Stackdriver）の一部で、多くの Google Cloud サービスのログを設定なしで取り込みます。AWS でいう CloudWatch Logs に相当する位置づけです。

主要概念と用語

• ログエントリ（Log Entry）: 1 件のログ。タイムスタンプ、重大度（severity）、リソース、ペイロード（textPayload / jsonPayload）などのフィールドを持つ
• ログ名 / ログストリーム: ログエントリが属する論理的なログの単位。AWS のロググループに近い概念
• モニタリング対象リソース（Monitored Resource）: ログがどのリソースから出たか（gce_instance、cloud_run_revision、k8s_container など）
• ログルーター（Log Router）: 取り込まれた全ログエントリをいったん受け取り、シンクの条件に従って振り分ける中継点
• シンク（Sink）: フィルタに一致したログの行き先を定義する設定。宛先はログバケット、BigQuery、Cloud Storage、Pub/Sub など
• ログバケット（Log Bucket）: ログの保存先。既定で _Required と _Default の2つが存在し、ユーザー定義バケットも作れる
• 除外フィルタ（Exclusion）: シンクで不要なログを取り込み対象から外す設定。コスト削減に使う
• ログベースの指標（Log-based Metrics）: ログのパターン一致やフィールド抽出から時系列指標を生成し、アラートに使える
• 重大度（Severity）: DEFAULT から DEBUG、INFO、WARNING、ERROR、CRITICAL までの段階。検索やアラートの絞り込みに使う
• 監査ログ（Cloud Audit Logs）: 誰がいつ何をしたかを記録する管理アクティビティ/データアクセスのログ。AWS の CloudTrail に相当

仕様・制限・クォータ

• ログは ログルーター が全件受け取り、シンクのフィルタに従って各バケットや外部宛先へルーティングする
• 既定バケットは2種類ある。_Required は管理アクティビティ監査ログ等を保持し、保持期間は固定で課金されず削除もできない。_Default はそれ以外を保持し、保持期間は既定値があり延長できる
• ログバケットの 保持期間 は設定可能で、要件に応じて短縮も延長もできる。延長分は課金対象になりやすい
• ログエントリには サイズ上限があり、超過分は切り捨てられる場合がある
• ログベースの指標やラベルには 基数（cardinality） の実務的な制約があり、設計時に意識する
• ログ分析（Log Analytics） を有効にすると、ログバケットに対して SQL で分析できる

具体的な保持日数やサイズの上限値、無料枠の数値は変動しうるため、最新の値は公式ドキュメントで確認してください。

内部の仕組み

各 Google Cloud サービスや、VM 上の Ops エージェント、API 経由のアプリが、ログエントリを Cloud Logging に送信します。送られたログはまず ログルーター に集約され、定義された シンク のフィルタ式（包含フィルタ）に一致したものが、それぞれの宛先へ並行して配信されます。

既定では、_Default シンクが大半のログを _Default バケットへ、_Required シンクが監査系ログを _Required バケットへ送ります。ここに ユーザー定義シンク を追加することで、同じログを BigQuery や Cloud Storage、Pub/Sub にも同時にエクスポートできます。1 つのログエントリが複数のシンクに一致すれば、それぞれの宛先へ重複して送られます。

設計パターン / ベストプラクティス

• 分析用途は BigQuery シンク に集約し、SQL で横断分析する。長期・低コストの保管は Cloud Storage シンク
• リアルタイム連携や外部 SIEM への転送は Pub/Sub シンク を起点にする
• 不要なログ（ヘルスチェックや冗長なアクセスログ）は 除外フィルタ で取り込み前に落とす
• 組織全体のログを集約するなら 集約シンク（Aggregated Sink） を組織やフォルダ階層に設定する
• 構造化ログ（jsonPayload）で出力し、フィールド単位の検索やログベース指標を活きやすくする
• 重要パターンは ログベースの指標 にし、Cloud Monitoring のアラートにつなぐ

運用・監視

• ログが見えない → ログルーターのシンク/除外フィルタと、振り分け先バケットを確認。書き込み側の IAM（roles/logging.logWriter）も点検
• エクスポートが届かない → シンクの宛先側の権限を確認。シンク作成時に払い出されるサービスアカウントに、宛先（BigQuery データセットや Cloud Storage バケット）への書き込み権限が必要
• VM のアプリログが取れない → Ops エージェント の導入と設定、サービスアカウントの権限を確認
• 取り込み遅延や欠損 → フィルタ式の誤りや、宛先側のクォータ/スキーマ不一致を点検

コスト

課金は主に ログの取り込み量（GiB） と、既定保持を超える 保持 で決まります。_Required バケットの監査ログや、Google Cloud の一部既定ログは無料で扱われ、一定の無料枠も用意されています。Cloud Storage や BigQuery へエクスポートした先では、各サービス側のストレージ/クエリ課金が別途発生します。

セキュリティ

• ログバケットは CMEK（顧客管理鍵 / Cloud KMS） で暗号化でき、アクセスは IAM で制御する
• 権限は IAM ロール で最小化する。閲覧は roles/logging.viewer、書き込みは roles/logging.logWriter、設定変更は管理者ロールに限定
• データアクセス監査ログは機微情報を含みうるため、有効範囲を要件に合わせて絞る
• 機微情報のログ流出を防ぐため、除外フィルタや Sensitive Data Protection（旧 DLP） で秘匿化する
• 改ざん防止が要件なら ログバケットのロック（保持の固定） で、保持期間中の削除・短縮を禁止する

Well-Architected の観点

• オペレーショナルエクセレンス: ログを一元集約し、構造化ログとログベース指標で運用の可観測性を高める。シンク設計を IaC で管理し、再現性を担保する。

試験で問われるポイント

関連サービス・比較

メトリクスやアラート、ダッシュボードは姉妹サービスの Cloud Monitoring が担い、両者で Google Cloud の可観測性を構成します。

ハンズオン / CLI例

# 直近のエラー以上のログをフィルタして確認
gcloud logging read \
  'resource.type="cloud_run_revision" AND severity>=ERROR' \
  --limit=20 --freshness=1h \
  --format="table(timestamp, severity, textPayload)"

# ユーザー定義のログバケットを作成（保持期間を指定）
gcloud logging buckets create app-logs \
  --location=global \
  --retention-days=90

# エラー以上のログを BigQuery へエクスポートするシンクを作成
gcloud logging sinks create errors-to-bq \
  bigquery.googleapis.com/projects/PROJECT_ID/datasets/app_logs \
  --log-filter='severity>=ERROR'

# 不要なヘルスチェックのログを取り込みから除外
gcloud logging sinks update _Default \
  --add-exclusion=name=skip-healthcheck,filter='httpRequest.requestUrl="/healthz"'

# テスト用のログエントリを書き込む
gcloud logging write my-test-log "hello from cloud logging" --severity=INFO