変更要約: Professional Cloud DevOps Engineer 第4章を新規作成（ドメイン4「可観測性」: Ops Agent/OpenTelemetry/Managed Service for Prometheus/Cloud Audit Logs/VPC Flow Logs・ログ最適化・合成モニタ・ログベースメトリクス・Logs Explorer・BigQuery/Pub/Sub/Cloud Storage エクスポート・PII/PHI 秘匿、Metrics Explorer/PromQL ダッシュボード/アラートポリシー/PagerDuty・分散トレース Cloud Trace/OpenTelemetry・トレースとログ相関・トラブルシュート）。
4.2メトリクス・ダッシュボード・アラートと分散トレース
Metrics Explorer によるメトリクス分析、ダッシュボード（PromQL・共有・プレイブック）、アラートポリシー（SLI/SLO・コスト）と第三者連携（PagerDuty 等）、分散トレース（OpenTelemetry・Cloud Trace・トレースとログの相関）、インフラ/CI-CD/アプリ/性能/レイテンシのトラブルシュートを理解します。
集めたテレメトリは、見える化・気づき・原因追跡に変えて初めて価値が出ます。メトリクスを可視化し、賢くアラートし、分散トレースで遅延の原因をたどります。
4.2.1メトリクス・ダッシュボード・アラート
メトリクスは Metrics Explorer で探索し、ダッシュボード にまとめます（PromQL でクエリ、共有や プレイブック の添付も可）。アラートポリシー は症状ベース（SLI/SLO 違反、コスト超過）で設定し、過剰なノイズを避けます。通知は Webhook で PagerDuty などの第三者ツールに連携します。「複数チャートの一覧＝ダッシュボード」「SLO 違反で通知＝アラートポリシー」を結びます。
4.2.2分散トレースとトラブルシュート
マイクロサービスの遅延は 分散トレース（Cloud Trace・OpenTelemetry で計装）でたどります。リクエストを スパン の ウォーターフォール として可視化し、どの呼び出しが遅いかを特定します。トレース ID を構造化ログと相関 させると、遅いリクエストの詳細ログへ即座に辿れます。トラブルシュートは インフラ/CI-CD/アプリ/可観測性/性能・レイテンシ の各層を、ログ・メトリクス・トレースを突き合わせて切り分けます。「マイクロサービスの遅延原因＝分散トレース」を押さえます。
「要件 → 手段」が頻出。例：「メトリクスを探索」＝Metrics Explorer、「PromQL でダッシュボード」＝ダッシュボード、「SLO 違反で通知」＝アラートポリシー、「オンコール連携」＝PagerDuty（Webhook）、「マイクロサービスの遅延を特定」＝分散トレース（Cloud Trace）、「遅いリクエストの詳細ログへ」＝トレース ID とログの相関。
混同に注意：
①アラートは原因でなく症状（SLO/ユーザー影響）ベースにしてノイズを避ける。
②メトリクス（集計値）とトレース（1 リクエストの経路）とログ（イベント）は役割が別＝相関して使う。
③トレースは全リクエストでなくサンプリングが普通。
4.2.3この節のまとめ
- Metrics Explorer で探索、ダッシュボード(PromQL/プレイブック)、アラートは SLO/コストの症状ベース＋PagerDuty 連携
- 分散トレース＝Cloud Trace/OpenTelemetry、スパンのウォーターフォール、トレース ID とログを相関
- トラブルシュートはログ・メトリクス・トレースを突き合わせ、インフラ/CI-CD/アプリ/性能を切り分け
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 複数のメトリクスチャートを 1 画面にまとめ、チームで共有したい。最適なのはどれですか？
Q2. SLO 違反やコスト超過などの条件で通知を出したい。最適なのはどれですか？
Q3. マイクロサービス間でどの呼び出しが遅いかを特定したい。最適なのはどれですか？
Q4. 遅いリクエストのトレースから、その詳細ログへ素早く辿りたい。最も有効なのはどれですか？
Q5. オンコールのエスカレーション通知を外部ツールへ送りたい。最も一般的な連携先はどれですか？
Q6. 通知ノイズを減らすため、アラートはどの基準で設計するのが望ましいですか？