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

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

ログ

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

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

また、外部 HTTP(S) ロードバランサに適用されるログの除外がないことも確認してください。Cloud HTTP load balancer ログが許可されていることを確認する方法については、リソースタイプの除外の表示をご覧ください。

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

Console

  1. Google 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. Google 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. Google 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 つの 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 リソースには基づきません。

[モニタリング] に移動

ログの内容

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

  • 重大度、プロジェクト ID、プロジェクト番号、タイムスタンプなど、ほとんどのログで表示される一般情報。
  • HttpRequest ログフィールド ただし、HttpRequest.protocolHttpRequest.latency は、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 クライアントにレスポンスがプロキシされる前に、バックエンドからロードバランサへの接続が予期せず閉じられました。これは、ロードバランサが別のエンティティ(VM インスタンス上で稼働するサードパーティのロードバランサなど)にトラフィックを送信していて、そのエンティティの TCP タイムアウト値が外部 HTTP(S) ロードバランサのタイムアウト値の 10 分(600 秒)より短い場合に発生します。手動でターゲット サービスの 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 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
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

IP 拒否リストまたは許可リストのロギング

次に示すログビューアのログエントリは、HTTP(S) IP 拒否リストまたは IP 許可リストのロギングのためのものであり、jsonPayload 内の次のような構造を含んでいます。HTTP リクエストの詳細は、httpRequest メッセージに含まれます。

  • status_details(文字列) - レスポンス コードのテキスト記述
  • enforced_security_policy - 実際に適用されたセキュリティ ポリシールール。
    • outcome(文字列) - ACCEPTDENYUNKNOWN_OUTCOME
    • configured_action(文字列) - outcome と同じ
    • name(文字列) - セキュリティ ポリシーの名前
    • priority(数値) - 一致するルールの優先度
  • preview_security_policy - リクエストがプレビュー用に構成されたルールに該当した場合に構成されます(プレビュー ルールが適用済みのルールよりも優先される場合にのみ表示されます)
    • outcome(文字列) - ACCEPTDENYUNKNOWN_OUTCOME
    • configured_action(文字列) - outcome と同じ
    • name(文字列) - セキュリティ ポリシーの名前
    • priority(数値) - 一致するルールの優先度

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

モニタリング

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

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

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

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

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

  1. Google Cloud Console で [モニタリング] に移動します。

    [モニタリング] に移動

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

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

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

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

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

アラート ポリシーを定義する

アラート ポリシーを作成して指標の値をモニタリングすると、条件に違反した場合に通知できます。Google Cloud HTTP/S 負荷分散ルールリソースをモニタリングするアラート ポリシーの一般的な作成手順は次のとおりです。

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

    [Monitoring] に移動

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

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

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

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

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

  1. Google Cloud Console で [モニタリング] に移動します。
    [モニタリング] に移動
  2. [ダッシュボード] > [ダッシュボードを作成] を選択します。
  3. [グラフを追加] をクリックします。
  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 で受信されてから、GFE が最後のレスポンス バイトで要求クライアントから ACK を受信するまでのレイテンシの分布。総レイテンシはリクエスト / レスポンスによって測定されるので、Connection: keep-alive を使った同じ接続上のリクエスト間の休止は測定に影響しません。この測定値は通常、Cloud Monitoring ビューで 95 パーセンタイルに縮小されます。

例: ロードバランサが、英国から 1 秒間に 1 件のリクエスト(すべて 100 ms のレイテンシ)と、米国から 1 秒間に 9 件のリクエスト(すべて 50 ms のレイテンシ)を処理しています。1 分間では、英国から 60 件、米国から 540 件のリクエストが発生することになります。モニタリング指標には、すべてのディメンションにわたる分散が保存されます。この場合、以下を要求できます。
  • 平均全体レイテンシ(300/600) - 50ms
  • 平均英国レイテンシ(30/60) - 100ms
  • 95 パーセンタイル全体レイテンシ(570/600) - 100ms
  • その他
フロントエンド 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 接続を処理したバックエンド サービスのインスタンス グループの GCP スコープ(リージョンまたはゾーン)。

使用可能なインスタンス グループが存在しない場合やリクエストが別のエンティティによって処理された場合は、バックエンド サービスのインスタンス グループのリージョンやゾーンではなく、次の値のいずれかが表示されます。
  • 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 ZONE インスタンス グループがゾーン インスタンス グループの場合、ユーザー リクエストを処理したインスタンス グループの GCP ゾーン。(たとえば、us-central1-aeurope-west1-basia-east1-c

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

このオプションを選択すると、グラフにフロントエンド指標(クライアントからロードバランサへ)ではなく、バックエンド指標(ロードバランサからバックエンドへ)が表示されます。
PROXY CONTINENT ユーザーの HTTP(S) 接続を終了した HTTP(S) GFE の大陸(たとえば、AmericaEuropeAsia
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 SERVICE ユーザー リクエストを処理したバックエンド サービスの名前。
MATCHED URL RULE ユーザー HTTP(S) リクエストのプレフィックスと一致する URL マップパス ルール(最大 50 文字)。
FORWARDING RULE リクエストを送信するためにクライアントに使用された転送ルールの名前。

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

次のステップ