Cloud Trace 總覽

Cloud Trace 是Google Cloud的分散式追蹤系統,可協助您瞭解應用程式處理使用者或其他應用程式傳入的要求所花費的時間,以及處理要求時花在 RPC 呼叫等作業上的時間。此外,在開發服務、開發代理程式應用程式或排解故障問題時,Trace 也能提供協助。舉例來說,這項服務可協助您瞭解複雜的微服務架構如何處理要求,並找出要檢查的記錄。

由於 Trace 會從 Google Cloud 服務 (例如 App Engine) 和您檢測的應用程式接收延遲資料,因此可協助您回答以下問題:

  • 應用程式處理特定要求需要多長的時間?
  • 為何應用程式處理要求需要這麼長的時間?
  • 為何有些要求的處理時間比其他要求長?
  • 要求傳送到應用程式的整體延遲狀況?
  • 應用程式的延遲時間隨著時間增加或減少了嗎?
  • 我該如何縮短應用程式的延遲時間?
  • 應用程式的依附元件為何?

如要瞭解如何使用 Trace 管理應用程式,請參閱「Troubleshooting distributed applications: Using traces and logs together for root-cause analysis」這篇網誌。

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

環境支援

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

Trace 提供用戶端程式庫,可讓您檢測應用程式,擷取追蹤資訊。如需各個語言的設定操作說明,請參閱「為 Trace 進行檢測」一文。

自動追蹤設定

部分設定會自動擷取追蹤記錄資料:

  • App Engine 標準環境

    Java 8、Python 2 和 PHP 5 應用程式不需要使用 Trace 用戶端程式庫。這些執行階段會針對向應用程式 URI 發出的要求,自動傳送延遲資料至 Trace。這類要求包括在 App Engine 服務之間往返的 RPC 呼叫延遲資料。Trace 支援 Cloud SQL 以外的所有 App Engine Admin API。

  • Cloud Run functions 和 Cloud Run

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

用來擷取追蹤記錄資料的 API

您可以使用 Telemetry API 或 Cloud Trace API,將追蹤資料傳送至專案。建議使用 Telemetry API 的原因如下:

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

  • 追蹤資料的儲存格式通常與 OpenTelemetry 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,請建立機構政策限制

Cloud Trace 和代理程式應用程式

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

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

如要瞭解哪些遠端 Google Cloud MCP 伺服器支援追蹤記錄產生功能,以及如何設定應用程式,指示這些伺服器建立時距,請參閱「使用 Trace 檢查 MCP 呼叫」。

如何檢測應用程式

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

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

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

  • 如要瞭解哪些遠端 Google Cloud MCP 伺服器支援追蹤記錄產生功能,以及如何設定應用程式,指示這些伺服器建立時距,請參閱「使用 Trace 檢查 MCP 呼叫」。

您也可以使用 Cloud Trace 用戶端程式庫檢測應用程式。不過,我們建議使用 OpenTelemetry。 OpenTelemetry 程式庫比 Trace 用戶端程式庫更簡單,而且會以 OpenTelemetry 定義的 OTLP 格式匯出追蹤記錄資料,因此建議使用 OpenTelemetry 程式庫。詳情請參閱「Cloud Trace 用戶端程式庫」。

元件

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

追蹤用戶端

如果您使用的程式設計語言有適用的 OpenTelemetry 程式庫,即可使用 OpenTelemetry 簡化建立及傳送追蹤記錄資料的流程。OpenTelemetry 不僅更容易使用,還會實作批次處理,因此效能可能會有所提升。

如果沒有 OpenTelemetry 程式庫,請匯入 Trace SDK 程式庫並使用 Cloud Trace API,檢測您的程式碼。Cloud Trace API 會將追蹤資料傳送至您的 Google Cloud 專案。

追蹤介面

您可以在 Trace 介面中近乎即時地查看及分析追蹤記錄資料。

如要查看及分析時距資料,請使用Google Cloud 控制台中的「Trace 探索工具」和「可觀測性分析」頁面:

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

  • 可觀測性分析:您可以在這個頁面執行查詢,使用 SQL 匯總分析 span。SQL 查詢也可以彙整追蹤和記錄資料。您可以透過表格或圖表查看查詢結果。建立連結的資料集後,您可以使用 BigQuery 分析 span。詳情請參閱「查詢及分析追蹤記錄」。

VPC Service Controls 支援

Trace 是支援 VPC Service Controls 的服務。追蹤記錄服務名稱為 cloudtrace.googleapis.com。您為 Trace 服務建立的任何 VPC Service Controls 限制,只會套用至該服務。這些限制不適用於任何其他服務,包括 telemetry.googleapis.com 服務等,這些服務也可以擷取追蹤資料。

如要瞭解詳情,請參考下列資源:

Cloud Trace 和資料落地

如果您因為有資料落地或影響層級 4 (IL4) 的需求而使用 Assured Workloads,請勿使用 Cloud Trace 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,請建立機構政策限制

定價

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

後續步驟