Cloud Logging バケットを Observability Analytics + Linked Dataset で BigQuery から分析できるようにしてみた

2026.05.17
Cloud Logging のバケットにためたログを BigQuery で SQL 分析する構成を Terraform で構築してみました。
Cloud Logging のシンクから BigQuery に直送する Direct Routing という方式があります。
ただこの方式は Cloud Logging と BigQuery にデータが二重保管されてストレージ料金がかかり、スキーマも独自の camelCase 短縮形になるという欠点があります。
代わりに Observability Analytics + Linked BigQuery Dataset という構成を取ると、Cloud Logging バケットにだけデータを置いた状態のまま、BigQuery 経由でも SQL 分析できます。
https://cloud.google.com/blog/products/data-analytics/moving-to-log-analytics-for-bigquery-export-users?hl=en
検証例として監査ログを流し、BigQuery からクエリ結果が返るところまで確認します。
なお本記事の手順は単一プロジェクトのバケットでも組織レベルで集約したバケットでも同じです。
 前提Cloud Logging API / BigQuery API が有効化されたプロジェクト
Terraform hashicorp/google プロバイダ v6 以降
作業者は roles/logging.admin 相当の権限を持つ
検証ではバケット名 audit-logs を asia-northeast1 に作成する
 全体構成データの実体は Cloud Logging バケットの1か所のみです。BigQuery 側からは _AllLogs 仮想ビュー経由で読み取れます。
 Terraform 実装 Observability Analytics 有効化バケットmain.tf
resource "google_logging_project_bucket_config" "audit_logs" {
  project          = var.project_id
  location         = var.location
  bucket_id        = "audit-logs"
  retention_days   = 30
  enable_analytics = true
  description      = "監査ログ保管バケット（Observability Analytics 有効）"
}
enable_analytics = true で Observability Analytics を有効化します
不可逆操作です。一度 true にすると false には戻せません。Terraform で false に書き換えてもバケットの状態は変わらないので注意してください
取り消したい場合はバケットを削除するしか手段がなく、7日間 DELETE_REQUESTED の soft delete 期間に入ります
 Linked BigQuery Datasetmain.tf
resource "google_logging_linked_dataset" "audit_logs" {
  link_id     = "audit_logs"
  parent      = "projects/${var.project_id}"
  bucket      = google_logging_project_bucket_config.audit_logs.id
  location    = var.location
  description = "Linked dataset for audit-logs"
}
link_id がそのまま BigQuery dataset 名になります
BigQuery dataset の命名規則上、ハイフン (-) は使えません。バケット名のハイフンをアンダースコアに置換した命名にしておくと分かりやすいです
1バケットあたり Linked Dataset は1個までという制約があります
 テスト用シンク検証のため、同プロジェクトの監査ログをバケットにルーティングするシンクを作成します。
main.tf
resource "google_logging_project_sink" "audit_to_bucket" {
  name                   = "audit-logs-sink"
  project                = var.project_id
  destination            = "logging.googleapis.com/projects/${var.project_id}/locations/${var.location}/buckets/${google_logging_project_bucket_config.audit_logs.bucket_id}"
  filter                 = "logName:cloudaudit.googleapis.com"
  unique_writer_identity = false
}
unique_writer_identity = false は、同一プロジェクト内のバケットにルーティングする場合 Writer SA への IAM 付与が要らないという指定です。
 やってみた Terraform 適用terraform apply でリソースを作成します。
$ terraform apply -auto-approve
...
google_logging_project_bucket_config.audit_logs: Creation complete after 55s
google_logging_project_sink.audit_to_bucket: Creation complete after 3s
google_logging_linked_dataset.audit_logs: Creation complete after 52s

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
ログバケットとシンクが作成されました。
 監査ログを発生させるシンク作成からシンクが伝搬するまで3分ほど待ったあと、監査ログを意図的に発生させます。
SA の作成・削除は Admin Activity ログが確実に出るので検証に便利です。
PROJECT_ID=your-project-id

gcloud iam service-accounts create test-trigger --project=${PROJECT_ID}
gcloud iam service-accounts delete test-trigger@${PROJECT_ID}.iam.gserviceaccount.com \
  --project=${PROJECT_ID} --quiet
 BigQuery 経由でクエリログがバケットに取り込まれるまで1〜2分待ってから クエリを実行します。
コンソールから BigQuery に遷移して、以下のクエリを貼り付け 実行 を選択します。
SELECT
    timestamp,
    log_id,
    proto_payload.audit_log.method_name AS method_name,
    proto_payload.audit_log.service_name AS service_name,
    proto_payload.audit_log.authentication_info.principal_email AS principal
  FROM <project-id>.audit_logs._AllLogs # <project-id>は要置き換え
  WHERE timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 MINUTE)
    AND log_id = 'cloudaudit.googleapis.com/activity'
    AND proto_payload.audit_log.method_name LIKE '%ServiceAccount%'
  ORDER BY timestamp DESC
  LIMIT 5
SA 作成・削除の Admin Activity ログを BigQuery 経由で取得できました。
bq コマンド（BigQuery CLI）の場合は以下のように実行できます。
bq query --use_legacy_sql=false \
  --project_id=${PROJECT_ID} \
  --location=asia-northeast1 \
  "SELECT
     timestamp,
     log_id,
     proto_payload.audit_log.method_name AS method_name,
     proto_payload.audit_log.service_name AS service_name,
     proto_payload.audit_log.authentication_info.principal_email AS principal
   FROM \`${PROJECT_ID}.audit_logs._AllLogs\`
   WHERE timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 MINUTE)
     AND log_id = 'cloudaudit.googleapis.com/activity'
     AND proto_payload.audit_log.method_name LIKE '%ServiceAccount%'
   ORDER BY timestamp DESC
   LIMIT 5"
 おわりにCloud Logging バケットを BigQuery で SQL 分析したいとき、Direct Routing よりも Observability Analytics + Linked Dataset のほうが、重複保管がなくスキーマもクリーンなので特別な理由がなければこちらで十分でした。
enable_analytics = true が不可逆な点だけ、検証環境で動作確認してから本番適用するのが安全です。