Cloud Trace 總覽

Cloud Trace 是一套分散式追蹤系統， Google Cloud 可追蹤要求延遲情形，並協助您排解服務和生成式 AI 應用程式的效能瓶頸 。Trace 會從Google Cloud 服務和已檢測的應用程式收集延遲資料，協助您瞭解微服務架構中要求的處理方式，並找出相關記錄。

Trace 可協助您回答下列問題：

  • 應用程式處理特定要求需要多長的時間？
  • 為什麼要求需要很長時間才能完成？
  • 為什麼部分要求需要較長時間才能完成？
  • 應用程式要求的整體延遲時間為何？
  • 應用程式延遲時間是否隨著時間增加或減少？
  • 如何縮短應用程式的延遲時間？
  • 應用程式的依附元件為何？

如要瞭解如何搭配使用追蹤記錄和記錄檔進行根本原因分析，請參閱網誌文章「Troubleshooting distributed applications: Using traces and logs together for root-cause analysis」(排解分散式應用程式問題：搭配使用追蹤記錄和記錄檔進行根本原因分析)。

如要瞭解如何剖析應用程式，請參閱「Cloud Profiler」。

環境支援

Trace 可在下列環境中透過 Linux 執行：

元件

Trace 由追蹤用戶端和 Google Cloud 專案構成，前者會收集追蹤記錄並傳送至後者。接著，您可以使用Google Cloud 控制台查看及分析追蹤用戶端收集的資料。如要瞭解資料模型，請參閱「追蹤記錄和範圍」。

追蹤用戶端

追蹤用戶端會從應用程式收集延遲和時距資料，並匯出至 Google Cloud 專案。您可以根據環境和需求，透過檢測應用程式程式碼，自動或手動收集追蹤資料。

追蹤介面

如要查看及分析 span 資料，可以使用Google Cloud 控制台中的「Trace Explorer」和「Observability Analytics」頁面：

  • 追蹤記錄檢視工具：顯示追蹤記錄資料的匯總資訊，並可讓您詳細檢查個別追蹤記錄。熱視圖會顯示匯總延遲資料，您可以使用指標探索這些資料。如要限制顯示的資料，可以新增篩選器。 您也可以查看及探索個別時距和追蹤記錄：

  • 可觀測性分析：提供 SQL 查詢介面。查詢可以加入追蹤和記錄檔資料，查詢結果可以表格或圖表形式呈現。建立連結的 BigQuery 資料集後，您可以使用 BigQuery 分析追蹤資料。詳情請參閱「查詢及分析追蹤記錄」。

自動追蹤設定

下列設定會自動擷取追蹤資料：

  • App Engine 標準環境

    • 第一代執行階段會自動攔截追蹤範圍，並傳送至 Cloud Trace。詳情請參閱「舊版套裝服務總覽」。

    • 第二代執行階段會自動擷取整體要求延遲時間，並在要求中加入 X-Cloud-Trace-Context HTTP 標頭。詳情請參閱「執行階段支援時間表」。

  • Cloud Run functions 和 Cloud Run

    系統會自動將傳入和傳出 HTTP 要求的延遲資料傳送至 Trace。

檢測應用程式

為應用程式加入檢測功能，收集特定資訊，瞭解應用程式的效能並排解失敗問題。多個開放原始碼檢測架構會收集記錄、指標和追蹤記錄資料，並將資料傳送給任何供應商，包括 Google Cloud。對於代理程式應用程式，部分架構可能會收集提示和回應，或傳遞可追蹤部分遠端 Google Cloud MCP 伺服器呼叫的內容。

如要檢測應用程式，建議您使用開放原始碼、與供應商無關的檢測架構 (例如 OpenTelemetry)，而非供應商和產品專屬的 API 或用戶端程式庫。如要瞭解這些架構，請參閱「 檢測和觀測能力」和「選擇檢測方法」。

我們提供的檢測範例使用 OpenTelemetry：

雖然您可以使用 Cloud Trace 用戶端程式庫來檢測應用程式，但我們建議您使用 OpenTelemetry。建議使用 OpenTelemetry 程式庫，而非 Trace 用戶端程式庫，因為前者較為簡單，且會以 OpenTelemetry 定義的 OTLP 格式匯出追蹤記錄資料。詳情請參閱「為 Trace 進行檢測」和「Cloud Trace 的用戶端程式庫」。

Cloud Trace 和代理程式應用程式

如要瞭解代理程式應用程式的行為，請設定應用程式收集提示和回應，或在呼叫遠端 Google Cloud MCP 伺服器時產生範圍。提示和回覆可協助您瞭解代理應用程式使用的推論方式。記錄工具呼叫的範圍可協助您確認工具叫用、呼叫狀態和要求延遲。

多個檢測範例會說明如何設定應用程式，以收集提示和回覆。這些範例依賴 OpenTelemetry。詳情請參閱「如何檢測生成式 AI 應用程式」。

Google Cloud MCP 伺服器可以產生追蹤範圍。詳情請參閱「使用 Trace 檢查 MCP 呼叫」。

擷取追蹤記錄資料的 API

您可以透過 Telemetry API 或 Cloud Trace API，將追蹤記錄資料傳送至專案。我們建議使用 Telemetry API，原因如下：

  • 這個 API 與開放原始碼 OpenTelemetry 生態系統相容，且限制通常比 Cloud Trace API (專有 Google Cloud API) 更寬鬆。

  • 追蹤資料的儲存格式通常與 OTLP 定義的 proto 檔案一致。部分欄位可能會先從 OpenTelemetry 專屬資料類型轉換為 JSON 資料類型，再進行儲存。如需儲存格式的相關資訊，請參閱「追蹤記錄資料的結構定義」。

  • 如要以收集器為基礎匯出追蹤資料，您的檢測作業不需要依賴 Google Cloud專用匯出工具。

  • 部分功能 (例如應用程式監控) 只能在您將追蹤資料傳送至 Telemetry API 時，才能取得相關資訊。

如要避免 Google Cloud 專案儲存追蹤資料，請停用 Cloud Trace API。停用 Cloud Trace API 會產生下列影響：

  • Google Cloud 服務不會將追蹤記錄資料傳送至專案。
  • Google Cloud 回覆傳送至 Cloud Trace API 端點的要求時，會傳回錯誤代碼。
  • Google Cloud Observability 會捨棄傳送至追蹤記錄專用 Telemetry API 端點的追蹤記錄資料。請勿停用 Telemetry API，因為該 API 可以接收記錄、指標和追蹤記錄資料。

如果您管理機構，並想禁止使用 Cloud Trace，請建立機構政策限制。

VPC Service Controls 支援

Google Cloud 服務和應用程式可以使用 Cloud Trace API 或 Telemetry API，將追蹤資料傳送至專案。Cloud Trace 提供的視覺化服務會使用 Cloud Trace API 擷取顯示的追蹤資料：

  • Cloud Trace 是支援 VPC Service Controls 的服務。追蹤記錄服務名稱為 cloudtrace.googleapis.com。如需詳細資料和限制，請參閱「支援的產品：Cloud Trace」。

  • Telemetry API 是支援 VPC Service Controls 的服務。服務名稱為「telemetry.googleapis.com」。如需詳細資料和限制，請參閱「支援的產品：Telemetry API」。

如要設定預設值，指定追蹤資料的儲存 Google Cloud 區域，以及是否使用客戶自行管理的金鑰加密資料，請使用 Observability API。您也可以使用這個 API 設定連結的 BigQuery 資料集，透過 BigQuery 服務查詢追蹤資料，以及設定追蹤範圍，彙整儲存在多個專案中的追蹤資料。

  • Observability API 是支援 VPC Service Controls 的服務。服務名稱為「observability.googleapis.com」。如要瞭解詳細資料和限制，請參閱「支援的產品：Observability API」。

如要瞭解詳情，請參考下列資源：

Cloud Trace 和資料落地

如果您因為有資料落地或影響等級 4 (IL4) 的需求而使用 Assured Workloads，請勿使用 Cloud Trace API 傳送追蹤範圍。

如要避免 Google Cloud 專案儲存追蹤資料，請停用 Cloud Trace API。請勿停用 Telemetry API，因為該 API 可以接收記錄、指標和追蹤記錄資料。

追蹤記錄保留

類別 保留期限
儲存在 _Trace 值區中的範圍 30 天

IAM 角色

Cloud Trace 使用 Identity and Access Management (IAM) 來控管資源存取權。如需 Cloud Trace API 和 Telemetry API 角色清單，請參閱「使用 IAM 控管存取權」。

由於 Telemetry API 是消費者 API，因此將資料傳送至 Telemetry API 時，您必須指定配額專案，並授予應用程式的服務帳戶使用該配額的權限。詳情請參閱「Telemetry API：驗證」。

定價

如要瞭解 Cloud Trace 的定價，請參閱「Google Cloud Observability 定價」頁面。

後續步驟