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

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

ロギング

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

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

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

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

コンソール

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

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

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

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

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

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

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

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

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

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

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

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

ここで

  • --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 create コマンドを使用してバックエンド サービスを作成し、ロギングを有効にします。

gcloud compute backend-services create BACKEND_SERVICE \
 --global \
 --enable-logging \
 --logging-sample-rate=VALUE \
 --load-balancing-scheme=EXTERNAL

ここで

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

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

コンソール

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

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

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

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

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

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

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

  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 Console で、[ロード バランシング] ページに移動します。

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

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

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

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

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

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

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

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

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

gcloud: グローバル モード

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

ロギングの完全な無効化

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

ここで

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

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

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) トラフィックのモニタリングとデバッグに有用な情報が含まれています。ログレコードには、すべてのログレコードのデフォルト フィールドである必須フィールドが含まれています。

フィールド フィールドの形式 フィールドのタイプ: 必須または省略可 説明
severity
insertID
logName		 LogEntry 必須 ログエントリで説明されている一般的なフィールド。
timestamp string (Timestamp format) 省略可 第 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
文字列 必須 statusDetails フィールドには、ロードバランサが行った、HTTP のステータスを返した理由を説明する文字列が入ります。これらのログ文字列の詳細については、statusDetails HTTP 成功メッセージと statusDetails HTTP 失敗メッセージをご覧ください。
文字列 必須 backendTargetProjectNumber フィールドには、バックエンド ターゲット（バックエンド サービスまたはバックエンド バケット）が作成されたプロジェクト番号が保持されます。このフィールドの形式は "projects/PROJECT_NUMBER" です。この情報は、カスタム エラー レスポンスを使用するグローバル外部アプリケーション ロードバランサでのみ使用できます。
integer 必須 overrideResponseCode には、クライアントに送信されるレスポンスに適用されるオーバーライド レスポンス コードが保持されます。この情報は、カスタム エラー レスポンスを使用するグローバル外部アプリケーション ロードバランサでのみ使用できます。
文字列 必須 errorService フィールドには、カスタムエラー レスポンスを提供したバックエンド サービスが保持されます。この情報は、カスタム エラー レスポンスを使用するグローバル外部アプリケーション ロードバランサでのみ使用できます。
文字列 必須 errorBackendStatusDetails フィールドには、クライアントに配信される最終的なレスポンスの statusDetails が保持されます。この情報は、カスタム エラー レスポンスを使用するグローバル外部アプリケーション ロードバランサでのみ使用できます。

リソースラベル

次の表に、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 に、同じサブジェクトとサブジェクト公開鍵情報を共有する中間証明書が 3 つ以上あります。詳細については、閉じられた接続についてログに記録されたエラーをご覧ください。 0
client_cert_chain_max_name_constraints_exceeded 検証に指定された中間証明書に 10 を超える名前の制約があります。詳細については、閉じられた接続についてログに記録されたエラーをご覧ください。 0
client_cert_chain_invalid_eku クライアント証明書またはその発行元のいずれかに、clientAuth を含む Extended Key Usage（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

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

プロキシには 2 つのレイヤがあるため、第 1 層の GFE が第 2 層の GFE に到達できない場合があります。これは、進行中のロールアウト、ロードバランサの過負荷、断続的な構成の問題など、内部エラーが原因である可能性があります。

 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
multiple_iap_policies 複数の Identity-Aware Proxy（IAP）ポリシーを組み合わせることはできません。バックエンド サービスに IAP ポリシーが接続され、別のポリシーがサーバーレス オブジェクトに接続されている場合は、いずれかのポリシーを削除してもう一度試してください。サーバーレス オブジェクトに App Engine、Cloud Run、Cloud Run 関数が含まれています。 500
malformed_chunked_body リクエストの本文のチャンク エンコードが不適切です。 411
request_loop_detected ロードバランサがリクエスト ループを検出しました。このループは、構成ミスにより、バックエンドがロードバランサにリクエストを転送した場合に発生します。 502、503
required_body_but_no_content_length HTTP リクエストは本文を要求していますが、リクエスト ヘッダーに content-length ヘッダーまたは transfer-encoding: chunked ヘッダーが含まれていませんでした。 400 または 403
secure_url_rejected https:// URL 付きのリクエストが、平文の HTTP/1.1 接続を介して受信されました。 400
ssl_certificate_san_verification_failed ロードバランサは、構成されたホスト名と一致するバックエンドにより提示される SSL 証明書の SAN（Subject Alternative Name）を見つけられませんでした。 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
serverless_neg_routing_failed サーバーレス NEG リクエストはディスパッチできません。このエラーは、NEG で指定されたリージョンに到達できない場合、またはリソース名（Cloud Run 関数名など）が見つからない場合に発生します。 404、502、503
fault_filter_abort このエラーは、お客様が障害フィルタを構成していて、特定のリクエストに対してその障害フィルタがトリガーされた場合に発生します。 値は 200～599 にする必要があります。

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 について詳しくは、Cloud Logging API の概要をご覧ください。

モニタリング

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

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

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

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

事前定義された Cloud Monitoring ダッシュボードの表示

Cloud Monitoring には、ロードバランサをモニタリングする事前定義されたダッシュボードが用意されています。事前定義されたダッシュボードには、Cloud Monitoring によって自動的にデータが入力されます。

事前定義されたダッシュボードにアクセスするには、次の手順を行います。

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

    [モニタリング] に移動

  2. Monitoring のナビゲーション パネルで、[ダッシュボード] をクリックします。

  3. [カテゴリ] で [GCP] をクリックします。

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

    • 外部アプリケーション ロードバランサ専用の事前定義ダッシュボードを表示するには、[外部 HTTP(S) ロードバランサ] というダッシュボードを選択します。このページには、プロジェクト内のすべての外部アプリケーション ロードバランサの 5XX レスポンスの割合とバックエンド レイテンシのダッシュボードが表示されます。また、プロジェクト内のすべての外部アプリケーション ロードバランサを示すダッシュボードのリストも示されます。

      クリックすると各ロードバランサのダッシュボードに移動できます。各ダッシュボードには次のものが含まれます。

      • レスポンス コードクラス（5XX、4XX、3XX、2XX）ごとにレスポンスの内訳を表示する事前入力されたグラフ
      • 合計レイテンシ
      • バックエンド レイテンシ
      • フロントエンド RTT
      • リクエスト数
      • ロードバランサのログへのリンク

  4. サードパーティ サービスのダッシュボードを表示するには、[ダッシュボード] ページに戻ります。[カテゴリ] で [その他] をクリックします。

    • 特定のサードパーティのサービス ダッシュボードを表示するには、リストからダッシュボードを見つけてその名前をクリックします。

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

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

ガイドを表示

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

  1. Google Cloud コンソールで、[アラート] ページに移動します。

    [アラート] に移動

    検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。

  2. 通知チャンネルを作成せずに通知を受け取る場合は、[EDIT NOTIFICATION CHANNELS] をクリックして、通知チャンネルを追加します。チャンネルを追加したら、[アラート] ページに戻ります。
  3. [アラート] ページで、[CREATE POLICY] をクリックします。
  4. 指標を選択するには、[指標を選択] メニューを開き、次の操作を行います。
    1. メニューを関連するエントリに限定するには、フィルタバーに「Global External Application Load Balancer Rule」と入力します。結果が表示されない場合は、[Show only active resources & metrics] をオフに切り替えます。
    2. [リソースの種類] で、[グローバル外部アプリケーション ロードバランサ ルール] を選択します。
    3. 指標カテゴリと指標を選択して、[適用] を選択します。
  5. [次へ] をクリックします。
  6. [Configure alert trigger] ページの設定によって、アラートがトリガーされるタイミングが決まります。条件タイプを選択し、必要に応じてしきい値を指定します。詳細については、指標しきい値のアラート ポリシーを作成するをご覧ください。
  7. [次へ] をクリックします。
  8. （省略可）アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャンネルを選択し、[OK] をクリックします。
  9. （省略可）インシデントの自動クローズ期間を更新します。このフィールドは、指標データがない場合に Monitoring がインシデントを閉じるタイミングを決定します。
  10. （省略可）[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
  11. [アラート名] をクリックして、アラート ポリシーの名前を入力します。
  12. [ポリシーを作成] をクリックします。
詳細については、アラート ポリシーをご覧ください。

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

ロードバランサの指標用にカスタム Cloud Monitoring ダッシュボードを作成できます。

  1. Google Cloud コンソールで [Monitoring] ページに移動します。

    [モニタリング] に移動

  2. [ダッシュボード] > [CREATE DASHBOARD] を選択します。

  3. [グラフを追加] をクリックして、グラフのタイトルを指定します。

  4. 表示する時系列を指定するため、リソースタイプと指標タイプを選択します。

    1. [リソースと指標] セクションでグラフをクリックし、[指標を選択] セクションで使用可能なオプションを選択します。
      • グローバル外部アプリケーション ロードバランサの場合は、[グローバル外部アプリケーション ロードバランサ ルール] というリソースの種類を選択します。
    2. [適用] をクリックします。

  5. モニタリング フィルタを指定するには、[フィルタ] > [フィルタを追加] をクリックします。

  6. [保存] をクリックします。

指標報告の頻度と保持

外部アプリケーション ロードバランサの指標は、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

レイテンシの分布。レイテンシは、GFE が受信したリクエストの最初のバイトから送信したレスポンスの最後のバイトまでの時間です。

総レイテンシは、リクエスト/レスポンスによって測定されます。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 クライアントと GFE 間の接続ごとに測定され、平滑化されたラウンドトリップ時間（RTT）の分布（GFE の TCP スタックによって測定）。平滑化された RTT は、RTT 測定値で発生する可能性のある変動と異常を処理するアルゴリズムです。
バックエンド レイテンシ* https/backend_latencies

GFE がバックエンドに最初のリクエスト バイトを送信してから、バックエンドから最後のレスポンス バイトを受信するまでのレイテンシの分布。

WebSocket 接続の場合、バックエンド レイテンシは WebSocket セッションの全期間に適用されます。†
レスポンス コードクラス比 各レスポンス コードクラス（2XX、4XX、...）にある外部アプリケーション ロードバランサのレスポンスの合計割合。Cloud Monitoring では、この値はデフォルトのダッシュボードでのみ取得できます。カスタム ダッシュボードでは取得できません。API を使用して、アラートを設定できます。
バックエンドのリクエスト数 https/backend_request_count 外部アプリケーション ロードバランサからバックエンドに送信されたリクエストの数。
バックエンド リクエストのバイト数 https/backend_request_bytes_count 外部アプリケーション ロードバランサからバックエンドへのリクエストとして送信されたバイト数。
バックエンド レスポンスのバイト数 https/backend_response_bytes_count バックエンドから外部アプリケーション ロードバランサへのレスポンスとして送信されたバイト数（キャッシュを含む）。

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

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

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

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

従来のバージョンのアプリケーション ロードバランサとグローバル外部アプリケーション ロードバランサごとに指標が集計されます。集計された指標は、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

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

チャンク キャッシュが使用される場合、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 です。

次のステップ