Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

在 Cloud Monitoring 中監控 Pub/Sub

您可以使用 Google Cloud 控制台或 Cloud Monitoring API 監控 Pub/Sub。

本文說明如何使用 Monitoring，在 Google Cloud 控制台中監控 Pub/Sub 使用情形。

如要查看其他 Google Cloud 資源的指標 (除了 Pub/Sub 指標)，請使用 Monitoring。
否則，您可以使用 Pub/Sub 提供的監控資訊主頁。請參閱「監控主題」和「監控訂閱項目」。

如需在自動調度資源時使用指標的最佳做法，請參閱將 Pub/Sub 指標做為調度信號的最佳做法。

事前準備

使用監控功能前，請先準備下列項目：

Cloud Billing 帳戶
已啟用計費功能的 Pub/Sub 專案

如要確保已取得這兩項資訊，請完成「快速入門導覽課程：使用 Cloud 控制台」。

查看現有資訊主頁

您可以在同一個環境中，查看及分析不同來源的資料。Google Cloud 提供預先定義和自訂的資訊主頁。舉例來說，您可以查看預先定義的 Pub/Sub 資訊主頁，也可以建立自訂資訊主頁，顯示與 Pub/Sub 相關的指標資料、快訊政策和記錄項目。

如要使用 Cloud Monitoring 監控 Pub/Sub 專案，請按照下列步驟操作：

前往 Google Cloud 控制台的「Monitoring」頁面。

前往「Monitoring」
如果尚未在頁面頂端選取專案名稱，請立即選取。
按一下導覽選單中的「資訊主頁」。
在「資訊主頁總覽」頁面中，建立新的資訊主頁，或選取現有的「Pub/Sub」資訊主頁。

如要搜尋現有的 Pub/Sub 資訊主頁，請在「所有資訊主頁」的篩選條件中選取「名稱」屬性，然後輸入 Pub/Sub。

如要進一步瞭解如何建立、編輯及管理自訂資訊主頁，請參閱「管理自訂資訊主頁」。

查看單一 Pub/Sub 指標

如要使用 Google Cloud 控制台查看單一 Pub/Sub 指標，請按照下列步驟操作：

前往 Google Cloud 控制台的「Monitoring」頁面。

前往「Monitoring」
在導覽窗格中，選取「Metrics Explorer」。
在「設定」部分，按一下「選取指標」。
在篩選器中輸入 Pub/Sub。
在「Active resources」(有效資源) 中，選取「Pub/Sub Subscription」(Pub/Sub 訂閱項目) 或「Pub/Sub Topic」(Pub/Sub 主題)。
深入瞭解特定指標，然後按一下「套用」。

系統會開啟特定指標的頁面。

如要進一步瞭解監控資訊主頁，請參閱 Cloud Monitoring 說明文件。

查看 Pub/Sub 指標和資源類型

如要查看 Pub/Sub 向 Cloud Monitoring 回報的指標，請參閱 Cloud Monitoring 說明文件中的 Pub/Sub 指標清單。
如要查看 pubsub_topic、pubsub_subscription 或 pubsub_snapshot 受監控資源類型的詳細資料，請參閱 Cloud Monitoring 說明文件中的「受監控資源類型」。

存取 PromQL 編輯器

Metrics Explorer是 Cloud Monitoring 內建的介面，可探索及以視覺化方式呈現指標資料。在Metrics Explorer中，您可以使用 Prometheus 查詢語言 (PromQL) 查詢及分析 Pub/Sub 指標。

如要在Metrics Explorer中存取程式碼編輯器，並使用 PromQL 查詢 Cloud Monitoring 指標，請參閱「使用程式碼編輯器進行 PromQL 查詢」。

舉例來說，您可以輸入 PromQL 查詢，監控在過去 1 小時內傳送至特定訂閱項目的訊息數量：

sum(
  increase({
    "__name__"="pubsub.googleapis.com/subscription/sent_message_count",
    "monitored_resource"="pubsub_subscription",
    "project_id"="your-project-id",
    "subscription_id"="your-subscription-id"
  }[1h])
)

監控配額用量

針對特定專案，您可以使用 IAM 與管理員配額資訊主頁，查看目前的配額和用量。

您可以使用下列指標查看歷來配額用量：

這些指標會使用受監控的consumer_quota資源類型。如要查看更多配額相關指標，請參閱「指標清單」。

舉例來說，下列 PromQL 查詢會建立圖表，顯示每個區域使用的發布商配額比例：

sum by (quota_metric, location) (
  rate({
    "__name__"="serviceruntime.googleapis.com/quota/rate/net_usage",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com",
    "quota_metric"="pubsub.googleapis.com/regionalpublisher"
  }[${__interval}])
)
/
(max by (quota_metric, location) (
  max_over_time({
    "__name__"="serviceruntime.googleapis.com/quota/limit",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com",
    "quota_metric"="pubsub.googleapis.com/regionalpublisher"
  }[${__interval}])
) / 60 )

如果預期用量會超過預設配額限制，請為所有相關配額建立快訊政策。當用量達到限制的某個比例時，系統就會觸發這些快訊。舉例來說，如果任何 Pub/Sub 配額的使用量超過 80%，下列 PromQL 查詢就會觸發警告政策：

sum by (quota_metric, location) (
  increase({
    "__name__"="serviceruntime.googleapis.com/quota/rate/net_usage",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com"
  }[1m])
)
/
max by (quota_metric, location) (
   max_over_time({
    "__name__"="serviceruntime.googleapis.com/quota/limit",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com"
  }[1m])
)
> 0.8

如要進一步自訂配額指標的監控和快訊功能，請參閱「使用配額指標」。

如要進一步瞭解配額，請參閱「配額與限制」。

維持有效的訂閱方案

如要維持正常的訂閱狀態，可以使用 Pub/Sub 提供的指標監控多項訂閱屬性。舉例來說，您可以監控未確認訊息的數量、訊息確認期限到期時間等。您也可以檢查訂閱項目是否正常運作，確保訊息傳送延遲時間較短。

如要進一步瞭解特定指標，請參閱下文。

監控待處理訊息

如要確保訂閱者能跟上訊息的流動，請建立資訊主頁。資訊主頁會顯示下列積壓工作指標，並依資源匯總所有訂閱項目：

未確認的訊息 (subscription/num_unacked_messages_by_region)：查看未確認的訊息數量。
最舊的未確認訊息存在時間 (subscription/oldest_unacked_message_age_by_region)：查看訂閱項目待處理事項中最舊的未確認訊息存在時間。
傳遞延遲時間健康狀態分數 (subscription/delivery_latency_health_score)：用來檢查訂閱項目的整體健康狀態，與傳遞延遲時間相關。如要進一步瞭解這項指標，請參閱本文的相關章節。

建立快訊政策，在這些值超出系統可接受的範圍時觸發。舉例來說，未確認訊息的絕對數量不一定有意義。如果訂閱項目每秒可處理一百萬則訊息，一百萬則訊息的待處理量或許可以接受，但如果訂閱項目每秒只能處理一則訊息，一百萬則訊息的待處理量就無法接受。

請改用區域版本的指標，而非全球版本

Pub/Sub 提供區域和全域版本的指標，可用於監控訂閱項目待處理事項。請務必使用帶有 by_region 後置字元的區域版本：

如果您希望監控資訊主頁和快訊政策在單一區域發生中斷時仍能正常運作，請勿使用這些指標的全球版本。如要取得這些指標的全球版本，必須計算所有已知有訊息的區域的待處理項目，這表示單一區域的服務中斷會導致資料缺漏。相較之下，指標的 by_region 版本會計算並回報各區域的積壓工作。如果無法計算單一區域的待處理工作，指標仍會回報其他區域的值。

常見的待處理事項問題

問題	問題	解決方案
`oldest_unacked_message_age_by_region` 和 `num_unacked_messages_by_region` 兩者同步成長。	訂閱者無法跟上訊息量	新增更多訂閱者執行緒或程序。新增更多訂閱端機器或容器。檢查程式碼是否有錯誤，導致程式碼無法順利確認或及時處理訊息。請參閱「監控確認期限到期時間」。
如果待處理項目數量穩定且偏少，但 `oldest_unacked_message_age_by_region` 持續增加，可能會有幾則訊息無法處理。	無法傳送的訊息	檢查應用程式記錄，瞭解是否有某些訊息導致程式碼異常終止。違規訊息不太可能卡在 Pub/Sub 中，而不是在用戶端中，但仍有這種可能性。確認程式碼能順利處理每封郵件後，請提出支援案件。如果某些訊息導致程式碼當機，請考慮將這些訊息轉送至dead-letter 主題。
`oldest_unacked_message_age_by_region`超過訂閱訊息保留時間。	永久遺失資料	設定警告，在訊息保留時間到期前觸發。

監控傳遞延遲時間健康狀態

在 Pub/Sub 中，傳送延遲時間是指發布的訊息傳送至訂閱端所需的時間。如果訊息積壓量增加，可以使用「傳送延遲健康狀態分數」 (subscription/delivery_latency_health_score) 檢查導致延遲增加的因素。

這項指標會衡量單一訂閱項目在 10 分鐘滾動週期內的健康狀態。這項指標可深入瞭解下列條件，訂閱項目必須符合這些條件，才能持續維持低延遲：

可忽略的搜尋要求。
可忽略的負面確認訊息 (nacked)。
過期訊息確認期限可忽略不計。
確認延遲時間一律少於 30 秒。
使用率持續偏低，表示訂閱項目有足夠容量處理新訊息。

「傳遞延遲時間健康狀態分數」指標會針對每個指定條件回報 0 或 1 分。1 分代表健康狀態良好，0 分則代表健康狀態不良。

搜尋要求：如果訂閱項目在過去 10 分鐘內有任何搜尋要求，分數會設為 0。搜尋訂閱項目可能會導致舊訊息在首次發布後很久才重新播放，進而增加傳送延遲時間。
負向確認 (nack) 訊息：如果訂閱項目在過去 10 分鐘內有任何負向確認 (nack) 要求，分數會設為 0。如果收到負面確認，系統會重新傳送訊息，但傳送延遲時間會增加。
過期的確認期限：如果訂閱項目在過去 10 分鐘內有任何過期的確認期限，分數會設為 0。如果訊息超過確認期限，系統會重新傳送訊息，但傳送延遲時間會增加。
確認延遲：如果過去 10 分鐘內，所有確認延遲的第 99.9 個百分位數曾大於 30 秒，分數就會設為 0。如果確認延遲時間較長，表示訂閱端用戶端處理訊息的時間異常長。這個分數可能代表訂閱端有錯誤或資源限制。
使用率偏低：系統會根據各訂閱類型，以不同方式計算使用率。
- StreamingPull：如果開啟的串流不足，分數會設為 0。開啟更多串流，確保有足夠容量處理新訊息。
- 發送：如果發送端有太多待處理訊息，分數會設為 0。為推送端點增加容量，以便接收新訊息。
- 提取：如果未處理的提取要求不足，分數會設為 0。開啟更多並行提取要求，確保您已準備好接收新訊息。

如要查看指標，請在「指標探索器」中，選取 Pub/Sub 訂閱資源類型的「傳送延遲健康狀態分數」指標。新增篩選條件，一次只選取一個訂閱項目。選取「堆疊面積圖」，然後指向特定時間，即可查看該時間點的訂閱項目條件分數。

下圖是使用堆疊面積圖繪製的一小時指標圖表。凌晨 4 點 15 分，綜合健康狀態分數達到 5 分，各項標準的分數均為 1 分。稍後，當使用率分數降至 0 時，綜合分數會在凌晨 4 點 20 分降至 4 分。

傳遞延遲時間指標的螢幕截圖

PromQL 提供文字型運算介面，可用來取得 Cloud Monitoring 時間序列資料。下列 PromQL 查詢會建立圖表，用來評估訂閱項目的傳遞延遲時間健康狀態分數。

sum_over_time(
  {
    "__name__"="pubsub.googleapis.com/subscription/delivery_latency_health_score",
    "monitored_resource"="pubsub_subscription",
    "subscription_id"="$SUBSCRIPTION"
  }[${__interval}]
)

監控確認期限

為減少訊息傳送延遲時間，Pub/Sub 允許訂閱端用戶端在有限時間內確認 (ack) 特定訊息。這段時間範圍稱為「確認期限」。如果訂閱者太久未確認訊息，系統會重新傳送訊息，導致訂閱者收到重複訊息。重新遞送的原因有很多：

訂閱者資源不足 (需要更多執行緒或機器)。
每則訊息的處理時間都比訊息確認期限長。Cloud 用戶端程式庫通常會將個別訊息的期限延長至可設定的上限。不過，圖書館也適用最長延期期限。
某些訊息會導致用戶端持續當機。

您可以評估訂閱者錯過確認期限的頻率。具體指標取決於訂閱類型：

Pull 和 StreamingPull： subscription/expired_ack_deadlines_count
推送： subscription/push_request_count 篩選依據：response_code != "success"

如果確認期限過期率過高，可能會導致系統效率不彰，造成高昂的成本。您必須支付每次重新傳送的費用，以及重複處理每則訊息的費用。反之，如果過期率很低 (例如 0.1% 至 1%)，可能代表健康狀態良好。

監控訊息輸送量

Pull 和 StreamingPull 訂閱者可能會在每個提取回應中收到批次訊息；推送訂閱者則會在每個推送要求中收到單一訊息。您可以透過下列指標，監控訂閱端處理的批次訊息處理量：

提取： subscription/pull_request_count (請注意，這項指標也可能包含傳回時沒有訊息的提取要求)
StreamingPull： subscription/streaming_pull_response_count

您可以監控訂閱端處理的個別或未批次處理訊息處理量，方法是使用依 delivery_type 標籤篩選的指標 subscription/sent_message_count。

下列 PromQL 查詢會提供時間序列圖表，顯示在 10 分鐘的滾動期間內，傳送至特定 Pub/Sub 訂閱項目的訊息總數。將 $PROJECT_NAME 和 $SUBSCRIPTION_NAME 的預留位置值替換為實際專案和主題 ID。

sum(
  increase({
    "__name__"="pubsub.googleapis.com/subscription/sent_message_count",
    "monitored_resource"="pubsub_subscription",
    "project_id"="$PROJECT_NAME",
    "subscription_id"="$SUBSCRIPTION_NAME"
  }[10m])
)

監控推送訂閱項目

如果是推送訂閱，請監控下列指標：

subscription/push_request_count

依據 response_code 和 subscription_id 將指標分組。由於 Pub/Sub 推送訂閱項目會使用回應代碼做為隱含的訊息確認，因此監控推送要求回應代碼非常重要。由於推送訂閱項目遇到逾時或錯誤時，會以指數方式退避，因此待處理項目可能會根據端點的回應方式快速增加。

建議您針對高錯誤率設定快訊，因為這類錯誤率會導致遞送速度緩慢，並造成待處理事項不斷增加。您可以建立依回應類別篩選的指標。不過，推送要求計數可能更有用，可做為調查待處理工作量大小和時間的工具。
subscription/num_outstanding_messages

Pub/Sub 通常會限制未處理訊息的數量。在大多數情況下，待處理訊息應少於 1,000 則。當處理量達到每秒 10,000 封郵件的速率時，服務會調整未處理郵件數量的限制。這項限制是以 1,000 為單位遞增。除了最大值以外，我們不會提供任何具體保證，因此 1,000 則未處理的訊息是很好的參考指標。
subscription/push_request_latencies

這項指標有助於瞭解推送端點的回覆延遲分配情形。由於待處理訊息數量有限，端點延遲會影響訂閱輸送量。如果處理每則訊息需要 100 毫秒，則處理量上限可能為每秒 10 則訊息。

如要提高未處理訊息上限，推播訂閱者必須確認超過 99% 的訊息。

您可以使用 PromQL 計算訂閱者確認訊息的分數。下列 PromQL 查詢會建立圖表，顯示訂閱項目中訂閱者確認訊息的比例：

rate({
  "__name__"="pubsub.googleapis.com/subscription/push_request_count",
  "monitored_resource"="pubsub_subscription",
  "subscription_id"="$SUBSCRIPTION",
  "response_class"="ack"
}[${__interval}])
/
rate({
  "__name__"="pubsub.googleapis.com/subscription/push_request_count",
  "monitored_resource"="pubsub_subscription",
  "subscription_id"="$SUBSCRIPTION"
}[${__interval}])

使用篩選條件監控訂閱項目

如果您在訂閱項目上設定篩選器，Pub/Sub 會自動確認不符合篩選條件的訊息。你可以監控這項自動確認功能。

積壓工作指標只會納入符合篩選條件的訊息。

如要監控與篩選器不符的自動確認訊息比率，請使用 subscription/ack_message_count 指標，並將 delivery_type 標籤設為 filter。

如要監控不符合篩選器條件的自動確認訊息的處理量和費用，請使用 subscription/byte_cost 指標，並將 operation_type 標籤設為 filter_drop。如要進一步瞭解這些訊息的費用，請參閱 Pub/Sub 定價頁面。

使用 SMT 監控訂閱項目

如果訂閱項目包含會篩除訊息的 SMT，待處理工作指標會包含篩除的訊息，直到 SMT 實際對這些訊息執行作業為止。也就是說，積壓的訊息可能會顯得較多，而最舊未確認訊息的存在時間可能會比傳送給訂閱者的訊息更久。如果您使用這些指標自動調整訂閱者人數，就更要留意這點。

監控轉寄的無法傳送訊息

如要監控 Pub/Sub 轉送至 dead-letter 主題的無法傳遞訊息，請使用 subscription/dead_letter_message_count 指標。這項指標會顯示 Pub/Sub 從訂閱項目轉送的無法傳遞訊息數量。

如要確認 Pub/Sub 是否轉送無法傳遞的訊息，可以比較 subscription/dead_letter_message_count 指標與 topic/send_request_count 指標。比較 Pub/Sub 轉送這些訊息的 dead-letter 主題。

您也可以將訂閱項目附加至 dead-letter 主題，然後使用下列指標，監控這個訂閱項目中轉送的無法傳遞訊息：

subscription/num_unacked_messages_by_region

訂閱方案中累積的轉寄郵件數量
subscription/oldest_unacked_message_age_by_region

訂閱項目中最舊轉送訊息的存在時間

維持發布商的健康狀態

發布商的主要目標是快速保存訊息資料。使用 topic/send_request_count 監控這項成效，並依 response_code 分組。這項指標會指出 Pub/Sub 是否正常運作並接受要求。

如果可重試的錯誤背景率低於 1%，則不必擔心，因為大多數 Cloud 用戶端程式庫都會重試訊息失敗。調查錯誤率大於 1% 的情況。由於無法重試的代碼是由應用程式處理 (而非用戶端程式庫)，因此您應檢查回應代碼。如果發布商應用程式無法妥善發出不正常狀態信號，請考慮對 topic/send_request_count 指標設定快訊。

同樣重要的是，在發布用戶端中追蹤發布要求失敗的狀況。雖然用戶端程式庫通常會重試失敗的要求，但無法保證發布成功。如要瞭解如何在使用 Cloud Client Libraries 時偵測永久發布失敗，請參閱「發布訊息」。發布商應用程式至少必須記錄永久發布錯誤。如果將這些錯誤記錄至 Cloud Logging，您可以設定記錄指標和警告政策。

監控訊息輸送量

發布商可能會批次傳送訊息。您可以透過下列指標，監控發布端傳送的訊息處理量：

topic/send_request_count：發布商傳送的批次訊息量。
A count of topic/message_sizes: the volume of individual (unbatched) messages being sent by publishers.

如要取得發布訊息的確切數量，請使用下列 PromQL 查詢。這項 PromQL 查詢可有效擷取在定義的時間間隔內，發布至特定 Pub/Sub 主題的個別訊息數量。將 $PROJECT_NAME 和 $TOPIC_ID 的預留位置值替換為實際專案和主題 ID。

sum by (topic_id) (
  increase({
    "__name__"="pubsub.googleapis.com/topic/message_sizes_count",
    "monitored_resource"="pubsub_topic",
    "project_id"="$PROJECT_NAME",
    "topic_id"="$TOPIC_ID"
  }[${__interval}])
)

如要更清楚地呈現資料 (尤其是每日指標)，請考慮下列事項：

查看較長期間的資料，進一步瞭解每日趨勢。
使用長條圖呈現每日訊息數量。

後續步驟

如要為特定指標建立快訊，請參閱「管理以指標為基礎的快訊政策」。
如要進一步瞭解如何使用 PromQL 建構監控圖表，請參閱「使用程式碼編輯器進行 PromQL 查詢」。
如要進一步瞭解 Monitoring API 的 API 資源 (例如指標、受監控資源、受監控資源群組和警報政策)，請參閱「API 資源」。

在 Cloud Monitoring 中監控 Pub/Sub 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

事前準備

查看現有資訊主頁

查看單一 Pub/Sub 指標

查看 Pub/Sub 指標和資源類型

存取 PromQL 編輯器

監控配額用量

維持有效的訂閱方案

監控待處理訊息

請改用區域版本的指標，而非全球版本

常見的待處理事項問題

監控傳遞延遲時間健康狀態

監控確認期限

監控訊息輸送量

監控推送訂閱項目

使用篩選條件監控訂閱項目

使用 SMT 監控訂閱項目

監控轉寄的無法傳送訊息

維持發布商的健康狀態

監控訊息輸送量

後續步驟

在 Cloud Monitoring 中監控 Pub/Sub