変更要約: Professional Cloud Developer 第6章を新規作成（ドメイン4「統合」後半: 可観測性＝Google Cloud Observability/メトリクス(Monitoring)/ログ(Logging)/トレース(Trace)/トレース ID 相関/Gemini Cloud Assist、トラブルシューティング＝Error Reporting のエラー集約・メトリクス→トレース→ログの切り分け・修正/ロールバック）。
6.1可観測性（メトリクス・ログ・トレース）
Google Cloud Observability によるコードの計装、メトリクス・ログ・トレースの収集、Cloud Logging での調査、Cloud Trace の分散トレースとトレース ID によるスパンの相関、そして AI 支援の可観測性を理解します。
本番で何が起きているかを知るには、アプリを観測可能にします。Google Cloud Observability で、メトリクス・ログ・トレースの三本柱を計装します。
6.1.1三本柱の計装
可観測性の三本柱は、数値の傾向を見る メトリクス（Cloud Monitoring）、出来事を記録する ログ（Cloud Logging）、リクエストの経路を追う トレース（Cloud Trace）です。コードを 計装してこれらを出力し、ダッシュボードやアラートで監視します。「数値の監視/アラート＝メトリクス（Monitoring）」「出来事の記録・検索＝ログ（Logging）」「リクエスト経路＝トレース（Trace）」と区別します。
6.1.2調査と相関
障害の原因は Cloud Logging でログを検索して調べます。分散システムでは Cloud Trace でリクエストが通ったサービスの スパンを可視化し、トレース ID でログとトレースを 相関させて、どのサービスが遅い/失敗したかを特定します。Gemini Cloud Assist による AI 支援で、ログやメトリクスの解釈・原因究明を加速できます。「サービス横断の経路を追う＝Cloud Trace のスパン」「ログとトレースの突合＝トレース ID」を押さえます。
「症状 → 道具」が頻出。例：「数値の傾向を監視し通知」＝メトリクス（Cloud Monitoring）、「出来事を検索して原因調査」＝Cloud Logging、「サービス横断のレイテンシを追う」＝Cloud Trace、「ログとトレースを突合」＝トレース ID で相関、「AI で原因究明を加速」＝Gemini Cloud Assist。
混同に注意：
①メトリクス（数値）/ログ（出来事）/トレース（経路）の三本柱を取り違えない。
②分散システムの遅延特定にはトレース ID での相関が鍵。
③計装しないと観測できない（後付けは難しい）。
6.1.3この節のまとめ
- 三本柱＝メトリクス(Monitoring)/ログ(Logging)/トレース(Trace)を計装
- 原因調査は Cloud Logging、分散の経路は Cloud Trace のスパン、相関はトレース ID
- Gemini Cloud Assist で AI 支援の可観測性
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 障害の原因をログを検索して調査したい。最適なサービスはどれですか？
Q2. 分散システムで、リクエストが通ったサービスのレイテンシを経路で追いたい。使うのはどれですか？
Q3. 複数サービスにまたがるログとトレースを突き合わせたい。使うのはどれですか？
Q4. 数値の傾向を監視し、しきい値超過で通知したい。使うのはどれですか？
Q5. 可観測性の三本柱として正しい組み合わせはどれですか？
Q6. ログやメトリクスの解釈・原因究明を AI で加速したい。使うのはどれですか？