HTTP(S) ロード バランシングと Cloud CDN のロギングとモニタリング

このドキュメントでは、HTTP(S) ロード バランシングと Cloud CDN を使用して Cloud LoggingCloud Monitoring を構成して使用する方法を説明します。

ロギング

HTTP(S) 負荷分散のバックエンド サービスのロギングの有効 / 無効を切り替えたり、ログを表示したりすることができます。バックエンド バケットを使用する HTTP(S) ロード バランシングの場合、ロギングは自動的に有効になり、無効にすることはできません。

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

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

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

Console

  1. Cloud Console の [ロード バランシング] ページに移動します。
    [ロード バランシング] ページに移動
  2. ロードバランサの名前をクリックします。
  3. [編集] をクリックします。
  4. [バックエンドの構成] をクリックします。
  5. [バックエンド サービスを作成] を選択します。
  6. 必須のバックエンド サービス フィールドに入力します。
  7. [ロギングを有効にする] をクリックします。
  8. [サンプルレート] の値を選択します。レートは 0.01.0(デフォルト)に設定できます。
  9. [更新] をクリックして、バックエンド サービスの編集を完了します。
  10. [更新] をクリックして、ロードバランサの編集を終了します。

gcloud: グローバル モード

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

ここで

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

gcloud: リージョン モード

gcloud compute backend-services create BACKEND_SERVICE \
    --region=REGION \
    --enable-logging \
    --logging-sample-rate=VALUE \
    --load-balancing-scheme=EXTERNAL_MANAGED

ここで

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

gcloud: 従来モード

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

ここで

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

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

Console

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

gcloud: グローバル モード

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

ここで

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

gcloud: リージョン モード

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

ここで

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

gcloud: 従来モード

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

ここで

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

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

Console

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

gcloud: グローバル モード

ロギングの完全な無効化

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

ここで

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

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

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

gcloud: リージョン モード

ロギングの完全な無効化

gcloud compute backend-services update BACKEND_SERVICE \
    --region=REGION \
    --no-enable-logging

ここで

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

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

gcloud beta compute backend-services update BACKEND_SERVICE \
 --global | --region=REGION \
 --logging-sample-rate=VALUE

gcloud: 従来モード

ロギングの完全な無効化

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

ここで

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

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

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

ここで

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

ログの表示

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

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

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

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

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

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

グローバル外部 HTTP(S) ロードバランサ(従来のバージョン)とグローバル外部 HTTP(S) ロードバランサの場合、リソースログ(resource.type=http_load_balancer)を使用して、ログベースの指標をエクスポートできます。作成される指標は、「Google Cloud HTTP ロード バランシング ルール(ログベースの指標)」リソース(l7_lb_rule)に基づきます。このリソースは、https_lb_rule リソースではなく、Cloud Monitoring ダッシュボードで使用できます。

リージョン外部 HTTP(S) ロードバランサの場合、リソースログ(resource.type=internal_http_lb_rule)を使用してログベースの指標をエクスポートできます。

ログの内容

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

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

statusDetail HTTP 正常終了メッセージ

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

statusDetail HTTP 異常終了メッセージ

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

バックエンド バケットのロギング

バックエンド バケットがあるロードバランサでは、ロギングが自動的に有効になります。バックエンド バケットのロギングを変更または無効にすることはできません。

Google Cloud Armor のロギング

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

ログの操作

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

モニタリング

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

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

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

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

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

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

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

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

    [Monitoring] に移動

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

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

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

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

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

      • レスポンス コードクラス(5XX、4XX、3XX、2XX)ごとにレスポンスの内訳を示す自動入力のグラフ
      • 合計レイテンシ
      • バックエンド レイテンシ
      • フロントエンド RTT
      • リクエスト数
      • ロードバランサのログへのリンク
  4. サードパーティ サービスのダッシュボードを表示するには、[ダッシュボード] ページに戻ります。[カテゴリ] で [その他] をクリックします。

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

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

アラート ポリシーを作成して指標の値をモニタリングすると、条件に違反した場合に通知できます。次の手順は、プレビューのアラート インターフェースを対象としています。

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

    [Monitoring] に移動

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

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

HTTP(S) ロード バランシングの指標に関するカスタムの Cloud Monitoring ダッシュボードを作成できます。

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

指標報告の頻度と保持

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

モニタリング指標

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

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

例: ロードバランサが、英国から 1 秒間に 1 件のリクエスト(すべて 100 ms のレイテンシ)と、米国から 1 秒間に 9 件のリクエスト(すべて 50 ms のレイテンシ)を処理しています。1 分間では、英国から 60 件、米国から 540 件のリクエストが発生することになります。モニタリング指標には、すべてのディメンションにわたる分散が保存されます。次のような情報をリクエストできます。

  • 平均全体レイテンシ(300/600) - 50 ms
  • 平均英国レイテンシ(30/60) - 100 ms
  • 95 パーセンタイル全体レイテンシ(570/600) - 100 ms
フロントエンド RTT(*) https/frontend_tcp_rtt クライアントと GFE 間の接続ごとに測定され、平滑化されたラウンドトリップ時間(RTT)の分布(GFE の TCP スタックによって測定)。平滑化された RTT は、RTT 測定値で発生する可能性のある変動と異常を処理するアルゴリズムです。
バックエンド レイテンシ(*) 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 handshake の影響も受ける、平滑化された RTT 値です。

指標のフィルタリング項目

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

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

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

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

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

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

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

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

  • FRONTEND_5XX - GFE がバックエンドを選択する前に内部エラーが発生しました。GFE からクライアントに 5XX が返されました。
  • INVALID_BACKEND - リクエストを割り当て可能な正常なバックエンドが見つからなかったため、GFE からリクエスト送信元に 5XX レスポンスが返されました。
  • NO_BACKEND_SELECTED - バックエンドを選択する前にエラーまたはその他の割り込みが発生しました。
  • SERVED_FROM_BACKEND_BUCKET - バックエンド バケットがリクエストを処理しました。
  • SERVED_FROM_CACHE - Cloud CDN でリクエストが処理されたため、バックエンドは割り当てられませんでした。
  • MULTIPLE_BACKENDS - 複数のバックエンドでリクエストが処理されました。

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

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

次のステップ