HTTP(S) 負荷分散のロギングとモニタリング

このドキュメントでは、HTTP(S) 負荷分散に使用する Cloud Logging と Cloud Monitoring について説明します。

ロギング

HTTP(S) 負荷分散のロギングのバックエンド サービスを有効化、無効化、表示できます。

バックエンド サービスごとにロギングを有効または無効にできます。すべてのリクエストをロギングするか、ランダムにサンプリングしたフラクションのみをロギングするかを構成できます。

外部 HTTP(S) ロードバランサに適用されるログの除外がないことを確認する必要があります。Cloud HTTP Load Balancer ログが許可されているかどうか確認する方法については、リソースタイプの除外の表示をご覧ください。

新しいバックエンド サービスでのロギングの有効化

Console

  1. Cloud Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. ロードバランサの名前をクリックします。
  3. [編集] をクリックします。
  4. [バックエンドの設定] をクリックします。
  5. バックエンド サービスの横にある [編集] をクリックします。
  6. ロギングを完全に無効にするには、[ロギングを有効にする] をクリアします。
  7. ロギングを有効にした場合、[サンプルレート] に異なる値を設定できます。0.0 から 1.0 まで(デフォルト)の任意の値に設定できます。保存されるログの数を 20% に減らすには、値を 0.2 に設定します。
  8. [更新] をクリックします。

gcloud

gcloud compute backend-services create BACKEND_SERVICE \
 --global \
 --enable-logging \
 --logging-sample-rate=VALUE \
 ... other values

ここで

  • --global は、バックエンド サービスがグローバルであることを示します。
  • --enable-logging は、バックエンド サービスのロギングを有効にします。
  • --logging-sample-rate=<var>VALUE</var> には、0.0 から 1.0 までの値を指定できます。0.0 を設定すると、リクエストはまったくロギングされません。1.0 を設定すると、すべてのリクエストがロギングされます。--enable-logging パラメータを指定した場合のみ有効となります。ロギングを有効にしても、サンプリング レートが 0.0 であれば、ロギングを無効にしているのと同じ結果になります。

既存のバックエンド サービスでのロギングの有効化

Console

  1. Cloud Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. ロードバランサの名前をクリックします。
  3. [編集] をクリックします。
  4. [バックエンドの設定] をクリックします。
  5. バックエンド サービスの横にある [編集] をクリックします。
  6. [ロギングを有効にする] をクリックします。
  7. [サンプルレート] の値を選択します。レートは 0.01.0(デフォルト)に設定できます。
  8. [更新] をクリックします。

gcloud

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE

ここで

  • --global は、バックエンド サービスがグローバルであることを示します。
  • --enable-logging は、バックエンド サービスのロギングを有効にします。
  • --logging-sample-rate=<var>VALUE</var> には、0.0 から 1.0 までの値を指定できます。0.0 を設定すると、リクエストはまったくロギングされません。1.0 を設定すると、すべてのリクエストがロギングされます。--enable-logging パラメータを指定した場合のみ有効となります。ロギングを有効にしても、サンプリング レートが 0.0 であれば、ロギングを無効にしているのと同じ結果になります。

既存のバックエンド サービスでのロギングの無効化または変更

Console

  1. Cloud Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. ロードバランサの名前をクリックします。
  3. [編集] をクリックします。
  4. [バックエンドの設定] をクリックします。
  5. バックエンド サービスの横にある をクリックします。
  6. ロギングを完全に無効にするには、[ロギングを有効にする] をクリアします。
  7. ロギングを有効にした場合、[サンプルレート] に異なる値を設定できます。レートは 0.01.0(デフォルト)に設定できます。保存されるログの数を 20% に減らすには、値を 0.2 に設定します。
  8. [更新] をクリックします。

gcloud

ロギングの完全な無効化

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --no-enable-logging

ここで

  • --global は、バックエンド サービスがグローバルであることを示します。
  • --no-enable-logging はバックエンド サービスのロギングを無効にします。

ロギングのサンプルレートの変更

gcloud compute backend-services update BACKEND_SERVICE \
 --global \
 --logging-sample-rate=VALUE

ここで

  • --global は、バックエンド サービスがグローバルであることを示します。
  • --logging-sample-rate=<var>VALUE</var> には、0.0 から 1.0 までの値を指定できます。0.0 を設定すると、リクエストはまったくロギングされません。1.0 を設定すると、すべてのリクエストがロギングされます。--enable-logging パラメータを指定した場合のみ有効となります。ロギングを有効にしても、サンプリング レートが 0.0 であれば、ロギングを無効にしているのと同じ結果になります。

ログの表示

ログを表示するには、ログビューアに移動します。

HTTP(S) ログはまず転送ルールでインデックス化され、次に URL マップでインデックス化されます。

  • すべてのログを表示するには、最初のプルダウン メニューで [Cloud HTTP Load Balancer] > [すべての転送ルール] を選択します。
  • 1 つの転送ルールのログを表示するには、単一の転送ルール名を選択します。
  • 1 つの URL マップのログを表示するには、転送ルールをハイライト表示して URL マップを選択します。

通常、ブール型のログフィールドは、フィールドの値が true の場合にのみ表示されます。ブール フィールドの値が false の場合、そのフィールドはログから省略されます。

ログフィールドには UTF-8 エンコードが適用されます。UTF-8 以外の文字列は、疑問符に置き換えられます。

外部 HTTP(S) ロードバランサ リソースログ(resource.type=http_load_balancer)のログベースの指標のエクスポートを構成できます。作成される指標は、Cloud Monitoring ダッシュボードにある「Google Cloud HTTP 負荷分散ルール(ログベースの指標)」リソース(l7_lb_rule)に基づきます。https_lb_rule リソースには基づきません。

[Monitoring] に移動

ログの内容

HTTP(S) 負荷分散ログエントリには、HTTP(S) トラフィックのモニタリングおよびデバッグに役立つ情報が含まれています。ログエントリには次のタイプの情報が含まれています。

  • 重大度、プロジェクト ID、プロジェクト番号、タイムスタンプなどの一般情報。
  • HttpRequest ログフィールド。ただし、HttpRequest.protocol は HTTP(S) 負荷分散の Cloud Logging ログには含まれません。
  • structPayload 内の statusDetails フィールド。このフィールドには、ロードバランサが行った、HTTP のステータスを返した理由を説明する文字列が入ります。これらのログの文字列については下の表で詳しく説明します。
  • ロードバランサから発行されたリダイレクト(HTTP レスポンス ステータ スコード 302 Found)は記録されません。バックエンド インスタンスから発行されたリダイレクトはログに記録されます。

statusDetail HTTP 正常終了メッセージ

statusDetails(正常終了) 意味 一般的に記録されるレスポンス コード
byte_range_caching HTTP リクエストが Cloud CDN のバイト範囲キャッシュを使用して提供されました。 任意のキャッシュ可能なレスポンス コード
response_from_cache HTTP リクエストが Cloud CDN キャッシュから提供されました。 任意のキャッシュ可能なレスポンス コード
response_from_cache_validated リターンコードは、バックエンドによって検証された Cloud CDN キャッシュ済みエントリから設定されました。 任意のキャッシュ可能なレスポンス コード
response_sent_by_backend HTTP リクエストは、バックエンドに正常にプロキシされました。 バックエンドから返されます - HTTP レスポンス コードは、バックエンドで実行されているソフトウェアによって設定されます。

statusDetail HTTP 異常終了メッセージ

statusDetails(異常終了) 意味 一般的に記録されるレスポンス コード
aborted_request_due_to_backend_early_response 本文付きのリクエストは、バックエンドが早期レスポンスを送信したため中断され、エラーコードが返されました。レスポンスはクライアントに転送されました。リクエストは終了しました。 4XX または 5XX
backend_connection_closed_after_partial_response_sent クライアントに部分的レスポンスが送られた後、バックエンドへの接続が予期せず閉じました。 HTTP レスポンス コードは、バックエンドで実行されているソフトウェアによって設定されます。HTTP レスポンス コード 0(ゼロ)は、バックエンドが不完全な HTTP ヘッダーを送信したことを意味します。
backend_connection_closed_before_data_sent_to_client バックエンドは、レスポンスがクライアントにプロキシされる前に、予期せずロードバランサへの接続を閉じました。これは、ロードバランサが別のエンティティにトラフィックを送信している場合に発生します。他のエンティティは、外部 HTTP(S) ロードバランサの 10 分(600 秒)のタイムアウトよりも短い TCP タイムアウトが設定されたサードパーティ ロードバランサである可能性があります。サードパーティ ロードバランサが VM インスタンスで実行されている場合があります。手動でターゲット サービスの TCP タイムアウト(keep-alive)を 600 秒よりも大きな値に設定することで、問題が解決する可能性があります。 502
backend_early_response_with_non_error_status バックエンドは、リクエスト本文全体を受信する前に、リクエストに対するエラー以外のレスポンス(1XX または 2XX)を送信しました。 502
backend_interim_response_not_supported バックエンドは、暫定レスポンスがサポートされていないコンテキストでリクエストに暫定 1XX レスポンスを送信しました。 502
backend_response_corrupted バックエンドによって送信された HTTP レスポンス本文のチャンクの転送エンコードが無効か、レスポンス本文が破損しています。 任意のレスポンス コード。破損の性質によって異なります。多くの場合、502 です。
backend_response_headers_too_long バックエンドから送信された HTTP レスポンス ヘッダーが上限を超えました。詳細については、HTTP(S) 負荷分散のヘッダーサイズの制限をご覧ください。 502
backend_timeout バックエンドは、レスポンスを生成中にタイムアウトしました。 502
body_not_allowed クライアントは、本文付き HTTP リクエストを送信しましたが、使用される HTTP メソッドは本文を許可していません。 400
byte_range_caching_aborted ロードバランサは、リソースがキャッシュ可能でバイト範囲をサポートしていることを示すレスポンスを以前に受信しました。Cloud CDN が一貫性を欠くレスポンス(たとえば、予想される 206 Partial Content 以外のレスポンス コードを伴うレスポンス)を受信しました。これは、バイト範囲リクエストを使用してキャッシュ フィルを実行しようとした場合に発生します。その結果、ロードバランサはクライアントへのレスポンスを中止しました。 2XX
byte_range_caching_forwarded_backend_response ロードバランサは、リソースがキャッシュ可能でバイト範囲をサポートしていることを示すレスポンスを以前に受信しました。Cloud CDN が一貫性を欠くレスポンス(たとえば、予想される 206 Partial Content 以外のレスポンス コードを伴うレスポンス)を受信しました。これは、バイト範囲リクエストを使用してキャッシュ フィルを実行しようとした場合に発生します。その後、ロードバランサは、一貫性を欠くレスポンスをクライアントに転送しました。 バックエンドからの戻り値(任意のレスポンス コード)。
byte_range_caching_retrieval_abandoned クライアントが Cloud CDN によって開始されたバイト範囲リクエストまたは検証リクエストをキャンセルしました。 バックエンドからの戻り値(任意のレスポンス コード)。
byte_range_caching_retrieval_from_backend_failed_after_partial_response Cloud CDN によって開始されたバイト範囲リクエストまたは検証リクエストでエラーが発生しました。Cloud CDN によって開始されたリクエストに対応する Cloud Logging のログエントリを参照して、バックエンドの詳細を確認してください。 2XX
cache_lookup_failed_after_partial_response ロードバランサは、内部エラーのため Cloud CDN キャッシュから完全なレスポンスを提供できませんでした。 2XX
cache_lookup_timeout_after_partial_response クライアントがコンテンツをタイムリーに取得しなかったため、Cloud CDN キャッシュ検索ストリームがタイムアウトになりました。 2XX
client_disconnected_after_partial_response ロードバランサが部分的レスポンスを送信した後で、クライアントへの接続が切断されました。 バックエンドからの戻り値(任意のレスポンス コード)。
client_disconnected_before_any_response ロードバランサが、何らのレスポンスも送信する前に、クライアントへの接続が切断されました。 0
client_timed_out Google Front End(GFE)、リクエストまたはレスポンスのいずれかをプロキシ処理する間に、進捗がないため、クライアント接続をアイドル状態にしました。 0 または 408
denied_by_security_policy Google Cloud Armor のセキュリティ ポリシーが原因で、ロードバランサがリクエストを拒否しました。 セキュリティ ポリシーで構成されています。
error_uncompressing_gzipped_body gzip で圧縮された HTTP レスポンスの解凍エラーが発生しました。 503
failed_to_connect_to_backend ロードバランサは、バックエンドに接続できませんでした。これには、接続フェーズ中のタイムアウトが含まれます。 502
failed_to_pick_backend ロードバランサは、リクエストを処理するための正常なバックエンドを選択できませんでした。 502
failed_to_negotiate_alpn ロードバランサとバックエンドは、TLS での通信に使用するアプリケーション レイヤ プロトコル(HTTP/2 など)のネゴシエーションに失敗しました。 502
headers_too_long リクエスト ヘッダーが、許容最大値より大きいです。 413
http_version_not_supported サポートされていない HTTP バージョンです。現状、HTTP 0.9、1.0、1.1、2.0 のみがサポートされます。 400
internal_error ロードバランサの内部エラーです。通常、ロードバランサ インフラストラクチャの一時的なエラーを表します。クエリを再試行してください。 4XX
invalid_external_origin_endpoint カスタムの送信元の構成が無効です。インターネット NEG の構成を確認し、有効な FQDN または IP アドレスとポートを指定していることを確認してください。 4XX
invalid_http2_client_header_format クライアントからの HTTP/2 ヘッダーが無効です。 400
multiple_iap_policies 複数の Identity-Aware Proxy(IAP)ポリシーを組み合わせることはできません。バックエンド サービスに IAP ポリシーが接続され、別のポリシーがサーバーレス オブジェクトに接続されている場合は、いずれかのポリシーを削除してもう一度試してください。サーバーレス オブジェクトには、App Engine、Cloud Run(フルマネージド)、Cloud Functions などがあります。 500
malformed_chunked_body リクエストの本文のチャンク エンコードが不適切です。 411
request_loop_detected ロードバランサがリクエスト ループを検出しました。このループは、構成ミスにより、バックエンドがロードバランサにリクエストを転送した場合に発生します。 502
required_body_but_no_content_length HTTP リクエストは本文を要求していますが、リクエスト ヘッダーに content-length ヘッダーまたは transfer-encoding: chunked ヘッダーが含まれていませんでした。 400 または 403
secure_url_rejected https:// URL 付きのリクエストが、平文の HTTP/1.1 接続を介して受信されました。 400
ssl_san_verification_failed ロードバランサは、構成されたホスト名と一致するバックエンドにより提示される SSL 証明書の SAN(Subject Alternative Name)を見つけることができませんでした。 502
ssl_certificate_chain_verification_failed バックエンドによって提示された SSL 証明書が SSL 証明書の検証に失敗しました。 502
unsupported_method クライアントは、指名されていない HTTP リクエスト メソッドを指定しました。 400
upgrade_header_rejected クライアントの HTTP リクエストにはアップグレード ヘッダーが含まれ、拒否されました。 400
uri_too_long HTTP リクエスト URI が許容最大長を超えていました。 414
websocket_closed WebSocket 接続が切断されました。 101
websocket_handshake_failed WebSocket が handshake できませんでした。 任意のレスポンス コード。handshake 失敗の性質によって異なります。
request_body_too_large HTTP リクエストの本文がバックエンドでサポートされている最大長を超えています。VM バックエンドには適用されません。 413
handled_by_identity_aware_proxy このレスポンスは、アクセスを許可する前のクライアントの本人確認時に、Identity-Aware Proxy によって生成されました。 200、302、400、401、403、500、502
serverless_neg_routing_failed サーバーレス NEG リクエストはディスパッチできません。このエラーは、NEG で指定されたリージョンに到達できない場合、またはリソース名(Cloud Functions 名など)が見つからない場合に発生します。 404、502

Google Cloud Armor セキュリティ ポリシーのロギング

次に示すログビューアのログエントリは、Google Cloud Armor のセキュリティ ポリシーとルールのロギング用です。jsonPayload でエントリの構造は次のとおりです。HTTP リクエストの詳細は、httpRequest メッセージに表示されます。

  • status_details(文字列): レスポンス コードを説明するテキスト
  • enforced_security_policy: 適用されたセキュリティ ポリシー ルール
    • name(文字列): セキュリティ ポリシーの名前
    • priority(数値): セキュリティ ポリシーの一致ルールの優先度
    • configured_action(文字列): 一致ルールで構成したアクションの名前(ALLOWDENY など)
    • outcome(文字列): 構成されたアクションの実行結果(これは configured_action と同じとは限りません)
    • preconfigured_expr_ids(文字列): ルールをトリガーしたすべての事前構成済み WAF ルール式の ID
  • preview_security_policy: リクエストがプレビュー用に構成されたルールに一致する場合に入力される(プレビュー ルールが適用済みのルールよりも優先される場合にのみ表示されます)
    • name(文字列): セキュリティ ポリシーの名前
    • priority(数値): セキュリティ ポリシーの一致ルールの優先度
    • configured_action(文字列): 一致ルールで構成したアクションの名前(ALLOWDENY など)
    • outcome(文字列): 構成されたアクションの実行結果(これは configured_action と同じとは限りません)
    • preconfigured_expr_ids(文字列): ルールをトリガーしたすべての事前構成済み WAF ルール式の ID

Cloud Logging API を使用して、外部 HTTP(S) ロードバランサのログを操作できます。Logging API では、特定のフィールドが設定されたログをインタラクティブにフィルタリングできます。一致するログを Cloud Logging、Cloud Storage、BigQuery、Pub/Sub にエクスポートします。Logging API の詳細については、ログの表示をご覧ください。

モニタリング

HTTP(S) 負荷分散は、モニタリング データを Cloud Monitoring にエクスポートします。

モニタリング指標は次の目的で使用します。

  • ロードバランサの構成、使用状況、パフォーマンスを評価する
  • 問題のトラブルシューティングを行う
  • リソースの使用率とユーザー エクスペリエンスを改善する

Cloud Monitoring の事前定義されたダッシュボードに加えて、カスタム ダッシュボードの作成、アラートのセットアップ、Cloud Monitoring API を使った指標の照会を行うことができます。

Cloud Monitoring ダッシュボードの表示

  1. Cloud Console で [Monitoring] に移動します。

    [Monitoring] に移動

  2. Monitoring のナビゲーション パネルで、[サービス] が表示されている場合は、[サービス] > [Cloud load balancers] を選択します。特定のロードバランサのダッシュボードを表示するには、リストでロードバランサを見つけて、その名前をクリックします。

  3. それ以外の場合は、次のように [ダッシュボード] を選択します。

    • Google Cloud ロードバランサのダッシュボードのリストを表示するには、[Google Cloud Load Balancers] というダッシュボードを選択します。特定のロードバランサのダッシュボードを表示するには、リストでロードバランサを見つけて、その名前をクリックします。

    • AWS ロードバランサのダッシュボードのリストを表示するには、[Amazon Web Services] というダッシュボードを選択します。特定のロードバランサのダッシュボードを表示するには、リストでロードバランサを見つけて、その名前をクリックします。

左側のペインでは、この外部 HTTP(S) ロードバランサのさまざまな詳細を確認できます。右側のペインには時系列のグラフが表示されます。[Breakdowns] リンクをクリックすると、特定の内訳が表示されます。

アラート ポリシーの定義

アラート ポリシーを作成して指標の値をモニタリングすると、条件に違反した場合に通知できます。

1 つ以上の Google Cloud HTTP/S 負荷分散ルール リソースをモニタリングするアラート ポリシーを作成するには、次の手順を行います。

  1. Google Cloud Console で、[Monitoring] ページに移動します。

    [Monitoring] に移動

  2. Monitoring のナビゲーション パネルで [アラート] を選択し、次に [Create Policy] を選択します。
  3. [Add Condition] をクリックします。
    1. [Target] ペインの設定で、モニタリングするリソースと指標を指定します。[Find resource type and metric] フィールドで、[Google Cloud HTTP/S Load Balancing Rule] を選択します。次に、指標リストから指標を選択します。
    2. アラート ポリシーの [Configuration] ペインの設定で、アラートがトリガーされるタイミングを決定します。このペインのほとんどのフィールドにはデフォルト値が入力されています。ペインのフィールドの詳細については、アラート ポリシーのドキュメントの構成をご覧ください。
    3. [追加] をクリックします。
  4. 通知セクションに移動するには、[次へ] をクリックします。
  5. (省略可)アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャネルを選択し、[OK] をクリックします。

    追加する通知チャネルが一覧にない場合は、[通知チャネルを管理] をクリックします。新しいブラウザタブの [通知チャネル] ページが表示されます。このページで、構成された通知チャンネルを更新できます。更新が完了したら、元のタブに戻って 更新アイコンをクリックし、アラート ポリシーに追加する通知チャンネルを選択します。

  6. ドキュメントのセクションに移動するには、[次へ] をクリックします。
  7. [名前] をクリックし、アラート ポリシーの名前を入力します。
  8. (省略可)[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
  9. [Save] をクリックします。
詳細については、アラート ポリシーをご覧ください。

Cloud Monitoring のカスタム ダッシュボードの定義

HTTP(S) 負荷分散の指標に関するカスタムの Cloud Monitoring ダッシュボードを作成できます。

  1. Cloud Console で [Monitoring] に移動します。
    [Monitoring] に移動
  2. [ダッシュボード] > [ダッシュボードを作成] を選択します。
  3. [Add Chart] をクリックします。
  4. グラフにタイトルを付けます。
  5. 指標とフィルタを選択します。指標の場合、リソースタイプは Cloud HTTP ロードバランサです。
  6. [保存] をクリックします。

指標報告の頻度と保持

外部 HTTP(S) ロードバランサの指標は、1 分単位のバッチで Cloud Monitoring にエクスポートされます。モニタリング データは 6 週間保持されます。ダッシュボードでは、1H(1 時間)、6H(6 時間)、1D(1 日)、1W(1 週間)、6W(6 週間)のデフォルト間隔でデータ分析の結果を確認できます。また、6W から 1 分までの任意の間隔で手動で分析を行うこともできます。

外部 HTTP(S) ロードバランサのモニタリング指標

外部 HTTP(S) ロードバランサの次の指標が、Cloud Monitoring に報告されます。

指標 名前 説明
リクエスト数 https/request_count 外部 HTTP(S) ロードバランサによって配信されるリクエスト数
リクエスト バイト数 https/request_bytes_count クライアントから外部 HTTP(S) ロードバランサへのリクエストとして送信されたバイト数
レスポンス バイト数 https/response_bytes_count 外部 HTTP(S) ロードバランサからクライアントへのレスポンスとして送信されたバイト数
総レイテンシ https/total_latencies レイテンシの分布。レイテンシは、GFE がリクエストの最初のバイトを受信してから、要求側のクライアントから ACK の最後のレスポンス バイトの受信するまで測定されます。総レイテンシは、リクエスト/レスポンスによって測定されます。Connection: keep-alive を使った同じ接続上のリクエスト間の休止は測定に影響しません。この測定値は通常、Cloud Monitoring ビューで 95 パーセンタイルに縮小されます。

例: ロードバランサが、英国から 1 秒間に 1 件のリクエスト(すべて 100 ms のレイテンシ)と、米国から 1 秒間に 9 件のリクエスト(すべて 50 ms のレイテンシ)を処理しています。1 分間では、英国から 60 件、米国から 540 件のリクエストが発生することになります。モニタリング指標には、すべてのディメンションにわたる分散が保存されます。次のような情報をリクエストできます。
  • 平均全体レイテンシ(300/600) - 50 ms
  • 平均英国レイテンシ(30/60) - 100 ms
  • 95 パーセンタイル全体レイテンシ(570/600) - 100 ms
フロントエンド RTT(*) https/frontend_tcp_rtt クライアントと GFE 間の接続ごとに測定された平滑化された RTT の分布(GFE の TCP スタックによって測定)。
バックエンド レイテンシ(*) https/backend_latencies GFE がバックエンドに最初のリクエスト バイトを送信してから、バックエンドから最後のレスポンス バイトを受信するまでのレイテンシの分布。
レスポンス コードクラス比 各レスポンス コードクラス(2XX、4XX、...)にある外部 HTTP(S) ロードバランサのレスポンスの合計割合。Cloud Monitoring では、この値はデフォルトのダッシュボードでのみ取得できます。カスタム ダッシュボードでは取得できません。API を使用して、アラートを設定できます。
バックエンドのリクエスト数 https/backend_request_count 外部 HTTP(S) ロードバランサからバックエンドに送信されたリクエストの数。
バックエンド リクエストのバイト数 https/backend_request_bytes_count 外部 HTTP(S) ロードバランサからバックエンドへのリクエストとして送信されたバイト数。
バックエンド レスポンスのバイト数 https/backend_response_bytes_count バックエンドから外部 HTTP(S) ロードバランサへのレスポンスとして送信されたバイト数。

(*)フロントエンド RTT とバックエンド レイテンシの合計が総レイテンシ以下であるという保証はありません。これは、HTTP レスポンスが ACK された時点で GFE からクライアントへのソケット上の RTT をポーリングしますが、これらの測定値の一部をカーネルからの報告に依存しており、指定した HTTP レスポンスの RTT 測定値がカーネルで保持されていることを保証できないためです。最終結果は、現在の HTTP リクエストの実際のタイミングに影響を与えない過去の HTTP レスポンス、SYN / ACK、および SSL ハンドシェイクの影響も受ける、平滑化された RTT 値です。

外部 HTTP(S) ロードバランサの指標のフィルタリング ディメンション

指標は、外部 HTTP(S) ロードバランサごとに集計されます。集計された指標は、次の項目(*)でフィルタ処理できます。

プロパティ 説明
backend_scope 接続を処理したバックエンド サービスのインスタンス グループの Google Cloud スコープ(リージョンまたはゾーン)。

使用可能なインスタンス グループが存在しない場合やリクエストが別のエンティティによって処理された場合は、バックエンド サービスのインスタンス グループのリージョンやゾーンではなく、次の値のいずれかが表示されます。
  • FRONTEND_5XX - GFE がバックエンドを選択する前に内部エラーが発生しました。GFE からクライアントに 5XX が返されました。
  • INVALID_BACKEND - リクエストを割り当て可能な正常なバックエンドが見つからなかったため、GFE からリクエスト送信元に 5XX レスポンスが返されました。
  • NO_BACKEND_SELECTED - バックエンドを選択する前にエラーまたはその他の割り込みが発生しました。
  • SERVED_FROM_BACKEND_BUCKET - バックエンド バケットがリクエストを処理しました。
  • SERVED_FROM_CACHE - GFE キャッシュによってリクエストが処理されたため、バックエンドは割り当てられませんでした。
  • MULTIPLE_BACKENDS - リクエストが複数のバックエンドによって処理された可能性があります。キャッシュが 1 つ以上のバイト範囲リクエストを別のバックエンドに送信しました。BACKEND_SCOPE の概要を使用して、ロードバランサとバックエンド間のリクエストを可視化します。

このオプションを選択すると、グラフにフロントエンド指標(クライアントからロードバランサへ)ではなく、バックエンド指標(ロードバランサからバックエンドへ)が表示されます。
backend_scope = "backend_zone" インスタンス グループがゾーン インスタンス グループの場合、クライアントのリクエストを処理したインスタンス グループの Google Cloud ゾーン。(たとえば、us-central1-aeurope-west1-basia-east1-c

このオプションを選択すると、グラフにフロントエンド指標(クライアントからロードバランサへ)ではなく、バックエンド指標(ロードバランサからバックエンドへ)が表示されます。
backend_scope = "backend_region" インスタンス グループがリージョン インスタンス グループの場合、クライアントのリクエストを処理したインスタンス グループの Google Cloud リージョン。(たとえば、us-central1europe-west1asia-east1

このオプションを選択すると、グラフにフロントエンド指標(クライアントからロードバランサへ)ではなく、バックエンド指標(ロードバランサからバックエンドへ)が表示されます。
proxy_continent HTTP(S) 接続を終了した HTTP(S) GFE の大陸(例: AmericaEuropeAsia)。
backend_type = "INSTANCE GROUP" クライアントのリクエストを処理したインスタンス グループの名前。

使用可能なインスタンス グループが存在しない場合やリクエストが別のエンティティによって処理された場合は、インスタンス グループではなく、次の値のいずれかが表示されます。
  • FRONTEND_5XX - GFE がバックエンドを選択する前に内部エラーが発生しました。GFE からクライアントに 5XX が返されました。
  • INVALID_BACKEND - リクエストを割り当て可能な正常なバックエンドが見つからなかったため、GFE からリクエスト送信元に 5XX レスポンスが返されました。
  • NO_BACKEND_SELECTED - バックエンドを選択する前にエラーまたはその他の割り込みが発生しました。
  • INVALID_BACKEND - GFE が有効な正常バックエンドを見つけられなかったため、リクエスト元に 5xx を返しました。
  • SERVED_FROM_BACKEND_BUCKET - バックエンド バケットがリクエストを処理しました。
  • SERVED_FROM_CACHE - Cloud CDN でリクエストが処理されたため、バックエンドは割り当てられませんでした。
  • MULTIPLE_BACKENDS - 複数のバックエンドでリクエストが処理されました。

このオプションを選択すると、グラフにフロントエンド指標(クライアントからロードバランサへ)ではなく、バックエンド指標(ロードバランサからバックエンドへ)が表示されます。
backend_target_type = "BACKEND_SERVICE" リクエストを処理したバックエンド サービスの名前。
matched_url_path_rule HTTP(S) リクエストのプレフィックスと一致する URL マップパス ルール(最大 50 文字)。
forwarding_rule_name リクエストを送信するためにクライアントに使用された転送ルールの名前。

(*)現在、「レスポンス コードクラス比」指標は、ロードバランサ全体でのみ入手可能で、これ以上の内訳は入手できません。

次のステップ