標準主題疑難排解

本文提供一些常見的疑難排解提示，協助您將訊息發布至標準 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 壓力過大、執行緒狀況不佳，或是主機 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 MBps 至 700 MBps。

發布逾時時間不足

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

用戶端程式庫問題

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

C++

用戶端程式庫 Issue Tracker

C#

用戶端程式庫 Issue Tracker

Go

用戶端程式庫 Issue Tracker

Java

用戶端程式庫 Issue Tracker

Node.js

用戶端程式庫 Issue Tracker

PHP

用戶端程式庫 Issue Tracker

Python

用戶端程式庫 Issue Tracker

小茹

用戶端程式庫 Issue Tracker

結構定義問題

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

訊息加密問題

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

訊息儲存政策問題

如果訂閱項目未收到發布的訊息，可能是因為主題已啟用訊息儲存政策。 如果發生這種情況，發布指標可能會顯示 FAILED_PRECONDITION 錯誤。

這類錯誤通常會包含下列訊息：

Cannot publish messages that contain ordering keys
to topic projects/...  due a message storage policy on the topic that would
require the messages to be forwarded to another region. Please either change
the topic's message storage policy or publish to an allowed region using
the appropriate regional Cloud Pub/Sub endpoint.

或

The topic's message storage policy requires enforcement
in transit, but the Publish request was received by a Pub/Sub server in
a non-allowed region. Please either publish via a regional Pub/Sub endpoint
corresponding to an allowed region, or update the topic's message storage policy.

如要解決這個問題，請採取下列任一做法：

• 更新主題的訊息儲存政策，允許使用該區域。
• 使用適當的區域性 Pub/Sub 端點，設定發布端將訊息發布至允許的區域。

單一訊息轉換 (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 追蹤，協助您偵錯發布延遲。