# GCP 學習 - Pub/Sub Subscription 故障排除介紹

關於這一篇文章是我在操作Google clud platform 的 Pub/Sub 問題排查 紀錄，參考的是官方的說明文件

# 常規問題排查

如果您在使用Pub/Sub 時遇到問題，請查閱以下實用的問題排查步驟。

## 無法創建主題

確認您擁有必要的權限。如需建立Pub/Sub 主題，您需要擁有專案的Pub/Sub Editor ( roles/pubsub.editor) IAM 角色。如果您沒有此角色，請與您的管理員聯絡。如需詳細了解有關主題的問題排查信息，請參閱[問題排查主題](https://cloud.google.com/pubsub/docs/topic-troubleshooting?hl=zh-cn)和[導入主題問題排查](https://cloud.google.com/pubsub/docs/import-topic-troubleshooting?hl=zh-cn)。

## 無法建立訂閱

檢查您是否已完成以下操作：

* 確認您擁有必要的權限。如需建立Pub/Sub 訂閱，您需要專案的Pub/Sub Editor (roles/pubsub.editor) IAM 角色。如果您沒有此角色，請與您的管理員聯絡。

* 指定訂閱的名稱。

* 指定要將訂閱附加到的現有主題的名稱。

若要建立推送訂閱，請在pushEndpoint欄位中將https://（而不是http://或HTTPS://）指定為接收網址的協定。

如需詳細了解訂閱問題排查，請參[閱排查拉取訂閱問題、排查推播訂閱問題、追蹤BigQuery 訂閱問題](https://cloud.google.com/pubsub/docs/pull-troubleshooting?hl=zh-cn)和[排查Cloud Storage 訂閱問題](https://cloud.google.com/docs/cloudstorage-troubleshooting?hl=zh-cn)。

## 403 (Forbidden)個錯誤

如果遇到此錯誤，請執行以下操作：

* 確保您已在Google Cloud 控制台中啟用了Pub/Sub API。
* 確保發出請求的主帳號對相關Pub/Sub API 資源具有所需權限，尤其是當您使用Pub/Sub API 進行跨專案通訊時。
* 如果您使用的是Dataflow，請確保{PROJECT_NUMBER}@cloudservices.gserviceaccount.com和Compute Engine 服務帳號{PROJECT_NUMBER}[e-mail]均具有相關Pub/Sub API 資源的所需權限。如需了解詳情，請參閱[Dataflow 安全性和權限](https://cloud.google.com/dataflow/docs/concepts/security-and-permissions?hl=zh-cn#permissions)。
* 如果您使用的是App Engine，請檢查專案的「權限」頁面，查看App Engine 服務帳號是否被列為編輯者。如果不是，請將您的App Engine 服務帳號新增為編輯者。通常情況下，App Engine 服務帳號的格式為`<project-id>@appspot.gserviceaccount.com`。

## 使用過多的管理操作

如果您發現佔用了過多的管理操作配額，則可能需要重構程式碼。例如，請考慮以下偽代碼。在此範例中，管理操作( GET) 用於在嘗試使用其資源之前檢查是否有訂閱。GET和CREATE都是管理操作：

if !GetSubscription my-sub {
  CreateSubscription my-sub
}
Consume from subscription my-sub

更有效率的模式是嘗試使用訂閱的訊息（假設您可以合理地確定訂閱的名稱）。在這種樂觀方法中，只有在發生錯誤時，您才能取得或建立訂閱。請參考下面的範例：

try {
  Consume from subscription my-sub
} catch NotFoundError {
  CreateSubscription my-sub
  Consume from subscription my-sub
}

# 對標準主題進行問題排查

本文檔提供了將訊息發佈到標準Pub/Sub 主題時的一些常見問題排查提示。

詳細了解如何向主題發布訊息及各種功能。

## 發布延遲時間較長
發布延遲時間是指完成發布商用戶端所發出的發布請求所需的時間。發佈延遲時間與端對端傳送延遲時間不同，端對端傳送延遲時間是指發佈到Pub/Sub 的訊息傳送至訂閱者用戶端所花費的時間。您可能會發現發布延遲或端對端延遲較高，即使其他延遲類型的值較低也是如此。 Pub/Sub 發布者用戶端、客戶端和Pub/Sub 後端之間的傳輸或Pub/Sub 後端可能會出現較長的發布延遲。您可以使用`topic/send_request_latencies`指標來檢查Pub/Sub 後端中產生的發布延遲時間。後端發布延遲時間較長可能與以下因素有關：

* Pub/Sub 專為低延遲、高吞吐量的傳送而設計。如果主題的吞吐量較低，則與該主題關聯的資源可能需要更長時間進行初始化。

* 如果您使用了訊息儲存政策，則可能會影響發送到主題和訂閱的請求的整體延遲時間。查看使用此配置時[效能和可用性的影響](https://cloud.google.com/pubsub/docs/resource-location-restriction?hl=zh-cn#performance_and_availability_implications)。

如果您的發布商用戶端觀察到的發布延遲時間明顯長於指標中反映的延遲時間，這可能表示存在以下用戶端因素：

* 確保您沒有為每個發佈內容建立新的發布者。建議為每個應用程式的每個主題使用一個發布者用戶端來發布所有訊息。啟動新的發布者物件和新增執行緒會產生延遲成本。如果您使用Cloud Functions 發布訊息，請注意，呼叫也可能會影響發布延遲時間。

* 如果您發現預設的重試設定不足以滿足您的用例，請進行相應的調整。但是，請確認新值不會過高。了解如何配置[重試請求](https://cloud.google.com/pubsub/docs/retry-requests?hl=zh-cn)。

請注意，較長的發布延遲時間可能會導致`DEADLINE_EXCEEDED`錯誤，下一部分將對此進行討論。

## 發布操作失敗並顯示DEADLINE _ EXCEEDED

發布請求期間出現DEADLINE_EXCEEDED錯誤表示請求未能在分配的時間內完成。這可能是由於各種因素造成的，例如請求未到達Pub/Sub 服務或影響請求的效能問題。

如需驗證發布要求是否到達Pub/Sub 服務，請使用topic/send_request_count指標（按response_code分組）監控主題。此指標可協助您確定請求在到達Pub/Sub 主題之前是否失敗。如果指標為空，則表示存在外部因素阻止訊息到達Pub/Sub 服務。此外，為了排除間歇性問題的可能性，請檢查錯誤率。如果錯誤率非常低，這可能是間歇性問題。

如果請求到達Pub/Sub，則可能是以下一些原因導致發布操作失敗並出現DEADLINE_EXCEEDED錯誤：

## 客戶端瓶頸

發布失敗可能是由客戶端瓶頸導致的，例如記憶體不足、CPU 壓力、線程運行狀況不佳或託管發布商用戶端的虛擬機器中出現網路擁塞。如果Publish呼叫返回DEADLINE_EXCEEDED，可能是因為非同步Publish呼叫排隊速度要快於將其發送到服務的速度，這會逐漸增加請求延遲時間。此外，請檢查下列方法是否有助於確定係統中可能存在的瓶頸：

* 檢查發布訊息的速度是否快於客戶端發送訊息的速度。通常，每個非同步Publish呼叫都會傳回一個Future物件。如需追蹤等待傳送的訊息數，請儲存要透過每次Publish呼叫傳送的訊息數，並且僅在Future物件的回呼中將其刪除。

* 確保在發布商運行的機器與Google Cloud 之間有足夠的上傳頻寬。開發Wi-Fi 網路的頻寬通常為1-10MB/秒，或每秒1000-10000 個典型的訊息。如果在沒有速率限制的情況下循環發布訊息，可能會在短時間內產生短時間的高頻寬突發。為避免這種情況，您可以在Google Cloud 內的機器上執行發布者，或降低發布訊息的速率，使其與您的可用頻寬保持一致。

* 基於任何原因（例如啟動網路擁塞或防火牆）檢查主機和Google Cloud 之間的延遲時間是否非常高。[計算網路吞吐量](https://github.com/GoogleCloudPlatform/community/blob/master/archived/network-throughput.md)提供了有關如何找出不同場景下的頻寬和延遲時間的提示。

* 歸根究底，一個機器能發布的數據量有限。您可能需要嘗試橫向擴縮或在多台電腦上執行發布者用戶端的多個執行個體。[測試Cloud Pub/Sub 用戶端以最大限度地提高串流處理效能](https://cloud.google.com/blog/products/data-analytics/testing-cloud-pubsub-clients-to-maximize-streaming-performance?hl=zh-cn)示範了Pub/Sub 如何在單一Google Cloud 虛擬機器上隨著CPU 數量的增加而擴充。例如，您可以在16 核心Compute Engine 實例上為1 KB 訊息實作500 MB/秒到700 MB/秒的吞吐量。

## 發布超時時長不足

如需降低發布呼叫的逾時率，請務必在發布商用戶端的重試設定中指定足夠長的逾時。對於重試設置，將初始截止時間設定為10 秒，將總逾時設定為600 秒。即使您沒有累積大量未發送的訊息，也可能會導致發布呼叫逾時。但是，如果您的問題是由持續性瓶頸而不是偶爾超時導致的，則重試更多次可能會導致更多錯誤。

## 架構問題

如果您的發佈內容開始返回INVALID_ARGUMENT，則可能是有人更新了主題以更改關聯的架構、刪除了架構或刪除了與主題關聯的架構修訂版本。在這種情況下，請將主題的架構設定更新為與所發佈訊息相符的架構和修訂版本集，或調整訊息格式以符合目前架構。

## 郵件加密問題

如果您已將Pub/Sub 主題設定為使用客戶管理的加密金鑰來加密發佈的訊息，則發布可能會失敗並出現FAILED_PRECONDITION錯誤。如果Cloud KMS 金鑰已停用，或無法再透過Cloud EKM 存取外部管理的金鑰，則可能會發生此錯誤。若要繼續發布，請恢復對金鑰的存取權限。

# 導入主題問題排查
本文檔提供了一些有關Pub/Sub 導入主題的常見問題排查提示。

配置匯入主題並開始擷取訊息後，您可以檢查相關的Cloud Monitoring 指標，確認是否已擷取資料。執行以下步驟：

1. 在控制台中，前往主題頁面。

2. 點選要進行問題排查的導入主題。

3. 在主題詳情頁面中，點選指標標籤頁。

4. 在圖表中查看註入位元組數指標。

5. 如果未提取任何數據，請在主題詳情頁面中檢查主題狀態欄位是否有錯誤。

6. 您也可以查看注入資料來源狀態指標。 為此，請在主題詳情頁面中點擊指標標籤頁。

7. 下面列出了您可能會遇到的錯誤：

| 錯誤代碼 | 說明 | 修復 |
| -------- | -------- | -------- |
| KINESIS_PERMISSION_DENIED | 由於權限問題，使用Kinesis資料時發生錯誤。 | 驗證 AWS ARN 的準確性，並檢查 AWS 角色是否具有角色所需的 Kinesis 讀取權限。 |
| | |確認服務帳號存在，並且已按照使用自訂信任政策在 AWS 中建立角色中所述的步驟正確配置該帳號。 |
| | | 驗證 Pub/Sub服務帳號是否擁有權限。iam.serviceAccounts.getOpenIdToken |
| | | 驗證您是否已將服務帳號角色使用者新增至服務帳號。 |
| PUBLISH_PERMISSION_DENIED | 由於權限問題，發佈到主題時發生錯誤。 | 向Pub /Sub服務帳號爭取所需的發佈權限。 |
| STREAM_NOT_FOUND | 找不到指定的 Kinesis 資料流。 | 驗證資料流ARN是否準確。 |
| CONSUMER_NOT_FOUND | 缺少 Kinesis 使用方法。 | 驗證使用方ARN是否準確。 |

8.如果其中沒有任何錯誤，請查看保持運作狀況良好的發布者中的最佳實踐。

# 排查拉取訂閱問題

本文檔提供了有關 Pub/Sub 拉取訂閱的一些常見問題排查提示。

為了有效監控您的 Pub/Sub 訂閱，建議您先查看傳送延遲時間健康狀況得分( subscription/delivery_latency_health_score )，以檢查哪些因素可能會導致延遲時間出現意外或增加。

## 早期的未確認訊息的存在時長不斷增加
oldest_unacked_message_age是監控 Pub/Sub 訂閱運作狀況的關鍵指標。價值的資料洞見。

監控訊息積壓可確保及時、有效率地處理訊息。的問題的潛在問題。

以下是一些您可以調查的常見積壓問題：

## 客戶端配置問題
當oldest_unacked_message_age和num_undelivered_messages指標同時增加時，可能意味著訂閱者無法跟上訊息量。

* 客戶端健康狀況：分析託管訂閱者用戶端的機器上的資源利用率，例如CPU、記憶體和網路頻寬。

* 客戶端程式碼：查看最近的程式碼變更並檢查錯誤日誌。的同一行。

* 損耗限制：驗證您是否未超出託管服務所施加的任何 Pub/Sub損耗或限制。

## 訂閱者已否定訊息
當訂閱者否定訊息（NACK）時，它會向Pub/Sub 無法發出成功處理該訊息的訊號。導致郵件阻塞出現長時間延遲。

請注意，透過 NACK 並不能保證下一次拉取會另外提取的訊息。訊息的方法。​

如果您需要跳過某些訊息，建議的方法是確認這些訊息，即使您有意處理這些訊息。未確認，都會造成積壓問題並造成重複廢水。

## 傳送延遲時間
Pub/Sub 中的傳輸延遲時間是指從發布者的消息到達訂閱者所需的時間。

## 訂閱人數不足
對於使用StreamingPull 的用戶端，為了持續實現低延遲，請為訂閱維持多次開啟的StreamingPull 連接。 ，因此subscription/open_streaming_pulls您增加了延遲風險。

對於使用一元拉取的用戶端，為了持續實現低延遲，請訂閱維護多個待處理的拉取請求。程度地減少連接缺口並講述大量延遲時間。

如果您需要高吞吐量、低延遲，同時滿足減少營運開銷和處理成本，建議您使用進階客戶端程式庫。時間的更好選擇。

## 積壓高
請注意，Pub/Sub 訂閱中未確認的訊息積壓的訊息會顯著增加延遲延遲時間，因為訂閱者不會立即處理訊息。

## 訂購按鍵並僅傳送一次
排序鍵和「恰好一次」傳送是有價值的功能，但在 Pub/Sub 中需要額外的協調才能確保正確的傳送。但任何必要的協調步驟都可能會導致延遲時間暫時增加或錯誤率增加。

考慮訊息排序或訊息傳送一次對於應用是否必要。

## 郵件大小變大
訊息大小突然增加可能會增加Pub/Sub與客戶端之間的傳輸時間，並減少慢速客戶端中的訊息處理時間。

如果您發現延遲延遲時間增加，可以使用topic/message_sizes指標（按topic_id分組）查看郵件大小。

## 遺失的消息

如果您懷疑訊息未成功傳送給訂閱者，可能是以下某些原因導致的。

## 具有多種使用方的Pub/Sub訂閱中的消息分發
在 Pub/Sub 中，訊息可能會在使用方之間不均勻分配。缺少預期，或只接收部分訊息，而不是其他使用方。

請注意，對客戶端而言，訊息可能已經未完成，積壓的未確認訊息不一定表示您會在下一個拉取請求中收到這些訊息。 CLI 中的拉取功能，或在本機上執行自訂訂閱者來檢查訊息的人員。

對於一元拉取客戶端，您可能會觀察到一些拉取請求返回零訊息。可能缺少配置的最大訊息數，甚至為零訊息。

如果您懷疑有上述任何行為，請調查是否有多個使用方同時附加到訂閱並進行檢查。

## 點擊訂閱過濾
檢查訂閱是否附加了篩選條件。

## 使用returnImmediately選項
如果您的客戶端使用的是一元拉取，請檢查returnImmediately字段設定是否為true。出現積壓，這也會導致拉取請求回傳0 則訊息。

## 處理重複的乾燥機

subscription/expired_ack_deadlines_count如果訂閱者無法在確認時限內確認訊息，通常會出現 Pub/Sub 中的訊息重複情況。。​​

降低重複率，請延長訊息終止時間。

客戶端程式庫會自動處理期限延長，但是您可以設定期限延長期限有預設限制。
如果您要建立自己的客戶端程式庫，請使用modifyAckDeadline延長確認時限的方法。
如果從訂閱節目中拉取訊息的速度快於處理和確認訊息的速度，則某些訊息可能會過期並需要延長期限。情況下，這可能會導致訂閱者充滿內容，增強積壓。

為避免訂閱者應接不間歇，請減少訂閱者每次拉取的訊息數量。

停止減少訂閱者完成同時拉取的訊息數，您需要設定在訂閱者的串流控制中降低未訊息數上限設定。調整未完成訊息的數量上限。

## 強制重試
支援強制 Pub/Sub 重試訊息，請傳送請求nack。modifyAckDeadlineackDeadlineSeconds

## 排序鍵
當 Pub/Sub 重新提交帶有排序鍵的訊息時，它會使用同一排序鍵重新傳送所有後續訊息，即使這些訊息之前已確認也是如此。嚴格保證相關訊息只有在成功確認序列中的先前訊息後才會發送。

## 訂閱者：NACK 處理訊息
請參閱[訂閱者正在接收訊息](https://cloud.google.com/pubsub/docs/pull-troubleshooting?hl=zh-cn#subscriber_negatively_acknowledged_the_messages)。

## 排查 StreamingPull 訂閱問題
StreamingPull 流始終以不正常狀態關閉。但這種行為是設計上的。

由於 StreamingPull 流始終以錯誤關閉因此，在診斷錯誤時檢查資料流終止指標並沒有response_code幫助。response_classsubscription/streaming_pull_response_count

請尋找以下錯誤：

* 如果訂閱積壓有訊息使用已失效的雲端KMS金鑰加密，則可能會出現不符合前提條件的錯誤。

* 如果 Pub/Sub 無法處理請求，則可能會發生不可用的錯誤。

* 如果訂閱被刪除或最初不存在，則可能會出現「未找到」錯誤。如果您提供的訂閱路徑無效，就會出現後一種情況。

# 追蹤大眾訂閱問題

主動訂閱者是一種 Pub/Sub 訂閱者，其中訊息從 Pub/Sub 發送到使用者指定的 HTTPS 端點使用者。個別訂閱的一些常見問題排查。

為了有效監控您的 Pub/Sub 訂閱，建議您先查看傳送延遲時間健康狀況得分( subscription/delivery_latency_health_score)，以檢查哪些因素可能會導致意外延遲時間。

## 終點失敗或運作緩慢
如果端點傳回錯誤回應代碼，系統會認為訊息傳送失敗，並稍後重試。

您可以使用多個指標來主動監控訂閱。Pub/Sub 回傳錯誤。subscription/push_request_countresponse_coderesponse_classresponse_classack

* deadline_exceeded響應類別表示一個端點未在所需的確認（ack）時限內響應subscription/push_request_latencies。
* invalid回應類別表示端點發回的回應 Pub/Sub 無法正確理解或處理。
* remote_server_4xx回應類別通常表示驗證或權限問題。詳細了解身分驗證在主動訂閱中的工作原理。
* remote_server_5xx回應類別表示端點有伺服器端問題。
* unreachable回應類別表示完全無法存取端點伺服器。

詳細了解 Pub/Sub API 最常見的[錯誤代碼](https://cloud.google.com/pubsub/docs/reference/error-codes?hl=zh-cn)。

## 對VPC-SC邊界內部訂閱的限制
如果在專案中啟用了VPC 服務控制(VPC-SC) 保護，則建立自訂訂閱會受到限制。 ：Request is prohibited by organization's policy。run.app​

# 參考文件
[Pub/Sub > 常規問題排查 ](https://cloud.google.com/pubsub/docs/troubleshooting?hl=zh-cn)

# 結尾
以上就是設定Google Cloud Platform (GCP) 的 Pub/Sub 常規問題排查紀錄，GCP Pub/Sub是一個強大的消息傳遞服務，適用於各種異步通信和事件驅動架構場景，希望能幫助到你，如果有任何問題或需要進一步的幫助，歡迎在留言區提出。

###### tags: `更新上部落格`