バックエンド サービスのログと指標

このドキュメントでは、従来のアプリケーション ロードバランサ、グローバル外部アプリケーション ロードバランサ、Cloud CDN を使用した Cloud Logging と Cloud Monitoring の構成方法と使用方法について説明します。

ロギング

外部アプリケーション ロードバランサのバックエンド サービスのログの有効化、無効化、表示を行えます。バックエンド バケットを使用する外部アプリケーション ロードバランサの場合、ロギングは自動的に有効になり、無効にすることはできません。

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

外部アプリケーション ロードバランサに適用されるログの除外がないことを確認する必要があります。Cloud HTTP Load Balancer ログが許可されているかどうか確認する方法については、除外フィルタをご覧ください。

ログのサンプリングと収集

ロードバランサのバックエンド仮想マシン（VM）インスタンスによって処理されるリクエスト（および対応するレスポンス）がサンプリングされます。これらのサンプリングされたリクエストが処理され、ログが生成されます。logConfig.sampleRate パラメータに従って、ログエントリとして出力されるリクエストの割合を制御します。logConfig.sampleRate が 1.0（100%）の場合、すべてのリクエストのログが生成され、Cloud Logging に書き込まれます。

オプション フィールド

ログレコードには必須フィールドとオプション フィールドがあります。[ログの内容] セクションには、オプション フィールドと必須フィールドが表示されます。すべての必須フィールドは常に含まれます。保持するオプション フィールドはカスタマイズできます。

  • [すべてのオプションのフィールドを含める] を選択すると、ログレコード形式のすべてのオプションのフィールドがログに含まれます。新しいオプション フィールドがレコード形式に追加されると、ログに新しいフィールドが自動的に含まれます。

  • [すべてのオプションのフィールドを除外する] を選択した場合、オプション フィールドはすべて省略されます。

  • [カスタム] を選択した場合は、含めるオプション フィールド（tls.protocol,tls.cipher,orca_load_report.cpu_utilization,orca_load_report.mem_utilization など）を指定できます。

オプション フィールドのカスタマイズ手順については、新しいバックエンド サービスでロギングを有効にするをご覧ください。

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

コンソール

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. ロードバランサの名前をクリックします。

  3. [編集] をクリックします。

  4. [バックエンドの構成] をクリックします。

  5. [バックエンド サービスを作成] を選択します。

  6. 必須のバックエンド サービス フィールドに入力します。

  7. [ロギング] セクションで、[ロギングを有効にする] チェックボックスをオンにします。

  8. [サンプルレート] の値を選択します。0.0 から 1.0 までの数値を設定できます。0.0 はリクエストがログに記録されていないことを意味し、1.0 はリクエストの 100% がログに記録されることを意味します。デフォルト値は 1.0 です。

  9. 省略可: ログにすべてのオプション フィールドをすべて含めるには、[任意項目] セクションで [すべてのオプションのフィールドを含める] をクリックします。

  10. バックエンド サービスの編集を終了するには、[更新] をクリックします。

  11. ロードバランサの編集を終了するには、[更新] をクリックします。

gcloud: グローバル モード

gcloud compute backend-services create コマンドを使用してバックエンド サービスを作成し、ロギングを有効にします。

gcloud compute backend-services create BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --logging-optional=LOGGING_OPTIONAL_MODE \
    --logging-optional-fields=OPTIONAL_FIELDS

gcloud compute backend-services create コマンドは次のフィールドをサポートしています。

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

  • --logging-optional を使用すると、ログに含めるオプション フィールドを指定できます。

    • INCLUDE_ALL_OPTIONAL: すべてのオプション フィールドを含めます。

    • EXCLUDE_ALL_OPTIONAL（デフォルト）: すべてのオプション フィールドを除外します。

    • CUSTOM: OPTIONAL_FIELDS で指定するオプション フィールドのカスタムリストを含めます。

  • --logging-optional-fields を使用すると、ログに含めるオプション フィールドのカンマ区切りのリストを指定できます。

    たとえば、tls.protocol,tls.cipher は、LOGGING_OPTIONAL_MODE が CUSTOM に設定されている場合にのみ設定できます。カスタム指標を使用して ORCA 負荷レポートの要素をロギングする場合は、LOGGING_OPTIONAL_MODE を CUSTOM に設定し、ロギングする要素を OPTIONAL_FIELDS フィールドに指定します。例: orca_load_report.cpu_utilization,orca_load_report.mem_utilization。

既存のバックエンド サービスでロギングを有効にする

コンソール

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. ロードバランサの名前をクリックします。

  3. [編集] をクリックします。

  4. [バックエンドの構成] をクリックします。

  5. バックエンド サービスの横にある [編集] をクリックします。

  6. [ロギング] セクションで、[ロギングを有効にする] チェックボックスをオンにします。

  7. [サンプルレート] フィールドで、サンプリング確率を設定します。0.0 から 1.0 までの数値を設定できます。0.0 はリクエストがログに記録されていないことを意味し、1.0 はリクエストの 100% がログに記録されることを意味します。デフォルト値は 1.0 です。

  8. バックエンド サービスの編集を終了するには、[更新] をクリックします。

  9. ロードバランサの編集を終了するには、[更新] をクリックします。

gcloud: グローバル モード

gcloud compute backend-services update コマンドを使用して、既存のバックエンド サービスでロギングを有効にします。

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

ここで

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

gcloud: 従来モード

gcloud compute backend-services update コマンドを使用して、既存のバックエンド サービスでロギングを有効にします。

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

ここで

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

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

コンソール

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. ロードバランサの名前をクリックします。

  3. [編集] をクリックします。

  4. [バックエンドの構成] をクリックします。

  5. バックエンド サービスの横にある [編集] をクリックします。

  6. ロギングを完全に無効にするには、[ロギング] セクションで [Logging を有効にする] チェックボックスをオフにします。

  7. ロギングを有効にした場合、[サンプルレート] に異なる値を設定できます。0.0 から 1.0 までの数値を設定できます。0.0 はリクエストがログに記録されていないことを意味し、1.0 はリクエストの 100% がログに記録されることを意味します。デフォルト値は 1.0 です。たとえば、0.2 は、サンプリングされたリクエストの 20% がログを生成することを意味します。

  8. バックエンド サービスの編集を終了するには、[更新] をクリックします。

  9. ロードバランサの編集を終了するには、[更新] をクリックします。

gcloud: グローバル モード

gcloud compute backend-services update コマンドを使用して、バックエンド サービスのロギングを無効にします。

ロギングの完全な無効化

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

ここで

  • --global は、バックエンド サービスがグローバルであることを示します。このフィールドは、グローバル外部アプリケーション ロードバランサで使用されるバックエンド サービスに使用します。
  • --no-enable-logging はバックエンド サービスのロギングを無効にします。

既存のバックエンド サービスでロギングのオプション フィールドを有効にする

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE \
    --logging-optional=LOGGING_OPTIONAL_MODE \
    --logging-optional-fields=OPTIONAL_FIELDS

ここで

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

  • --logging-optional を使用すると、ログに含めるオプション フィールドを指定できます。

    • INCLUDE_ALL_OPTIONAL: すべてのオプション フィールドを含めます。

    • EXCLUDE_ALL_OPTIONAL（デフォルト）: すべてのオプション フィールドを除外します。

    • CUSTOM: OPTIONAL_FIELDS で指定するオプション フィールドのカスタムリストを含めます。

  • --logging-optional-fields を使用すると、ログに含めるオプション フィールドのカンマ区切りのリストを指定できます。

    たとえば、tls.protocol,tls.cipher は、LOGGING_OPTIONAL_MODE が CUSTOM に設定されている場合にのみ設定できます。カスタム指標を使用して ORCA 負荷レポートの要素をロギングする場合は、LOGGING_OPTIONAL_MODE を CUSTOM に設定し、ロギングする要素を OPTIONAL_FIELDS フィールドに指定します。例: orca_load_report.cpu_utilization,orca_load_report.mem_utilization。

ロギングのオプション モードを CUSTOM からその他に更新

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

ここで

  • --logging-optional を使用すると、ログに含めるオプション フィールドを指定できます。

    • INCLUDE_ALL_OPTIONAL: すべてのオプション フィールドを含めます。

    • EXCLUDE_ALL_OPTIONAL（デフォルト）: すべてのオプション フィールドを除外します。

  • 既存の CUSTOM フィールドを消去するには、--logging-optional-fields を明示的に構成する必要があります。この API では、CUSTOM 以外のモードと CUSTOM フィールドを組み合わせることはできません。

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

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

gcloud: 従来モード

gcloud compute backend-services update コマンドを使用して、バックエンド サービスのロギングを無効にします。

ロギングの完全な無効化

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 には、0.0 から 1.0 までの値を指定できます。0.0 を設定すると、リクエストはまったくロギングされません。1.0 を設定すると、すべてのリクエストがロギングされます。--enable-logging パラメータの場合のみ有効です。ロギングを有効にしても、サンプリング レートが 0.0 であれば、ロギングが無効の場合と同じ結果になります。

ログを表示する

このタスクを Google Cloud コンソールで直接行う際の順を追ったガイダンスについては、「ガイドを表示」をクリックしてください。

ガイドを表示

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

ログを表示するには、[ログ エクスプローラ] ページに移動します。

[ログ エクスプローラ] に移動

  • すべてのログを表示するには、[リソース] フィルタ メニューで [Cloud HTTP ロードバランサ] > [すべての転送ルール] を選択します。

  • 1 つの転送ルールのログを表示するには、単一の転送ルール名を選択します。

  • 1 つの URL マップのログを表示するには、転送ルールを選択してから、URL マップを選択します。

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

ログフィールドには UTF-8 エンコードが適用されます。UTF-8 以外の文字セットは、疑問符に置き換えられます。従来のアプリケーション ロードバランサとグローバル外部アプリケーション ロードバランサの場合、リソースログ（resource.type="http_load_balancer"）を使用してログベースの指標をエクスポートできます。作成される指標は、「アプリケーション ロードバランサ ルール（ログベースの指標）」リソース（l7_lb_rule）に基づいています。これは、https_lb_rule リソースではなく、Cloud Monitoring ダッシュボードで使用できます。

ログの内容

外部アプリケーション ロードバランサのログエントリには、HTTP(S) トラフィックのモニタリングとデバッグに有用な情報が含まれています。ログレコードには、すべてのログレコードのデフォルト フィールドである必須フィールドが含まれています。

ログレコードには、HTTP(S) トラフィックに関する追加情報を追加するオプション フィールドが含まれています。オプション フィールドは、ストレージ コストを節約するために省略できます。

一部のログフィールドはマルチ フィールド形式であり、1 つのフィールドに複数のデータが含まれます。たとえば、tls フィールドは TlsInfo 形式で、earlyDataRequest フィールドが含まれています。これらのマルチ フィールドのフィールドについては、次のレコード形式の表で説明します。

フィールド フィールドの形式 フィールドのタイプ: 必須または省略可 説明
severity
insertID
logName		 LogEntry 必須 ログエントリで説明されている一般的なフィールド。
timestamp string（Timestamp 形式） 省略可 第 1 レイヤの GFE がリクエストを受信した時刻。
httpRequest HttpRequest 必須 HTTP リクエストをロギングするための共通プロトコル。

resource.type="http_load_balancer" に対して HttpRequest.protocol は入力されません。

​
resource MonitoredResource 必須

MonitoredResource は、ログエントリに関連付けられているリソースタイプです。

MonitoredResourceDescriptor は、型名とラベルのセットを使用して MonitoredResource オブジェクトのスキーマを記述します。詳細については、リソースラベルをご覧ください。
jsonPayload object（Struct 形式） 必須 JSON オブジェクトとして表されるログエントリ ペイロード。JSON オブジェクトには、次のフィールドが含まれています。
  • statusDetails
  • backendTargetProjectNumber
  • overrideResponseCode
  • errorService
  • errorBackendStatusDetails
  • authzPolicyInfo
  • loadBalancingScheme
  • tls
  • orca_load_report
文字列 必須 statusDetails フィールドには、ロードバランサが行った、HTTP のステータス コードを返した理由を説明する文字列が入ります。これらのログ文字列の詳細については、statusDetails HTTP 成功メッセージと statusDetails HTTP 失敗メッセージをご覧ください。
文字列 必須 backendTargetProjectNumber フィールドには、バックエンド ターゲット（バックエンド サービスまたはバックエンド バケット）が作成されたプロジェクト番号が保持されます。このフィールドの形式は "projects/PROJECT_NUMBER" です。この情報は、カスタム エラー レスポンスを使用するグローバル外部アプリケーション ロードバランサでのみ使用できます。
整数 必須 overrideResponseCode には、クライアントに送信されるレスポンスに適用されるオーバーライド レスポンス コードが保持されます。この情報は、カスタム エラー レスポンスを使用するグローバル外部アプリケーション ロードバランサでのみ使用できます。
文字列 必須 errorService フィールドには、カスタム エラー レスポンスを提供したバックエンド サービスが保持されます。この情報は、カスタム エラー レスポンスを使用するグローバル外部アプリケーション ロードバランサでのみ使用できます。
文字列 必須 errorBackendStatusDetails フィールドには、クライアントに配信される最終的なレスポンスの statusDetails が保持されます。この情報は、カスタム エラー レスポンスを使用するグローバル外部アプリケーション ロードバランサでのみ使用できます。
AuthzPolicyInfo 必須 authzPolicyInfo フィールドには、認可ポリシーの結果に関する情報が格納されます。この情報は、認可ポリシーを有効にしているグローバル外部アプリケーション ロードバランサでのみ使用できます。詳細については、承認ポリシーでログに記録される内容をご覧ください。
文字列 省略可 loadBalancingScheme フィールドは、従来のアプリケーション ロードバランサの移行機能を使用している場合にのみ自動的に入力されます。このフィールドには、リクエストのルーティングに使用されたロード バランシング スキームを記述する文字列が保存されます。有効な値は EXTERNAL または EXTERNAL_MANAGED です。
TlsInfo 必須

tls フィールドには、クライアントとロードバランサ間の接続の TLS メタデータを指定する TlsInfo フィールドが保持されます。このフィールドは、クライアントが TLS / SSL 暗号化を使用している場合にのみ使用できます。

ログに記録する要素を指定するには、--logging-optional-fields パラメータを使用します。

  • 省略可: tls.protocol
  • 省略可: tls.cipher
  • 必須: tls.earlyDataRequest

--logging-optional-fields を tls に設定してすべての要素を指定することはできません。
OrcaLoadReport 省略可

orca_load_report フィールドには、バックエンドで返された ORCA 負荷レポートの一部またはすべての要素が含まれます。このフィールドは、バックエンドが ORCA 負荷レポートを返していて、ORCA 負荷レポートをログに記録するようにロードバランサが構成されている場合にのみ存在します。

--logging-optional-fields パラメータを使用して、ORCA 負荷レポートの次の要素のどれをロギングする必要があるかを指定します。

  • orca_load_report.cpu_utilization
  • orca_load_report.mem_utilization
  • orca_load_report.request_cost
  • orca_load_report.utilization
  • orca_load_report.rps_fractional
  • orca_load_report.eps
  • orca_load_report.named_metrics
  • orca_load_report.application_utilization

--logging-optional-fields を orca_load_report に設定して、すべての要素をロギングするように指定することもできます。

TlsInfo フィールドの形式

フィールド フィールドの形式 フィールドのタイプ: 必須または省略可 説明
protocol 文字列 オプション クライアントがロードバランサとの接続を確立するために使用する TLS プロトコル。有効な値は TLSv1、TLSv1.1、TLSv1.2、TLSv1.3、QUIC です。クライアントが TLS/SSL 暗号化を使用していない場合、この値は NULL に設定されます。
cipher 文字列 オプション クライアントがロードバランサとの接続を確立するために使用する TLS 暗号。クライアントが HTTP(S) を使用していない場合、またはクライアントが TLS / SSL 暗号化を使用していない場合、この値は NULL に設定されます。
earlyDataRequest ブール値 必須 リクエストの TLS handshake に早期データが含まれている。

リソースラベル

次の表に、resource.type="http_load_balancer" のリソースラベルを示します。

フィールド タイプ 説明
backend_service_name 文字列 バックエンド サービスの名前。
forwarding_rule_name 文字列 転送ルール オブジェクトの名前。
project_id 文字列 このリソースに関連付けられた Google Cloud プロジェクトの ID。
target_proxy_name 文字列 転送ルールで参照されるターゲット プロキシ オブジェクトの名前。
url_map_name 文字列 バックエンド サービスを選択するように構成された URL マップ オブジェクトの名前。
zone 文字列 ロードバランサが実行されているゾーン。ゾーンは global です。

statusDetails 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 レスポンス コードは、バックエンドで実行されているソフトウェアによって設定されます。

statusDetails HTTP 失敗メッセージ

statusDetails（異常終了） 意味 共通の付随ステータス コード
aborted_request_due_to_backend_early_response 本文付きのリクエストは、バックエンドが早期レスポンスを送信したため中断され、ステータス コードが返されました。レスポンスはクライアントに転送されました。リクエストは終了しました。 4XX または 5XX
backend_connection_closed_after_partial_response_sent クライアントに部分的レスポンスが送られた後、バックエンドへの接続が予期せず閉じました。

HTTP ステータス コードは、バックエンドで実行されているソフトウェアによって設定されます。 HTTP ステータス コード 0（ゼロ）は、バックエンドが不完全な HTTP ヘッダーを送信したことを意味します。

HTTP(S) 接続が WebSocket 接続にアップグレードされた場合、HTTP ステータス コードは 101 です。
backend_connection_closed_before_data_sent_to_client バックエンドは、レスポンスがクライアントにプロキシされる前に、予期せずロードバランサへの接続を閉じました。

502、503

HTTP(S) 接続が WebSocket 接続にアップグレードされた場合、HTTP ステータス コードは 101 です。
backend_early_response_with_non_error_status バックエンドは、リクエスト本文全体を受信する前に、リクエストに対するエラー以外のステータス コード（1XX または 2XX）を送信しました。 502、503
backend_interim_response_not_supported バックエンドは、暫定レスポンスがサポートされていないコンテキストでリクエストに暫定 1XX ステータス コードを送信しました。

502、503
backend_response_corrupted バックエンドによって送信された HTTP レスポンス本文のチャンクの転送エンコードが無効か、レスポンス本文が破損しています。 任意のステータス コード。破損の性質によって異なります。多くの場合、502、503 です。
backend_response_headers_too_long バックエンドから送信された HTTP レスポンス ヘッダーが上限を超えました。詳細については、外部アプリケーション ロードバランサのヘッダーサイズをご覧ください。 502、503
backend_timeout

バックエンドは、レスポンスを生成中にタイムアウトしました。

WebSocket 接続の場合:

  • グローバル外部アプリケーション ロードバランサの場合、バックエンド サービスのタイムアウトが経過した後、GFE がアイドル状態の WebSocket 接続を閉じると、ステータス コードが生成されます。
  • 従来のアプリケーション ロードバランサの場合、バックエンド サービスのタイムアウトが経過した後、GFE がアイドル状態またはアクティブ状態の WebSocket 接続を閉じると、ステータス コードが生成されます。

502、503

HTTP(S) 接続が WebSocket 接続にアップグレードされた場合、HTTP ステータス コードは 101 です。
banned_by_security_policy リクエストは Google Cloud Armor のレートベースの禁止ルールによって拒否されました。 429
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 ロードバランサが部分的レスポンスを送信した後で、クライアントへの接続が切断されました。

バックエンドからの戻り値（任意のステータス コード）。

HTTP(S) 接続が WebSocket 接続にアップグレードされた場合、HTTP ステータス コードは 101 です。
client_disconnected_before_any_response ロードバランサが、何らのレスポンスも送信する前に、クライアントへの接続が切断されました。

0

HTTP(S) 接続が WebSocket 接続にアップグレードされた場合、HTTP ステータス コードは 101 です。
client_timed_out Google Front End（GFE）、リクエストまたはレスポンスのいずれかをプロキシ処理する間に、進捗がないため、クライアント接続をアイドル状態にしました。 0 または 408
client_cert_invalid_rsa_key_size クライアントのリーフ証明書または中間証明書の RSA 鍵のサイズが無効です。 詳細については、閉じられた接続についてログに記録されたエラーをご覧ください。 0
client_cert_unsupported_elliptic_curve_key クライアント証明書または中間証明書で、サポートされていない楕円曲線が使用されています。詳細については、閉じられた接続についてログに記録されたエラーをご覧ください。 0
client_cert_unsupported_key_algorithm クライアント証明書または中間証明書が、非 RSA または ECDSA 以外のアルゴリズムを使用しています。詳細については、閉じられた接続についてログに記録されたエラーをご覧ください。 0
client_cert_pki_too_large 検証に使用する PKI に、同じサブジェクトとサブジェクトの公開鍵情報を共有する中間証明書が 10 個以上あります。詳細については、閉じられた接続についてログに記録されたエラーをご覧ください。 0
client_cert_chain_max_name_constraints_exceeded 検証に指定された中間証明書に 10 を超える名前の制約があります。詳細については、閉じられた接続についてログに記録されたエラーをご覧ください。 0
client_cert_chain_invalid_eku クライアント証明書またはその発行元のいずれかに、clientAuth を含む鍵の拡張的用途（EKU）がありません。詳細については、閉じられた接続についてログに記録されたエラーをご覧ください。 0
client_cert_validation_timed_out 証明書チェーンの検証中に時間制限を超えました。詳細については、閉じられた接続についてログに記録されたエラーをご覧ください。 0
client_cert_validation_search_limit_exceeded 証明書チェーンの検証中に、深度または反復処理の上限に達しました。詳細については、閉じられた接続についてログに記録されたエラーをご覧ください。 0
client_cert_validation_not_performed TrustConfig を設定せずに mTLS が構成されています。詳細については、閉じられた接続についてログに記録されたエラーをご覧ください。 0
client_cert_not_provided クライアントが handshake 中にリクエストされた証明書を提示しませんでした。 詳細については、閉じられた接続についてログに記録されたエラーをご覧ください。 0
client_cert_validation_failed MD4、MD5、SHA-1 などのハッシュ化アルゴリズムを使用すると、クライアント証明書が TrustConfig の検証に失敗します。詳細については、閉じられた接続についてログに記録されたエラーをご覧ください。 0
config_not_found

ロードバランサにプロジェクト構成がありません。このエラーは特に、新しいリソースを追加する構成変更を行った後に、断続的に発生することがあります。

このエラーの別の原因として、第 1 レイヤの GFE が第 2 レイヤの GFE に到達できないことも考えられます。これは、進行中のロールアウト、ロードバランサの過負荷、断続的な構成の問題など、内部エラーが原因である可能性があります。

これらのエラーは一時的なもので、SLA の範囲内です。ただし、エラー率が 0.01% を超える場合は、Google Cloud サポートにお問い合わせください。

 404、502、503
direct_response ロードバランサがこのリクエストをオーバーライドして、固定レスポンスを返しました。 問題の性質に応じて、HTTP ステータス コードが表示されます。たとえば、HTTP 410 ステータス コードは、支払いの滞納が原因でバックエンドが利用できないことを意味します。
denied_by_security_policy Google Cloud Armor のセキュリティ ポリシーが原因で、ロードバランサがリクエストを拒否しました。 セキュリティ ポリシーで構成されています。
error_uncompressing_gzipped_body gzip で圧縮された HTTP レスポンスの解凍エラーが発生しました。 502、503
failed_to_connect_to_backend ロードバランサは、バックエンドに接続できませんでした。これには、接続フェーズ中のタイムアウトが含まれます。 502、503
failed_to_pick_backend ロードバランサは、リクエストを処理するための正常なバックエンドを選択できませんでした。 502、503
failed_to_negotiate_alpn ロードバランサとバックエンドは、TLS での通信に使用するアプリケーション レイヤ プロトコル（HTTP/2 など）のネゴシエーションに失敗しました。 502、503
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_request_headers

クライアントから受信した HTTP リクエスト ヘッダーに、該当する HTTP 仕様で許可されていない文字が 1 つ以上含まれています。

たとえば、二重引用符（"）や標準 ASCII 範囲外の文字（0x80 以上のバイト）を含むヘッダー フィールド名は無効です。

詳しくは以下をご覧ください。

 400
invalid_http2_client_header_format クライアントからの HTTP/2 ヘッダーが無効です。詳しくは invalid_request_headers をご覧ください。 400
invalid_http2_client_request_path

クライアントからの HTTP/2 リクエストパスに、URI 仕様で許可されていない文字が 1 つ以上含まれています。

詳細については、RFC 3986 の「3.3. Path」セクションをご覧ください。

 400
multiple_iap_policies 複数の Identity-Aware Proxy（IAP）ポリシーを組み合わせることはできません。バックエンド サービスに IAP ポリシーが接続され、別のポリシーがサーバーレス オブジェクトに接続されている場合は、いずれかのポリシーを削除してもう一度試してください。サーバーレス オブジェクトに App Engine、Cloud Run、Cloud Run functions が含まれています。 500
malformed_chunked_body リクエストの本文のチャンク エンコードが不適切です。 411
request_loop_detected ロードバランサがリクエスト ループを検出しました。このループは、構成ミスにより、バックエンドがロードバランサにリクエストを転送した場合に発生します。 502、503
required_body_but_no_content_length HTTP リクエストは本文を要求していますが、リクエスト ヘッダーに content-length ヘッダーまたは transfer-encoding: chunked ヘッダーが含まれていませんでした。 400、403、411
secure_url_rejected https:// URL 付きのリクエストが、平文の HTTP/1.1 接続を介して受信されました。 400
server_cert_chain_exceeded_limit サーバー証明書チェーンが長すぎる（サーバー証明書に 10 を超える中間証明書が含まれる）。 502、503

server_cert_chain_invalid_eku

 サーバー証明書に Extended Key Usage (EKU) 拡張フィールドがありますが、そのフィールドに serverAuth が含まれていません。

server_cert_chain_max_name_constraints_exceeded

 検証に指定された中間証明書に 10 を超える名前の制約がある。 502、503
server_cert_exceeded_size_limit サーバー証明書のペイロード（中間証明書を含む）が大きすぎる（16 KB 超）。 503
server_cert_invalid_rsa_key_size

サーバー証明書または中間証明書の RSA 鍵のサイズが無効。

検証は実行されません。

RSA 鍵の長さは 2,048～4,096 ビットです。

 503
server_cert_not_provided サーバーが handshake 中にリクエストされた証明書を提示しなかった。 503
server_cert_pki_too_large

検証に使用する PKI に、同じサブジェクトとサブジェクトの公開鍵情報を共有する 11 個以上の中間証明書がある。

検証は実行されません。

 503
server_cert_trust_config_not_found 一致する TrustConfig が見つからない。 503
server_cert_unsupported_elliptic_curve_key

サーバー証明書または中間証明書で、サポートされていない楕円曲線が使用されています。

検証は実行されません。

有効な曲線は P-256 と P-384 です。

 503
server_cert_unsupported_key_algorithm

サーバー証明書または中間証明書が、非 RSA または ECDSA 以外のアルゴリズムを使用しています。

検証は実行されません。

 503
server_cert_validation_internal_error 証明書チェーンの検証中に内部エラーが発生した。 503
server_cert_validation_not_performed

TrustConfig リソースを設定せずに mTLS を構成した。

 503
server_cert_validation_search_limit_exceeded

証明書チェーンの検証中に、深度または反復処理の上限に達しました。

証明書チェーンの最大深度は、ルート証明書とサーバー証明書を含めて 10 です。反復処理の上限は 100 回です（サーバー証明書チェーンの検証のために確認された証明書）。

 503
server_cert_validation_timed_out 証明書チェーンの検証中に制限時間を超過した。 503
server_cert_validation_unavailable サービスで証明書チェーンの検証を実行できない。 503
ssl_certificate_san_verification_failed ロードバランサは、構成されたホスト名と一致するバックエンドから提示された SSL 証明書でサブジェクト代替名（SAN）を見つけることができません。 502、503
ssl_certificate_chain_verification_failed バックエンドによって提示された SSL 証明書が SSL 証明書の検証で不合格となりました。 502、503
throttled_by_security_policy リクエストは Google Cloud Armor のスロットル ルールによってブロックされました。 429
unsupported_method クライアントは、指名されていない HTTP リクエスト メソッドを指定しました。 400
unsupported_100_continue クライアント リクエストに「Expect: 100-continue」ヘッダーが含まれていますが、これはプロトコルでサポートされていません。 400
upgrade_header_rejected クライアントの HTTP リクエストにはアップグレード ヘッダーが含まれ、拒否されました。 400
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、503

429（IAP によってスロットリング）
serverless_neg_routing_failed サーバーレス NEG リクエストはディスパッチできません。このエラーは、NEG で指定されたリージョンに到達できない場合、またはリソース名（Cloud Run functions 名など）が見つからない場合に発生します。 404、502、503
fault_filter_abort このエラーは、お客様が障害フィルタを構成していて、特定のリクエストに対してその障害フィルタがトリガーされた場合に発生します。 値は 200～599 にする必要があります。
early_data_rejected

TLS 早期データで送信されたリクエストが無効でした。

これは、次のような場合に発生することがあります（ただし、これらに限定されません）。

  • TargetHttpsProxy の TLS 早期データが STRICT に設定されているが、リクエストにクエリ パラメータが含まれている。
  • TargetHttpsProxy の TLS 早期データが STRICT または PERMISSIVE に設定されているが、リクエストで非べき等の HTTP メソッド（POST や PUT など）が使用されている。
 425

mTLS クライアント証明書検証のログを表示する

相互 TLS クライアント証明書の検証中に、閉じられた接続についてログに記録されたエラーを表示するには、次の操作を行います。

コンソール クエリ

  1. Google Cloud コンソールで、[ログ エクスプローラ] ページに移動します。

    [ログ エクスプローラ] に移動

  2. [クエリを表示] をクリックします。

  3. または、[クエリ] フィールドに次の内容を貼り付けます。FORWARDING_RULE_NAME は、転送ルールの名前に置き換えます。

    jsonPayload.statusDetails=~"client_cert"
jsonPayload.@type="type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
resource.labels.forwarding_rule_name=FORWARDING_RULE_NAME

  4. [クエリを実行] をクリックします。

認可ポリシー リクエスト ログ

Load Balancer ログエントリ JSON ペイロードの authz_info オブジェクトには、認可ポリシーに関する情報が含まれています。これらのポリシーによって許可または拒否されたトラフィックのログベースの指標を構成できます。認可ポリシーのログの詳細をご確認ください。

フィールド タイプ 説明
authz_info.policies[] オブジェクト リクエストに一致するポリシーのリスト。
authz_info.policies[].name 文字列 リクエストに一致する認可ポリシーの名前。

名前が空である理由は次のとおりです。

  • リクエストに一致する ALLOW ポリシーがないため、リクエストは拒否されます。
  • リクエストに一致する DENY ポリシーがないため、リクエストが許可されます。
authz_info.policies[].result enum 結果は ALLOWED または DENIED のいずれかになります。
authz_info.policies[].details 文字列 詳細には次のものが含まれます。
  • allowed_as_no_deny_policies_matched_request
  • denied_as_no_allow_policies_matched_request
  • denied_by_authz_extension
  • denied_by_cloud_iap
authz_info.overall_result enum 結果は ALLOWED または DENIED のいずれかになります。

Google Cloud Armor のロギング

statusDetail HTTP エラー メッセージの表には、Google Cloud Armor に適用されるメッセージが含まれています。Google Cloud Armor が記録する内容については、リクエスト ロギングの使用をご覧ください。

共有 VPC デプロイのロギング

通常、アプリケーション ロードバランサのログと指標は、転送ルールがあるプロジェクトにエクスポートされます。したがって、サービス管理者（バックエンド サービスが作成されたプロジェクトのオーナーまたはユーザー）は、デフォルトではロードバランサのログと指標にアクセスできません。IAM ロールを使用して、これらの権限をサービス管理者に付与できます。使用可能な IAM ロールとアクセス権を付与する方法について詳しくは、Monitoring へのアクセス権を付与するをご覧ください。

ログの操作

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

モニタリング

ロードバランサは、モニタリング データを Monitoring にエクスポートします。

モニタリング指標を使用すると、次のことができます。

  • ロードバランサの構成、使用状況、パフォーマンスを評価する
  • 問題を解決する
  • リソースの使用率とユーザー エクスペリエンスを改善する

指標報告の頻度と保持

外部アプリケーション ロードバランサの指標は、1 分単位のバッチで Cloud Monitoring にエクスポートされます。モニタリング データは 6 週間保持されます。

ダッシュボードでは、1H（1 時間）、6H（6 時間）、1D（1 日）、1W（1 週間）、6W（6 週間）のデフォルト間隔でデータ分析の結果を確認できます。また、6 週間から 1 分までの間隔を任意に指定して手動で分析を行うこともできます。

モニタリング指標

外部アプリケーション ロードバランサの次の指標をモニタリングできます。

グローバル外部アプリケーション ロードバランサの次の指標が、Cloud Monitoring に報告されます。指標の先頭には loadbalancing.googleapis.com/ が付加されます。

指標 名前 説明
リクエスト数 https/request_count 外部アプリケーション ロードバランサによって処理されるリクエストの数。
リクエスト バイト数 https/request_bytes_count クライアントから外部アプリケーション ロードバランサへのリクエストとして送信されたバイト数
レスポンス バイト数 https/response_bytes_count 外部アプリケーション ロードバランサからクライアントへのレスポンスとして送信されたバイト数
総レイテンシ https/total_latencies

合計レイテンシの分布。合計レイテンシは、プロキシが受信したリクエストの最初のバイトから、プロキシが送信したレスポンスの最後のバイトまでの時間（ミリ秒単位）です。これには、プロキシがリクエストを処理する時間、プロキシからバックエンドにリクエストを送信する時間、バックエンドがリクエストを処理する時間、レスポンスがプロキシに返送される時間、プロキシがレスポンスを処理してクライアントにレスポンスを送信する時間などが含まれます。

クライアントとプロキシ間の RTT は含まれません。Connection: keep-alive を使った同じ接続上のリクエスト間の休止は測定に影響しません。この測定値は通常、Cloud Monitoring ビューで 95 パーセンタイルに縮小されます。

WebSocket 接続の場合、このフィールドは接続の全期間を指します*。

例: ロードバランサが、英国から 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

フロントエンド RTT の分布。フロントエンド RTT は、データがクライアントからプロキシに移動し、プロキシからクライアントに戻るまでにかかる時間（ミリ秒単位）です。これには、リクエストがクライアントからプロキシに移動し、プロキシからクライアントに戻るまでにかかる時間が含まれます。これは、接続の存続期間中は更新されません。たとえば、3-way handshake で（TCP）接続をセットアップするには 1.5 RTT かかります。

リクエストが処理されると、ロードバランサはクライアントとプロキシ間でデータが往復する時間をサンプリングして平均化し、平滑化された RTT 値をログに記録します。平滑化された RTT は、RTT 測定値で発生する可能性のある変動と異常を処理するアルゴリズムです。
バックエンド レイテンシ† https/backend_latencies

バックエンドのレイテンシの分布。バックエンドのレイテンシは、バックエンドが受信したリクエストの最初のバイトから、プロキシが受信したレスポンスの最後のバイトまでの時間（ミリ秒単位）です。これには、プロキシからバックエンドにリクエストを送信する時間、バックエンドでリクエストを処理する時間、レスポンスをプロキシに返信する時間などが含まれます。
レスポンス コードクラス比 各レスポンス コードクラス（2XX、4XX、...）にある外部アプリケーション ロードバランサのレスポンスの合計割合。Monitoring では、この値はデフォルトのダッシュボードでのみ取得できます。カスタム ダッシュボードでは取得できません。Monitoring API を使用して、アラートを設定できます。
バックエンドのリクエスト数 https/backend_request_count 外部アプリケーション ロードバランサからバックエンドに送信されたリクエストの数。
バックエンド リクエストのバイト数 https/backend_request_bytes_count 外部アプリケーション ロードバランサからバックエンドへのリクエストとして送信されたバイト数。
バックエンド レスポンスのバイト数 https/backend_response_bytes_count バックエンドから外部アプリケーション ロードバランサへのレスポンスとして送信されたバイト数（キャッシュを含む）。

* WebSocket 接続をモニタリングするには、WebSocket 専用のバックエンド サービスを作成します。

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

指標のディメンションのフィルタリング

外部アプリケーション ロードバランサの指標にフィルタを適用できます。

従来のアプリケーション ロードバランサと、グローバル外部アプリケーション ロードバランサのそれぞれについて指標が集計されます。集計された指標は、resource.type="http_load_balancer" または resource.type="https_lb_rule" の次のディメンションでフィルタリングできます。すべてのディメンションがすべての指標で使用できるわけではありません。

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

使用可能なインスタンス グループが存在しない場合やリクエストが別のエンティティによって処理された場合は、バックエンド サービスのインスタンス グループのリージョンやゾーンではなく、次の値のいずれかが表示されます。

  • FRONTEND_5XX: GFE がバックエンドを選択する前に内部エラーが発生しました。GFE からクライアントに 5XX が返されました。
  • INVALID_BACKEND: リクエストを割り当て可能な正常なバックエンドが見つからなかったため、GFE からリクエスト送信元に 5XX レスポンスが返されました。
  • NO_BACKEND_SELECTED: バックエンドを選択する前にエラーまたはその他の割り込みが発生したか、URL リダイレクトが発生しました。
  • MULTIPLE_BACKENDS: リクエストが複数のバックエンドによって処理された可能性があります。これは、Cloud CDN がキャッシュからリクエストの一部を処理し、1 つ以上のバイト範囲リクエストをバックエンドに送信したときに発生することがあります。backend_scope のオプションを使用して、ロードバランサとバックエンドとの間のリクエストを可視化します。

このオプションを選択すると、グラフにフロントエンド指標（クライアントからロードバランサへ）ではなく、バックエンド指標（ロードバランサからバックエンドへ）が表示されます。
backend_type

クライアントのリクエストを処理したバックエンド グループの名前。INSTANCE GROUP と NETWORK_ENDPOINT_GROUP のいずれかで、バックエンドが割り当てられていない場合は UNKNOWN が返されます。使用可能なバックエンド グループが存在しない、またはリクエストが別のエンティティによって処理された場合は、バックエンド グループではなく、次の値のいずれかが表示されます。

  • FRONTEND_5XX: GFE がバックエンドを選択する前に内部エラーが発生しました。GFE からクライアントに 5XX が返されました。
  • INVALID_BACKEND: リクエストを割り当て可能な正常なバックエンドが見つからなかったため、GFE からリクエスト送信元に 5XX レスポンスが返されました。
  • NO_BACKEND_SELECTED: バックエンドが選択される前または URL リダイレクトが発生する前に、エラーまたはその他の割り込みが発生しました。
  • MULTIPLE_BACKENDS: リクエストが複数のバックエンドによって処理された可能性があります。これは、Cloud CDN がキャッシュからリクエストの一部を処理し、1 つ以上のバイト範囲リクエストをバックエンドに送信したときに発生することがあります。backend_scope のオプションを使用して、ロードバランサとバックエンドとの間のリクエストを可視化します。
backend_target_type リクエストを処理したバックエンド サービスの名前。BACKEND_SERVICE と BACKEND_BUCKET のいずれかですが、バックエンドが割り当てられていない場合は UNKNOWN、バックエンドが選択できるようになる前にエラーやその他の割り込みが発生した、または URL リダイレクトが発生した場合は NO_BACKEND_SELECTED です。
matched_url_path_rule HTTP(S) リクエストのプレフィックスと一致する URL マップパス ルール（最大 50 文字）。
forwarding_rule_name リクエストを送信するため、クライアントによって使用された転送ルールの名前。
url_map_name

URL マップキーの一部として構成された URL マップ パスルールまたはルートルール。フォールバックとして UNMATCHED または UNKNOWN の場合もあります。

  • UNMATCHED は、どの URL パスルールにも一致しないリクエストを示しているので、url_map_name はデフォルトのパスルールを使用します。
  • UNKNOWN は内部エラーを表します。
target_proxy_name 転送ルールで参照されるターゲット HTTP(S) プロキシ オブジェクトの名前。
backend_target_name バックエンド ターゲットの名前。ターゲットは、バックエンド サービスとバックエンド バケットのいずれかです。バックエンドが割り当てられていない場合は、UNKNOWN が返されます。
backend_name バックエンド インスタンス グループ、バケット、または NEG の名前。バックエンドが割り当てられなかった場合は UNKNOWN が返されます。バックエンドを選択できるようになる前にエラーやその他の割り込みが発生した場合、または URL リダイレクトが発生した場合は NO_BACKEND_SELECTED が返されます。
backend_scope_type

バックエンド グループのスコープのタイプ。GLOBAL、REGION、ZONE、MULTIPLE_BACKENDS のいずれかですが、バックエンドを選択できるようになる前にエラーやその他の割り込みが発生した場合、URL リダイレクトが発生した場合は NO_BACKEND_SELECTED で、他の backend_type 出力になることもあります。

チャンク キャッシュが使用される場合、MULTIPLE_BACKENDS が使用されます。1 つのクライアント リクエストをサポートするため、データの複数のチャンクに対して複数のクエリが、同じバックエンドに送信されます。
proxy_continent HTTP(S) 接続を終了した HTTP(S) GFE の大陸（例: America、Europe、Asia）
protocol クライアントが使用するプロトコル（HTTP/1.0、HTTP/1.1、HTTP/2.0、QUIC/HTTP/2.0、UNKNOWN のいずれか）。
response_code リクエストの HTTP ステータス コード。
response_code_class リクエストの HTTP ステータス コードクラス: 200、300、400、500、または 0（なしの場合）。
cache_result プロキシによる HTTP リクエストの処理のキャッシュ結果: HIT、MISS、DISABLED、PARTIAL_HIT（キャッシュとバックエンドからそれぞれ部分的に処理されたリクエスト）、UNKNOWN。
client_country HTTP リクエストを発行したクライアントの国（例: United States、Germany）
load_balancing_scheme 使用されるロード バランシング スキーム。従来のアプリケーション ロードバランサを使用している場合、値は EXTERNAL です。グローバル外部アプリケーション ロードバランサを使用する場合、値は EXTERNAL_MANAGED です。

次のステップ