DEEP DIVE

🔭 可観測性とトラブルシュート徹底深掘り

Cloud Logging / Monitoring / Trace / Managed Prometheus / OpenTelemetry / Profiler / Gemini Cloud Assist の 内部動作・制限値・事故ケース・運用ベストプラクティス・コスト落とし穴を、Google Cloud 公式ドキュメントベースで徹底解説します。PCDE で 25% の比重を持つ最重要セクションの最終仕上げと、本番 SRE 業務のリファレンスを兼ねた一枚教材です。

公式 docs 準拠 🎯 上級 ⚙️ 内部動作 📊 制限値表 ⚠️ 事故ケース 35+ 💰 コスト落とし穴

🎯 試験頻出 ⚠️ 事故ケース ✅ ベストプラクティス 📋 制限値 💰 コスト

🔑 TL;DR — このページの結論可観測性は Metrics + Logs + Traces + Profiles + Synthetic + AI の総合戦。Cloud Logging は Log Router → Sink → Log Bucket / BQ / Pub-Sub / GCS 構成で、コスト削減は Exclusion > Sampling > Retention 短縮の順、ログエントリは 256 KiB（Audit 512 KiB）/ ラベル 64 個制限。_Required バケットは 400 日固定・削除不可。Cloud Monitoring は カスタムメトリクス 10,000 個 / ラベル 30 個 / 時系列 200,000、Prometheus は ラベル 200 個 / 時系列 1,000,000 と桁違い。アラートは SLO Multi-burn-rate（Fast 1h=14.4x / Slow 6h=6x）、Notification Channel は policy あたり 16 個。GMP（Managed Service for Prometheus）は サンプル数課金 / 保持 24 ヶ月 / カーディナリティ無制限だが、自前で recording rules でコスト制御が必須。OpenTelemetry は W3C Trace Context が標準、Trace ID は logging.googleapis.com/trace で必ずログに含める。Cloud Trace は OTLP / Telemetry API が推奨、Cloud Run / Functions は X-Cloud-Trace-Context 自動処理。Profiler は CPU/Heap/Allocated/Contention/Wall/Threads の 6 種、本番常時 < 1% オーバヘッド。
最大の事故源は Data Access ログ有効化でログ料金が桁違い増、高基数ラベルで時系列爆発、tail-based sampling の Collector OOM、Notification Channel が本番障害時に動かない、trace ID が外部 API 跨ぎで途切れるの 5 つです。

📚 参照する公式ドキュメント

本資料は以下の Google Cloud 公式ドキュメント（2026 年時点）から技術詳細・制限・SLA・ベストプラクティスを抽出しています。各章で都度引用と URL を併記します。

#	領域	公式 URL
1	Cloud Logging overview	cloud.google.com/logging/docs/overview
2	Cloud Logging quotas	cloud.google.com/logging/quotas
3	Log Router & Sinks	cloud.google.com/logging/docs/routing/overview
4	Log buckets	cloud.google.com/logging/docs/buckets
5	Log-based metrics	cloud.google.com/logging/docs/logs-based-metrics
6	Cloud Audit Logs	cloud.google.com/logging/docs/audit
7	Cloud Monitoring overview	cloud.google.com/monitoring/docs/monitoring-overview
8	Cloud Monitoring quotas	cloud.google.com/monitoring/quotas
9	Alerting policies	cloud.google.com/monitoring/alerts
10	Managed Service for Prometheus	cloud.google.com/stackdriver/docs/managed-prometheus
11	GMP Managed Collection	cloud.google.com/stackdriver/docs/managed-prometheus/setup-managed
12	Cloud Trace overview	cloud.google.com/trace/docs/overview
13	OpenTelemetry concepts	opentelemetry.io/docs/concepts/
14	OTel Collector	opentelemetry.io/docs/collector/
15	Cloud Profiler	cloud.google.com/profiler/docs
16	Error Reporting	cloud.google.com/error-reporting/docs
17	Ops Agent	cloud.google.com/logging/docs/agent/ops-agent
18	SLOs & Burn rate	cloud.google.com/stackdriver/docs/solutions/slo-monitoring
19	Gemini Cloud Assist	cloud.google.com/gemini/docs/cloud-assist/overview
20	SRE Workbook Ch.5 Alerting	sre.google/workbook/alerting-on-slos/

1可観測性 3 軸 + α の全体像

「監視（Monitoring）」と「可観測性（Observability）」は別物。前者は既知の故障を事前定義の指標で検知するもの、後者は未知の故障を後から任意の高次元データで追跡できる性質です。Google Cloud は Metrics / Logs / Traces の 3 軸に Profiles / Synthetic / AI 解析を加えた 6 つを 1 プラットフォーム（Cloud Observability）で提供し、相互ジャンプが可能。試験では「どのツールを使うか」の判断軸が頻出します。

「Observability is the ability to measure a system's current state based on the data it generates, such as logs, metrics, and traces.」 — Google Cloud DevOps capabilities ↗

1.1 6 つの観測軸を 1 枚図で

図 1.1: 6 つの観測軸と Google Cloud のマッピング。点線は相互に紐付け可能なジャンプ動線。

1.2 Monitoring vs Observability の本質差

📡 Monitoring（監視）

想定する故障：既知
データ：事前定義の指標
質問：「閾値を超えたか？」
典型：CPU > 80% アラート
失敗モード：「ダッシュボードは緑だが障害発生」

🔍 Observability（可観測性）

想定する故障：未知
データ：任意の高次元データ
質問：「なぜそうなったか？」
典型：trace / log / profile を相関分析
失敗モード：「データはあるがクエリ困難」（高基数問題）

1.3 The Four Golden Signals（SRE Book）

シグナル	意味	計測対象	典型 PromQL
Latency	リクエスト処理時間（成功と失敗を分けて測る）	p50 / p95 / p99	`histogram_quantile(0.99, ...)`
Traffic	システムへの要求量	RPS / QPS / 同接	`sum(rate(req_total[1m]))`
Errors	失敗したリクエスト率	5xx / 例外	`sum(rate(req{status=~"5.."}[5m])) / sum(rate(req[5m]))`
Saturation	リソースの「飽和度」	CPU / Mem / queue 長	`container_cpu_usage / cpu_limit`

🔑 試験で問われる「どれを使うか」判断軸

「集計された数値で傾向を見たい」→ Metrics（Monitoring / GMP）
「個別イベントの詳細・誰が何をしたか」→ Logs（Logging / Audit Logs）
「リクエストがどこで遅いか」→ Trace（Cloud Trace + OTel）
「どの関数が CPU/メモリを食ってるか」→ Profiler
「外部からエンドポイントが生きてるか」→ Uptime / Synthetic Monitor
「例外を集約してまとめて見たい」→ Error Reporting
「複雑なメトリクススパイクの原因を自然言語で要約」→ Gemini Cloud Assist Investigations

1.4 Pull vs Push 収集モデル

モデル	例	長所	短所
Pull（scrape）	Prometheus / GMP Managed Collection	サービス側は `/metrics` を露出するだけ、scrape 失敗が即可視化、cardinality 制御が collector で可能	NW 経路設計が必要、ephemeral リソース（Cloud Run など）に弱い
Push	OpenTelemetry OTLP / Cloud Logging API / Monitoring API `createTimeSeries`	ephemeral リソースに強い、ファイアウォール越え簡単	送信失敗を検知しづらい、cardinality 制御がアプリ側

💡 GCP での使い分け

GKE 上の Pod から Prometheus メトリクス → GMP Managed Collection（pull）
Cloud Run / Cloud Functions のメトリクス → OTLP push（OTel SDK）
VM 上の OS / アプリ → Ops Agent（内部は push）
外部 SaaS / 他クラウド → OTel Collector を経由して GCP に push

2Cloud Logging 徹底解剖

Cloud Logging はすべてのログが Log Router を中央経由し、Sink（フィルタ + 宛先）で Log Bucket / BigQuery / Pub/Sub / GCS に振り分けられる「中央郵便局」型アーキテクチャ。試験では「Sink 設計」「_Default vs _Required vs ユーザー定義 Bucket」「Audit Logs 4 種類」「LQL」「log-based metric」「Exclusion でコスト削減」「Log Analytics（BQ 統合）」が頻出します。

「The Log Router checks each log entry against existing inclusion and exclusion filters to determine which entries to discard, which to route to Cloud Logging storage, and which to route to supported destinations.」 — Routing and storage overview ↗

2.1 Cloud Logging アーキテクチャ全景

図 2.1: ログは Logging API（または自動収集）から Log Router を必ず経由し、各 Sink に複製送信される。Log-based Metric は Router の段階で集計。

2.2 Log Bucket 3 種類と保持期間

バケット	保持	変更	削除	料金	用途
`_Default`	30 日（既定）	1〜3,650 日に変更可	可	取り込み $0.50/GiB（最初 50 GiB/月無料）+ 超過分 $0.01/GiB/月	通常ログ既定保管
`_Required`	400 日固定	変更不可	不可	完全無料	Admin Activity / System Event の Audit Log
ユーザー定義	1〜3,650 日（10 年）	可	可	同 _Default	コンプラ用長期保管、地域制限（CMEK / リージョン指定）

⚠️ 試験頻出ポイント

_Required は 400 日固定・削除不可・無料。Admin Activity と System Event が自動投入される。
ユーザー定義 Bucket は作成時にリージョン指定（後から変更不可）。GDPR 等で EU リージョン固定が必須なケースで頻出。
CMEK（顧客管理鍵）はユーザー定義 Bucket でのみ設定可。_Default でも CMEK 設定可だが、組織単位設定が推奨。
Bucket は作成後に保持期間を縮めても、既存ログが即削除されるわけではない（次回 retention チェックで対象化）。

2.3 Log Router と Sink 設計

Sink はフィルタ（inclusion + exclusion）+ 宛先で構成。Log Router は受信したログをすべての Sink に並行コピーするため、同じログを「分析用 BQ」と「アーカイブ GCS」両方に送ることが可能。Exclusion は Sink 単位で作用し、_Default Sink の Exclusion はそのまま取り込み課金停止に直結します。

Sink 宛先別の使い分け

宛先	典型ユースケース	遅延	注意点
Log Bucket	Logging 内で LQL 検索 + 長期保持	数秒	Bucket リージョン跨ぎ不可、LQL のみ（SQL 不可。Log Analytics 有効化で SQL も可）
BigQuery	SQL アドホック分析（旧来の方式）	数分	データ二重保存（Bucket + BQ）→ Log Analytics 推奨に置き換え
BigQuery (Log Analytics)	Bucket を直接 BQ linked dataset として SQL（2023+）	数秒	データ重複なし、追加課金なし。新規構築の第一選択
Pub/Sub	SIEM / Splunk / Datadog 連携、リアルタイム ETL	サブ秒	at-least-once、サブスクライバで idempotency 担保
Cloud Storage	長期アーカイブ（7 年保管等）	1 時間単位ファイル	JSONL 形式、Object Lifecycle で Coldline/Archive 自動化
Splunk (直送)	Splunk Cloud / Enterprise への直結（2024 GA）	サブ秒	Pub/Sub + Dataflow パターンの代替、設定が大幅シンプル化
Other GCP project	セキュリティ集約プロジェクトに送付	数秒	writer identity に宛先側で `roles/logging.bucketWriter` 付与

# Sink 作成例：5xx エラーだけ BigQuery（Log Analytics）に送る gcloud logging sinks create errors-to-bq \ bigquery.googleapis.com/projects/PRJ/datasets/app_logs \ --log-filter='severity>=ERROR AND httpRequest.status>=500' \ --use-partitioned-tables # Aggregated Sink（Org 全体の Audit Log を 1 BQ に集約） gcloud logging sinks create org-audit-sink \ bigquery.googleapis.com/projects/security-proj/datasets/audit \ --include-children \ --organization=ORG_ID \ --log-filter='logName:"cloudaudit.googleapis.com"' # 重要：作成後、writer identity が表示されるので宛先側で IAM 付与 gcloud projects add-iam-policy-binding security-proj \ --member="serviceAccount:o123-456@gcp-sa-logging.iam.gserviceaccount.com" \ --role=roles/bigquery.dataEditor

2.4 Aggregated Sink（組織レベル集約）

通常 Sink はプロジェクト単位。--include-children で Organization / Folder 配下のプロジェクトすべてを再帰的に集約できる。CISO 向けの中央セキュリティログ集約、コンプラ要件の Audit Log 7 年保管、コスト分析の基盤として必須。

必要 IAM ロール

Org/Folder 作成者：roles/logging.admin（Organization レベル）

writer identity

自動生成 SA。宛先側に Editor/Writer 権限を付与する必要あり

filter 設計

Audit Log だけ（logName:"cloudaudit.googleapis.com"）が定番。全ログ集約は料金爆発の原因になりがち

制約

Aggregated Sink は宛先として別プロジェクトを選ぶのが慣行（セキュリティ分離）

2.5 Log Analytics（BQ 統合の真打ち）

Log Bucket を「BigQuery linked dataset としてアップグレード」する機能（2023 GA）。データ二重保存なし・追加課金なしで、Logs Explorer の SQL タブから直接クエリ可能、BQ コンソールからも参照可能。旧来の「BigQuery Sink」を置き換える現代の標準。

# 既存 _Default を Log Analytics 有効化 gcloud logging buckets update _Default \ --location=global \ --enable-analytics # Log Analytics クエリ（過去 24h の Cloud Run エラーをサービス別集計） SELECT JSON_VALUE(resource.labels.service_name) AS service, COUNT(*) AS errors FROM `PRJ.global._Default._AllLogs` WHERE timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 24 HOUR) AND severity = 'ERROR' AND resource.type = 'cloud_run_revision' GROUP BY service ORDER BY errors DESC;

🔑 試験頻出：「ログを SQL で分析、データ重複なしで最安は？」 → Log Analytics（既存 Bucket をアップグレード）。古い「BQ Sink」も動くが、データ二重課金になるため新規は Log Analytics 一択。

2.6 LQL（Logging Query Language）必須演算子

演算子	意味	例
`=` / `!=`	完全一致 / 不一致	`severity="ERROR"`
`:`	サブストリング / フィールド存在	`textPayload:"timeout"`
`>=` `<=`	比較（severity / timestamp / 数値）	`severity>=WARNING`
`=~` `!~`	正規表現 RE2	`resource.labels.zone=~"us-.*"`
`AND` `OR` `NOT`	論理結合（AND 省略可）	`severity=ERROR OR severity=CRITICAL`
`timestamp_sub`	相対時刻	`timestamp>=timestamp_sub(@now,"5m")`
`sample()`	サンプリング（取り込み時）	`sample(insertId, 0.1)` → 10%
`ip_in_net()`	CIDR マッチ	`ip_in_net(jsonPayload.client_ip,"10.0.0.0/8")`

2.7 log-based metric の 2 種類と制限

ログイベントをメトリクス化する機能。Logging で気付けないトレンドを Monitoring 上で可視化・アラートできる。1 プロジェクトあたり 500 個の上限あり、増加不可。

種別	集計	typical 例	注意点
Counter	ログ行をカウント	5xx エラー数 / 分、特定例外発生数	軽量、デフォルト
Distribution	ログから数値を抽出して分布化	レイテンシ p50/p99、payload サイズ	`EXTRACT()` で値抽出、bucket 設計が重要

# Counter metric: 5xx 数（ラベル付き） gcloud logging metrics create cloud_run_5xx \ --description="Cloud Run 5xx count" \ --log-filter='resource.type="cloud_run_revision" httpRequest.status>=500' \ --label-extractors='service=EXTRACT(resource.labels.service_name)' # Distribution metric: API レイテンシ # YAML 定義（API 経由） filter: 'resource.type="cloud_run_revision" httpRequest.requestUrl:"/api"' metricDescriptor: unit: "s" valueType: DISTRIBUTION valueExtractor: "EXTRACT(httpRequest.latency)" bucketOptions: exponentialBuckets: numFiniteBuckets: 20 growthFactor: 2.0 scale: 0.01

⚠️ log-based metric の落とし穴

label-extractor で高基数ラベル（user_id, request_id 等）を抽出すると時系列爆発。1 ラベル値 = 1 時系列。
System log-based metrics（logging.googleapis.com/log_entry_count 等）は自動提供・無料。User-defined は取り込みログから抽出するため、Exclusion で消したログからは作れない（順序：Inclusion → LBM → Storage）。
過去ログには遡及適用されない（作成時刻以降のみ）。
Counter は無料、Distribution は有料（custom metric として課金）。

2.8 Cloud Audit Logs 4 種類（最頻出）

ログ種別	記録内容	デフォルト	課金	保管
Admin Activity	リソースの変更（CREATE/UPDATE/DELETE/設定変更）	常に有効・無効化不可	無料	`_Required` 400 日
Data Access	データの読み書き（GCS object / BQ クエリ等）	既定で無効（BQ 以外）	課金あり	`_Default` 30 日
System Event	GCP 内部システムイベント（live migration 等）	常に有効・無効化不可	無料	`_Required` 400 日
Policy Denied	IAM / VPC SC で拒否されたアクセス	常に有効・無効化不可	課金あり	`_Default` 30 日

Data Access の 3 サブカテゴリ：ADMIN_READ（設定読取）/ DATA_READ（データ読取）/ DATA_WRITE（データ書込）。BigQuery は例外で DATA_READ / DATA_WRITE がデフォルト ON（変更にはコンソール操作必要）。

# Data Access ログを GCS で有効化（IAM Policy で auditConfigs） auditConfigs: - service: storage.googleapis.com auditLogConfigs: - logType: DATA_READ exemptedMembers: [serviceAccount:noisy-sa@prj.iam.gserviceaccount.com] - logType: DATA_WRITE - logType: ADMIN_READ # Logs Explorer での絞り込み logName:"cloudaudit.googleapis.com/activity" # Admin Activity logName:"cloudaudit.googleapis.com/data_access" # Data Access logName:"cloudaudit.googleapis.com/system_event" logName:"cloudaudit.googleapis.com/policy" # Policy Denied

2.9 Cloud Logging クォータ・制限値（公式表）

公式 Logging quotas ↗ から抜粋。試験で「最大値」「変更可否」が問われる項目に絞っています。

カテゴリ	項目	上限	変更
エントリ	1 ログエントリの最大サイズ	256 KiB	不可
	Audit ログエントリ最大サイズ	512 KiB	不可
	1 エントリのラベル数	64	不可
	ラベル値の長さ	64 KiB（超過は truncate）	不可
取り込み	取り込みレート（プレミアム region）	4.8 GB/分（per project）	申請可
	取り込みレート（その他 region）	300 MB/分（per project）	申請可
	entries.list API レート	60 req/分	不可
Bucket / Sink	Log Bucket 数 / project	100（→ 申請で 2,500）	申請可
	Sink 数 / project	200（→ 申請で 4,000）	申請可
	Log Views / Bucket	30（→ 申請で 1,000）	申請可
	Bucket 保持期間	1〜3,650 日	可（_Required 除く）
LBM / 検索	log-based metric 数 / project	500	不可
	LQL クエリ長	20,000 chars	不可
	Live-tailing 同時セッション	10 / project	不可

2.10 Cloud Logging 事故ケース 7 件

⚠️ 事故 #L1：Data Access ログを GCS で全有効化したらログ料金が月 80 万円に

状況	大量の小ファイル read を行うバッチプロセスがあり、GCS の `DATA_READ` で 1 日 5 TiB のログ発生
原因	Data Access ログは課金対象。バッチ系の大量 read を行うサービスアカウントを exemptedMembers から外していた
対処	① `exemptedMembers` でバッチ SA を除外、② バッチログは別 GCS bucket（VPC SC 内）に直書きでアクセス記録は VPC Flow Logs で代替

⚠️ 事故 #L2：PII（クレカ番号）がアプリログに混入、Compliance 違反

状況	決済 API が例外時に request body をログ出力。Audit Log の対象でないが Logging 全体で PII 検出
原因	アプリ層での PII リダクション未実装、Sensitive Data Protection（旧 DLP）API 未連携
対処	① 既存ログを Log Bucket から削除（Audit ログ削除には Org Logging Admin 必要）、② アプリで Sensitive Data Protection `deidentify_content` を必ず通す

⚠️ 事故 #L3：Exclusion 設定漏れで Cloud Run ヘルスチェックログが月 200 GiB

状況	Cloud Run / GKE で `/healthz` が 1 秒ごとに ping され、INFO ログが日 7 GiB
原因	テンプレ exclusion なし、INFO で取り込み課金発生
対処	`gcloud logging sinks update _Default --add-exclusion=name=hc,filter='httpRequest.requestUrl="/healthz"'`。即時反映、当月から課金停止

⚠️ 事故 #L4：log-based metric の label に request_id を抽出して時系列爆発、Monitoring API が 429

状況	1 時系列あたり 30,000 active TS 制限を超過、メトリクス参照 API が 429 Too Many Requests を返す
原因	`label-extractors='request_id=EXTRACT(jsonPayload.request_id)'` でカーディナリティ無限大のラベル設定
対処	① 当該 LBM を削除、② service_name / status_code 等有限カーディナリティのラベルのみに変更、③ アラート設計を Burn rate ベースに再構築

⚠️ 事故 #L5：Aggregated Sink の include-children 漏れで子フォルダの Audit Log が抜けた

状況	子フォルダで新規プロジェクトを作成、CISO 集約 BQ に Audit Log が来ない
原因	Aggregated Sink を Folder 単位で作っていたが、新規プロジェクトを別フォルダに作成 → 集約対象外
対処	① Sink を Org レベルに昇格、② プロジェクト作成時のOrg Policy で配置フォルダ強制

⚠️ 事故 #L6：Bucket 保持を 30 日 → 7 日に縮小したら Audit Log まで消えた

状況	コスト削減で `_Default` を 7 日にしたら、Policy Denied ログまで消失。SOC2 監査で問題
原因	Admin Activity / System Event は `_Required` だが、Policy Denied と Data Access は `_Default`。30 日→7 日で監査窓が崩壊
対処	① Audit Log 専用 Bucket（保持 7 年）に Sink で振り分け、② `_Default` は 7 日のままで OK

⚠️ 事故 #L7：BQ Sink で同じログが Log Bucket + BQ で二重課金

状況	旧来の「BQ Sink」で全ログを BQ にも送付。Log Bucket（取り込み）+ BQ（ストレージ）両方で課金
原因	2023+ の Log Analytics 統合を知らず、旧来パターン継続
対処	① `_Default` を Log Analytics 有効化、② 既存 BQ Sink を停止、③ クエリは Log Analytics 経由に

2.11 Cloud Logging ベストプラクティス 10 項目

常に構造化ログ（JSON）：jsonPayload に出す。textPayload は LBM・Trace 紐付け・検索性すべてで不利。
severity を正しく設定：DEBUG/INFO/WARNING/ERROR/CRITICAL。INFO で出すべきものを ERROR で出すとアラート濫発。
trace ID をログに必ず含める：logging.googleapis.com/trace と spanId。Cloud Trace と相互ジャンプ可能に。
Exclusion を必ず設定：health check / debug / sidecar ノイズを取り込み時点で削減。最大のコスト削減レバー。
Log Analytics を新規構築で使う：BQ Sink ではなく Bucket アップグレード。データ重複なし。
Audit Log 専用 Bucket を作る：_Default の保持を縮めても Audit Log は影響を受けないように分離。
PII はアプリ層で Sensitive Data Protection：Logging 側でのリダクションは取り込み後、コストが二重。
log-based metric のラベルは低カーディナリティ：user_id / request_id は NG、service / status / region は OK。
Aggregated Sink を Org レベルで：セキュリティ集約は Folder ではなく Org、宛先は別プロジェクトで分離。
Logging quota を Monitoring：logging.googleapis.com/billing/bytes_ingested を Budget Alert で監視。

3Cloud Monitoring 徹底解剖

Cloud Monitoring は時系列データベース（TSDB）+ Metrics Explorer + Dashboards + Alerting Policies + Notification Channels + SLO + Synthetic Monitor を統合したサービス。PCDE では「PromQL 必修」「SLO Burn rate アラート」「Metric Scope（複数プロジェクト集約）」「高基数ラベル事故」「Notification Channel 種類」が頻出。MQL は非推奨で PromQL に統一されつつあります。

「Cloud Monitoring provides visibility into the performance, uptime, and overall health of cloud-powered applications.」 — Cloud Monitoring overview ↗

3.1 Cloud Monitoring 全体アーキテクチャ

図 3.1: Cloud Monitoring の内部 TSDB は Monarch（Google 社内の時系列基盤）。あらゆる収集経路から書き込まれ、Explorer/Dashboard/Alert/SLO で同じ TSDB を参照。

3.2 メトリクスの 3 種別（kind）と階層

kind	意味	例	PromQL 注意
`GAUGE`	その時点の値	CPU 使用率、メモリ、queue depth	そのまま参照 OK
`CUMULATIVE`	累積値（リセットで 0 に戻る）	リクエスト総数、エラー総数	必ず `rate()` / `increase()`でラップ
`DELTA`	期間内の増分	バッチ処理件数	合計や平均で集約

メトリクス型（valueType）は BOOL / INT64 / DOUBLE / STRING / DISTRIBUTION。p99 レイテンシ等の分位点が必要なら DISTRIBUTION + histogram_quantile が定石。

3.3 PromQL 必須関数（試験必出）

関数	用途	典型例
`rate(v[t])`	counter の秒あたり平均増加率（範囲内の最初と最後を補間）	`rate(http_requests_total[5m])`
`irate(v[t])`	直近 2 サンプルの瞬間速度（突発検知）	`irate(http_requests_total[1m])`
`increase(v[t])`	期間内の総増分（rate × 期間と同義）	`increase(error_count[1h])`
`sum() by (...)`	ラベルでグループ集約（外側）	`sum by (service) (rate(req[5m]))`
`avg() by (...)`	ラベルで平均	`avg by (zone) (cpu)`
`histogram_quantile(q, v)`	histogram から分位点を補間算出	`histogram_quantile(0.99, sum by (le) (rate(latency_bucket[5m])))`
`label_replace()`	ラベル変換（正規表現）	`label_replace(up, "host", "$1", "instance", "([^:]+):.*")`
`topk(k, v)` / `bottomk(k, v)`	上位 / 下位 k 件	`topk(5, rate(errors[5m]))`
`predict_linear(v[t], s)`	線形回帰で s 秒後を予測（forecast）	`predict_linear(disk_used[6h], 86400) > 1e12`
`absent(v)`	メトリクス欠落検知（metric absence alert）	`absent(up{job="api"})`

# 4 Golden Signals の PromQL 雛形 # Latency p99 (5m) histogram_quantile(0.99, sum by (le, service) (rate(http_request_duration_seconds_bucket[5m]))) # Traffic sum by (service) (rate(http_requests_total[1m])) # Errors（5xx 率） sum by (service) (rate(http_requests_total{status=~"5.."}[5m])) / sum by (service) (rate(http_requests_total[5m])) # Saturation（CPU 使用率 / quota） avg by (instance) (rate(container_cpu_usage_seconds_total[5m])) / avg by (instance) (container_spec_cpu_quota / container_spec_cpu_period)

3.4 Alerting Policy の設計パターン

パターン	condition	用途	注意
Threshold（閾値）	値が X を超える期間が Y 分以上	従来型、CPU/Mem 等	flapping 発生しやすい、`duration` 必須
Metric absence	メトリクスが Y 分以上欠落	「データが来てない」検知	Ops Agent 落ち、API 障害
Forecast（予測）	線形外挿で X 時間以内に閾値超過	Disk full / quota 枯渇予兆	窓設計が重要、ノイズに弱い
Rate of change	変化率（増加/減少）が X を超える	急上昇 / 急減検知	Saw-tooth に弱い
SLO Burn rate（推奨）	エラー予算の消費速度が X 倍	症状ベース、SRE Workbook 標準	SLO 定義が必要
Log-based	特定ログパターン件数	「特定エラーが N 件超」	LBM 経由でも同等

3.5 SLO Multi-burn-rate アラート（SRE Workbook 第 5 章）

単純な「エラー率 > X%」では誤報・遅報のトレードオフが悪い。Burn rate（エラー予算の消費速度倍率：1.0 = SLO 期間ぴったりで使い切る）を、短窓と長窓の両方で ANDすることで、フラッピングを抑えつつ早期検知。

種別	窓（短 AND 長）	Burn rate 閾値	意味	対応
Fast burn (Page)	5m AND 1h	14.4x	1h で 2% の予算消費 → 緊急	PagerDuty Critical
Slow burn (Page)	30m AND 6h	6x	6h で 5% 消費	PagerDuty Critical
Medium (Ticket)	2h AND 24h	3x	24h で 10% 消費	Slack / Jira
Slow (Ticket)	6h AND 3d	1x	3d で 10% 消費（背景調査）	Backlog

# SLO 定義（28d rolling） displayName: "API Availability 99.9%" serviceLevelIndicator: requestBased: goodTotalRatio: goodServiceFilter: 'metric.type="..." metric.labels.status="2xx"' totalServiceFilter: 'metric.type="..."' goal: 0.999 rollingPeriod: 2419200s # 28 days # Multi-burn-rate Alerting Policy conditions: - displayName: "Fast burn (14.4x, 1h)" conditionThreshold: filter: 'select_slo_burn_rate("projects/.../serviceLevelObjectives/...", "3600s")' comparison: COMPARISON_GT thresholdValue: 14.4 duration: 60s - displayName: "Slow burn (6x, 6h)" conditionThreshold: filter: 'select_slo_burn_rate("projects/.../serviceLevelObjectives/...", "21600s")' comparison: COMPARISON_GT thresholdValue: 6 duration: 60s combiner: OR

暗記テーブル（28 日 SLO の予算を使い切る時間）：

28 日でちょうど消費

約 4.7 日

14.4x

約 2 日

36x

約 19 時間

3.6 Notification Channel 一覧と推奨

Channel	用途	推奨度	注意
Email	個人通知、Ticket レベル	△	緊急に弱い、開かれない
SMS	緊急エスカレ	△	Twilio 経由、国際 SMS コスト
Slack	チーム共有（OAuth）	◎	OAuth 失効に注意、メンション設計
PagerDuty	オンコールローテ + エスカレ	◎	Integration Key で連携、Severity マッピング設定
Webhook	カスタム連携（Rootly / 自前 ChatOps）	○	Basic auth / token auth 対応
Pub/Sub	Functions / Run でプログラム処理	○	at-least-once、サブスクライバで idempotency
Mobile App	Cloud Console アプリの push 通知	—	個人用、本番運用には弱い

⚠️ Channel テストの重要性 Notification Channel は定期的にテスト通知を送ること。Slack OAuth が切れた / PagerDuty Service が消えた / Webhook が 410 を返す等、本番障害時に通知が届かないのが最悪のパターン。Synthetic Monitor で channel.test API を週次実行するのが推奨。

3.7 Metric Scope（旧 Workspace）：複数プロジェクト集約

1 つの「scoping project」に他のプロジェクトを論理的に追加すると、Dashboards / Alerting / Metrics Explorer で横断クエリ可能。組織レベルの SRE 集約環境の基盤。

サポート規模

公式 375 projects（パフォーマンス影響覚悟なら最大 3,500）

注意

1 プロジェクトは同時に複数の Metric Scope に所属可。所属プロジェクト側の `roles/monitoring.viewer` 等が必要

SLO / Alert

Scope 内のメトリクスを跨いだ Alert / SLO を作成できる

ベスプラ

本番／非本番でスコープを分ける。CISO 用にもう 1 つ別 scope を作る

3.8 Dashboards as Code（Terraform）

resource "google_monitoring_dashboard" "api" { dashboard_json = jsonencode({ displayName = "API Service Dashboard" gridLayout = { columns = "2" widgets = [ { title = "Request Rate (RPS)" xyChart = { dataSets = [{ timeSeriesQuery = { prometheusQuery = "sum(rate(http_requests_total[1m]))" } }] } }, { title = "p99 Latency" xyChart = { dataSets = [{ timeSeriesQuery = { prometheusQuery = "histogram_quantile(0.99, sum by (le) (rate(latency_bucket[5m])))" } }] } } ] } }) }

3.9 Cloud Monitoring クォータ・制限値（公式表）

カテゴリ	項目	上限	変更
メトリクス	カスタム metric descriptor 数 / project	10,000	申請可
	カスタムメトリクスのラベル数 / descriptor	30	不可
	Prometheus descriptor のラベル数	200	不可
	active 時系列 / resource（custom）	200,000	申請可
	active 時系列 / resource（Prometheus）	1,000,000	申請可
Alerting	Alerting policies / Metric Scope	2,000（→ 申請で 10,000）	申請可
	Conditions / policy（metric-based）	6	不可
	Notification channels / policy	16	不可
	Notification channels / Metric Scope	4,000	申請可
Dashboard	Dashboards / Metric Scope	1,000	申請可
	Charts / dashboard	100	不可
	Lines / chart	50	不可
Retention	Custom / external / Prometheus メトリクス	24 ヶ月（6 週原解像度、以降 downsample）	—
Retention	その他（一部 GCP system metric）	6 週	—
Scope	Projects / Metric Scope	375（officially）/ 3,500（max）	—

3.10 Cloud Monitoring 事故ケース 7 件

⚠️ 事故 #M1：高基数ラベル（user_id）で時系列爆発 → 1M 時系列で API 429

状況	新機能で「user_id ごとに API 呼び出し回数を集計したい」と `user_id` ラベル付き counter を OTel 経由で push。1 週で 800k 時系列
原因	カスタムメトリクスのactive 時系列 200k 上限を超過。さらに古い時系列も保持されるため累積で増加
対処	① user_id ラベルを削除、② 必要なら BigQuery + Log Analytics で集計、③ ラベルは低カーディナリティの軸のみ（service / region / status_class）

⚠️ 事故 #M2：Alert flapping で 1 日 400 通、オンコール疲労

状況	「CPU > 80% で 1 分」のシンプル閾値が、深夜バッチで毎回飛び、3 ヶ月でオンコール離職
原因	① duration が短すぎ、② alignmentPeriod が短くノイズで上下、③ 症状ベース（ユーザー影響）ではなく原因ベース
対処	① SLO + Multi-burn-rate に再設計、② duration を 5m / 30m に拡大、③ バッチ時間帯は Snooze、④ メンテ窓は Notification Policy で抑制

⚠️ 事故 #M3：本番障害時に PagerDuty が鳴らなかった

状況	P1 障害が発生したが、オンコールが PagerDuty 通知を受け取らず、Slack 報告で気付くまで 45 分
原因	3 ヶ月前に PagerDuty Service を消して別 service へ移行、Notification Channel ID が無効化されていた
対処	① Synthetic Monitor で週次テスト alert を発火、② Channel 一覧を Terraform 管理、③ Cloud Functions で channel.test API を定期実行

⚠️ 事故 #M4：MQL で書いた Dashboard が deprecated 通知で全社停止候補に

状況	Cloud Monitoring がMQL を deprecate、PromQL への移行案内
原因	2019-2022 に作った Dashboard / Alert が MQL 依存、移行計画なし
対処	① 全 MQL を PromQL に変換（公式コンバータ参照）、② Dashboard を Terraform 化して再構築、③ 新規は PromQL のみ強制

⚠️ 事故 #M5：predict_linear forecast が誤検知して深夜 page 連発

状況	「disk が 24h 以内に満杯」forecast が、夜間バッチ後の一時増で連続発火
原因	forecast 窓が短すぎ、バックグラウンドノイズに敏感
対処	① 観測窓を 6h → 24h、② 予測期間を短くする、③ disk usage は SLO ではなく Ticket レベル alert に格下げ

⚠️ 事故 #M6：Metric Scope に追加忘れで新規プロジェクトが「見えない」

状況	新規プロジェクトの Cloud Run メトリクスが SRE Dashboard に出ない
原因	scoping project への追加忘れ、Terraform からも漏れていた
対処	① プロジェクト作成 Terraform module で自動で Metric Scope に追加、② Org Policy で必須化

⚠️ 事故 #M7：Notification channel per policy 16 個制限に達して新規 team 追加不可

状況	大規模組織で 1 つの Alert に 20+ teams をマッピング、追加できない
原因	policy あたり Notification Channel 16 個の上限（変更不可）
対処	① 単一 Pub/Sub channel に統一、② Cloud Functions で team ルーティング、③ policy を分割してチームグループごとに

3.11 Cloud Monitoring ベストプラクティス 9 項目

ラベルは低カーディナリティのみ：user_id / request_id は厳禁。service / region / status_class は OK。
SLO + Burn rate に統一：原因ベース閾値 alert は最小限。症状ベースで toil を減らす。
MQL は使わない：deprecate 済み、PromQL に統一。
Channel を週次テスト：channel.test を Synthetic Monitor or Cloud Functions で。
Dashboard / Alert を Terraform 化：環境間差分をなくす、災害復旧で即再生。
Alerting Policy に Playbook URL：通知メッセージに runbook リンクを含める。
SLO は 28 日 rolling から始める：calendar period より誤魔化しが効かない。
Metric Scope を分離：本番／非本番／セキュリティ。
Monitoring API quota も監視：自身の write API quota 不足が原因の欠落を検知。

4Managed Service for Prometheus（GMP）深掘り

GMP は OSS Prometheus 100% 互換の PromQL を Cloud Monitoring 上で動かすサービス。スケール・HA・長期保管（24 ヶ月）・カーディナリティ無制限をマネージドで提供。OSS Prometheus は単一プロセスでスケール上限がある一方、GMP は Monarch ベースで事実上無制限。試験では「Managed vs Self-deployed Collection」「PodMonitoring CR」「料金計算（サンプル課金）」「OSS との差分」が問われます。

「Google Cloud Managed Service for Prometheus is Google Cloud's fully managed multi-cloud solution for Prometheus metrics. It lets you globally monitor and alert on your workloads, using Prometheus, without having to manually manage and operate Prometheus at scale.」 — GMP overview ↗

4.1 Managed Collection vs Self-deployed Collection

図 4.1: 新規はManaged Collection 一択。Self-deployed は既存 OSS Prometheus からの移行か、local aggregation が必須なケース。

4.2 PodMonitoring / ClusterPodMonitoring / NodeMonitoring（K8s CR）

CR 種別	scope	用途	YAML キー
`PodMonitoring`	namespace 単位	app チームが自分の namespace で scrape 対象を宣言	`spec.selector.matchLabels`
`ClusterPodMonitoring`	cluster 全体	kube-state-metrics / cluster-wide な共通メトリクス	`spec.selector.matchLabels`
`NodeMonitoring`	cluster 全体（Node 単位）	node-exporter 系の Node メトリクス	`spec.endpoints[].port`
`Rules` / `ClusterRules`	namespace / cluster	recording rules / alerting rules を K8s で管理	OSS Prometheus rule YAML 互換
`OperatorConfig`	cluster	Operator 全体設定（外部ラベル等）	`gmp-public` ns で 1 個

# PodMonitoring 例（app namespace 内） apiVersion: monitoring.googleapis.com/v1 kind: PodMonitoring metadata: name: app-metrics namespace: payment spec: selector: matchLabels: app: payment-api endpoints: - port: metrics interval: 30s metricRelabeling: - action: drop # 高基数 metric を捨てる sourceLabels: [__name__] regex: 'go_gc_duration_seconds.*' - action: labeldrop # 高基数 label を捨てる regex: 'pod|instance' --- # ClusterPodMonitoring 例（cluster-wide） apiVersion: monitoring.googleapis.com/v1 kind: ClusterPodMonitoring metadata: name: kube-state-metrics spec: selector: matchLabels: app: kube-state-metrics endpoints: - port: http-metrics interval: 30s --- # Rules 例（local recording + alert） apiVersion: monitoring.googleapis.com/v1 kind: Rules metadata: name: payment-rules namespace: payment spec: groups: - name: payment rules: - record: payment:rps expr: sum(rate(http_requests_total[1m])) - alert: PaymentHighErrorRate expr: | sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.01 for: 5m annotations: summary: "Payment 5xx rate > 1%"

4.3 GMP の料金モデルとコスト制御

主な課金

取り込みされたサンプル数（バケット型階段単価）+ 読み取り API 数（少額）

ストレージ

追加料金なし（24 ヶ月まで）。これが GMP の最大の魅力

デフォルト ingest quota

500 QPS（=100k サンプル/秒）/ project

デフォルト read quota

100 QPS / Metric Scope

カーディナリティ

公式に「active 時系列に上限なし」だが、料金で実効上限になる。`metricRelabeling` で抑制必須

サンプル数の概算公式

# 1 metric × 1 series × 1 scrape = 1 sample samples/月 = (scrape_targets × metrics_per_target × series_per_metric) × (60 / interval_seconds × 60 × 24 × 30) # 例：100 Pod × 200 metric × 平均 5 series × 30s 間隔 → 月約 86 億サンプル # 100 × 200 × 5 × (60/30 × 60 × 24 × 30) = 100,000 × 86,400 = 8.64B/月

⚠️ コスト爆発の典型 3 パターン

scrape interval が短すぎ：15s vs 60s で 4 倍コスト。SRE 用には 30s で十分。
histogram bucket 過多：1 メトリクスで bucket 50 個 + label 5 個 + service 200 個 = 50,000 series。
Java JVM / Go runtime メトリクスを丸ごと取得：`go_gc_*` `jvm_gc_*` は数百種類、ほぼ使わないので drop 推奨。

4.4 PromQL 互換性と Cloud Monitoring との違い

項目	OSS Prometheus	GMP	Cloud Monitoring 既存メトリクス
PromQL 互換性	100%	100%	部分対応（PromQL ラッパー経由）
メトリクス名前空間	任意	`prometheus.googleapis.com/...`	`compute.googleapis.com/...` 等 GCP 標準
ラベル上限	無制限	200 / descriptor	30 / descriptor
active 時系列	無制限（メモリ次第）	無制限（料金で実効上限）	200k / resource
保持期間	設定次第	24 ヶ月	24 ヶ月
Grafana 互換	○	○（PromQL API 経由）	△（PromQL ラッパー）

4.5 Multi-cluster Federation と Global View

GMP はデフォルトで同じ project に書き込まれた全クラスタのメトリクスを 1 つの PromQL でクエリ可能（global view）。OSS Prometheus でいう federation を、明示的設定なしに実現。複数 region / 複数クラスタの kube-state-metrics を 1 つの dashboard に出すといった用途で強力。

# 異なるクラスタを区別する `cluster` ラベルが自動付与される sum by (cluster, location) ( rate(kube_pod_container_status_running[1m]) ) # Multi-tenant：複数 project の集約は Metric Scope 経由で可能 # scoping project の Grafana から各 project の Prometheus を統合 view

4.6 GMP 事故ケース 4 件

⚠️ 事故 #G1：cardinality 爆発で月 800 万円、当月停止

状況	新規導入で全 service の `http_requests_total` を `user_id, request_id, ip_address` ラベル付きで取得、1 週で 30M time series
原因	OSS 感覚で「無制限だから何でも付ける」、`metricRelabeling` 未設定
対処	① 即座に PodMonitoring で `labeldrop user_id\|request_id\|ip_address`、② 既存 series は時間経過で消滅、③ 料金制御 alert を設定

⚠️ 事故 #G2：scrape interval 15s で 4 倍コスト、SRE には 30s で十分

状況	OSS Prometheus テンプレからのコピペで 15s interval を踏襲
原因	デフォルト OSS 設定の流用、Burn rate アラートには 30s で必要十分
対処	① PodMonitoring の `interval: 30s` に変更、② Page アラートが必要なメトリクスのみ 15s に

⚠️ 事故 #G3：Java JVM メトリクス丸ごとで series 数桁違い

状況	Spring Boot 100 Pod が `micrometer` で 800 metric × 各 5 series × 3 GC bucket 等で series 数 1.2M
原因	JVM / GC メトリクスの大半は使わないのに全部取り込み
対処	① `metricRelabeling action: drop` で `jvm_buffer_`, `jvm_classes_` 等を drop、② 残す metric を whitelist 化

⚠️ 事故 #G4：Self-deployed Prometheus で local aggregation 動かず、メトリクス欠落

状況	OSS Prometheus からの移行直後、recording rule の結果が GMP に来ない
原因	OSS の `remote_write` 設定で `external_labels` の `cluster` が重複、GMP 側で衝突 reject
対処	① `external_labels` の cluster ラベルを一意に、② Managed Collection への移行を検討

5OpenTelemetry & Cloud Trace 深掘り

分散トレース（distributed tracing）はマイクロサービス時代の必須スキル。Google Cloud は OpenTelemetry（OTel）を第一級サポートし、Cloud Trace / Monitoring / Logging に統合送信できる。試験では「OTel Collector の 3 段構成」「Head vs Tail Sampling」「W3C Trace Context」「Trace ID と Log の紐付け」「Cloud Run / Functions の自動紐付け」が頻出。OpenCensus は legacyで OTel に統合済み。

「OpenTelemetry is a collection of APIs, SDKs, and tools. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software's performance and behavior.」 — OpenTelemetry concepts ↗

5.1 OpenTelemetry 全体図

図 5.1: Collector の必須順序は memory_limiter → 加工 → batch。Sampler は加工と batch の間。Exporter はgooglecloud（Trace+Logging）と googlemanagedprometheus（GMP）を分離。

5.2 OTel Collector：Receivers / Processors / Exporters

📥 主要 Receivers

otlp — OTLP（gRPC 4317 / HTTP 4318）
prometheus — OSS Prometheus scrape
jaeger — Jaeger 互換受信
zipkin — Zipkin 互換受信
filelog — テキストログファイル tail
hostmetrics — OS（CPU/Mem/Disk）

⚙️ 主要 Processors

memory_limiter — メモリ保護（必須）
batch — バッチ送信（必須）
attributes — 属性追加/削除（PII redact）
resource — Resource Attribute 操作
probabilistic_sampler — Head-based
tail_sampling — Tail-based（後述）
transform — OTTL で任意変換

主要 Exporters：googlecloud（Cloud Trace + Logging）/ googlemanagedprometheus（GMP）/ otlp / prometheus / logging（stdout デバッグ用）。

# OTel Collector 推奨構成 receivers: otlp: protocols: grpc: {endpoint: 0.0.0.0:4317} http: {endpoint: 0.0.0.0:4318} processors: memory_limiter: check_interval: 1s limit_mib: 1500 spike_limit_mib: 512 attributes: actions: - key: user.email action: delete # PII 削除 - key: env value: prod action: insert tail_sampling: decision_wait: 30s num_traces: 100000 policies: - name: errors # エラーは 100% 保持 type: status_code status_code: {status_codes: [ERROR]} - name: latency # 500ms 超は 100% 保持 type: latency latency: {threshold_ms: 500} - name: sample-10pct # 残りは 10% type: probabilistic probabilistic: {sampling_percentage: 10} batch: timeout: 10s send_batch_size: 1024 exporters: googlecloud: # Cloud Trace + Logging project: my-proj googlemanagedprometheus: # GMP project: my-proj service: pipelines: traces: receivers: [otlp] processors: [memory_limiter, attributes, tail_sampling, batch] exporters: [googlecloud] metrics: receivers: [otlp] processors: [memory_limiter, batch] exporters: [googlemanagedprometheus] logs: receivers: [otlp] processors: [memory_limiter, batch] exporters: [googlecloud]

5.3 Sampling 戦略：Head-based vs Tail-based

戦略	判定タイミング	長所	短所	使い分け
Head-based（SDK 側 probabilistic）	span 開始時	軽量、決定論的、Collector 不要	エラー trace を捨てる可能性	低トラフィック / シンプル系
Tail-based（Collector で trace 全体を見てから）	trace 終了後（30s 待機等）	エラー / 遅い trace を 100% 保持	Collector メモリ消費大、設定複雑	本番マイクロサービス
parentbased_*	親 span の決定に従う	distributed で一貫性確保	—	マイクロサービス必須
always_on / always_off	常に on/off	明示的	—	デバッグ / 完全停止

⚠️ Tail-based sampling の落とし穴

Collector はtrace 全体をメモリに保持するため、num_traces × 平均 span サイズで OOM。
decision_wait の間に下流からの span が来なければincomplete traceとして誤評価。マイクロサービスの最長遅延 +α を見積もる。
Tail-based は水平スケール時の Trace 分散に注意。同じ trace_id を同じ Collector に届ける必要があり、load balancing exporter で routing。

5.4 Context Propagation：W3C / B3 / X-Cloud-Trace-Context

形式	ヘッダ	採用元	備考
W3C Trace Context	`traceparent`, `tracestate`	OpenTelemetry 標準	新規はこれ一択
B3（Zipkin）	`X-B3-TraceId`, `X-B3-SpanId`, `X-B3-Sampled`	Zipkin / Istio	legacy 互換
GCP 独自	`X-Cloud-Trace-Context: TRACE_ID/SPAN_ID;o=1`	Cloud Run / Functions / GAE	自動で W3C と相互変換

traceparent ヘッダ形式：00-{trace_id 32hex}-{parent_id 16hex}-{flags 2hex}。flags の 01 は sampled。

# OTel SDK（Python）で W3C + B3 両対応 from opentelemetry.propagate import set_global_textmap from opentelemetry.propagators.b3 import B3MultiFormat from opentelemetry.trace.propagation.tracecontext import TraceContextTextMapPropagator from opentelemetry.propagators.composite import CompositePropagator set_global_textmap(CompositePropagator([ TraceContextTextMapPropagator(), B3MultiFormat(), ]))

🔑 試験頻出：「trace ID が外部 API 跨ぎで途切れる」原因 No.1 → サービス間でpropagation format が一致していない。OTel 標準は W3C Trace Context。Istio 系は B3 を投げるので、必ず両方対応の CompositePropagator か、Istio 側を W3C に切り替える。

5.5 Trace ID と構造化ログの紐付け（最頻出）

構造化ログ（jsonPayload）に以下のキーを含めると、Cloud Logging が自動で Trace と相互紐付け。Logs Explorer の「Show trace」ボタンや Cloud Trace の「Logs」タブで相互ジャンプできる。

フィールド	形式	意味
`logging.googleapis.com/trace`	`projects/PROJECT_ID/traces/TRACE_ID`	trace への参照（フル名）
`logging.googleapis.com/spanId`	16 桁 hex	該当 span ID
`logging.googleapis.com/trace_sampled`	bool	true なら sampling 対象

# Python：構造化ログに trace ID を含める import json from opentelemetry import trace PROJECT_ID = "my-proj" def log_with_trace(severity, message, **kwargs): span = trace.get_current_span() ctx = span.get_span_context() entry = {"severity": severity, "message": message, **kwargs} if ctx.is_valid: entry["logging.googleapis.com/trace"] = \ f"projects/{PROJECT_ID}/traces/{format(ctx.trace_id, '032x')}" entry["logging.googleapis.com/spanId"] = format(ctx.span_id, "016x") entry["logging.googleapis.com/trace_sampled"] = ctx.trace_flags.sampled print(json.dumps(entry)) # Cloud Logging が stdout を構造化ログとして取り込む

Cloud Run / Cloud Functions では X-Cloud-Trace-Context から自動抽出されるため、上記コードは GKE / GCE で明示的に必要。

5.6 Cloud Trace 仕様と制限

項目	内容
プロトコル	OpenTelemetry（OTLP）/ Cloud Trace API（proprietary）/ Telemetry API（OTel エコシステム互換推奨）
trace ID	128-bit（32 桁 hex）、W3C 標準
span ID	64-bit（16 桁 hex）
サンプリング	SDK / Collector で制御。Cloud Trace 側でも追加サンプリング（過去 30 日のレートに基づく）が入ることに注意
保持期間	30 日
ランタイム	Compute Engine / GKE / App Engine / Cloud Run 等。App Engine standard と Cloud Run は自動 traceサポート
制限	VPC Service Controls 対応 / Assured Workloads 非対応（データ residency 要件）
料金	取り込み 250 万 span/月無料、以降は span 数に応じた階段料金

5.7 OpenCensus vs OpenTelemetry

OpenCensus は Google 発のテレメトリ標準（2018-）、2019 年に OpenTracing と統合してOpenTelemetryとなった。OpenCensus は legacy、新規は必ず OTel。既存 OpenCensus コードは opentelemetry-opencensus-bridge で段階移行可能。

5.8 OTel / Trace 事故ケース 5 件

⚠️ 事故 #T1：trace ID が Istio mesh の sidecar で途切れる

状況	Istio + OTel SDK のサービスで、Service A → B 間で trace が分離（Trace ID が変わる）
原因	Istio は B3 ヘッダで propagate、アプリは W3C のみ受信 → 互換性なしで新規 trace 生成
対処	① OTel SDK で CompositePropagator(W3C + B3)、または ② Istio mesh-config で W3C propagation 有効化

⚠️ 事故 #T2：tail-based sampling の Collector が OOM

状況	num_traces=200,000 + 平均 trace 500 span の設定で Collector メモリ 8 GB が即枯渇
原因	decision_wait 60s × 5,000 RPS の trace を全部メモリ保持
対処	① num_traces を 50,000 に縮小、② Collector を horizontal scale + load balancing exporter で trace_id routing、③ decision_wait を 15s に短縮

⚠️ 事故 #T3：Cloud Run で trace と log の紐付けが効かない

状況	Cloud Run でアプリログから Trace ID へのジャンプリンクが出ない
原因	アプリが `print()` で textPayload を出力 → 構造化ログでないため `X-Cloud-Trace-Context` の自動抽出が利かない
対処	① JSON でログ出力（`{"severity":"INFO","message":"..."}`）、② `logging.googleapis.com/trace` を明示的に含める

⚠️ 事故 #T4：100% sampling 設定でも Cloud Trace 側で 0.1 req/sec まで間引かれる

状況	アプリ側 100% でも、Cloud Trace 表示では trace が大半欠落
原因	Cloud Trace 側の追加 sampling（高頻度トラフィック保護のための自動制御）
対処	① `force=true` フラグ付き Trace API 直書き、② OTel Collector → googlecloud exporter で抑制を回避（推奨）

⚠️ 事故 #T5：OpenCensus 経由のメトリクスが二重課金

状況	legacy OpenCensus exporter + 新 OTel SDK 両方稼働、Custom Metric が両方から書き込まれて時系列倍増
原因	移行期の併用
対処	① 段階移行は OpenCensus exporter を即 disable、② OTel への完全切替を期限付きで実施

6Cloud Profiler & Error Reporting

Cloud Profiler は本番環境で常時動かせる低オーバヘッド（< 1% CPU）の継続的プロファイラ。Error Reporting はアプリ例外を自動グルーピングして集約。両者とも「コード行レベル」「例外発生箇所」を高頻度メトリクス以上の解像度で見せる、可観測性の最終層です。

6.1 Cloud Profiler の 6 種類

プロファイル	計測内容	典型用途	Java	Go	Python	Node.js
CPU time	CPU を使った時間	「どの関数が CPU を食う？」	○	○	○	○
Heap	アロケート済みのメモリ	メモリリーク調査	○	○	○	○
Allocated heap	アロケート総量（GC 含む）	GC pressure 分析	○	○	—	—
Contention	ロック / Mutex 競合	Goroutine / thread 待ち	○	○	—	—
Wall time	経過時間（IO 待ち含む）	IO blocking 分析	○	○	○	○
Threads	スレッド数の推移	スレッドリーク	○	—	—	—

🔑 試験頻出：症状 → Profiler 種別の即答表

CPU 100% に張り付き → CPU time profile
メモリ増加が止まらない（リーク） → Heap profile
GC pause が長い → Allocated heap profile
Goroutine / Mutex 待ちで応答遅延 → Contention profile
同期 IO 待ちで CPU 使ってないのに遅い → Wall time profile
Java の thread leak → Threads profile

6.2 Profiler 統合と Heap profile によるメモリリーク検出フロー

# Python import googlecloudprofiler googlecloudprofiler.start( service='my-service', service_version='1.0.0', verbose=3, ) # Go import "cloud.google.com/go/profiler" profiler.Start(profiler.Config{ Service: "my-service", ServiceVersion: "1.0.0", }) # Java（-javaagent） java -agentpath:/opt/cprof/profiler_java_agent.so=-cprof_service=my-svc,-cprof_service_version=1.0.0 -jar app.jar

Heap profile を 1 時間後 / 12 時間後で比較ビュー（diff）を開く
増加し続けている関数 / 型を特定（flame graph の横幅 = アロケート量）
GC 後も残るオブジェクトに着目（cache / global map / unclosed resources）
修正後、再度 Profiler で減少を確認

6.3 Profiler の制限

オーバヘッド

公式 < 1% CPU、本番常時稼働を前提

プロファイル間隔

サービス × バージョン × ゾーンごとに約 1 分間のサンプル

言語制限

Python は CPU / Heap / Wall のみ。Contention / Allocated は Java / Go 限定

UI 保持

過去 30 日のプロファイル参照可

料金

無料

6.4 Error Reporting の自動グルーピングアルゴリズム

例外・エラーをスタックトレースのシグネチャ（クラス名 + メソッド名 + 行番号 + 例外型）で自動グループ化。同じ根本原因のエラーは 1 つの「Error Group」に集約される。

項目	内容
集約キー	例外型 + スタックトレース上位 N フレーム（フレームワーク特有の wrapper は除外）
取得元	① `severity>=ERROR` のログから自動抽出、② `report()` API で明示報告
UI 情報	スタックトレース / 発生回数 / 影響ユーザー数 / 最初/最後の発生時刻 / 関連 Trace
連携	Cloud Logging（自動）/ Cloud Trace（紐付け）/ Alerting Policy（新規エラーグループ通知）
料金	無料

💡 Error Reporting vs Cloud Logging の使い分け

「例外を集約して影響範囲を見たい」→ Error Reporting
「個別ログを検索したい」→ Cloud Logging Logs Explorer
「新規エラー発生で通知」→ Error Reporting Alerting（log-based alert より楽）

6.5 Profiler / Error Reporting 事故ケース 3 件

⚠️ 事故 #P1：Profiler agent でアプリのレイテンシが 5% 増

状況	Java アプリで Profiler 有効化後、p99 が 100ms → 105ms に
原因	Java の `-agentpath` 起動オプションが古く、最新版の最適化が効いていない
対処	① Java agent を最新（>= 2024 リリース）に更新、② 高負荷時のみ Profiler を一時停止する設定も検討

⚠️ 事故 #P2：Python Profiler で Contention profile が取れず

状況	「Python アプリの GIL 競合を Contention profile で見たい」リクエスト
原因	Cloud Profiler のPython は CPU / Heap / Wall のみサポート、Contention は Java / Go 限定
対処	① py-spy や cProfile で代替、② Wall time profile で IO 待ちの間接観測

⚠️ 事故 #P3：Error Reporting で 1 エラーが 50 グループに分散、傾向掴めず

状況	同じ NullPointerException が 50 個の別グループとして表示
原因	スタックトレース内に dynamic class（Spring AOP proxy 等）が含まれ、フレームごとに別シグネチャ化
対処	① stack trace 除外パターンをカスタムグルーピングルールで設定、② log-based metric で例外型ベースに集計し直し

7Gemini Cloud Assist 深掘り（2024-2025 新規）

Gemini Cloud Assist は Google Cloud Console に統合されたAI 支援機能。Cloud Observability に深く統合されており、ログ要約 / メトリクス解釈 / Trace 要約 / クエリ自動生成 / Investigations（根本原因仮説）で MTTR（平均復旧時間）を大幅短縮。PCDE では「AI 統合で何ができるか」「データプライバシー」「IAM ロール」が問われます。

「Gemini Cloud Assist provides AI-powered assistance to help you design, operate, and troubleshoot your applications on Google Cloud.」 — Gemini Cloud Assist overview ↗

7.1 Observability 関連の主要機能

機能	使い方	典型ユースケース
Log Summary / Insights	Logs Explorer の「Summarize logs」ボタン	「過去 1h の異常を要約」「なぜ errors spike？」
Investigations	アラートから「Investigate」	過去ログ + メトリクス + 最近のデプロイを相関分析して根本原因仮説を提示
Explain this chart	Dashboard / Metrics Explorer のチャートで右クリック	メトリクス名・ラベル・値から「なぜこの値か」自然言語で解説
Trace Summary	Cloud Trace の Trace 詳細	複雑な waterfall を「最大ボトルネックは X」と要約
Query 自動生成（LQL / PromQL）	Explorer 内の自然言語入力	「先週 5xx が多かったサービス」→ LQL / PromQL に変換
Error grouping insights	Error Reporting	同種エラーの根本パターンを AI が解説

7.2 Investigations の動作モデル

アラート発火時、Gemini が以下のデータソースを相関分析：

アラート発火直前 30-60 分のログ・メトリクス・トレース
最近のデプロイ（Cloud Build / Cloud Deploy のイベント）
過去の類似アラート（同じ条件で発火した過去 N 件と対応履歴）
関連リソース（同じ project / VPC / cluster 内の他リソース）

出力例：

「This alert correlates with a Cloud Deploy rollout at 14:23 UTC that updated 'payment-api' from v2.3.1 to v2.4.0. Error rate increased from 0.1% to 4.2% on this revision only. Suggested action: rollback or investigate the new version's database connection pool config.」

7.3 Explain this chart / Trace summary の例

📊 Explain this chart

「The chart shows CPU usage on 'web-api' service, which spiked from 30% to 85% at 10:15. This coincides with traffic increase from 200 RPS to 600 RPS. Related metric: container_memory_usage also increased. Likely a traffic surge, not a memory leak.」

🔗 Trace summary

「Request took 1.2s total. Breakdown: 50ms auth, 200ms cache miss, 850ms DB query on 'users' table (with full table scan, no index hit), 100ms response serialization. Bottleneck: DB query. Suggested: add index on 'email' column.」

7.4 IAM ロール

ロール	権限
`roles/cloudaicompanion.user`	Gemini Cloud Assist の利用（自然言語入力、要約、Query 生成）
`roles/cloudaicompanion.admin`	組織レベルでの利用管理、有効化／無効化
`roles/observability.editor`	Investigations の作成・編集

7.5 データプライバシーと制限

データ学習

入力データはモデル学習に使われない（Enterprise 契約デフォ）

データ residency

主要リージョン（us / eu / asia）のみ。Assured Workloads 環境は要確認

VPC SC

VPC Service Controls 内でも利用可（perimeter 越え不要）

ライセンス

Standard tier は無料枠あり、Enterprise は別ライセンスが必要なケース

制限

1 セッションあたりのコンテキスト長、リクエスト/分の rate limit あり

7.6 Gemini Cloud Assist 事故ケース 2 件

⚠️ 事故 #G1：Investigations が誤った原因を提示し、誤ロールバック

状況	アラート発火時に Gemini が「最近のデプロイが原因」と提示、エンジニアが即ロールバック → 実際の原因は別の外部 API 障害
原因	AI 提示は仮説であり確定ではない。検証を省略した
対処	① Investigation 結果は必ずログ・メトリクス・トレースで裏付け、② Playbook に「AI 提示 → 検証 → 対応」フローを明記

⚠️ 事故 #G2：金融機関で PII 含むログ要約が監査指摘

状況	Log Summary 機能でユーザーメールアドレスを含むエラーログを要約させ、監査でデータ residency 違反指摘
原因	ログに PII が含まれたまま、AI モデルに送信
対処	① アプリ層で Sensitive Data Protection（DLP）でリダクション、② Gemini Cloud Assist の利用範囲を Org Policy で制限、③ Assured Workloads では Gemini 無効化

8事故ケース総集編 / トラブルシュート判断ツリー

8.1 5 領域別トラブルシュート判断フロー

図 8.1: 障害発生時、まず「5 領域のどれか」を即判定し、各領域の初動ツールに直行する。Logs Explorer は全領域の起点になりやすい。

8.2 全章の事故ケース一覧（30+ 件）

#	領域	事故	根本原因	即対処
1	Logging	Data Access ログで月 80 万円	exemptedMembers 未設定	SA を除外、bytes_ingested を Budget Alert
2	Logging	PII（クレカ）混入	アプリ層リダクション欠如	Sensitive Data Protection API
3	Logging	health check ログ月 200 GiB	Exclusion 未設定	`--add-exclusion` で即削減
4	Logging	LBM の request_id ラベルで時系列爆発	高基数ラベル	低基数ラベルに変更
5	Logging	Aggregated Sink から子フォルダ漏れ	Folder 単位 sink	Org レベルに昇格
6	Logging	_Default 7 日縮小で Policy Denied 消失	Audit 別 Bucket 化忘れ	Audit 専用 Bucket 7 年
7	Logging	BQ Sink で Log Bucket と二重課金	Log Analytics 未使用	Bucket を analytics 化
8	Monitoring	user_id ラベルで時系列 1M 超	カーディナリティ無制限と誤解	ラベル削除、200k 制限尊守
9	Monitoring	Alert flapping で 400 通/日	原因ベース閾値	SLO Burn rate に置換
10	Monitoring	本番障害で PagerDuty 鳴らず	Channel 無効化放置	週次 channel.test
11	Monitoring	MQL Dashboard deprecate 通告	レガシー MQL 依存	PromQL に完全移行
12	Monitoring	predict_linear forecast で深夜 page	窓が短すぎ	観測窓 24h に拡大
13	Monitoring	Metric Scope 追加忘れで新規 prj 不可視	手動運用	Terraform で自動追加
14	Monitoring	Channel/policy 16 個制限	大規模 team マッピング	Pub/Sub 一元 + Functions ルーティング
15	GMP	cardinality で月 800 万円	OSS 感覚で全ラベル	metricRelabeling labeldrop
16	GMP	15s scrape で 4 倍コスト	OSS テンプレ流用	30s に変更
17	GMP	JVM メトリクスで series 1.2M	未選別取り込み	drop pattern で whitelist
18	GMP	self-deployed で external_labels 衝突	cluster ラベル重複	label 一意化、Managed へ
19	Trace	Istio で trace 途切れ	W3C / B3 不一致	CompositePropagator
20	Trace	tail sampling Collector OOM	num_traces 過大	水平スケール + LB routing
21	Trace	Cloud Run で trace-log 紐付かず	textPayload 出力	JSON 構造化ログ
22	Trace	100% sampling でも Trace 欠落	Cloud Trace 側 sampling	OTel Collector exporter 経由
23	Trace	OpenCensus 並走で二重メトリクス	移行期の併用	OpenCensus 即 disable
24	Profiler	Java Profiler でレイテンシ 5% 増	古い agent	agent 最新化
25	Profiler	Python Contention profile 不可	Python サポート外	py-spy / Wall time 代替
26	Error Rep	1 例外が 50 グループに分散	動的 class のスタックトレース	カスタムグルーピングルール
27	Gemini	Investigations 仮説で誤ロールバック	検証省略	必ずログ・メトリクスで裏付け
28	Gemini	PII 含むログ要約で監査指摘	DLP 未適用	アプリ層 DLP + Org Policy 制限
29	Infra	VM が NW 接続不可	VPC / FW 設定	Connectivity Tests
30	Infra	FW ルール過剰許可	運用不在	Firewall Insights
31	CI/CD	Cloud Build hang	Default Pool で Private 不可	Private Pool
32	App	5xx 急増の原因不明	trace-log 紐付け欠如	OTel + 構造化ログ
33	Perf	p99 悪化、関数特定できず	Profiler 未導入	Cloud Profiler 常時稼働
34	Perf	memory leak が GC 後も増加	cache / unclosed resource	Heap profile diff
35	Obs	メトリクス突然欠落	Ops Agent crash	agent log + metric absence alert

8.3 試験で問われる即答パターン

🔑 即答マトリクス（試験本番で迷ったらこれ）

問題のキーワード	正解（即答）
VM のログ + メトリクス収集（新規）	Ops Agent（Legacy 2 つは非推奨）
Audit Log 4 種類でデフォルト無効	Data Access（BigQuery は例外で ON）
`_Required` バケットの保持期間	400 日固定・削除不可・無料
ログ取り込みコストを即座に下げたい	Exclusion（Sink 編集だけで即時反映）
SQL でログ分析、データ重複なし	Log Analytics（Bucket アップグレード）
組織全 Audit Log を 1 BQ に集約	Org-level Aggregated Sink with `--include-children`
PII を本番ログから除去	アプリ層で Sensitive Data Protection（旧 DLP）API
複数ステップの能動監視	Synthetic Monitor（Uptime Checks では単一）
distribution metric の可視化	Heatmap
p99 レイテンシを histogram から	`histogram_quantile(0.99, ...)`
counter の秒速	`rate()` / 突発は `irate()`
新規 K8s で Prometheus を導入	GMP Managed Collection + PodMonitoring CR
OTel 推奨 propagation	W3C Trace Context（`traceparent`）
エラー / 遅い trace を必ず残す	Tail-based sampling（Collector 側）
trace と log の紐付けフィールド	`logging.googleapis.com/trace`
Cloud Run で trace-log 自動紐付け	`X-Cloud-Trace-Context` ヘッダ自動処理
本番で常時 CPU/Mem ホットスポット	Cloud Profiler（< 1% オーバヘッド）
メモリリーク調査	Heap profile
Mutex / Goroutine 競合	Contention profile（Java / Go のみ）
例外を集約して影響範囲	Error Reporting
SRE Workbook Fast burn rate	1h で 14.4x（5m AND 1h）
SRE Workbook Slow burn rate	6h で 6x（30m AND 6h）
症状ベース alert	SLO Burn rate ベース
複数プロジェクトを 1 つに集約	Metric Scope（375 prj 推奨）
使われていない FW ルール検出	Firewall Insights
2 点間ネットワーク到達性診断	Connectivity Tests（NIC）
GCP インフラ内のパケロス可視化	Performance Dashboard（NIC）
複雑なアラート根本原因の AI 推定	Gemini Cloud Assist Investigations
「過去 1h の異常を自然言語で要約」	Gemini Cloud Assist Log Summary
Cloud Service Mesh の旧名	Anthos Service Mesh（ASM）
OpenCensus の現状	legacy、OpenTelemetry に統合済み

8.4 トラブルシュート意思決定フロー

💡 障害発生時の切り分け順序（標準プレイブック）

5 領域のどれか判定：Infrastructure / CI/CD / Application / Observability / Performance のうちどれか即決
Cloud Audit Logs を先に見る：「誰がいつ何を呼んだか」を確定。最近の変更がないか
Logs Explorer で 5xx / ERROR を時系列確認：いつから増えたか、急峻 or なだらかか
関連 trace を Cloud Trace で開く：waterfall で遅延箇所を特定
該当 service の Profiler を確認：CPU / Heap / Contention の傾向変化
Service Mesh metrics でサービス間通信を確認（istio_*）
VPC Flow Logs / Performance Dashboard で NW 層を確認
Gemini Investigations で仮説生成 → 必ず証拠で裏付け
Quota / Budget を確認：自身の Monitoring / Logging API quota も含む
Postmortem に必ず記録：再発防止 + alert 設計の見直し

8.5 次のステップ

🎯 試験前最終チェック

Section 4（可観測性とトラブルシュート）で基礎概念を再確認
Deep Dive: CI/CD と組み合わせて、デプロイ起因の障害シナリオを通しで理解
問題演習で本番形式の問題を解く
用語集で曖昧な用語を即時引き
公式 PCDE 試験ガイドとサンプル問題を最終チェック

9. Cloud Logging 運用深掘り：事故・コスト・肥大化対策

Cloud Logging は「気づけば月数十万円〜数百万円」が最も起きやすいサービス。事故ケース 10 件、コスト構造、肥大化パターン、最適化テクニックを徹底深掘り。

📖 公式：Cloud Logging pricing / Logging quotas and limits

9.1 重大事故ケース 10 件

⚠️ 事故 9-1：VPC Flow Logs を全 subnet で sample=100% にして月 200 万円ネットワーク調査のため一時的に全 subnet で aggregation_interval: INTERVAL_5_SEC + flow_sampling: 1.0 + metadata: INCLUDE_ALL_METADATA を有効化。1 週間放置で月換算 200 万円超過。
対処：subnet 単位で必要な範囲のみ enable、デフォルトは flow_sampling: 0.5 + INTERVAL_10_MIN。
教訓：VPC Flow Logs は「全 ON」絶対禁止、subnet 単位で granular に。Org Policy constraints/compute.requireVpcFlowLogs + 同時に compute.vpcFlowLogsConfig でサンプル率上限を強制。

⚠️ 事故 9-2：Data Access Logs 全有効で SA 生成 API call が全記録、BQ Sink クォータ超過コンプライアンス対応で auditConfig.dataAccess: ALL_SERVICES を Org level で有効化。Cloud KMS の Decrypt 等が秒間 1 万回 audit log 化、BQ sink の streaming insert quota（100 MB/sec/project）を超過し sink が DROP モード。
対処：Data Access Logs はサービス単位で選択有効化（storage.googleapis.com のみ等）、BQ sink 先を専用 project に分離 + quota 引き上げ。

⚠️ 事故 9-3：Log Bucket retention を 365 日に変更して 2 ヶ月後に料金 3 倍規制対応で _Default bucket retention を 30 → 365 日に変更。retention 延長は過去ログにも遡及適用のため、既存 storage が一気に 12 倍課金対象に。
対処：retention 延長は新規 bucket に Aggregated Sink、規制ログのみ長期保管。Log Buckets retention 公式 ↗

⚠️ 事故 9-4：開発環境の DEBUG ログ垂れ流しで本番並みコスト Dev project に log Exclusion なし、Spring Boot app の DEBUG ログを GKE workload が秒間 1000 件出力。Dev で月 15 万円。
対処：env 単位で exclusion filter テンプレ化、Terraform module で severity < INFO の exclusion を全 dev/staging project に自動適用。

⚠️ 事故 9-5：log-based metric の高基数ラベル（user_id）で時系列爆発ユーザ別エラーカウントを log-based metric の label に user_id（10 万ユーザ）を含めた結果、custom metric の cardinality limit（メトリクスあたり 100,000 series）超過で metric の値が null になる。Cloud Monitoring の ingestion コストも増大。
対処：ラベルは bounded set のみ（status_code、method、region 等）。ユーザ別分析は BQ sink → SQL。

⚠️ 事故 9-6：Pub/Sub sink の subscription 詰まりで dead-lettering 失敗 Pub/Sub sink で subscriber app の処理が追いつかず backlog 数億メッセージ。retention 7 日経過で消失、後段の SIEM に届かず audit 要件違反。
対処：Pub/Sub sink は subscriber の処理能力に余裕、dead-letter topic 必須、ack_deadline 適切に、subscriber を Dataflow streaming 等の autoscale ベースに。

⚠️ 事故 9-7：Aggregated Sink の Org level 権限不足で sink が空振り Org level Aggregated Sink を作成、destination は別 project の BQ。sink の writer identity（SA）に destination project の BigQuery Data Editor 付与漏れで sink は successful 表示なのに BQ には何も流れない（silent failure）。
対処：sink 作成後 gcloud logging sinks describe で writer identity を取得 → 必ず destination で IAM grant、Cloud Monitoring で sink の logging.googleapis.com/exports/error_count を監視。

⚠️ 事故 9-8：LQL の巨大時間範囲で console フリーズ + クエリ料金 Logs Explorer で resource.type="k8s_container" を時間指定なしで実行、過去 90 日分スキャン → ブラウザ unresponsive、Log Analytics の場合は BQ クエリ料金が発生。
対処：常に時間範囲を絞る（最大 7 日推奨）、severity filter / resource filter を最初に。

⚠️ 事故 9-9：Sink filter ミスで重要監査ログを除外コスト削減目的で NOT resource.type="cloud_run_revision" exclusion filter を _Default に適用。意図外に Cloud Run の全 access log を exclusion、後日インシデント調査で証跡が無い。
対処：exclusion filter は除外より sink 経由の別 bucket 化を優先、_Required bucket（admin activity, system event）は変更不可だが他は要設計。

⚠️ 事故 9-10：_Default Bucket を誤って削除（30 日 retention 設定後）コスト削減で _Default bucket retention を変更しようと delete → 再作成を実行、過去 30 日のログが消失。
対処：_Default は delete 禁止（retention 変更のみ）、Org Policy iam.disableServiceAccountKeyDeletion 相当の bucket protection は存在しないため、role を絞る（logging.adminBucket 権限を最小化）。

9.2 Cloud Logging コスト構造の解剖

料金コンポーネント	単価（目安）	無料枠
Ingestion fee（_Default bucket）	$0.50 / GiB	最初の 50 GiB/月/project
Storage fee（retention 30 日超過分）	$0.01 / GiB / 月	30 日無料
Log Analytics（既存 _Default）	クエリ実行 $5/TB	無料 storage
VPC Flow Logs	Logging ingestion 単価 + Network telemetry $0.50/GiB	—
Sink to BigQuery	BQ ingestion + storage 別途	BQ 側の無料枠あり
Sink to Pub/Sub	Pub/Sub publish $40/TiB	10 GiB/月
Sink to GCS	GCS storage class 単価	5 GiB/月

💰 計算例：GKE クラスタの DEBUG ログ垂れ流し Pod 数 100、各 1KB/sec の DEBUG ログ → 月 ≈ 250 GiB
Ingestion: (250 - 50) × $0.50 = $100/月（小さく見えるが、これが 30 dev project あれば月 $3,000）
→ Exclusion で severity<INFO を除外すればほぼゼロ。

9.3 コスト肥大化の典型パターン 6 件

📈 肥大化パターン A：VPC Flow Logs 全 ON 全 subnet × 100% sampling = 月 100-500 万円も珍しくない。対処：subnet 単位で必要な範囲のみ、デフォルト flow_sampling: 0.5、aggregation_interval: INTERVAL_10_MIN。

📈 肥大化パターン B：Data Access Logs 全サービス有効 Cloud Storage / KMS / Spanner で秒間万単位の API call → 月数十万円。対処：サービス単位で必要なものだけ enable、原則 READ は disable し ADMIN_WRITE + DATA_WRITE のみ。

📈 肥大化パターン C：DEBUG / TRACE ログ垂れ流しアプリ側 log level が DEBUG のまま prod デプロイ → ingestion 10 倍。対処：env 別 log level の徹底、CI で log level チェック、Cloud Logging Exclusion を全 dev/staging project でテンプレ化。

📈 肥大化パターン D：log-based metric 高基数 label に user_id / request_id / trace_id 等を含める。対処：labels は bounded set（10-100 種類以内）、unbounded 値は metric ではなく BQ sink → SQL で集計。

📈 肥大化パターン E：BQ sink で partition なし BQ sink の宛先 table が partition 未設定 → 全 table が full scan 対象、クエリ料金爆発。対処：sink の destination_options で use_partitioned_tables: true を必ず指定。

📈 肥大化パターン F：retention 延長を遡及適用 _Default の retention 30 → 365 日に変更すると、過去 30 日分も 365 日 storage 課金対象に。対処：新規 sink + 新規 bucket に分離、規制対象ログだけ長期保管。

9.4 最適化テクニック 10 個

Exclusion filter テンプレ化：全 dev/staging project に severity<INFO AND NOT (protoPayload.@type=~ "AuditLog") を Terraform module で適用
Sampling 戦略：access log は sample(insertId, 0.1) で 10% sampling
_Default bucket retention 最適化：30 日（デフォルト）で十分、長期は別 bucket か GCS Coldline
Log Analytics 活用：BQ への sink 不要、既存 _Default bucket 上で SQL クエリ。BQ ingestion コスト回避
Aggregated Sink で多 project 集約：Org level で SIEM 用 sink を 1 つだけ、各 project から個別 sink を作らない
VPC Flow Logs：flow_sampling: 0.1（10%）+ aggregation_interval: INTERVAL_10_MIN + metadata: EXCLUDE_ALL_METADATA で必要最小限
Audit Logs 選択的有効化：Data Access Logs は storage / bigquery 等の重要サービスのみ、KMS は WRITE のみ
Structured logging：JSON payload に統一 → log-based metric / LQL クエリで高速集計、生ログのスキャン回避
Per-resource quota：logging.googleapis.com/quotas/log_entries_per_resource_per_minute で異常な resource を検知
Log Router Sink の階層化：_Default → Exclusion → 専用 bucket（Tier 1=30 日 / Tier 2=90 日 / Tier 3=365 日）の 3 階層構成

9.5 監視・アラート設計

監視対象	Metric / Query	アラート閾値
Log ingestion 量	`logging.googleapis.com/billing/bytes_ingested`	日次 baseline × 2.0 (anomaly)
Sink failure	`logging.googleapis.com/exports/error_count`	> 0 で即時 page
VPC Flow Logs ingestion	resource.type による filter	baseline 比 1.5x
Data Access Logs ingestion	protoPayload.@type filter	baseline 比 2.0x
log-based metric の高基数	`logging.googleapis.com/billing/log_metric_series_count`	limit の 80%

🔑 試験ポイント — Cloud Logging コスト最適化

「ログ料金が高すぎる」要件 → Exclusion filter（最大効果）
「監査ログを長期保管したい・低コストで」→ GCS Sink (Coldline/Archive)、Log Bucket retention 延長は遡及で高額
「SIEM に流したい」→ Pub/Sub Sink（リアルタイム）、ad-hoc 分析は BQ Sink、規制保管は GCS Sink
「全 project のログを 1 か所」→ Org level Aggregated Sink
「個人情報除去」→ Sensitive Data Protection (DLP) + log processor

10. Cloud Monitoring 運用深掘り：事故・コスト・肥大化対策

📖 公式：Cloud Monitoring pricing / Monitoring quotas and limits

10.1 重大事故ケース 10 件

⚠️ 事故 10-1：高基数 metric（request_id を label に）で時系列 100 万を超過 Cloud Run のレスポンス時間を計測する custom metric に request_id を label として追加 → 1 metric あたり時系列が無制限増加し、Monitoring 側で writes が 429 reject。さらに ingestion 課金は labels を含む series 数で増えるため月 50 万円。
対処：unbounded value は label にしない。bounded（10-100 種類）の label のみ。

⚠️ 事故 10-2：Alerting Policy の condition で「auto-close after 7 days」忘れ閾値超過で発火した alert が条件解消後も close されず、PagerDuty 上で何ヶ月も残り続け alert noise。新規重要 alert が埋もれる。
対処：全 alerting policy に auto_close: "604800s" (7 日) を必ず設定。

⚠️ 事故 10-3：Notification Channel の email が共有 alias で見られず `oncall@example.com` の alias を notification channel に登録、メンバー変更後に新メンバーが alias 未登録で alert を受け取れず、本番障害 2 時間検知遅れ。
対処：notification channel は 個人 email ではなく PagerDuty / Slack channel webhook を必須化、人事変更で破綻しない仕組み。

⚠️ 事故 10-4：SLO の rolling window 設定ミスで信頼度誤算 SLO を rolling 30 days で設定したつもりが calendar month。月初は実質的に過去データなしで「100% 達成」、月末になると急に消費判明 → リリース判断が遅れる。
対処：rolling vs calendar の選択を明示、可視化ダッシュボードで window 種類を表示。

⚠️ 事故 10-5：Multi-burn-rate alert を 1 段階だけ設定し fast burn 見逃し slow burn (3d で 100%) のみ設定、fast burn（1h で 14.4x）なし → 1 時間で月予算 2% を消費する大事故を検知できず。
対処：必ず Fast (14.4x@1h) + Slow (6x@6h) + Slow-burn (1x@3d) の 3 段構成。

⚠️ 事故 10-6：Dashboard を console 手動作成、人事異動で全消失重要ダッシュボードを個人 user のフィルタとして保存（personal scope）、退職後にアクセス不可。
対処：Dashboard as Code（Terraform google_monitoring_dashboard）で全管理、shared scope。

⚠️ 事故 10-7：Uptime check の endpoint を public IP 直指定で SSL 証明書更新時 alert uptime check が IP 直で、SSL/TLS 検証時に CN mismatch で false alert。
対処：hostname ベース uptime check、SSL verify 必須化。

⚠️ 事故 10-8：PromQL のクエリで evaluation interval 短すぎて metrics 取得負荷 rate(http_requests_total[1m]) を 10 秒 evaluation interval で alert policy にした結果、Monitoring API 側 QPS limit 抵触で alert evaluation 失敗。
対処：evaluation interval は metric の sampling rate と同等以上（通常 60 秒）。

⚠️ 事故 10-9：Metric Scope を gigantic に拡げて latency 悪化 375 project を 1 metric scope に集約、Metrics Explorer のクエリ 30 秒〜。
対処：Metric Scope は論理境界（環境別、事業部別）で分割、375 上限まで使い切らない。

⚠️ 事故 10-10：Custom Metric を OpenTelemetry から push で重複登録 OTel SDK で同じ metric 名を 2 つの service が異なる definition で登録、Monitoring 側で metric descriptor 衝突 で片方の値が null。
対処：metric 命名規約と registry を中央管理、metric descriptor は 1 service 1 owner。

10.2 Cloud Monitoring コスト構造

項目	料金（目安）	無料枠
GCP プロダクト metric（system metric）	無料	全て無料
Custom metric（user-defined / log-based / Agent）	$0.2580 / MiB	最初の 150 MiB/月/billing account
Monitoring API call	$0.01 / 1,000 calls	1M calls/月
Uptime checks	無料（最大 100/project）	—
Synthetic Monitor（Cloud Functions ベース）	Cloud Functions の料金	—
Notification（SMS）	地域別 SMS 料金	—

💰 計算例：custom metric の高基数で月 10 倍コスト 1 metric × 1,000 series × 60 sec sampling = 月 ≈ 2.6 GiB ≈ $5
これに user_id 100,000 種類を label 追加 → 100,000 series → 月 ≈ 260 GiB ≈ $67（1 metric だけで）
→ labels は必ず bounded。

10.3 コスト肥大化の典型パターン 5 件

📈 パターン A：高基数 custom metric 上記計算例の通り、unbounded label で 10-100 倍。対処：metric design review、`label_replace` で集計層を入れる。

📈 パターン B：Agent ベースの全 metric 取り込み Ops Agent default 設定で全 process metric を ingestion → 1 VM あたり月 $5-10。対処：必要 metric を collection_interval 延ばす、不要 receiver は disable。

📈 パターン C：log-based metric の labels で爆発 log-based metric に request_id 等を含める。対処：bounded label のみ、生ログ分析は BQ sink → SQL。

📈 パターン D：Synthetic Monitor 過剰頻度 1 分間隔で 100 monitor × 12 region = 月 100 万 invocation の Cloud Functions 起動。対処：重要 endpoint のみ 1 min、その他は 5-15 min。

📈 パターン E：Monitoring API の external 利用過剰 Grafana / 内製 dashboard から Monitoring API を pull するパターンで QPS 過剰。対処：Cloud Monitoring の native dashboard を活用、外部 dashboard は Managed Prometheus 経由を検討。

10.4 最適化テクニック 10 個

Metric design review：新 metric 追加時に label の cardinality 試算（10/100/1k/10k で線引き）
Ops Agent の collection_interval 調整：60 秒 → 120-300 秒に
不要 receiver disable：Ops Agent の process receiver は通常不要
Dashboard as Code：Terraform で全 dashboard 管理、人事変更で消えない
Multi-burn-rate 3 段構成必須：Fast/Medium/Slow を全 SLO に
auto_close 設定：全 alerting policy に 7 日を設定、stale alert 防止
Notification Channel は webhook 推奨：個人 email/SMS は人事リスク
Metric Scope 分割：論理境界で 50-100 project ごとに分割、375 上限まで使わない
Synthetic Monitor は重要 endpoint のみ：5 min 間隔以上で十分
SLO は Cloud Service Mesh metric ベース（旧 ASM）：アプリ無改修で SLI 取得

10.5 監視・アラート設計（メタ監視）

監視対象	Metric	閾値
Custom metric ingestion 量	`monitoring.googleapis.com/billing/bytes_ingested`	baseline × 1.5
Alert policy evaluation failure	`monitoring.googleapis.com/alert/evaluation_failures_count`	> 0 で page
Notification channel failure	`monitoring.googleapis.com/notification/error_count`	> 0 で page
Metric API quota usage	`serviceruntime.googleapis.com/quota/rate/net_usage`	quota の 80%

🔑 試験ポイント — Cloud Monitoring

「Prometheus query 言語で alerting したい」→ PromQL Alert（Monitoring native 対応）
「アプリ無改修で SLI 取得」→ Cloud Service Mesh metric (旧 ASM) ベース SLO
「複数 project を 1 dashboard で」→ Metric Scope（最大 375 project）
「Notification の信頼性」→ Webhook + PagerDuty/Slack、email/SMS は副次
「ダッシュボード共有」→ Dashboard as Code (Terraform)

11. Managed Service for Prometheus 運用深掘り

📖 公式：GMP pricing / GMP Managed collection setup

11.1 重大事故ケース 8 件

⚠️ 事故 11-1：Self-deployed Prometheus を「とりあえず移行」せず GMP マネージドへ二重稼働 OSS Prometheus + GMP Managed Collection を併用、同じ scrape target を 2 倍 scrape → ingestion 料金 2 倍。
対処：移行は一気に Managed Collection に統一、OSS Prometheus は deprecate。

⚠️ 事故 11-2：PodMonitoring の namespace label 漏れで全 namespace を scrape PodMonitoring で selector に namespace 指定漏れ、別 namespace の不要 Pod まで scrape → カーディナリティ 10 倍、Monarch ingestion 制限 (200k series/project) 超過。
対処：必ず matchLabels で namespace + workload 限定、ClusterPodMonitoring は慎重に。

⚠️ 事故 11-3：高基数 metric（http_request_duration_seconds with path={dynamic}）アプリの自動計装で URL path を label にする実装、RESTful API の path parameter が unbounded で series 100 万超。
対処：path normalize（/users/123 → /users/{id}）、Histogram bucket 設計、relabel_configs で drop。

⚠️ 事故 11-4：Managed Collection で scrape interval を 15 sec → 5 sec に短縮で料金 3 倍 Production debugging で scrape interval を一時短縮、戻し忘れて 1 ヶ月放置。
対処：scrape interval は --config の Terraform で git 管理、debug 用は IaC で revert PR を必須化。

⚠️ 事故 11-5：HPA の Custom Metric が GMP 経由で取得失敗、scale-out しない HPA の type: External で GMP の metric を参照、External Metrics Stackdriver Adapter 認証設定漏れで取得失敗、HPA が永遠に min replicas。負荷増加時に SLO 違反。
対処：Workload Identity で SA に monitoring.viewer 付与、Adapter の --google-application-credentials 確認、HPA の status を Cloud Monitoring で監視。

⚠️ 事故 11-6：Multi-cluster federation で重複 ingestion 複数 GKE cluster で同じ external service を scrape、metric が重複登録され「2 倍に見える」誤った dashboard。
対処：federation の honor_labels 設定、cluster_id label を必ず付与、外部サービス scrape は専用 collector cluster。

⚠️ 事故 11-7：Cardinality 制限超過で metric が「null になる」silent failure Monarch の per-metric series 制限超過で新規 series が登録不可、既存 series のみ更新 → 部分的 metric。気付かず alerting が誤動作。
対処：Cardinality を monitoring.googleapis.com/billing/bytes_ingested で監視、新 metric 投入時は staging で cardinality 試算。

⚠️ 事故 11-8：PromQL のクエリ実行で BigQuery 並みの料金が突然発生 Grafana から数年分の range query を頻繁実行 → Monarch query API が高負荷、料金構造を理解せず利用で月数十万円。
対処：PromQL クエリは集計済み metric を作る（recording rules）、Grafana caching、query timeout 設定。

11.2 GMP コスト構造

項目	料金（目安）	備考
Sample ingestion	$0.06 / million samples（最初の 100k samples/月無料）	scrape ごとの sample 単位課金
Query API	$0.01 / 1,000 query API calls	Grafana 連携で頻発しがち
Storage	無料	Monarch 内に 24 ヶ月保持
Managed Collection	無料	Collector 自体は無料、ingestion のみ課金
Self-deployed	$0.06 / million samples（同じ）	+ Prometheus pod のリソース料金

11.3 肥大化パターン & 最適化

📈 肥大化パターン

A：高基数 label（path, request_id, user_id を含む metric）
B：scrape interval 短すぎ（5 sec を多用、本来 30-60 sec で十分）
C：不要 metric の全 scrape（go_goroutines 等の language runtime metric を全 ingestion）
D：Query API の過剰呼び出し（Grafana refresh interval 5 sec 等）

💡 最適化テクニック 8 個

relabel_configs / metric_relabel_configs で drop / keep：必要 metric のみ ingestion
scrape_interval 30-60 sec デフォルト：debug 時のみ短縮
recording rules で pre-aggregation：query 時の cardinality 削減
Histogram bucket 設計：必要な分布のみ、boundaries を絞る
PodMonitoring の selector を厳密に：namespace + workload 単位
ClusterPodMonitoring は最小限：cluster scope は cluster-level service のみ
Grafana query caching：データソースキャッシュ enabled、refresh 30 sec 以上
Cardinality monitoring：monitoring.googleapis.com/collection/uptime や billing metric で日次チェック

🔑 試験ポイント — GMP

「Prometheus を運用フリーで」→ Managed Service for Prometheus (Managed Collection)
「PromQL クエリで alert / dashboard」→ Cloud Monitoring + GMP（PromQL native）
「multi-cluster federation」→ Managed Service for Prometheus が標準対応、honor_labels で cluster_id 必須
「HPA から custom metric」→ External Metrics Stackdriver Adapter + Workload Identity

12. OpenTelemetry + Cloud Trace 運用深掘り

📖 公式：Cloud Trace setup / OpenTelemetry Collector

12.1 重大事故ケース 8 件

⚠️ 事故 12-1：Cloud Trace の sampling を 100% にしてアプリ CPU 30% 増加 detailed trace を取りたく sampling_ratio=1.0 を全 service に設定、OTel SDK の overhead でアプリ CPU 30% 増、レイテンシ p99 が 2 倍に。
対処：sampling は default 0.001（0.1%）+ head-based、debug 時のみ tail-based で error trace を 100% 保管。

⚠️ 事故 12-2：Trace ID + Log の correlation 未設定で原因特定不能 Trace は取れているがログ側に trace_id が出力されておらず、特定リクエストのログ追跡不可。
対処：構造化ログに logging.googleapis.com/trace field を必ず含める、SDK の log auto-instrumentation を有効化。

⚠️ 事故 12-3：W3C Trace Context propagation の不整合（B3 と W3C 混在） Java service は W3C、Python service は B3 を default propagator、trace が service 境界で分断、root span が複数発生。
対処：全 service で W3C Trace Context に統一、SDK 設定 OTEL_PROPAGATORS=tracecontext,baggage。

⚠️ 事故 12-4：OTel Collector の resource limits 未設定で Pod OOM Collector に高負荷時に大量 span が来て、queue で memory 100% → Pod OOMKilled、trace ロスト。
対処：memory_limiter processor を必須、queued_retry + batch processor で背圧制御、Pod に resources.limits 設定。

⚠️ 事故 12-5：Cloud Trace の保管期間 30 日を超えた古い trace 参照で 404 ポストモーテムで 2 ヶ月前の trace を確認しようとして消失。
対処：重要 trace は BigQuery sink で長期保管、または OTel Collector で googlecloudpubsub exporter で別保管。

⚠️ 事故 12-6：tail-based sampling で「error trace を保管」したつもりが OOM Collector で tail-based sampling、全 span を buffer に保持して error 判定 → buffer overflow で Collector 不安定。
対処：tail sampling の decision_wait を短く（5 sec 程度）、num_traces を制限、Collector を horizontal scale。

⚠️ 事故 12-7：OTel SDK 旧版で OpenCensus 互換 API を使い続け migration 遅延 OpenCensus は EoL、新 SDK との互換性壁で migration コスト膨張。
対処：早期に OTel SDK へ移行、bridge ライブラリで段階移行可。

⚠️ 事故 12-8：外部 SaaS への trace propagation 設定漏れ内部 service は trace ID 伝播するが、外部 API 呼び出しで trace が切れ、外部依存サービスのレイテンシ要因が見えない。
対処：HTTP client の auto-instrumentation を全 service で有効化、traceparent header の外部送信を許可。

12.2 Cloud Trace コスト構造

項目	料金（目安）	無料枠
Trace ingestion	$0.20 / million spans	2.5 million spans/月無料
Trace storage	無料	30 日保持
OTel Collector pod	GKE/GCE 料金	—

💰 計算例：sampling rate が 10 倍違うと月コスト想定：service で 100 req/sec、avg 5 spans/req
・100% sampling: 1.3 billion spans/月 → $260/月
・10% sampling: 130 million spans/月 → $26/月
・1% sampling (推奨): 13 million → $2.6/月
→ sampling は基本 0.1-1%、error は tail-based で必ず保管

12.3 肥大化パターン & 最適化

💡 最適化テクニック 8 個

Head-based sampling 0.1-1% + Tail-based で error 全保管
W3C Trace Context に propagation 統一
Log/Trace correlation 必須（trace_id in structured log）
OTel Collector resource limits 必須（memory_limiter + batch + queued_retry）
BigQuery long-term sink：重要 trace を BQ に
外部依存 trace propagation：HTTP client auto-instrumentation
service.name 命名規約：env-team-service の prefix 統一
Span attribute は bounded：unbounded value は drop

🔑 試験ポイント — OTel + Cloud Trace

「マイクロサービス間の遅延原因特定」→ Cloud Trace + OTel auto-instrumentation
「Trace ID と Log を紐付け」→ structured log に logging.googleapis.com/trace
「全 trace を長期保管」→ BigQuery sink（Cloud Trace は 30 日制限）
「OpenCensus からの移行」→ OTel bridge ライブラリで段階移行

13. Cloud Profiler 運用深掘り

📖 公式：Cloud Profiler concepts

13.1 重大事故ケース 6 件

⚠️ 事故 13-1：Profiler agent でアプリの p99 レイテンシが 20% 悪化 Python Profiler を default 設定で本番に有効化、CPU profile の sampling overhead でレイテンシ悪化。
対処：Python Profiler は statistical sampling のみ対応、本番 sampling rate を下げる（sampling_rate=1000等）、debug 時のみ詳細化。

⚠️ 事故 13-2：Heap profile が本番では取得不可（Node.js） Node.js の Profiler は heap profile を default で disable、メモリリーク調査時に取れず原因特定遅延。
対処：Profiler agent の言語別サポート一覧を事前確認、Node.js は heap.enabled: true で明示有効化。

⚠️ 事故 13-3：Profiler の service.version 命名規約なしで profile が混在 service.version に git-sha を入れず、複数 deploy が同じ profile pool に → 比較不能。
対処：service.version に git tag + timestamp、zone に region を必ず入れる。

⚠️ 事故 13-4：Profile 取得頻度を上げて Monitoring API quota 超過 Profile を 1 分ごとに upload する設定で 100 Pod、API call quota（10k/min）に抵触。
対処：default の 10 分間隔を維持、quota 引き上げ申請。

⚠️ 事故 13-5：Free tier 制限に気付かず本番で大量 profile 取得 Free tier は 1 ヶ月 1,000 profile/project、これを超えると取得停止（課金ではなく）。本番で profile が出ない時間帯発生。
対処：profile 取得頻度を見直し、Free tier 内に収める or paid tier upgrade。

⚠️ 事故 13-6：Wall-clock profile が default で取れず goroutine block 原因不明 Go アプリで I/O bound な処理の原因調査、CPU profile では原因見えず → Wall-clock profile が必要だが default で disable。
対処：Go Profiler は profiler.Config{Service: "x", MutexProfiling: true} で Mutex profile 有効化、Wall-clock は cpu_profile ではなく wall 指定。

13.2 Profile 種別と言語サポート

Profile 種別	Java	Go	Node.js	Python	用途
CPU time	✓	✓	✓	✓	計算負荷の高い関数特定
Heap	✓	✓	✓ (要設定)	—	メモリリーク特定
Allocated heap	✓	✓	—	—	GC pressure 分析
Contention (Mutex)	✓	✓ (要設定)	—	—	lock contention 特定
Threads	✓	—	—	—	thread 状態の可視化
Wall time	—	—	—	—	I/O 待ちを含む実時間

13.3 コスト構造

項目	料金
Profile 取得・保管	無料（Free tier within limits）
制限	1,000 profiles / project / month
Agent overhead	通常 1-2% CPU（Python は 3-5%）

13.4 最適化テクニック

💡 BP 6 個

本番では low overhead 設定：default 10 分間隔、debug 時のみ短縮
service.version に git SHA：deploy 単位で profile 比較可能に
Heap diff 分析：時系列で snapshot を取り、増加した allocation を特定
Trace と組合せ：Trace で遅い span 特定 → 同 service の Profiler で関数特定
Error Reporting と連動：エラー多発時に Profile を確認、メモリリーク等の根本原因特定
言語別サポート確認：Python は Heap 非対応、Node.js は Heap 要設定

🔑 試験ポイント — Cloud Profiler

「Java アプリの GC が遅い」→ Heap + Allocated heap profile
「Go アプリの I/O 待ち調査」→ Wall-clock profile（Goroutine block 含む）
「lock contention」→ Contention (Mutex) profile
「Python の CPU 重い処理」→ CPU profile（Heap は対応外）