三個服務，一個共同的資料底層

Google Cloud Observability（原 Google Cloud 的 Operations Suite）由幾個核心服務組成，這篇先建立整體地圖，後面三週會各自深入一個服務。

三個核心服務的分工

Cloud Logging：集中收集、儲存、搜尋日誌，支援結構化 JSON 日誌，可以設定 Sink 把日誌路由到 BigQuery、Cloud Storage 或 Pub/Sub 做進一步分析。這是 Week 2 的主角。

Cloud Trace：分散式追蹤服務，記錄請求（或在 Agent 場景下是一次任務執行）經過的每一個 Span，呈現成一棵時間軸樹狀圖。Google 官方已經針對生成式 AI 應用提供專門的 instrumentation 指引，包括對 ADK 應用的內建整合——這是 Week 3 的主角。

Cloud Monitoring：收集 Metrics、建立 Dashboard、設定 Alerting Policy，是告警與異常偵測的核心——這是 Week 4 的主角。

三者怎麼串起來看

這三個服務不是各自獨立的孤島，實務上的價值在於互相跳轉：你在 Dashboard 上看到一個異常的延遲尖峰（Monitoring），點進去可以看到對應時間點的完整 Trace（Trace），再從 Trace 上某個可疑的 Span 點進去看該次呼叫的完整結構化日誌（Logging）。Week 3 會示範這個串接怎麼設計。

跟 OpenTelemetry 的關係

Google Cloud Observability 支援 OpenTelemetry 標準——你可以用 OTel SDK 產生 Trace 與 Metrics，再匯出到 Cloud Trace 與 Cloud Monitoring，不需要綁死在 Google 專屬的 SDK 上。對 Gen AI 應用，OpenTelemetry 社群定義了專門的 GenAI 語意慣例（semantic conventions），Cloud Trace 也已支援解析符合這套慣例的 Span——Day 5 會深入這部分。

待實測提醒：Google Cloud Observability 各服務的免費額度、計價方式、以及與 OpenTelemetry 各版本的相容性會持續調整，發布前請對照 Google Cloud Observability 官方文件 確認目前狀態。

這篇的檢查清單

• [ ] 是否已釐清三個核心服務各自的角色，避免用單一服務硬做所有事？