本頁面由 Cloud Translation API 翻譯而成。

在 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 指標做為調度訊號的最佳做法。

事前準備

請在使用 Monitoring 之前，確認您已準備好下列項目：

Cloud 帳單帳戶
已啟用計費功能的 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」頁面
在導覽窗格中，選取「指標探索器」。
在「設定」部分中，按一下「選取指標」。
在篩選條件中輸入 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 編輯器

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

如要在指標探索器中存取程式碼編輯器，並使用 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)，可查看與傳遞延遲時間相關的整體訂閱項目健康狀態。如要進一步瞭解這項指標，請參閱本文件的相關章節。

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

常見的積壓工作問題

問題	問題	解決方案
`oldest_unacked_message_age_by_region` 和 `num_unacked_messages_by_region` 雙雙成長。	訂閱者跟不上訊息量	新增更多訂閱者執行緒或程序。新增更多訂閱端機器或容器。檢查程式碼是否有錯誤，導致程式碼無法順利確認或及時處理訊息。請參閱監控確認期限到期時間。
如果積壓工作量穩定且不大，但 `oldest_unacked_message_age_by_region` 持續增加，可能會有幾則訊息無法處理。	無法傳送的訊息	檢查應用程式記錄，瞭解是否有某些訊息導致程式碼異常終止。違規訊息不太可能卡在 Pub/Sub 中，而不是用戶端。確認程式碼可順利處理每則訊息後，請提出支援案件。如果某些訊息導致程式碼當機，請考慮將這些訊息轉送至無法傳送的郵件主題。
`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。開啟更多並行提取要求，確保您已準備好接收新訊息。

如要查看指標，請在 Metrics Explorer 中，選取 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%)，可能代表健康狀態良好。

監控訊息輸送量

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

提取： 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 轉送至無效信件主題的無法傳送訊息，請使用 subscription/dead_letter_message_count 指標。這項指標會顯示 Pub/Sub 從訂閱項目轉送的無法遞送訊息數量。

如要確認 Pub/Sub 是否轉送無法傳送的訊息，可以比較 subscription/dead_letter_message_count 指標與 topic/send_request_count 指標。比較 Pub/Sub 將這些訊息轉送至的無效信件主題。

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

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 用戶端程式庫時偵測永久發布失敗，請參閱「發布訊息」一文。發布商應用程式至少必須記錄永久發布錯誤。如果將這些錯誤記錄至 Cloud Logging，您可以使用快訊政策設定記錄指標。

監控訊息輸送量

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

topic/send_request_count：發布者傳送的批次訊息量。
計數：topic/message_sizes：發布商傳送的個別 (未批次處理) 訊息量。

如要取得已發布訊息的確切數量，請使用下列 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