SECTION 4

セクション 4：
可観測性とトラブルシュート

PCDE の最大セクション（出題比 ~25%）。Cloud Logging / Monitoring / Trace / Profiler / Error Reporting を中心に、OpenTelemetry 計装、LQL / PromQL、Audit Logs 4 種、Cloud Service Mesh（旧 ASM）、Burn rate アラート、Synthetic Monitor、Managed Service for Prometheus (GMP)、そして 2024-2025 新機能の Gemini Cloud Assist までを体系的に押さえ、5 領域（Infra / CI/CD / App / Observability / Performance） のトラブルシュート初動を即答できるレベルへ。

📊 出題 ~25% ★最重要 🔭 可観測性 3 軸 + α 🤖 Gemini Cloud Assist 📘🔧🎯 全レベル対応

出題 ~25% 📘 基礎 🔧 応用 🎯 要点

🔑 TL;DR — このセクションの要約可観測性は Metrics + Logs + Traces + Profiles + Synthetic + AI の総合戦。ログは Log Router + Sink で BigQuery（Log Analytics 推奨）/ Pub/Sub / GCS / 別 Bucket に振り分け、コスト削減は Exclusion > Sampling > Retention 短縮 の順。メトリクスは PromQL に統一（MQL は非推奨）、ヒストグラムは histogram_quantile。トレースは OpenTelemetry が標準、Trace ID を logging.googleapis.com/trace で構造化ログに必ず含める。Audit Logs 4 種のうち Data Access のみデフォルト無効。アラートは SLO Multi-burn-rate（Fast 1h=14.4x / Slow 6h=6x）。VM ログ・メトリクスは Ops Agent、K8s 新規 Prometheus は GMP Managed Collection。Cloud Service Mesh（旧 ASM）はコード変更なしに 4 Golden Signals を取得。Gemini Cloud Assist の Investigations / Log Summary / Explain this chart / Query 生成 で MTTR を短縮。

🎯 学習目標

🔭 可観測性の 3 軸 + α

可観測性 = 「システムの出力から内部状態を後から推測できる性質」。監視（事前に決めた指標）と異なり、未知の故障を任意の高次元データから追跡できる。

3 軸（Metrics / Logs / Traces）+ α（Profiler / Error Reporting / Synthetic）+ Gemini Cloud Assist で MTTR 短縮。

Metrics

集約済み数値時系列

CPU/メモリ/RPS/エラー率。Cloud Monitoring + GMP（PromQL）。GAUGE / CUMULATIVE / DELTA の 3 種別。

Logs

個別イベント

JSON / テキスト。構造化（jsonPayload）必須。LogEntry に severity / resource / labels / trace を含む。

Traces

分散リクエスト追跡

Span を木構造で表現。OpenTelemetry が標準、Trace ID で Logs / Profiler と相互リンク。

4.1 計装と収集（Ops Agent / OpenTelemetry / Audit Logs）

3 つのエージェント

エージェント	役割	状態
Ops Agent	ログ + メトリクスを統合送信（fluentbit + otel）	推奨（現行）
Legacy Logging Agent	ログのみ送信（fluentd）	非推奨
Legacy Monitoring Agent	メトリクスのみ送信（collectd）	非推奨

🔑 VM の収集VM のログ + メトリクス収集は 必ず Ops Agent。Legacy 2 つは新規導入禁止、移行対象。GKE / Cloud Run / Functions は 自動収集（エージェント不要）。

Ops Agent の設定例

# /etc/google-cloud-ops-agent/config.yaml logging: receivers: syslog: type: files include_paths: [/var/log/syslog] nginx_access: type: nginx_access include_paths: [/var/log/nginx/access.log] processors: parse_json: type: parse_json service: pipelines: default_pipeline: receivers: [syslog, nginx_access] processors: [parse_json] metrics: receivers: hostmetrics: type: hostmetrics collection_interval: 60s service: pipelines: default_pipeline: receivers: [hostmetrics]

OpenTelemetry（OTel）の基本

CNCF プロジェクト。ベンダーニュートラルな テレメトリ収集標準。Google Cloud の Trace / Monitoring / Logging は 第一級サポート。新規アプリは OTel SDK で計装が推奨。

コンポーネント	役割
OTel SDK	各言語の計装ライブラリ（Java/Python/Go/Node.js/.NET/Ruby）
OTel Collector	テレメトリの受信→処理→送信パイプライン
OTLP	標準データフォーマット（gRPC / HTTP）
Auto-instrumentation	ライブラリ呼び出しを自動でフック

OTel Collector の 3 段構成（Receivers → Processors → Exporters）

# OTel Collector config（最小） receivers: otlp: protocols: grpc: {endpoint: 0.0.0.0:4317} processors: batch: {timeout: 10s} exporters: googlecloud: {project: my-proj} service: pipelines: traces: receivers: [otlp] processors: [batch] exporters: [googlecloud]

Cloud Audit Logs 4 種類（最頻出）

ログ種別	内容	デフォルト	課金	保管先
Admin Activity	リソースの変更（作成/削除/設定変更）	常時有効、無効化不可	無料	`_Required` 400 日
Data Access	データの読み書き（GCS / BQ クエリ等）	既定で無効（明示有効化）	課金あり	`_Default` 30 日
System Event	GCP 内部イベント（GCE ライブマイグレ等）	常時有効、無効化不可	無料	`_Required` 400 日
Policy Denied	IAM / VPC SC で拒否されたアクセス	常時有効、無効化不可	課金あり	`_Default` 30 日

🔑 暗記キー「Data Access のみデフォルト無効、コンプラなら明示有効化」。Data Access の 3 サブカテゴリは ADMIN_READ / DATA_READ / DATA_WRITE。

Audit Logs 4 種類 — 視覚化

VPC Flow Logs と Firewall Insights

機能	内容
VPC Flow Logs	VPC サブネット内の 5-tuple フロー（src/dst IP/port、protocol）を記録
Firewall Insights	シャドウルール / Hit count / 過剰許可ルール検出
Firewall Rules Logging	ルール単位でログ有効化（「特定ルールに何がマッチしたか」）

Cloud Service Mesh のテレメトリ

⚠️ サービスリネームCloud Service Mesh は旧 Anthos Service Mesh（ASM）。Istio ベース。2024 年に統合・改称。

種別	内容	送信先
Metrics	`istio_requests_total` 等の Istio 標準メトリクス	Cloud Monitoring / Prometheus
Access Logs	Envoy proxy のアクセスログ	Cloud Logging
Traces	サービス間の分散トレース	Cloud Trace

🔑 売りService Mesh を入れると コード変更なしに 4 Golden Signals が取れる。

🔧 OTel Collector の主要 Receiver / Processor / Exporter

Receivers

otlp（標準）
prometheus（OSS scrape）
jaeger / zipkin
filelog（テキストログ）
hostmetrics（OS）

Processors

batch（必須）
memory_limiter（必須）
attributes（属性編集・PII 削除）
resource
probabilistic_sampler / tail_sampling
transform

Exporters

googlecloud（Trace/Mon/Log）
googlemanagedprometheus（GMP）
otlp（他のエンドポイント）
prometheus（scrape 用公開）
logging（stdout デバッグ）

🔧 推奨 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 batch: timeout: 10s send_batch_size: 1024 attributes: actions: - key: user.email action: delete # PII 削除 - key: env value: prod action: insert probabilistic_sampler: sampling_percentage: 10 exporters: googlecloud: project: my-proj googlemanagedprometheus: project: my-proj service: pipelines: traces: receivers: [otlp] processors: [memory_limiter, attributes, probabilistic_sampler, batch] exporters: [googlecloud] metrics: receivers: [otlp] processors: [memory_limiter, batch] exporters: [googlemanagedprometheus]

🔧 Audit Logs の有効化（IAM Policy）

# Data Access ログを有効化（IAM Policy） auditConfigs: - service: storage.googleapis.com auditLogConfigs: - logType: DATA_READ - logType: DATA_WRITE - logType: ADMIN_READ

🔧 VPC Flow Logs の有効化

gcloud compute networks subnets update SUBNET \ --region=us-central1 \ --enable-flow-logs \ --logging-aggregation-interval=interval-5-sec \ --logging-flow-sampling=0.5 \ --logging-metadata=include-all

🔧 自動計装（Python）

pip install opentelemetry-distro opentelemetry-exporter-otlp opentelemetry-bootstrap -a install # 主要ライブラリの自動計装をインストール opentelemetry-instrument --traces_exporter otlp python app.py # Flask / Django / requests / SQLAlchemy が自動でトレース化される

🔧 Service Mesh の標準メトリクス

メトリクス	内容
`istio_requests_total`	リクエスト総数
`istio_request_duration_milliseconds`	リクエスト処理時間
`istio_request_bytes` / `istio_response_bytes`	リクエスト/レスポンスサイズ
`istio_tcp_connections_opened_total`	TCP 接続数

🎯 計装と収集即答

要件	答え
VM のログ + メトリクス	Ops Agent
GKE / Cloud Run / Functions の収集	自動収集（エージェント不要）
OTel Collector の 3 段	Receivers / Processors / Exporters
「誰がリソースを変更したか」	Admin Activity log（常時有効）
「誰がデータを見たか」	Data Access log（既定無効、明示有効化）
「IAM/VPC SC で拒否」	Policy Denied log
VPC 内の 5-tuple フロー	VPC Flow Logs
不要 FW ルール検出	Firewall Insights
コード変更なしに 4 Golden Signals	Cloud Service Mesh（旧 ASM）

4.2 ログ管理（Log Router / Sink / LQL / Log Analytics）

Cloud Logging のアーキテクチャ

[アプリ / VM / GKE / GCP リソース] │ ▼ (Ops Agent / OTel / SDK / 自動収集) ┌──────────────────────┐ │ Log Router │ ← フィルタで振り分け └──────────────────────┘ │ │ │ ▼ ▼ ▼ ┌───────┐ ┌───────┐ ┌────────────┐ │ Log │ │Sink → │ │ Log-based │ │Buckets│ │BQ/PS/ │ │ Metric │ │ │ │ GCS │ │ │ └───────┘ └───────┘ └────────────┘

Log Buckets

バケット名	保持期間	削除	用途
`_Default`	30 日（1〜3650 日に変更可）	可	通常ログの既定保管先
`_Required`	400 日固定（変更不可）	不可	Admin Activity / System Event Audit 専用
ユーザー定義	1〜3650 日	可	コンプラ、長期保管

Sink の 4 つの宛先

宛先	用途	特徴
Log Bucket	Logging 内で保持	LQL で検索可、リージョン固定
BigQuery	SQL 分析	パーティション自動、Log Analytics 推奨
Pub/Sub	ストリーミング配信	SIEM、Splunk、ETL 起点
Cloud Storage	長期保管	安価、JSON Lines 形式

🔑 暗記BigQuery = 分析 / Pub/Sub = ストリーム / GCS = 長期保管 / Log Bucket = Logging 内検索。

構造化ログ（jsonPayload）が必須

アプリログは 常に構造化（JSON） で出力。これが Logs Explorer 検索性・log-based metric・trace 紐付けの前提。

{ "severity": "ERROR", "message": "Database connection failed", "user_id": 42, "retry": 3, "logging.googleapis.com/trace": "projects/my-proj/traces/abc123" }

LQL（Logging Query Language）基本構文

演算子	意味	例
`=`	完全一致	`severity="ERROR"`
`:`	サブストリング / フィールド存在	`textPayload:"timeout"`
`>=`	比較	`severity>=WARNING`
`=~`	正規表現	`resource.labels.zone=~"us-.*"`
`AND / OR / NOT`	論理結合	`severity=ERROR OR severity=CRITICAL`

LQL 必修パターン

# Cloud Run の 5xx resource.type="cloud_run_revision" httpRequest.status>=500 # Audit Logs logName:"cloudaudit.googleapis.com/activity" # Admin Activity logName:"cloudaudit.googleapis.com/data_access" # Data Access logName:"cloudaudit.googleapis.com/policy" # Policy Denied # OOMKilled pod resource.type="k8s_container" jsonPayload.message:"OOMKilled" # 過去 5 分 timestamp>=timestamp_sub(@now, "5m")

log-based metric の 2 種類

種別	集計内容	例
Counter	ログ行をカウント	エラー発生数 / 分
Distribution	ログから数値を抽出して分布	レイテンシ p50/p99 分布

💡 ヒント「ログの内容に応じてアラートを出したい」→ log-based metric を作って Alerting Policy が王道。distribution の可視化は Heatmap、分位点は histogram_quantile。

ログ最適化 — 4 つのレバー（優先順位）

優先度	手法	効果	注意
1	Exclusion（除外）	取り込み課金そのものを 0 に	完全に消える、後から見られない
2	Sampling	一部だけ取り込み	統計的に十分なら有効
3	Retention 短縮	ストレージ課金削減	保管期間を 30 日→7 日等
4	Log Buckets 削減	バケット数の整理	構成変更が必要

🔑 試験頻出「ログコストを急に下げたい」→ Exclusion（Sink 編集だけで即時反映、課金即停止）。Sink 追加は 重複課金になるので NG。

課金体系（概要）

項目	課金
ログ取り込み（Ingestion）	約 $0.50/GiB（最初 50 GiB/月無料）
ログストレージ（保持期間超過分）	約 $0.01/GiB/月
Audit ログ（`_Required`）	無料

🔧 Sink 宛先の使い分けマトリクス

用途	最適な宛先	理由
SQL でアドホック分析	BigQuery / Log Analytics	スキーマ自動、Log Analytics なら重複なし
リアルタイム ETL / SIEM 連携	Pub/Sub	Splunk / Datadog / ElasticSearch 中継
長期アーカイブ / 7 年保管	Cloud Storage Archive	最安、Object Lifecycle
Logging 内で LQL + 長期保持	ユーザー定義 Log Bucket	最大 3650 日
別プロジェクト集約	他 project の Log Bucket	クロスプロジェクト Sink

🔧 Log Analytics（最新ベストプラクティス）

既存 Log Bucket を アップグレード すると BigQuery で直接 SQL 可能になる。データ重複なし・追加課金なし。

-- Log Analytics で過去 24h の Cloud Run エラーをサービス別集計 SELECT JSON_VALUE(resource.labels.service_name) AS service, COUNT(*) AS errors FROM `my-proj.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;

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

通常の Sink は プロジェクト単位
Aggregated Sink は Organization / Folder 単位 で配下プロジェクトすべてを横断的に転送
セキュリティ監査の中央集約、コンプラ要件で必須

gcloud logging sinks create org-audit-sink \ bigquery.googleapis.com/projects/security-proj/datasets/audit_logs \ --include-children \ --organization=ORG_ID \ --log-filter='logName:"cloudaudit.googleapis.com/activity"'

🔑 試験頻出「組織全体の Audit Log を 1 つの BQ に集めたい」→ Org-level Aggregated Sink with --include-children。

🔧 Sink 設計の典型 3 段構成

全ログ ├── Exclusion Filter: health check / debug は破棄 │ ├── Sink A → BigQuery (Log Analytics) │ Filter: severity>=WARNING │ 用途: 分析・トラブルシュート │ ├── Sink B → GCS Archive │ Filter: logName:"cloudaudit.googleapis.com" │ 用途: コンプライアンス 7 年保管 │ └── Sink C → Pub/Sub → Splunk Filter: severity>=ERROR 用途: SIEM 連携

🔧 GCS Lifecycle で自動階層化

rule: - action: {type: SetStorageClass, storageClass: NEARLINE} condition: {age: 30} - action: {type: SetStorageClass, storageClass: COLDLINE} condition: {age: 90} - action: {type: SetStorageClass, storageClass: ARCHIVE} condition: {age: 365} - action: {type: Delete} condition: {age: 3650}

🔧 PII / PHI のリダクション

パターン	実装
A. アプリ層（推奨）	Sensitive Data Protection（旧 DLP）API を呼んで出力前にマスク
B. Sink + Pub/Sub + Dataflow テンプレ	Pub/Sub → Dataflow（DLP テンプレ）→ BigQuery
C. Log Processor（プレビュー）	Log Router 上で直接フィルタ + 変換

# Sensitive Data Protection（旧 DLP）でメール・カード番号をマスク from google.cloud import dlp_v2 dlp = dlp_v2.DlpServiceClient() response = dlp.deidentify_content(request={ "parent": f"projects/{PROJECT_ID}", "deidentify_config": {"info_type_transformations": { "transformations": [{"primitive_transformation": { "character_mask_config": {"masking_character": "*"}}}]}}, "inspect_config": {"info_types": [ {"name": "EMAIL_ADDRESS"}, {"name": "CREDIT_CARD_NUMBER"}, {"name": "JAPAN_BANK_ACCOUNT"}]}, "item": {"value": text}, }) logger.info(response.item.value)

🔧 Log Scopes & Log Views

機能	内容
Log Scopes	複数プロジェクトの複数 Log Bucket / View を 1 つの論理スコープにまとめて Logs Explorer 横断検索
Log Views	1 つの Log Bucket 内に絞り込みビュー（IAM で別チームに別 View 公開）

🔧 Exclusion / Sampling / Retention 実装テンプレ

# 1. Exclusion（健康チェック・デバッグログ） gcloud logging sinks update _Default \ --add-exclusion=name=exclude-health,filter='httpRequest.requestUrl="/healthz"' \ --add-exclusion=name=exclude-debug,filter='severity="DEBUG"' # 2. INFO を 10% サンプリング gcloud logging sinks update _Default \ --add-exclusion='name=sample-info,filter=severity="INFO",disabled=false,sampleRate=0.1' # 3. Retention 短縮（_Default を 7 日へ） gcloud logging buckets update _Default \ --location=global --retention-days=7

🎯 ログ管理即答

要件	答え
ログを SQL で分析（最安）	Log Analytics（Bucket をそのまま BQ 統合）
リアルタイムで外部 SIEM へ	Pub/Sub Sink
7 年アーカイブ最安	Cloud Storage Sink（Archive class）
組織全体の Audit ログ集約	Org-level Aggregated Sink with `--include-children`
ログコスト緊急削減	Exclusion（最優先）
PII を取り除く最確実	アプリ層で Sensitive Data Protection (DLP)
ログ行数をメトリクス化	Counter 型 log-based metric
ログから数値抽出して分布化	Distribution 型 log-based metric

🎯 Log Buckets 暗記

バケット	保持期間	削除
`_Default`	30 日（1〜3650 日に変更可）	可
`_Required`	400 日固定	不可
ユーザー定義	1〜3650 日	可

4.3 メトリクス・ダッシュボード・アラート（PromQL / GMP / Burn rate）

Cloud Monitoring の主要機能

機能	役割
Metrics Explorer	即席メトリクス可視化、PromQL / リスト UI
Dashboards	カスタムビュー、チームで共有
Alerting Policies	条件で通知
Notification Channels	通知先（Email/Slack/PagerDuty 等）
Uptime Checks	HTTP/HTTPS/TCP 死活監視
Synthetic Monitor	API ワークフロー能動監視
SLO	サービスレベル目標管理

メトリクスの 3 種別

種別	説明	例
GAUGE	その時点の値	CPU 使用率、メモリ
CUMULATIVE	累積値（リセットで 0 に戻る）	リクエスト総数
DELTA	期間内の増分	バッチ処理件数

4 つのチャートタイプ

チャート	用途
Line（折れ線）	時系列の推移（CPU、RPS）
Stacked bar（積み上げ棒）	カテゴリ別の積み上げ（サービス別エラー数）
Heatmap	distribution metric の分布可視化
Scorecard	単一値 + 閾値色分け（SLO 残量）

PromQL 基本構文（必須）

⚠️ MQL は非推奨Cloud Monitoring 旧来の MQL（Monitoring Query Language）は 非推奨。PromQL に統一。試験では PromQL を中心に問われる。

関数	用途	典型例
`rate(v[t])`	counter の秒速	`rate(requests_total[5m])`
`increase(v[t])`	期間内増分	`increase(errors[1h])`
`sum() by (...)`	グループ集約	`sum by (svc) (rate(req[5m]))`
`avg() by (...)`	グループ平均	`avg by (zone) (cpu)`
`histogram_quantile(q, v)`	分位点（p50/p99）	`histogram_quantile(0.99, sum by(le) (rate(latency_bucket[5m])))`
`topk(k, expr)`	上位 k	`topk(5, rate(errors[5m]))`
`label_replace()`	ラベル変換	`label_replace(up, "host", "$1", "instance", "([^:]+):.*")`

4 Golden Signals の PromQL 雛形

シグナル	PromQL
Latency	`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	`sum by (svc) (rate(http_requests_total{status=~"5.."}[5m])) / sum by (svc) (rate(http_requests_total[5m]))`
Saturation	`avg by (instance) (rate(container_cpu_usage_seconds_total[5m]))`

Managed Service for Prometheus (GMP)

項目	OSS Prometheus	GMP
スケール	単一サーバ	自動スケール（無制限）
保持期間	自前管理	最大 24 ヶ月
HA	自前構築	マネージド
PromQL	100%	100% 互換

🔑 2 つのデプロイモードManaged Collection（新規 GKE 推奨）と Self-deployed Collection（既存 Prometheus からの移行）。

Synthetic Monitor vs Uptime Checks

項目	Uptime Check	Synthetic Monitor
実装	URL を指定するだけ	Cloud Functions（Node.js）でコード
検査	ping / HTTP ステータス / 文字列マッチ	複数ステップ、ログイン、フォーム送信等
価格	無料	Functions 実行コスト

🔑 試験頻出「単一エンドポイントでなく 複数ステップ の検査がしたい」→ Synthetic Monitor。

🔧 Burn rate アラート設計（SRE Workbook 第 5 章）

単純な「エラー率 > X%」アラートは 誤報・遅報のトレードオフ が悪い。Burn rate（エラーバジェット消費速度）でアラートすると、短期の急悪化 と 長期のゆるい悪化 の両方を捉えられる。

🔧 Burn rate しきい値早見表

Burn rate	SLO 期間（28 日）の予算を使い切る時間
1x	28 日（ちょうど消費し切る）
6x	約 4.7 日
14.4x	約 2 日
36x	約 19 時間

🔧 Cloud Monitoring での実装例（SLO + Burn rate）

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

🔧 SLO 数値の暗記

SLO	月あたりエラーバジェット
99%	7 時間 18 分
99.5%	3 時間 39 分
99.9%	43 分 12 秒
99.95%	21 分 36 秒
99.99%	4 分 19 秒
99.999%	25.9 秒

🔧 Notification Channel タイプ

Channel	用途
PagerDuty	Critical、オンコールローテーション、エスカレーション
Rootly	インシデント管理 SaaS（PagerDuty 競合、Webhook ベース）
Slack / Teams	Warning、チーム共有
Email / SMS	個人通知、緊急時
Webhook	カスタム連携（HTTP POST、ChatOps）
Pub/Sub	プログラム処理（Functions / Run）
Mobile App	Cloud Console モバイルプッシュ

🔧 GMP 設定例（PodMonitoring CR）

apiVersion: monitoring.googleapis.com/v1 kind: PodMonitoring metadata: name: app-metrics spec: selector: matchLabels: app: my-api endpoints: - port: metrics interval: 30s

🔧 コスト制御アラート

# 直近 1h でログ取り込みが 100 GiB を超えたらアラート sum by (resource_container) ( rate(logging_googleapis_com:billing_bytes_ingested[1h]) ) * 3600 > 100 * 1024 * 1024 * 1024

🔧 Dashboards as Code（Terraform）

resource "google_monitoring_dashboard" "api_dashboard" { dashboard_json = jsonencode({ displayName = "API Service Dashboard" gridLayout = { columns = "2" widgets = [{ title = "Request Rate" xyChart = { dataSets = [{ timeSeriesQuery = { prometheusQuery = "sum(rate(http_requests_total[1m]))" } }] } }] } }) }

🔧 Synthetic Monitor の例（Node.js）

functions.cloudEvent('syntheticTest', async () => { // 1. ログインページ取得 const loginPage = await fetch('https://example.com/login'); if (!loginPage.ok) throw new Error('Login page failed'); // 2. API トークン取得 const tokenRes = await fetch('https://example.com/api/token', { method: 'POST', body: JSON.stringify({ user: 'test', pass: 'xxx' }), }); // 3. 認証付き API 呼び出し const token = (await tokenRes.json()).token; const dataRes = await fetch('https://example.com/api/data', { headers: { Authorization: `Bearer ${token}` }, }); if (dataRes.status !== 200) throw new Error('Data API failed'); });

🎯 メトリクス・アラート即答

要件	答え
OSS Prometheus 互換でマネージド	Managed Service for Prometheus (GMP)
新規 GKE で Prometheus	GMP Managed Collection
既存 Prometheus 移行	GMP Self-deployed Collection
分位点（p50/p99）	`histogram_quantile`
distribution 可視化	Heatmap
症状ベースのアラート	Multi-burn-rate（SLO ベース）
Fast burn しきい値	14.4x（1h ウィンドウ）
Slow burn しきい値（page）	6x（6h ウィンドウ）
複数ステップの能動監視	Synthetic Monitor（Cloud Functions）
単純な HTTP 死活	Uptime Checks

🎯 PromQL 必修パターン

質問	PromQL
RPS	`sum(rate(http_requests_total[1m]))`
サービス別 5xx 率	`sum by (svc) (rate(req{status=~"5.."}[5m])) / sum by (svc) (rate(req[5m]))`
p99 latency	`histogram_quantile(0.99, sum by (le) (rate(latency_bucket[5m])))`
Istio p99	`histogram_quantile(0.99, sum by (le, destination_workload) (rate(istio_request_duration_milliseconds_bucket[5m])))`

4.4 分散トレース（OpenTelemetry / Cloud Trace / log correlation）

Trace と Span

Trace ID: abc123 (リクエスト全体) │ ├─ Span: frontend.handleRequest [────────────────] 200ms │ │ │ ├─ Span: auth.verifyToken [──────] 50ms │ │ │ └─ Span: api.getData [──────────] 120ms │ │ │ ├─ Span: db.query.users [──] 30ms │ └─ Span: cache.get [─] 10ms

用語	意味
Trace	1 リクエストの全体（Trace ID で識別）
Span	Trace 内の 1 単位処理（開始時刻 + 期間 + 属性）
Parent Span ID	親 Span への参照（木構造を作る）
Waterfall	Span を時系列で可視化したビュー

Cloud Trace の特徴

項目	内容
プロトコル	OpenTelemetry（OTLP）標準サポート
サンプリング	デフォルト約 0.1 リクエスト/秒
保持期間	30 日
無料枠	250 万 span / 月
単価	$0.20 / 100 万 span（無料枠超過）

自動計装 vs 手動計装

種別	内容
自動計装	エージェントが主要ライブラリ（HTTP/DB/RPC）を自動でフック
手動計装	コードで `tracer.start_span()` を呼ぶ

# Python の手動計装 from opentelemetry import trace from opentelemetry.sdk.trace import TracerProvider from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter from opentelemetry.sdk.trace.export import BatchSpanProcessor trace.set_tracer_provider(TracerProvider()) trace.get_tracer_provider().add_span_processor( BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317")) ) tracer = trace.get_tracer(__name__) def process_order(order_id): with tracer.start_as_current_span("process_order") as span: span.set_attribute("order.id", order_id) with tracer.start_as_current_span("validate"): validate(order_id) with tracer.start_as_current_span("charge"): charge(order_id)

Trace ID と構造化ログの紐付け（重要）

「このリクエストのトレース waterfall」と「同じリクエストのログ」を 1 画面で見られると、調査速度が桁違いに上がる。

フィールド	意味
`logging.googleapis.com/trace`	`projects/PROJECT_ID/traces/TRACE_ID` の形式
`logging.googleapis.com/spanId`	16 桁 hex の Span ID
`logging.googleapis.com/trace_sampled`	true なら sampling 対象

🔑 試験頻出Cloud Run / Cloud Functions は X-Cloud-Trace-Context ヘッダから自動紐付け。GKE / GCE は明示的に上記フィールドを出力する。

Cloud Profiler 5 種別（+α）

プロファイル	内容	対応言語
CPU time	CPU を使った時間	Go / Java / Python / Node.js
Heap	現在アロケート済みメモリ（メモリリーク調査）	Go / Java / Node.js（Python なし）
Allocated heap	アロケート総量（GC 含む）	Go / Java
Contention	ロック競合（Mutex 待ち）	Go / Java
Threads	スレッド数	Java
Wall time	経過時間（IO 待ち含む）	Go / Java / Python

🔑 オーバーヘッド本番で常時動かせる（CPU オーバーヘッド < 1%）。「本番で継続的に CPU/メモリのホットスポットを見たい」→ Cloud Profiler。

Error Reporting

例外・エラーを 自動グルーピング して集約。スタックトレースの シグネチャ（クラス名 + メソッド名 + 行番号）でグルーピング。1 つの「Error Group」 = 同じ根本原因のエラー集合。

💡 使い分け「アプリ例外を集約して影響範囲を見たい」→ Error Reporting。「個別ログを検索したい」は Logging。

🔧 サンプリング戦略（Head-based vs Tail-based）

種別	タイミング	利点	欠点
Head-based（Probabilistic、SDK 側）	span 開始時	軽量、決定論的	エラー / 遅い trace を捨てる可能性
Tail-based（Collector 側で trace 全体を見てから）	trace 終了後	エラー / 遅い trace を必ず残す	バッファリング必要、Collector メモリ

🔧 Tail Sampling 設定例

processors: tail_sampling: decision_wait: 30s num_traces: 100000 policies: - name: errors type: status_code status_code: {status_codes: [ERROR]} - name: latency type: latency latency: {threshold_ms: 500} - name: sample-10pct type: probabilistic probabilistic: {sampling_percentage: 10} # → エラー span は 100% 保持、500ms 超は 100% 保持、それ以外は 10%

🔧 Context Propagation（W3C / B3）

フォーマット	ヘッダ	採用元
W3C Trace Context	`traceparent`, `tracestate`	OpenTelemetry 標準（推奨）
B3（Zipkin 由来）	`X-B3-TraceId` 等	Zipkin / Istio
Google Cloud format	`X-Cloud-Trace-Context`	GCP 内部

traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01 │ │ │ │ version trace_id(32hex) parent_id(16hex) flags

🔧 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 # W3C と B3 両方受け付ける set_global_textmap(CompositePropagator([ TraceContextTextMapPropagator(), B3MultiFormat() ]))

🔧 Trace ID をログに含める実装パターン（GKE / GCE）

import json, logging 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 Trace のサンプリング制限

デフォルトでは Cloud Trace 側でも 追加サンプリング（高頻度トラフィック保護）
アプリ側 100% でも、Trace 表示では 約 0.1 req/sec 程度に抑制
100% 保持したい場合は Trace API で force=true か、OTel Collector 経由で抑制回避

🔧 Cloud Profiler 統合（Python）

import googlecloudprofiler googlecloudprofiler.start( service='my-service', service_version='1.0.0', verbose=3, ) # → Flame graph で関数ホットスポットを可視化

🔧 Profiler 種別の使い分け判断

症状	プロファイル種別
CPU 100%	CPU time
メモリ増加止まらない	Heap
Mutex 待ちで応答遅い	Contention
同期 IO が多そう	Wall time
Goroutine リーク	Thread / Goroutine

🎯 分散トレース即答

要件	答え
マイクロサービス間ボトルネック	Cloud Trace
OTel 標準の伝播	W3C Trace Context（`traceparent`）
エラー trace を 100% 保持	Tail-based sampling
Trace を log に紐付けるフィールド	`logging.googleapis.com/trace`
Cloud Run でログと trace 自動紐付け	`X-Cloud-Trace-Context` ヘッダ自動処理
本番で常時プロファイル	Cloud Profiler
メモリリーク調査	Heap profile
Mutex 待ち調査	Contention profile
IO 待ち含む経過時間	Wall time profile
アプリ例外集約	Error Reporting

🎯 暗記必須の数値

項目	値
Cloud Trace 保持期間	30 日
Cloud Trace デフォルトサンプリング	約 0.1 req/sec
Cloud Trace 無料枠	250 万 span/月
Profiler オーバーヘッド	< 1% CPU

4.5 トラブルシュート（5 領域 × 適切なツール）

5 領域のトラブルシュート（初動の型）

PCDE では 5 種類のトラブル で適切なツールを即答できることが求められる。

判断ツリー（症状 → 初動ツール）

Infrastructure（インフラ障害）

症状	初動ツール
VM が NW 接続できない	Connectivity Tests（Network Intelligence Center）
サブネット内の通信状況	VPC Flow Logs
ファイアウォールルールの使われ方	Firewall Insights
ロードバランサのレイテンシ	Performance Dashboard
VM の CPU/メモリ	Cloud Monitoring + Ops Agent

CI/CD（パイプライン障害）

症状	初動ツール
ビルド失敗	Cloud Build logs（コンソール / `gcloud builds log`）
デプロイのロールアウト失敗	`gcloud deploy rollouts describe`
GKE デプロイの差分確認	Skaffold debug / `kubectl describe`
パイプラインの全体メトリクス	Cloud Monitoring の Cloud Build / Deploy metrics

Application（アプリ障害）

症状	初動ツール
5xx が増えた	Logs Explorer（`httpRequest.status>=500`）
例外の集計	Error Reporting
「どのリクエストが」遅い	Cloud Trace（waterfall）
「どの関数が」遅い / メモリ食い	Cloud Profiler

Observability（観測自体の障害）

症状	初動
メトリクスが急に欠落	Ops Agent が落ちていないか確認、Agent log（`/var/log/google-cloud-ops-agent/`）
ログ取り込みコスト急増	Log Router → 上位ログタイプを特定 → Exclusion
アラートが鳴らない	Alerting Policy の condition、Notification Channel の有効性、Snooze 中でないか確認

Performance / Latency（性能）

症状	初動
p99 レイテンシ悪化	Cloud Trace で遅い span → Cloud Profiler で関数特定
メモリ使用増	Heap profile
ネットワーク遅延	Performance Dashboard、Service Mesh metrics
DB クエリ遅延	Trace の DB span + DB 側プロファイラ

🔧 Infrastructure トラブルシュート — Connectivity Tests

gcloud network-management connectivity-tests create test-1 \ --source-instance=projects/my-proj/zones/us-central1-a/instances/vm-a \ --destination-instance=projects/my-proj/zones/us-central1-b/instances/vm-b \ --destination-port=80 --protocol=TCP # 結果には「VPC ルート / Firewall / NAT」のどこで弾かれたかが表示

🔧 Network Intelligence Center（NIC）

サブ機能	用途
Connectivity Tests	2 点間到達性
Network Topology	VPC 全体の可視化
Performance Dashboard	パケットロス・レイテンシ可視化
Firewall Insights	ルール使用状況分析
Network Analyzer	構成警告（推奨設定との差分）

🔧 VPC Flow Logs 分析（Log Analytics）

-- 上位通信先 IP SELECT jsonPayload.connection.src_ip AS src, jsonPayload.connection.dest_ip AS dst, SUM(CAST(jsonPayload.bytes_sent AS INT64)) AS bytes FROM `my-proj.global._Default._AllLogs` WHERE logName LIKE '%compute.googleapis.com%vpc_flows' AND TIMESTAMP_TRUNC(timestamp, HOUR) = TIMESTAMP_TRUNC(CURRENT_TIMESTAMP(), HOUR) GROUP BY src, dst ORDER BY bytes DESC LIMIT 10;

🔧 CI/CD トラブルシュート — Cloud Build

# 失敗した build を一覧 gcloud builds list --filter="status=FAILURE" --limit=10 # 詳細ログ gcloud builds log BUILD_ID # Logs Explorer resource.type="build" severity>=ERROR

典型障害	確認ポイント
Permission denied	Build SA の権限（`@cloudbuild.gserviceaccount.com`）
Image push 失敗	Artifact Registry の権限 + リポジトリ存在
Timeout	`timeout` を延長、または並列化
ネットワーク到達不可	Private Pool + VPC Peering を確認

🔧 Cloud Deploy rollout failures

# Release / Rollout 履歴 gcloud deploy rollouts list \ --release=RELEASE \ --delivery-pipeline=PIPELINE \ --region=REGION # 失敗したターゲットの詳細 gcloud deploy rollouts describe ROLLOUT \ --release=RELEASE \ --delivery-pipeline=PIPELINE \ --region=REGION

典型障害	確認
Approval 待ちで止まる	`gcloud deploy rollouts approve`
Render 失敗	`skaffold render` ローカル実行で再現
Deploy 失敗	Target に紐付く GKE / Run の権限 + Manifest 妥当性
Verify 失敗	`verify` ステップのジョブログ

🔧 Skaffold debug

# ローカルで CI/CD と同じビルド・デプロイを実行 skaffold dev --port-forward # ビルドのみ skaffold build --output=output.json # Render（マニフェスト生成） skaffold render --output=manifests.yaml

🔧 Application — Error Reporting + Trace + Profiler の組合せ

Error Reporting で新規 / 急増エラーを発見
エラーグループに紐づく 代表 Trace を開く
Cloud Trace waterfall で遅延・失敗箇所を特定
失敗 span に 関連ログ が紐付いている → 詳細メッセージを確認
必要に応じ Cloud Profiler でコード行ホットスポット

🔧 Observability — ログ取り込みコスト超過

ステップ	対処
1	ログソース別ボリュームを確認（`logging.googleapis.com/billing/bytes_ingested` を `resource_type` で集約）
2	上位ソースに Exclusion を追加
3	INFO / DEBUG はサンプリング
4	Bucket 保持期間短縮

🔧 Observability — メトリクス欠落

確認	対処
Ops Agent ステータス	`sudo systemctl status google-cloud-ops-agent`
エージェントログ	`/var/log/google-cloud-ops-agent/subagents/logging-module.log`
メトリクス取り込み割り当て	Quota & System Limits
API 有効化	`monitoring.googleapis.com`
SA 権限	`roles/monitoring.metricWriter`

🔧 Performance — Service Mesh metrics で切り分け

# サービス別 p99 レイテンシ histogram_quantile(0.99, sum by (le, destination_workload) ( rate(istio_request_duration_milliseconds_bucket[5m]) ) ) # サービス間のエラー率 sum by (source_workload, destination_workload) ( rate(istio_requests_total{response_code=~"5.."}[5m]) )

🎯 トラブルシュート初動表

領域	症状	初動ツール
Infrastructure	VM が接続できない	Connectivity Tests
Infrastructure	不要 FW ルール	Firewall Insights
Infrastructure	パケットロス	Performance Dashboard
Infrastructure	トラフィック内訳	VPC Flow Logs
CI/CD	ビルド失敗	Cloud Build logs
CI/CD	デプロイ失敗	`gcloud deploy rollouts describe`
CI/CD	ローカル再現	`skaffold dev`
Application	5xx 増加	Logs Explorer
Application	例外集計	Error Reporting
Application	リクエスト遅延	Cloud Trace（waterfall）
Application	コード行ホットスポット	Cloud Profiler
Observability	メトリクス欠落	Ops Agent 状態 + agent ログ
Observability	ログコスト超過	ソース別ボリューム → Exclusion
Observability	アラート鳴らない	Condition / Channel / Snooze 確認
Performance	p99 悪化	Cloud Trace → Profiler
Performance	メモリ増	Heap profile
Performance	NW 遅延	Performance Dashboard / Service Mesh metrics

🤖 Gemini Cloud Assist（2024-2025 新機能）

🔑 新機能の重要性Gemini Cloud Assist は Google Cloud Console に統合された AI 支援機能。Section 4 では特に ログ / メトリクス / トレース解析支援 で頻出。旧 Duet AI in Google Cloud がリネーム。

主要機能 5 つ

①

Log Summary / Insights

Logs Explorer 上で「過去 1h の異常を要約して」と自然言語で質問。Summarize logs ボタンで過去 N 時間のログトレンドを要約。

②

Investigations

アラートに対して 根本原因候補 を AI が提示。過去ログ・メトリクス・最近の Cloud Build / Deploy を相関分析し「最近のデプロイが原因かも」と仮説を出す。MTTR 短縮の中心機能。

③

Explain this chart

Metrics Explorer / Dashboard のグラフを「なぜこの値か」AI が自然言語で説明。異常値の可能性・関連メトリクスを提案。

④

Summarize trace

Cloud Trace の複雑な waterfall を自然言語で要約。「X で 200ms、Y で 50ms、最大ボトルネックは Y の DB クエリ」。

⑤

Query 自動生成

「先週 5xx が多かったサービスは？」→ LQL / PromQL を生成。自然言語クエリ → 適切な構文に変換。

+α

IAM ロール

roles/cloudaicompanion.user（利用）/ roles/cloudaicompanion.admin（管理）。入力データはモデル学習に使われない。

💡 試験頻出「複雑なメトリクスのスパイクの原因を素早く特定したい」→ Gemini Cloud Assist の Investigations。「ログを自然言語で検索したい」→ Query 自動生成 → LQL に変換。

🎯 要点と暗記 — 一問一答

Q1. VM のログ + メトリクス収集に使うエージェントは？

A. Ops Agent。fluentbit + otel ベース。Legacy Logging / Monitoring Agent は非推奨で置換対象。GKE / Cloud Run / Functions は自動収集でエージェント不要。

Q2. Audit Logs 4 種類の中でデフォルト無効なのは？

A. Data Access。Admin Activity / System Event / Policy Denied は常時有効・無効化不可。コンプラ要件で「誰がデータを見たか」を記録するには IAM Policy で Data Access ログを明示有効化（DATA_READ / DATA_WRITE / ADMIN_READ）。

Q3. 組織全体の Audit Log を 1 つの BigQuery に集めたい

A. Org-level Aggregated Sink with --include-children。通常の Sink はプロジェクト単位、Aggregated Sink は Org / Folder 単位で配下プロジェクトすべてを横断的に転送。

Q4. ログコストが急増、最も効果的な対策は？

A. Exclusion filter。Log Router で取り込み課金そのものを 0 にする。Sink 追加は重複課金になるので NG。優先順位は Exclusion → Sampling → Retention 短縮。

Q5. ログを SQL で分析、データ重複なしで最安は？

A. Log Analytics。既存 Log Bucket をアップグレードすると BigQuery で直接 SQL 可能。追加課金なし・データ重複なし。古い「BigQuery sink」より優先。

Q6. ログに含まれる PII を本番ログから取り除きたい

A. アプリ層で Sensitive Data Protection（旧 Cloud DLP）API を呼ぶ。出力前にマスキング・トークン化。代替として Sink + Pub/Sub + Dataflow（DLP テンプレ）パターンも。

Q7. PromQL で p99 レイテンシを取る関数は？

A. histogram_quantile(0.99, sum by (le) (rate(latency_bucket[5m])))。ヒストグラムは _bucket{le="..."} の累積分布で記録され、histogram_quantile が補間で分位点を算出。

Q8. SRE Workbook の Multi-burn-rate Fast アラートのしきい値は？

A. 1h ウィンドウで Burn rate 14.4x（短窓 5m と組合せ）。Slow page は 6h で 6x（短窓 30m）。Burn rate 1x = SLO 期間（28 日）でちょうど予算を使い切る速度、14.4x なら約 2 日で消費。

Q9. 複数ステップの能動監視（ログイン→API→検証）が必要

A. Synthetic Monitor。Cloud Functions（Node.js）でスクリプト記述。Uptime Checks は単一エンドポイントの ping のみ。

Q10. 新規 GKE クラスタで Prometheus を使いたい

A. Managed Service for Prometheus（GMP）Managed Collection。PodMonitoring CR で対象を指定、collector は GCP が管理。既存 Prometheus からの移行は Self-deployed Collection。

Q11. OpenTelemetry 標準の context propagation フォーマットは？

A. W3C Trace Context（traceparent / tracestate ヘッダ）。B3 は Zipkin / Istio、X-Cloud-Trace-Context は GCP 内部フォーマット。マイクロサービス間で全サービス同じ propagation format を採用すること。

Q12. エラー trace / 遅い trace を確実に保持しつつコスト削減

A. Tail-based sampling（OTel Collector の tail_sampling processor）。trace 全体を見てから判定するので、エラー span 100% / 500ms 超 100% / それ以外 10% のような戦略が可能。Head-based は SDK 側で軽量だが、エラー/遅い trace を捨てる可能性。

Q13. Trace と構造化ログを紐付けるログフィールドは？

A. logging.googleapis.com/trace（値は projects/PROJECT_ID/traces/TRACE_ID）+ logging.googleapis.com/spanId + logging.googleapis.com/trace_sampled。Cloud Run / Functions は X-Cloud-Trace-Context ヘッダから自動紐付け、GKE / GCE は明示出力。

Q14. Python アプリのメモリリーク調査に Cloud Profiler の Heap は使える？

A. 使えない。Python は CPU と Wall time のみサポート。Java は Heap allocation なし、Node.js は Wall / Contention なし。「Python のメモリリーク → Profiler Heap」は試験で誤りの選択肢になりがち。

Q15. 2 点間の VPC 到達性を診断したい

A. Connectivity Tests（Network Intelligence Center 配下）。構成解析で「VPC ルート / Firewall / NAT」のどこで弾かれたかを表示。実際のパケットは送らない。

Q16. GCP インフラ内のパケットロス・レイテンシを可視化したい

A. Performance Dashboard（NIC 配下）。リージョン間・ゾーン間の SLI として可視化。VM レベルではなく GCP インフラレベル。

Q17. アラートの根本原因を AI に推測させたい

A. Gemini Cloud Assist の Investigations。過去ログ・メトリクス・最近の Cloud Build / Deploy を相関分析して「最近のデプロイが原因かも」「特定の Pod だけで発生」など仮説を提示。MTTR 短縮の中心機能。

Q18. Cloud Deploy の rollout 失敗を最初に見るコマンド

A. gcloud deploy rollouts describe。Approval 待ち、Render 失敗、Verify 失敗などの状態を確認。ローカル再現は skaffold dev / render / build。

Q19. Cloud Service Mesh で自動収集される 3 種類は？

A. Metrics（istio_requests_total 等） / Access Logs（Envoy） / Traces。コード変更なしに 4 Golden Signals が取れるのが Service Mesh の最大の売り。旧 Anthos Service Mesh（ASM）。

Q20. distribution 型メトリクスの可視化に最適なチャートは？

A. Heatmap（ヒートマップ）。分位点取得は histogram_quantile。Scorecard は単一値、Line は時系列、Stacked bar はカテゴリ別積み上げ。

💡 必殺フレーズ集（試験当日用）

状況	即答
「VM のログ + メトリクス収集」	Ops Agent
「誰がリソースを変更したか」	Admin Activity log（常時有効）
「誰がデータを見たか」	Data Access log を明示有効化
「IAM/VPC SC で拒否」	Policy Denied log
「組織全体の Audit ログ集約」	Aggregated Sink with `--include-children`
「ログを SQL で分析、最安・重複なし」	Log Analytics
「リアルタイムで SIEM 連携」	Pub/Sub Sink
「7 年アーカイブ最安」	Cloud Storage Sink（Archive class）+ Lifecycle
「ログコスト緊急削減」	Exclusion filter（最優先）
「PII を取り除く最確実」	アプリ層で Sensitive Data Protection（DLP）
「ログから数値抽出して分布化」	Distribution 型 log-based metric
「ログ行数をメトリクス化」	Counter 型 log-based metric
「distribution 可視化」	Heatmap
「PromQL で分位点」	`histogram_quantile`
「PromQL で秒速」	`rate`
「OSS Prometheus 互換マネージド」	GMP
「新規 GKE で Prometheus」	GMP Managed Collection
「既存 Prometheus 移行」	GMP Self-deployed Collection
「症状ベース / アクション可能アラート」	Multi-burn-rate（SLO ベース）
「Fast burn しきい値」	14.4x（1h）
「Slow burn page しきい値」	6x（6h）
「複数ステップの能動監視」	Synthetic Monitor
「単純な HTTP 死活」	Uptime Checks
「マイクロサービス間ボトルネック」	Cloud Trace
「OTel 標準の伝播」	W3C Trace Context
「エラー trace を確実に保持」	Tail-based sampling
「Trace と log の紐付け」	`logging.googleapis.com/trace`
「Cloud Run で自動紐付け」	`X-Cloud-Trace-Context` ヘッダ
「本番で常時プロファイル」	Cloud Profiler
「メモリリーク調査」	Heap profile
「Mutex 待ち調査」	Contention profile
「IO 待ち含む経過時間」	Wall time profile
「アプリ例外集約」	Error Reporting
「2 点間 VPC 到達性」	Connectivity Tests
「GCP インフラのパケットロス」	Performance Dashboard
「不要 FW ルール検出」	Firewall Insights
「コード変更なしに 4 Golden Signals」	Cloud Service Mesh（旧 ASM）
「Cloud Build 失敗」	`gcloud builds log` / Logs Explorer
「Cloud Deploy rollout 失敗」	`gcloud deploy rollouts describe`
「ローカルで CI 再現」	Skaffold（`skaffold dev/render/build`）
「AI が異常を要約」	Gemini Cloud Assist Log Summary
「AI が障害根本原因を推測」	Gemini Cloud Assist Investigations
「自然言語で LQL/PromQL 生成」	Gemini Cloud Assist Query 生成
「メトリクスチャートを自然言語で説明」	Gemini Cloud Assist Explain this chart

🔑 5 分で復習する箇条書きまとめ

3 軸 + α: Metrics + Logs + Traces + Profiler + Error Reporting + Synthetic + Gemini
Audit Logs 4 種: Data Access のみデフォルト無効、他 3 つは常時有効・無効化不可
Log Buckets: _Default 30 日変更可 / _Required 400 日固定
Sink 宛先: BQ（Log Analytics 推奨）/ Pub/Sub / GCS / 別 Bucket
Aggregated Sink: Org / Folder 単位、--include-children
ログコスト削減: Exclusion > Sampling > Retention 短縮
PII: アプリ層で Sensitive Data Protection（DLP）
OTel Collector: Receivers / Processors / Exporters の 3 段
OTel 標準伝播: W3C Trace Context（traceparent）
Tail-based sampling: エラー / 遅い trace を 100% 保持
Trace 紐付け: logging.googleapis.com/trace、Cloud Run/Functions は自動
Profiler 5 種別: CPU / Heap / Contention / Wall / Thread（Python は CPU/Wall のみ）
PromQL: rate / increase / histogram_quantile / sum by（MQL は非推奨）
Multi-burn-rate: Fast 14.4x@1h / Slow 6x@6h / Medium 3x@24h / Slow 1x@3d
GMP: PromQL 100% 互換、24 ヶ月保持、Managed / Self-deployed Collection
Synthetic Monitor: 複数ステップ、Cloud Functions ベース
Cloud Service Mesh（旧 ASM）: コード変更なしに Metrics + Access Logs + Traces
5 領域トラブルシュート: Infra / CI/CD / App / Observability / Performance
Gemini Cloud Assist: Log Summary / Investigations / Explain chart / Trace 要約 / Query 生成

🧭 次のステップ

← セクション 3：SRE プラクティスセクション 5：パフォーマンス & コスト → 📝 問題演習を解く 📖 用語集

セクション 4：可観測性とトラブルシュート

🎯 学習目標

🔭 可観測性の 3 軸 + α

集約済み数値時系列

個別イベント

分散リクエスト追跡

4.1 計装と収集（Ops Agent / OpenTelemetry / Audit Logs）

3 つのエージェント

Ops Agent の設定例

OpenTelemetry（OTel）の基本

OTel Collector の 3 段構成（Receivers → Processors → Exporters）

Cloud Audit Logs 4 種類（最頻出）

Audit Logs 4 種類 — 視覚化

VPC Flow Logs と Firewall Insights

Cloud Service Mesh のテレメトリ

🔧 OTel Collector の主要 Receiver / Processor / Exporter

Receivers

Processors

Exporters

🔧 推奨 Collector 設定テンプレ

🔧 Audit Logs の有効化（IAM Policy）

🔧 VPC Flow Logs の有効化

🔧 自動計装（Python）

🔧 Service Mesh の標準メトリクス

🎯 計装と収集 即答

4.2 ログ管理（Log Router / Sink / LQL / Log Analytics）

Cloud Logging のアーキテクチャ

Log Buckets

Sink の 4 つの宛先

構造化ログ（jsonPayload）が必須

LQL（Logging Query Language）基本構文

LQL 必修パターン

log-based metric の 2 種類

ログ最適化 — 4 つのレバー（優先順位）

課金体系（概要）

🔧 Sink 宛先の使い分けマトリクス

🔧 Log Analytics（最新ベストプラクティス）

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

🔧 Sink 設計の典型 3 段構成

🔧 GCS Lifecycle で自動階層化

🔧 PII / PHI のリダクション

🔧 Log Scopes & Log Views

🔧 Exclusion / Sampling / Retention 実装テンプレ

🎯 ログ管理 即答

🎯 Log Buckets 暗記

4.3 メトリクス・ダッシュボード・アラート（PromQL / GMP / Burn rate）

Cloud Monitoring の主要機能

メトリクスの 3 種別

4 つのチャートタイプ

PromQL 基本構文（必須）

4 Golden Signals の PromQL 雛形

Managed Service for Prometheus (GMP)

Synthetic Monitor vs Uptime Checks

🔧 Burn rate アラート設計（SRE Workbook 第 5 章）

🔧 Burn rate しきい値 早見表

🔧 Cloud Monitoring での実装例（SLO + Burn rate）

🔧 SLO 数値の暗記

🔧 Notification Channel タイプ

🔧 GMP 設定例（PodMonitoring CR）

🔧 コスト制御アラート

🔧 Dashboards as Code（Terraform）

🔧 Synthetic Monitor の例（Node.js）

🎯 メトリクス・アラート 即答

🎯 PromQL 必修パターン

4.4 分散トレース（OpenTelemetry / Cloud Trace / log correlation）

Trace と Span

Cloud Trace の特徴

自動計装 vs 手動計装

Trace ID と構造化ログの紐付け（重要）

Cloud Profiler 5 種別（+α）

Error Reporting

🔧 サンプリング戦略（Head-based vs Tail-based）

🔧 Tail Sampling 設定例

🔧 Context Propagation（W3C / B3）

🔧 W3C + B3 を両方受け付ける設定

🔧 Trace ID をログに含める実装パターン（GKE / GCE）

🔧 Cloud Trace のサンプリング制限

🔧 Cloud Profiler 統合（Python）

🔧 Profiler 種別の使い分け判断

🎯 分散トレース 即答

セクション 4：
可観測性とトラブルシュート

🎯 計装と収集即答

🎯 ログ管理即答

🔧 Burn rate しきい値早見表

🎯 メトリクス・アラート即答

🎯 分散トレース即答