標準主題疑難排解

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

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

發布延遲時間長

發布延遲時間是指發布商用戶端發出發布要求所需的時間。發布延遲與端對端傳送延遲不同，後者是指從發布至 Pub/Sub 的訊息傳送至訂閱端用戶端所需的時間。即使其他延遲類型的值偏低，您可能還是會觀察到高發布延遲或端對端延遲。在 Pub/Sub 發布端用戶端、用戶端和 Pub/Sub 後端之間傳輸，或在 Pub/Sub 後端，都可能會發生高發布延遲時間。您可以使用 topic/send_request_latencies 指標檢查 Pub/Sub 後端發生的發布延遲情形。後端發布延遲時間過長可能與下列因素有關：

  • Pub/Sub 的設計可提供低延遲、高處理量的傳送服務。如果主題的吞吐量偏低，與主題相關聯的資源可能需要較長的時間才能初始化。

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

如果發布商客戶端觀察到發布延遲時間明顯高於指標所顯示的時間，可能表示有下列其中一個用戶端因素：

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

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

請注意，高發布延遲可能會導致 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 壓力、不良的執行緒健康狀況，或是主機代管發布者用戶端的網路壅塞。如果 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 執行個體上，您可以達到 500 MBps 到 700 MBps 的 1 KB 訊息傳輸速度。

發布逾時時間不足

如要降低發布呼叫的逾時率，請務必在發布商用戶端的重試設定中定義足夠長的逾時時間。針對重試設定，將初始期限設為 10 秒，總逾時時間設為 600 秒。即使您沒有累積大量未傳送的訊息，偶爾出現的大量要求延遲情況，也可能導致發布呼叫逾時。不過，如果問題是因持續的瓶頸而非偶發的逾時而發生，重試次數越多，可能會導致更多錯誤。

用戶端程式庫問題

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

C++

用戶端程式庫問題追蹤器

C#

用戶端程式庫問題追蹤器

Go

用戶端程式庫問題追蹤器

Java

用戶端程式庫問題追蹤器

Node.js

用戶端程式庫問題追蹤器

PHP

用戶端程式庫問題追蹤器

Python

用戶端程式庫問題追蹤器

Ruby

用戶端程式庫問題追蹤器

結構定義問題

如果您的發布內容開始傳回 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 追蹤功能，協助您排解發布延遲問題。