標準主題疑難排解

本文提供一些常見的疑難排解訣竅，協助您將訊息發布至標準 Pub/Sub 主題。

進一步瞭解如何將訊息發布至主題，以及各種功能。

發布延遲時間長

發布延遲時間是指完成發布要求所需的時間，這類要求是由發布商用戶端發出。發布延遲時間與端對端傳送延遲時間不同，後者是指訊息發布至 Pub/Sub 後，傳送至訂閱端用戶端所需的時間。即使其他延遲類型的值偏低，您仍可能會發現發布延遲或端對端延遲偏高。Pub/Sub 發布端用戶端、用戶端與 Pub/Sub 後端之間的傳輸過程，或 Pub/Sub 後端都可能導致發布延遲時間過長。您可以使用 topic/send_request_latencies 指標，檢查 Pub/Sub 後端發布作業造成的延遲。後端發布延遲時間過長可能與下列因素有關：

  • Pub/Sub 專為低延遲、高處理量傳送作業而設計。如果主題的處理量較低，與主題相關聯的資源可能需要較長時間才能初始化。

  • 如果您使用訊息儲存政策，可能會影響主題和訂閱項目的整體要求延遲時間。請查看使用這項設定的成效和可用性影響。

如果發布商用戶端觀察到的發布延遲時間遠高於指標反映的值，可能是因為下列其中一個用戶端因素：

  • 請確認您並非在每次發布時都建立新的發布商。建議您為每個應用程式的每個主題使用單一發布商用戶端，發布所有訊息。啟動新的發布者物件和新增執行緒會產生延遲成本。如果您使用 Cloud Run functions 發布訊息，請注意，叫用作業也可能會影響發布延遲時間。

  • 如果預設重試設定無法滿足您的用途，請進行相應調整。但請確認新值不會過高。瞭解如何設定重試要求。

請注意，發布延遲時間過長可能會導致 DEADLINE_EXCEEDED 錯誤，我們將在下一節中討論這類錯誤。

發布作業失敗，並顯示 DEADLINE_EXCEEDED 錯誤

發布要求期間發生 DEADLINE_EXCEEDED 錯誤，表示要求未在指定時間內完成。這可能是因為要求未送達 Pub/Sub 服務，或是效能問題影響要求等各種因素所致。

如要確認發布要求是否已送達 Pub/Sub 服務，請使用 topic/send_request_count 指標監控主題，並依 response_code 分組。這項指標可協助您判斷要求是否在抵達 Pub/Sub 主題前失敗。如果指標為空白，表示有外部因素導致訊息無法傳送至 Pub/Sub 服務。此外，如要排除間歇性問題的可能性，請使用先前提及的 topic/send_request_count 指標圖表，或 Google Cloud 控制台的「API 和服務」頁面，檢查錯誤率。如果錯誤率很低，可能是間歇性問題。

如果要求已送達 Pub/Sub，但發布作業仍因 DEADLINE_EXCEEDED 錯誤而失敗，可能原因如下：

用戶端瓶頸

發布失敗可能是因為用戶端發生瓶頸，例如記憶體不足、CPU 壓力過大、執行緒狀況不佳，或是主機代管發布端用戶端的 VM 網路壅塞。如果 Publish 呼叫傳回 DEADLINE_EXCEEDED，可能是因為非同步 Publish 呼叫的排隊速度快於傳送至服務的速度，導致要求延遲時間逐漸增加。此外，請檢查下列項目，判斷系統中是否有任何可能造成瓶頸的因素：

  • 檢查您發布訊息的速度是否比用戶端傳送訊息的速度快。通常每個非同步 Publish 呼叫都會傳回 Future 物件。如要追蹤待傳送的訊息數量，請儲存每次 Publish 呼叫時要傳送的訊息數量，並僅在 Future 物件的回呼中刪除。

  • 確認發布商執行的電腦與 Google Cloud之間有足夠的上傳頻寬。開發 Wi-Fi 網路的頻寬通常為 1 到 10 MBps，或每秒 1000 到 10000 則訊息。如果以迴圈發布訊息，且未限制頻率，可能會在短時間範圍內造成高頻寬用量。為避免這種情況，您可以在 Google Cloud 的電腦上執行發布者，或降低訊息發布速率，以符合可用頻寬。

  • 檢查主機和 Google Cloud 之間是否出現極高的延遲，原因可能是啟動網路壅塞或防火牆等。計算網路輸送量一文提供相關指標，協助您瞭解不同情境下的頻寬和延遲時間。

  • 單一機器可發布的資料量最終會受到限制。您可能需要嘗試水平擴展，或在多部機器上執行多個發布端用戶端執行個體。測試 Cloud Pub/Sub 用戶端，盡量提升串流效能一文說明瞭 Pub/Sub 如何在單一 Google Cloud VM 上隨著 CPU 數量增加而擴充。舉例來說，在 16 核心的 Compute Engine 執行個體上，1 KB 訊息的傳輸量可達 500 MB/秒 至 700 MB/秒。

發布逾時時間不足

如要降低發布呼叫的逾時率，請確保在發布商用戶端的重試設定中，定義了足夠長的逾時時間。在重試設定中，將初始期限設為 10 秒，總逾時時間設為 600 秒。即使您未累積大量未傳送的訊息，要求延遲偶爾暴增仍可能導致發布呼叫逾時。不過，如果問題是由持續的瓶頸所致，而非偶爾逾時，多次重試可能會導致更多錯誤。

用戶端程式庫問題

您可能正在執行已知有問題的用戶端程式庫版本。以下列出所有用戶端程式庫的問題追蹤器。如果您發現使用的用戶端程式庫版本有已知問題，請升級至最新版本。確保您已取得所有相關更新，包括修正項目和效能提升。

結構定義問題

如果發布作業開始傳回 INVALID_ARGUMENT，可能是有人更新主題以變更相關聯的結構定義、刪除結構定義，或刪除與主題相關聯的結構定義修訂版本。在這種情況下，請將主題的結構定義設定更新為與發布訊息相符的結構定義和修訂版本，或調整訊息格式以符合目前的結構定義。

訊息加密問題

如果您已將 Pub/Sub 主題設為使用客戶自行管理的加密金鑰加密發布的訊息，發布作業可能會失敗並顯示 FAILED_PRECONDITION 錯誤。如果 Cloud KMS 金鑰已停用，或是透過 Cloud EKM 管理的外部金鑰無法再存取，就可能會發生這個錯誤。如要恢復發布，請還原金鑰存取權。

單一訊息轉換 (SMT) 問題

如果您已在 Pub/Sub 主題上設定 SMT，當轉換無法套用至訊息時，發布作業可能會失敗並出現 INVALID_ARGUMENT 錯誤。如果發布批次中的任何訊息轉換失敗，整個批次就會無法發布。傳回的錯誤會指出失敗原因，例如：

INVALID_ARGUMENT: Pub/Sub failed to apply a message transformation to one or
more messages in the publish request. Error: Failed to execute JavaScript UDF:
`my_function`. Return value is not an object.

監控 SMT

如要瞭解 SMT 對主題的成效和影響，請使用下列監控指標：

topic/message_transform_latencies 指標會測量 SMT 套用至訊息所需的時間。這項指標只會測量 SMT 延遲時間，不包含訊息傳送時間的其他部分。

這項指標提供兩個重要標籤：

  • status：回報轉換是否成功，或是否發生問題。

  • filtered：指出 SMT 是否導致訊息遭到篩除。如果 SMT 篩選出主題上的訊息，Pub/Sub 會捨棄該訊息，且絕不會傳送給訂閱者。只有在 SMT 執行篩選時，這個 filtered 標籤才會為 true。使用 Pub/Sub 的內建篩選功能篩選的訊息，不會反映在這個特定指標中。

topic/byte_cost 指標可用於識別遭 SMT 篩除或 SMT 失敗的訊息。請找出下列特定值：

  • 當 SMT 篩選郵件時，operation_type 為 smt_publish_filter_drop。

  • 如果 SMT 無法轉換訊息，您會看到 response_code，而不是 OK。

後續步驟

探索 OpenTelemetry 追蹤，協助您排解發布延遲問題。