モニタリングの概要

Pub/Sub API では、Cloud Monitoring を介して指標をエクスポートします。Cloud Monitoring では、モニタリング ダッシュボードアラート ポリシーを作成したり、プログラムで指標にアクセスしたりできます。

指標の表示

Cloud Monitoring ダッシュボードを表示したり、アラート ポリシーを定義したりするには、Google Cloud Console で [モニタリング] に移動します。

[モニタリング] に移動

Cloud Monitoring API を使用して、サブスクリプションとトピックの指標をクエリしたり、表示したりすることもできます。

指標とリソースタイプ

トピックまたはサブスクリプションの割り当て使用量のモニタリング

API とサービスの割り当てダッシュボードを使用して、特定のトピックまたはサブスクリプションの現在の使用状況をモニタリングできます。

次の指標があります。

  • pubsub.googleapis.com/topic/byte_cost
  • pubsub.googleapis.com/subscription/byte_cost

これらの指標はバイト単位ですが、割り当て使用量はキロバイト単位で測定されることに注意してください。

サブスクライバーの正常性の維持

バックログのモニタリング

メッセージのフローにサブスクライバーが確実に対応できるようにするには、すべてのサブスクリプションのリソース別に集計された次の指標を表示するダッシュボードを作成します。

  • subscription/num_undelivered_messages
  • subscription/oldest_unacked_message_age

これらの値がシステムのコンテキストで異常に大きい場合に起動するアラート ポリシーを作成します。たとえば、配信されなかったメッセージの絶対数は必ずしも意味を持つとは限りません。100 万件のメッセージのバックログは、1 秒あたり 100 万件のメッセージのサブスクリプションでは許容できる可能性がありますが、1 秒あたり 1 件のメッセージのサブスクリプションでは許容できません。

現象 問題 ソリューション
oldest_unacked_message_agenum_undelivered_messages の両方が連動して増加しています。 サブスクライバーがメッセージの量についていけていない
  • サブスクライバーのスレッドまたはプロセスを追加します。
  • サブスクライバーのマシンまたはコンテナを追加します。
  • メッセージの正常な確認応答やタイムリーな処理を妨げるコードのバグの兆候を探します(確認応答期限切れのモニタリングを参照)。
バックログのサイズが安定的に小さく、かつ oldest_unacked_message_age が着実に増加している場合、処理できないメッセージの数は少ない可能性があります。 メッセージが溜まる アプリケーション ログを調べて、いくつかのメッセージがコードによるクラッシュの原因となっているかどうかを確認します。問題のメッセージがクライアントではなく Pub/Sub に溜まっている可能性は低いですが、起こり得ます。コードが各メッセージを正常に処理することを確認したら、サポートケースを作成します。
oldest_unacked_message_age がサブスクリプションのメッセージ保持期間を超えています。 永続的なデータ損失 サブスクリプションのメッセージ保持期間が終了する前に適切に起動するアラートを設定します。

確認応答期限切れのモニタリング

メッセージ配信のエンドツーエンドのレイテンシを短縮するために、Pub/Sub では、サブスクライバーのクライアントはメッセージが再配信される前の限られた時間内(「確認応答期限」と呼ばれる)に特定のメッセージを確認できます。サブスクライバーでのメッセージの確認応答に時間がかかりすぎると、メールが再配信され、サブスクライバーに重複するメッセージが表示されます。これは、いくつかの原因で発生します。

  • サブスクライバーのプロビジョニングが不足している(スレッドまたはマシンがさらに必要)。

  • 各メッセージの処理に、メッセージの確認応答期限よりも時間がかかる。Google Cloud クライアント ライブラリは、通常、個々のメッセージの期限を構成可能な上限まで延長します。ただし、最大延長期限はライブラリにも適用されます。

  • 一貫してクライアントをクラッシュするメッセージがある。

サブスクライバーが確認応答期限に間に合わないレートを測定すると役立つことがあります。具体的な指標は、サブスクリプション タイプによって異なります。

  • pull と StreamingPull: response_code != "success" でフィルタされた subscription/pull_ack_message_operation_count

  • push: response_code != "success" でフィルタされた subscription/push_request_count

確認応答期限切れの割合が過度に高いと、システムのコスト効率が悪くなることがあります。各再配信と、各メッセージの繰り返しの処理試行は課金の対象となります。逆に、期限切れの割合が低い場合(たとえば、0.1~1%)は正常です。

push サブスクリプションのモニタリング

push サブスクリプションの場合は、次の指標もモニタリングする必要があります。

  • subscription/push_request_count

    response_codesubcription_id で指標をグループ化します。Pub/Sub の push サブスクリプションでは、メッセージの暗黙の確認応答としてレスポンス コードを使用するため、push リクエストのレスポンス コードをモニタリングすることが重要です。push サブスクリプションでは、タイムアウトまたはエラーが発生すると、指数バックオフが行われるため、エンドポイントの応答に基づいてバックログが急速に増加することがあります。

    エラー率が高い場合は配信の遅延とバックログの増加につながるため、アラートを設定することを検討してください(レスポンス クラスでフィルタされた指標を作成します)。ただし、push リクエストの数のほうが、バックログのサイズと経過時間の増加を調査するツールとして役立つ傾向があります。

  • subscription/num_outstanding_messages

    一般に、Pub/Sub は未処理のメッセージの数を制限します。ほとんどの場合、未処理のメッセージは 1,000 件未満にする必要があります。原則として、サービスでは、サブスクリプションの全体的なスループットに基づいて、1 秒あたりのメッセージ数のスループットが約 10,000 のレートを達成したら、1,000 単位で制限を調整します。最大値を超えると明確な保証はないため、1,000 を目安として使用してください。

  • subscription/push_request_latencies

    この指標は、push エンドポイントのレスポンスのレイテンシ分布を把握するのに役立ちます。未処理のメッセージの数に制限があるため、エンドポイントのレイテンシはサブスクリプションのスループットに影響します。各メッセージの処理に 100 ミリ秒かかる場合、一般的に、スループットの上限は 1 秒あたり 10 メッセージになります。

配信エラーのトピックの監視

配信エラートピックに転送されたメッセージをモニタリングするには、配信エラートピックのサブスクリプションからsubscription/dead_letter_message_count指標を使用します。

転送されたメッセージが正常に受信されたことを確認するには、配信エラートピックでsubscription/dead_letter_message_counttopic/send_message_operation_count指標を比較します。

配信エラートピックのサブスクリプションの指標を使用して、配信エラートピックが受信した転送メッセージをモニタリングすることもできます。

  • subscription/num_undelivered_messages

    サブスクリプションが、配信エラートピックに転送されたメッセージのみを受信した場合、この指標は、サブスクライバーアプリケーションによって処理されない転送メッセージの数をカウントします。

  • subscription/oldest_unacked_message_age

    サブスクリプションが、配信エラートピックに転送されたメッセージのみを受信した場合、この指標は配信エラートピックに転送されたメッセージが有効期限に近づいているかどうかを示します。

パブリッシャーの正常性の維持

パブリッシャーの主な目標は、メッセージ データを迅速に保持することです。このパフォーマンスは、response_code でグループ化された topic/send_request_count を使用してモニタリングします。この指標は、Pub/Sub が正常であり、リクエストを受け入れているかどうかを示します。

ほとんどの Google Cloud クライアント ライブラリは、失敗したメッセージを再試行するため、再試行可能なエラーのバックグラウンド率(1% よりもはるかに低い)を懸念する必要はありません。エラー率が 1% を超える場合は調査する必要があります。再試行不可能なコードは(クライアント ライブラリではなく)アプリケーションで処理されるため、レスポンス コードを確認する必要があります。パブリッシャー アプリケーションで異常な状態を示す適切な方法がない場合、send_request_count の指標に対するアラートを設定することを検討してください。

パブリッシュ クライアントで、失敗したパブリッシュ リクエストを追跡することも同様に重要です。クライアント ライブラリは、通常、失敗したリクエストを再試行しますが、パブリッシュを保証するものではありません。Google Cloud クライアント ライブラリの使用時に永続的なパブリッシュ エラーを検出する方法については、メッセージのパブリッシュをご覧ください。パブリッシャー アプリケーションでは、少なくとも、永続的なパブリッシュ エラーをログに記録するようにしてください。これらのエラーを Cloud Logging に記録する場合は、アラート ポリシーを使用してログベースの指標を設定できます。