如果您使用 Pub/Sub 指標做為自動調度管道的信號，請參考下列建議。
使用多個信號自動調度管道
請勿只使用 Pub/Sub 指標自動調整管道資源配置。這可能會導致自動調整規模決策出現單點故障。請改用信號組合來觸發自動調度。例如，用戶端的 CPU 使用率就是額外信號。這項信號可指出用戶端工作是否正在處理工作，以及擴大用戶端工作是否能處理更多工作。以下列舉幾個可供管道使用的其他 Cloud 產品信號：
Compute Engine 支援根據 CPU 使用率和 Monitoring 指標等信號自動調度資源。Compute Engine 也支援多項指標和訊號，可提升可靠性。
如要進一步瞭解如何使用 Monitoring 指標調度資源，請參閱「根據 Monitoring 指標調度資源」。如要進一步瞭解如何根據 CPU 使用率調度資源，請參閱根據 CPU 使用率調度資源。
Google Kubernetes Engine 水平 Pod 自動調度資源 (HPA) 支援依據資源用量 (例如 CPU 和記憶體用量)、自訂 Kubernetes 指標，以及外部指標 (例如 Pub/Sub 的監控指標) 自動調度資源。並支援多種信號。
詳情請參閱「水平 Pod 自動調度資源」。
請改用區域版本的指標，而非全球版本
Pub/Sub 提供兩種版本的指標，通常會搭配自動調度功能使用。請務必使用含有 by_region 後置字元的版本：
如果您希望自動調度資源功能在單一區域發生中斷時仍能正常運作，請勿使用這些指標的全域版本。如要取得這些指標的全球版本，必須計算所有已知有訊息的區域的待處理項目，這表示單一區域的服務中斷會導致資料缺漏。相較之下，by_region 版本的指標會計算並回報每個區域的待處理項目。如果無法計算單一區域的待處理工作，指標仍會回報其他區域的值。
避免使用訂閱端輸送量指標自動調整訂閱端規模
請避免使用訂閱端輸送量指標 (例如 subscription/ack_message_count) 自動調整訂閱端用戶端的規模，請改用直接反映待處理訊息積壓量的指標，例如前述的 subscription/num_unacked_messages 或 subscription/oldest_unacked_message_age。
使用訂閱端輸送量指標進行自動調度時發生問題
使用這些指標可能會導致問題，因為這些指標代表 Pub/Sub 與訂閱者之間的流量。根據這類指標進行調整，可能會造成自我參照迴圈，導致傳送或確認的訊息減少，進而縮減用戶端。舉例來說，如果流量暫時下滑，或是其中一位訂閱者發生問題，就可能出現這種情況。
如果用戶端縮減至零或接近零，所有進行中的訂閱流量可能會停止，即使有新訊息送達，訂閱者也可能無法處理訊息。這可能會導致大量擷取延遲，並使訂閱端用戶端進入無法復原的狀態。
處理指標缺漏問題
請勿假設沒有指標就代表沒有訊息要處理。舉例來說，如果為了因應指標遺失而將處理工作縮減為零，則可能無法取用已積壓或在這段期間發布的訊息。這會增加端對端延遲時間。 為盡量縮短延遲時間，請將最小工作數設為大於零的值，這樣即使最近的 Pub/Sub 指標顯示佇列為空，您也隨時可以處理發布的訊息。
Compute Engine 自動調度器和 Google Kubernetes Engine HPA 的設計目的，都是在指標無法使用時維持目前的副本數量。如果沒有任何指標可用，這項功能可提供安全網。
您也可以實作 Pub/Sub 流量控制機制，避免工作因缺少指標而意外縮減規模，導致工作量過大。