在 Cloud Monitoring 中監控 Pub/Sub

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

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

• 如要查看 Pub/Sub 指標以外的其他 Google Cloud 資源指標，請使用 Monitoring。

• 否則，您可以使用 Pub/Sub 提供的監控資訊主頁。請參閱「監控主題」和「監控訂閱項目」。

如要瞭解在自動調度資源中使用指標的最佳做法，請參閱「使用 Pub/Sub 指標做為調度信號的最佳做法」。

事前準備

使用 Monitoring 前，請先準備下列項目：

• Cloud Billing 帳戶

• 已啟用計費功能的 Pub/Sub 專案

如要確認您是否兩者都擁有，請完成使用 Cloud 控制台的快速入門導覽課程。

查看現有資訊主頁

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

如要使用 Cloud Monitoring 監控 Pub/Sub 專案，請執行下列步驟：

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

   前往「Monitoring」頁面

2. 如果尚未在頁面頂端選取專案名稱，請立即選取。

3. 按一下導覽選單中的「資訊主頁」。

4. 在「Dashboards overview」(資訊主頁總覽) 頁面中，建立新的資訊主頁，或選取現有的 Pub/Sub 資訊主頁。

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

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

查看單一 Pub/Sub 指標

如要使用 Google Cloud 主控台查看單一 Pub/Sub 指標，請執行下列步驟：

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

   前往「Monitoring」頁面

2. 在導覽窗格中，選取「Metrics Explorer」。

3. 在「設定」部分中，按一下「選取指標」。

4. 在篩選器中輸入 Pub/Sub。

5. 在「Active resources」中，選取「Pub/Sub Subscription」或「Pub/Sub Topic」。

6. 進一步查看特定指標，然後按一下「套用」。

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

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

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

• 如要查看 Pub/Sub 向 Cloud Monitoring 回報的指標，請參閱 Cloud Monitoring 說明文件中的 Pub/Sub 指標清單。

• 如要查看 pubsub_topic、pubsub_subscription 或 pubsub_snapshot 受控資源類型的詳細資料，請參閱 Cloud Monitoring 說明文件中的「受控資源類型」。

存取 MQL 編輯器

Metrics Explorer 是 Cloud Monitoring 中的介面，專門用於探索及視覺化指標資料。在 Metrics Explorer 中，您可以使用 Monitoring Query Language(MQL) 查詢及分析 Pub/Sub 指標。

如要在使用 Metrics Explorer 時存取 MQL 編輯器，請參閱「存取程式碼編輯器」。

建構 MQL 查詢

以下是建立 Pub/Sub 指標 MQL 查詢時必須遵守的一些基本規則。

1. 開頭為 fetch pubsub_topic 或 fetch pubsub_subscription。這行程式碼會告訴編輯器您要查詢哪種類型的 Pub/Sub 資源，例如主題或訂閱項目。

2. 選取指標。使用 | metric 'metric_name' 指定要分析的指標。範例 Pub/Sub 指標為 pubsub.googleapis.com/subscription/ack_message_count (針對已確認的訊息)。

3. 使用 | filter 縮小資料範圍。常見的篩選器包括：

   • resource.project_id == 'your-project-id'
   • resource.topic_id == 'your-topic-id'
   • resource.subscription_id == 'your-subscription-id'

4. 使用 | align 和 | group_by 將資料匯總成有意義的間隔和分組。

5. 使用其他子句精進資料。MQL 提供多種其他子句，例如 | every (用於設定查詢執行頻率)、| within (用於指定時間範圍) 等等。

以下是用於監控傳送至特定訂閱項目的訊息每小時計數的查詢範例：

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/sent_message_count'
| filter resource.project_id == 'your-project-id'
&& resource.subscription_id == 'your-subscription-id'
| align delta(1h)
| every 1h
| group_by [], [value_sent_message_count_aggregate: aggregate(value.sent_message_count)]

監控配額用量

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

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

• serviceruntime.googleapis.com/quota/rate/net_usage
• serviceruntime.googleapis.com/quota/limit

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

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

fetch consumer_quota
| filter resource.service == 'pubsub.googleapis.com'
| { metric serviceruntime.googleapis.com/quota/rate/net_usage
    | filter metric.quota_metric == 'pubsub.googleapis.com/regionalpublisher'
    | align delta_gauge(1m)
    | group_by [metric.quota_metric, resource.location],
        sum(value.net_usage)
  ; metric serviceruntime.googleapis.com/quota/limit
    | filter metric.quota_metric == 'pubsub.googleapis.com/regionalpublisher'
    | group_by [metric.quota_metric, resource.location],
        sliding(1m), max(val()) }
| ratio

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

fetch consumer_quota
| filter resource.service == 'pubsub.googleapis.com'
| { metric serviceruntime.googleapis.com/quota/rate/net_usage
    | align delta_gauge(1m)
    | group_by [metric.quota_metric, resource.location],
        sum(value.net_usage)
  ; metric serviceruntime.googleapis.com/quota/limit
    | group_by [metric.quota_metric, resource.location],
        sliding(1m), max(val()) }
| ratio
| every 1m
| condition gt(val(), 0.8 '1')

如要進一步瞭解如何針對配額指標進行客製化監控和快訊，請參閱「使用配額指標」。

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

維持健全的訂閱

為維持訂閱項目的正常運作，您可以使用 Pub/Sub 提供的指標監控多個訂閱項目屬性。舉例來說，您可以監控未確認訊息的數量、訊息確認期限的到期日等等。您也可以檢查訂閱項目是否運作正常，以便達到低訊息傳送延遲。

如要進一步瞭解特定指標，請參閱後續章節。

監控訊息積壓情形

如要確保訂閱者能掌握訊息流程，請建立資訊主頁。資訊主頁可針對所有訂閱項目，依資源匯總顯示下列積案指標：

• 未確認訊息 (subscription/num_unacked_messages_by_region)，即可查看未確認訊息的數量。

• 最舊未確認訊息的存在時間 (subscription/oldest_unacked_message_age_by_region)，查看訂閱項目待處理訊息中最舊未確認訊息的存在時間。

• 傳遞延遲時間健康狀態分數 (subscription/delivery_latency_health_score)，用於檢查訂閱項目在傳遞延遲時間方面的整體健康狀態。如要進一步瞭解這個指標，請參閱本文相關章節。

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

常見的積壓問題

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

在 Pub/Sub 中，傳送延遲是指發布訊息傳送至訂閱端的時間。如果待處理郵件數量增加，您可以使用傳送延遲時間健康分數 (subscription/delivery_latency_health_score) 檢查導致延遲時間增加的因素。

這個指標會評估單一訂閱項目在 10 分鐘滾動時間區間內的健康狀態。這項指標可提供下列條件的深入分析，這些條件是訂閱項目能持續維持低延遲所需的必要條件：

• 可忽略的搜尋要求。

• 負面確認訊息 (nacked) 訊息數量極少。

• 訊息確認期限過期後的影響微乎其微。

• 持續的確認延遲時間不超過 30 秒。

• 持續低使用率，表示訂閱項目持續有足夠的處理新訊息能力。

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

• Seek requests：如果訂閱項目在過去 10 分鐘內有任何 seek 要求，分數會設為 0。尋找訂閱項目可能會導致舊訊息在首次發布後過很久才重播，導致傳送延遲時間增加。

• 已收到負面回應 (nack) 的訊息：如果訂閱項目在過去 10 分鐘內有任何已收到負面回應 (nack) 的要求，分數會設為 0。負面確認會導致郵件重新傳送，且傳送延遲時間會增加。

• 已過期的確認期限：如果訂閱項目在過去 10 分鐘內有任何已過期的確認期限，分數會設為 0。確認期限已過的訊息會以較長的傳送延遲時間重新傳送。

• 確認延遲：如果過去 10 分鐘內所有確認延遲的第 99.9 百分位數曾超過 30 秒，分數就會設為 0。高確認延遲時間表示訂閱端用戶端處理訊息的時間異常長。這個分數可能表示訂閱者用戶端發生錯誤，或有某些資源受限。

• 使用率偏低：系統會根據訂閱類型計算使用率。

  • StreamingPull：如果您沒有開啟足夠的串流，分數會設為 0。開啟更多串流，確保有足夠的容量來處理新訊息。

  • 推送：如果推送端點的待處理訊息過多，分數會設為 0。為推送端點增加容量，以便接收新訊息。

  • Pull：如果您沒有足夠的待處理提取要求，分數會設為 0。開啟更多並行拉取要求，確保您已準備好接收新訊息。

如要查看指標，請在 Metrics Explorer 中，選取 Pub/Sub 訂閱資源類型的「Delivery latency health score」指標。新增篩選器，一次只選取一個訂閱項目。選取「堆疊區域圖表」，並指向特定時間，即可查看該時間點訂閱項目的條件分數。

以下是使用堆疊區域圖表繪製一小時期間指標的螢幕截圖。綜合健康分數在凌晨 4 點 15 分上升至 5 分，每個條件分數為 1 分。之後，綜合分數在凌晨 4 點 20 分時降至 4，而使用率分數則降至 0。

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

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/delivery_latency_health_score'
| filter (resource.subscription_id == '$SUBSCRIPTION')
| group_by 1m,
   [value_delivery_latency_health_score_sum:
     sum(if(value.delivery_latency_health_score, 1, 0))]
| every 1m

監控確認期限到期

為了減少訊息傳送延遲時間，Pub/Sub 會為訂閱端用戶端提供有限的時間，讓他們確認 (ACK) 特定訊息。這段時間稱為 ack 期限。如果訂閱者花太多時間確認訊息，系統就會重新傳送訊息，導致訂閱者看到重複的訊息。發生這種重新送達情況的原因有很多：

• 訂閱者資源不足 (需要更多執行緒或機器)。

• 每則訊息的處理時間都比訊息確認期限長。Cloud 用戶端程式庫通常會將個別訊息的期限延長至可設定的最大值。不過，延長期限的最高期限也適用於程式庫。

• 某些訊息會持續導致用戶端當機。

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

• 提取和 StreamingPull： subscription/expired_ack_deadlines_count

• 推送： subscription/push_request_count 篩選條件：response_code != "success"

如果回應逾時期限到期率過高，可能會導致系統效率不彰。您必須為每次重新傳送和嘗試重複處理每則訊息支付費用。反之，如果失效率偏低 (例如 0.1% 至 1%)，可能就算是正常。

監控訊息傳輸量

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

• 提取： subscription/pull_request_count (請注意，這個指標可能也會納入提取要求，但沒有傳回任何訊息)

• StreamingPull： subscription/streaming_pull_response_count

您可以使用 delivery_type 標籤篩選指標 subscription/sent_message_count，監控訂閱者處理的個別或未分批的訊息傳送傳輸量。

下列 MQL 查詢會產生時序圖表，顯示每 10 分鐘傳送至特定 Pub/Sub 訂閱的訊息總數。將 $PROJECT_NAME 和 $SUBSCRIPTION_NAME 的預留位置值替換為實際專案和主題 ID。

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/sent_message_count'
| filter resource.project_id == '$PROJECT_NAME'
&& resource.subscription_id == '$SUBSCRIPTION_NAME'
| align delta(10m)
| every 10m
| group_by [],
[value_sent_message_count_aggregate: aggregate(value.sent_message_count)]

監控推送訂閱

如要監控推播訂閱項目，請監控下列指標：

• subscription/push_request_count

  依 response_code 和 subcription_id 分組指標。由於 Pub/Sub 推播訂閱會使用回應碼做為隱含的訊息確認，因此請務必監控推播要求回應碼。由於推播訂閱項目在遇到逾時或錯誤時會以指數方式回報，因此待處理工作量可能會因端點的回應方式而迅速增加。

  由於高錯誤率會導致提交速度變慢，並導致待處理工作數量增加，因此建議您設定相關快訊。您可以建立依據回應類別篩選的指標。不過，如果要調查積壓案件的大小和年齡，推送要求計數可能會更實用。

• subscription/num_outstanding_messages

  Pub/Sub 通常會限制待處理訊息的數量。在大多數情況下，請將未處理的訊息數量控制在 1,000 封以下。傳輸量達到每秒 10,000 則訊息的速率後，服務會調整未完成訊息數量的限制。這項限制以 1,000 為單位。超過最大值的數量並未提供特定保證，因此 1,000 則未讀訊息是個不錯的參考值。

• subscription/push_request_latencies

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

如要享有更高的未讀訊息限制，推播訂閱者必須確認收到的 99% 以上訊息。

您可以使用 Monitoring 查詢語言計算訂閱者確認訊息的比例。以下 MQL 查詢會建立圖表，其中顯示訂閱者在訂閱項目中確認訊息的比例：

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/push_request_count'
| filter
    (resource.subscription_id == '$SUBSCRIPTION')
    | filter_ratio_by [], metric.response_class == 'ack'
    | every 1m

使用篩選器監控訂閱項目

如果您在訂閱項目上設定篩選器，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：發布商傳送的個別 (未分批) 訊息數量。

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

fetch pubsub_topic
| metric 'pubsub.googleapis.com/topic/message_sizes'
| filter resource.project_id == '$PROJECT_NAME'
&& resource.topic_id == '$TOPIC_ID'
| align delta(60m)
| every 60m
| group_by [resource.topic_id],
[value_message_sizes_sum: count(value.message_sizes)]

如要呈現更精確的資料，尤其是每日指標，請考慮下列做法：

• 查看較長時間範圍內的資料，以便進一步瞭解每日趨勢。

• 使用長條圖呈現每日訊息數量。

後續步驟

• 如要為特定指標建立快訊，請參閱「管理以指標為基礎的快訊政策」一文。

• 如要進一步瞭解如何使用 MQL 建立監控圖表，請參閱「使用查詢編輯器」。

• 如要進一步瞭解 Monitoring API 的 API 資源 (例如指標、受控資源、受控資源群組和警報政策)，請參閱「API 資源」。