ロギング
外部アプリケーション ロードバランサのバックエンド サービスのログの有効化、無効化、表示を行えます。バックエンド バケットを使用する外部アプリケーション ロードバランサの場合、ロギングは自動的に有効になり、無効にすることはできません。
バックエンド サービスごとにロギングを有効または無効にできます。すべてのリクエストをロギングするか、ランダムにサンプリングしたフラクションのみをロギングするかを構成できます。
外部アプリケーション ロードバランサに適用されるログの除外がないことを確認する必要があります。Cloud HTTP Load
Balancer ログが許可されているかどうか確認する方法については、リソースタイプの除外の表示をご覧ください。
ログのサンプリングと収集
ロードバランサのバックエンド仮想マシン（VM）インスタンスによって処理されるリクエスト（および対応するレスポンス）がサンプリングされます。これらのサンプリングされたリクエストが処理され、ログが生成されます。logConfig.sampleRate パラメータに従って、ログエントリとして出力されるリクエストの割合を制御します。logConfig.sampleRate が 1.0（100%）の場合、すべてのリクエストのログが生成され、Cloud Logging に書き込まれます。
新しいバックエンド サービスでのロギングの有効化
コンソール
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
ロードバランサの名前をクリックします。
[編集] をクリックします。
[バックエンドの構成] をクリックします。
[バックエンド サービスを作成] を選択します。
必須のバックエンド サービス フィールドに入力します。
[ロギング] セクションで、[ロギングを有効にする] チェックボックスをオンにします。
[サンプルレート] の値を選択します。
0.0から1.0までの数値を設定できます。0.0はリクエストがログに記録されていないことを意味し、1.0はリクエストの 100% がログに記録されることを意味します。デフォルト値は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_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です。
既存のバックエンド サービスでロギングを有効にする
コンソール
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
ロードバランサの名前をクリックします。
[編集] をクリックします。
[バックエンドの構成] をクリックします。
バックエンド サービスの横にある [編集] をクリックします。
[ロギング] セクションで、[Logging を有効にする] チェックボックスをオンにします。
[サンプルレート] フィールドで、サンプリング確率を設定します。
0.0から1.0までの数値を設定できます。0.0はリクエストがログに記録されていないことを意味し、1.0はリクエストの 100% がログに記録されることを意味します。デフォルト値は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です。
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です。
既存のバックエンド サービスでのロギングの無効化または変更
コンソール
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
ロードバランサの名前をクリックします。
[編集] をクリックします。
[バックエンドの構成] をクリックします。
バックエンド サービスの横にある [編集] をクリックします。
ロギングを完全に無効にするには、[ロギング] セクションで [Logging を有効にする] チェックボックスをオフにします。
ロギングを有効にした場合、[サンプルレート] に異なる値を設定できます。
0.0から1.0までの数値を設定できます。0.0はリクエストがログに記録されていないことを意味し、1.0はリクエストの 100% がログに記録されることを意味します。デフォルト値は1.0です。たとえば、0.2は、サンプリングされたリクエストの 20% がログを生成することを意味します。バックエンド サービスの編集を終了するには、[更新] をクリックします。
ロードバランサの編集を終了するには、[更新] をクリックします。
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 (
|
省略可 | 第 1 レイヤの GFE がリクエストを受信した時刻。 |
| httpRequest | HttpRequest | 必須 | HTTP リクエストをロギングするための共通プロトコル。
|
| resource | MonitoredResource | 必須 | MonitoredResource は、ログエントリに関連付けられているリソースタイプです。 MonitoredResourceDescriptor は、型名とラベルのセットを使用して |
| jsonPayload | オブジェクト（Struct 形式） | 必須 | JSON オブジェクトとして表されるログエントリ ペイロード。JSON オブジェクトには、次のフィールドが含まれています。
|
| 文字列 | 必須 | statusDetails フィールドには、ロードバランサが行った、HTTP のステータスを返した理由を説明する文字列が入ります。これらのログ文字列の詳細については、statusDetails HTTP 成功メッセージと statusDetails HTTP 失敗メッセージをご覧ください。 |
|
| 文字列 | 必須 | backendTargetProjectNumber フィールドには、バックエンド ターゲット（バックエンド サービスまたはバックエンド バケット）が作成されたプロジェクト番号が保持されます。このフィールドの形式は "projects/PROJECT_NUMBER" です。この情報は、カスタム エラー レスポンスを使用するグローバル外部アプリケーション ロードバランサでのみ使用できます。 |
|
| 整数 | 必須 | overrideResponseCode には、クライアントに送信されるレスポンスに適用されるオーバーライド レスポンス コードが保持されます。この情報は、カスタム エラー レスポンスを使用するグローバル外部アプリケーション ロードバランサでのみ使用できます。 |
|
| 文字列 | 必須 | errorService フィールドには、カスタム エラー レスポンスを提供したバックエンド サービスが保持されます。この情報は、カスタム エラー レスポンスを使用するグローバル外部アプリケーション ロードバランサでのみ使用できます。 |
|
| 文字列 | 必須 | errorBackendStatusDetails フィールドには、クライアントに配信される最終的なレスポンスの statusDetails が保持されます。この情報は、カスタム エラー レスポンスを使用するグローバル外部アプリケーション ロードバランサでのみ使用できます。 |
|
| 文字列 | 省略可 | loadBalancingScheme フィールドは、従来のアプリケーション ロードバランサの移行機能を使用している場合にのみ自動的に入力されます。このフィールドには、リクエストのルーティングに使用されたロード バランシング スキームを記述する文字列が保存されます。有効な値は EXTERNAL または EXTERNAL_MANAGED です。 |
リソースラベル
次の表に、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 接続の場合:
|
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 つ以上含まれています。 たとえば、二重引用符（ 詳しくは以下をご覧ください。 |
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 |
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 functions 名など）が見つからない場合に発生します。 | 404、502、503 |
fault_filter_abort
|
このエラーは、お客様が障害フィルタを構成していて、特定のリクエストに対してその障害フィルタがトリガーされた場合に発生します。 | 値は 200～599 にする必要があります。 |
mTLS クライアント証明書検証のログを表示する
相互 TLS クライアント証明書の検証中に、閉じられた接続についてログに記録されたエラーを表示するには、次の操作を行います。
コンソール クエリ
Google Cloud コンソールで、[ログ エクスプローラ] ページに移動します。
[クエリを表示] をクリックします。
または、[クエリ] フィールドに次の内容を貼り付けます。
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
[クエリを実行] をクリックします。
認可ポリシー リクエスト ログ
Load Balancer ログエントリ JSON ペイロードの authz_info オブジェクトには、認可ポリシーに関する情報が含まれています。これらのポリシーによって許可または拒否されたトラフィックのログベースの指標を構成できます。
| フィールド | 型 | 説明 |
|---|---|---|
authz_info.policies[] |
オブジェクト | リクエストに一致するポリシーのリスト。 |
authz_info.policies[].name |
文字列 | リクエストに一致する認可ポリシーの名前。 名前が空である理由は次のとおりです。
|
authz_info.policies[].result |
列挙型 | 結果は ALLOWED または DENIED のいずれかになります。 |
authz_info.policies[].details |
文字列 | 詳細には次のものが含まれます。
|
authz_info.overall_result |
列挙型 | 結果は 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 によって自動的にデータが入力されます。
事前定義されたダッシュボードにアクセスするには、次の手順を行います。
Google Cloud コンソールで [Monitoring] に移動します。
Monitoring のナビゲーション パネルで、[ダッシュボード] をクリックします。
[カテゴリ] で [GCP] をクリックします。
すべての Google Cloud ロードバランサのダッシュボードのリストを表示するには、[Google Cloud ロードバランサ] というダッシュボードを選択します。特定のロードバランサのダッシュボードを表示するには、リストでロードバランサを見つけて、その名前をクリックします。
外部アプリケーション ロードバランサ専用の事前定義ダッシュボードを表示するには、[外部 HTTP(S) ロードバランサ] というダッシュボードを選択します。このページには、プロジェクト内のすべての外部アプリケーション ロードバランサの 5XX レスポンスの割合とバックエンド レイテンシのダッシュボードが表示されます。また、プロジェクト内のすべての外部アプリケーション ロードバランサを示すダッシュボードのリストも示されます。
クリックすると各ロードバランサのダッシュボードに移動できます。各ダッシュボードには次の情報が表示されます。- レスポンス コードクラス（5XX、4XX、3XX、2XX）ごとにレスポンスの内訳を示す自動入力のグラフ
- 合計レイテンシ
- バックエンド レイテンシ
- フロントエンド RTT
- リクエスト数
- ロードバランサのログへのリンク
サードパーティ サービスのダッシュボードを表示するには、[ダッシュボード] ページに戻ります。[カテゴリ] で [その他] をクリックします。
- 特定のサードパーティのサービス ダッシュボードを表示するには、リストからダッシュボードを見つけてその名前をクリックします。
アラート ポリシーを定義する
このタスクを Google Cloud コンソールで直接行う際の順を追ったガイダンスについては、「ガイドを表示」をクリックしてください。
アラート ポリシーを作成して指標の値をモニタリングすると、指標が条件に違反した場合に通知できます。
-
Google Cloud コンソールで、[notificationsアラート] ページに移動します。
検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] の結果を選択します。
- 通知チャンネルを作成せずに通知を受け取る場合は、[EDIT NOTIFICATION CHANNELS] をクリックして、通知チャンネルを追加します。チャンネルを追加したら、[アラート] ページに戻ります。
- [アラート] ページで、[CREATE POLICY] をクリックします。
- 指標を選択するには、[指標を選択] メニューを開き、次の操作を行います。
- メニューを関連するエントリに限定するには、フィルタバーに「
Global External Application Load Balancer Rule」と入力します。結果が表示されない場合は、[アクティブなリソースと指標のみを表示] をオフに切り替えます。 - リソースの種類で、[Global External Application Load Balancer Rule] を選択します。
- 指標カテゴリと指標を選択して、[適用] を選択します。
- メニューを関連するエントリに限定するには、フィルタバーに「
- [次へ] をクリックします。
- [Configure alert trigger] ページの設定によって、アラートがトリガーされるタイミングが決まります。条件タイプを選択し、必要に応じてしきい値を指定します。詳細については、指標しきい値のアラート ポリシーを作成するをご覧ください。
- [次へ] をクリックします。
- （省略可）アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャンネルを選択し、[OK] をクリックします。
- （省略可）インシデントの自動クローズ期間を更新します。このフィールドは、指標データがない場合に Monitoring がインシデントを閉じるタイミングを決定します。
- （省略可）[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
- [アラート名] をクリックして、アラート ポリシーの名前を入力します。
- [ポリシーを作成] をクリックします。
Cloud Monitoring のカスタム ダッシュボードの定義
ロードバランサの指標用にカスタム Cloud Monitoring ダッシュボードを作成できます。
Google Cloud コンソールで [Monitoring] ページに移動します。
[ダッシュボード] > [CREATE DASHBOARD] を選択します。
[グラフを追加] をクリックして、グラフのタイトルを指定します。
表示する時系列を指定するため、リソースタイプと指標タイプを選択します。
- [リソースと指標] セクションでグラフをクリックし、[指標を選択] セクションで使用可能なオプションを選択します。
- グローバル外部アプリケーション ロードバランサの場合は、リソースの種類として [Global External Application Load Balancer Rule] を選択します。
- [適用] をクリックします。
- [リソースと指標] セクションでグラフをクリックし、[指標を選択] セクションで使用可能なオプションを選択します。
モニタリング フィルタを指定するには、[フィルタ] > [フィルタを追加] をクリックします。
[保存] をクリックします。
指標報告の頻度と保持
外部アプリケーション ロードバランサの指標は、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 が受信したリクエストの最初のバイトから、GFE が送信したレスポンスの最後のバイトまでの時間です。 総レイテンシは、リクエスト/レスポンスによって測定されます。 WebSocket 接続の場合、このフィールドは接続の全期間を指します。† 例: ロードバランサが、英国から 1 秒間に 1 件のリクエスト（すべて 100 ms のレイテンシ）と、米国から 1 秒間に 9 件のリクエスト（すべて 50 ms のレイテンシ）を処理しています。1 分間では、英国から 60 件、米国から 540 件のリクエストが発生することになります。モニタリング指標には、すべてのディメンションにわたる分散が保存されます。次のような情報をリクエストできます。
|
| フロントエンド 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 スコープ（リージョンまたはゾーン）。 使用可能なインスタンス グループが存在しない場合やリクエストが別のエンティティによって処理された場合は、バックエンド サービスのインスタンス グループのリージョンやゾーンではなく、次の値のいずれかが表示されます。
このオプションを選択すると、グラフにフロントエンド指標（クライアントからロードバランサへ）ではなく、バックエンド指標（ロードバランサからバックエンドへ）が表示されます。 |
backend_type |
クライアントのリクエストを処理したバックエンド グループの名前。
|
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 マップ パスルールまたはルートルール。フォールバックとして
|
target_proxy_name |
転送ルールで参照されるターゲット HTTP(S) プロキシ オブジェクトの名前。 |
backend_target_name |
バックエンド ターゲットの名前。ターゲットは、バックエンド サービスとバックエンド バケットのいずれかです。バックエンドが割り当てられていない場合は、UNKNOWN が返されます。 |
backend_name |
バックエンド インスタンス グループ、バケット、または NEG の名前。バックエンドが割り当てられなかった場合は UNKNOWN が返されます。バックエンドを選択できるようになる前にエラーやその他の中断が発生した場合、または URL リダイレクトが発生した場合は NO_BACKEND_SELECTED が返されます。 |
backend_scope_type |
バックエンド グループのスコープのタイプ。 チャンク キャッシュが使用される場合、 |
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 です。 |
次のステップ
- 外部アプリケーション ロードバランサの概要を確認します。