このドキュメントでは、HTTP(S) 負荷分散に使用する Cloud Logging と Cloud Monitoring について説明します。
ロギング
HTTP(S) 負荷分散のロギングのバックエンド サービスを有効化、無効化、表示できます。
バックエンド サービスごとにロギングを有効または無効にできます。すべてのリクエストをロギングするか、ランダムにサンプリングしたフラクションのみをロギングするかを構成できます。
外部 HTTP(S) ロードバランサに適用されるログの除外がないことを確認する必要があります。Cloud HTTP Load
Balancer ログが許可されているかどうか確認する方法については、リソースタイプの除外の表示をご覧ください。
新しいバックエンド サービスでのロギングの有効化
Console
- Cloud Console の [負荷分散] ページに移動します。
[負荷分散] ページに移動 - ロードバランサの名前をクリックします。
- [編集] をクリックします。
- [バックエンドの設定] をクリックします。
- バックエンド サービスの横にある [編集] をクリックします。
- ロギングを完全に無効にするには、[ロギングを有効にする] をクリアします。
- ロギングを有効にした場合、[サンプルレート] に異なる値を設定できます。
0.0から1.0まで（デフォルト）の任意の値に設定できます。保存されるログの数を 20% に減らすには、値を0.2に設定します。 - [更新] をクリックします。
gcloud
gcloud compute backend-services create BACKEND_SERVICE \ --global \ --enable-logging \ --logging-sample-rate=VALUE \ ... other values
ここで
--globalは、バックエンド サービスがグローバルであることを示します。--enable-loggingは、バックエンド サービスのロギングを有効にします。--logging-sample-rate=<var>VALUE</var>には、0.0から1.0までの値を指定できます。0.0を設定すると、リクエストはまったくロギングされません。1.0を設定すると、すべてのリクエストがロギングされます。--enable-loggingパラメータを指定した場合のみ有効となります。ロギングを有効にしても、サンプリング レートが0.0であれば、ロギングを無効にしているのと同じ結果になります。
既存のバックエンド サービスでのロギングの有効化
Console
- Cloud Console の [負荷分散] ページに移動します。
[負荷分散] ページに移動 - ロードバランサの名前をクリックします。
- [編集] をクリックします。
- [バックエンドの設定] をクリックします。
- バックエンド サービスの横にある [編集] をクリックします。
- [ロギングを有効にする] をクリックします。
- [サンプルレート] の値を選択します。レートは
0.0～1.0（デフォルト）に設定できます。 - [更新] をクリックします。
gcloud
gcloud compute backend-services update BACKEND_SERVICE \
--global \
--enable-logging \
--logging-sample-rate=VALUE
ここで
--globalは、バックエンド サービスがグローバルであることを示します。--enable-loggingは、バックエンド サービスのロギングを有効にします。--logging-sample-rate=<var>VALUE</var>には、0.0から1.0までの値を指定できます。0.0を設定すると、リクエストはまったくロギングされません。1.0を設定すると、すべてのリクエストがロギングされます。--enable-loggingパラメータを指定した場合のみ有効となります。ロギングを有効にしても、サンプリング レートが0.0であれば、ロギングを無効にしているのと同じ結果になります。
既存のバックエンド サービスでのロギングの無効化または変更
Console
- Cloud Console の [負荷分散] ページに移動します。
[負荷分散] ページに移動 - ロードバランサの名前をクリックします。
- [編集] をクリックします。
- [バックエンドの設定] をクリックします。
- バックエンド サービスの横にある edit をクリックします。
- ロギングを完全に無効にするには、[ロギングを有効にする] をクリアします。
- ロギングを有効にした場合、[サンプルレート] に異なる値を設定できます。レートは
0.0～1.0（デフォルト）に設定できます。保存されるログの数を 20% に減らすには、値を0.2に設定します。 - [更新] をクリックします。
gcloud
ロギングの完全な無効化
gcloud compute backend-services update BACKEND_SERVICE \
--global \
--no-enable-logging
ここで
--globalは、バックエンド サービスがグローバルであることを示します。--no-enable-loggingはバックエンド サービスのロギングを無効にします。
ロギングのサンプルレートの変更
gcloud compute backend-services update BACKEND_SERVICE \ --global \ --logging-sample-rate=VALUE
ここで
--globalは、バックエンド サービスがグローバルであることを示します。--logging-sample-rate=<var>VALUE</var>には、0.0から1.0までの値を指定できます。0.0を設定すると、リクエストはまったくロギングされません。1.0を設定すると、すべてのリクエストがロギングされます。--enable-loggingパラメータを指定した場合のみ有効となります。ロギングを有効にしても、サンプリング レートが0.0であれば、ロギングを無効にしているのと同じ結果になります。
ログの表示
ログを表示するには、ログビューアに移動します。
HTTP(S) ログはまず転送ルールでインデックス化され、次に URL マップでインデックス化されます。
- すべてのログを表示するには、最初のプルダウン メニューで [Cloud HTTP Load Balancer] > [すべての転送ルール] を選択します。
- 1 つの転送ルールのログを表示するには、単一の転送ルール名を選択します。
- 1 つの URL マップのログを表示するには、転送ルールをハイライト表示して URL マップを選択します。
通常、ブール型のログフィールドは、フィールドの値が true の場合にのみ表示されます。ブール フィールドの値が false の場合、そのフィールドはログから省略されます。
ログフィールドには UTF-8 エンコードが適用されます。UTF-8 以外の文字列は、疑問符に置き換えられます。
外部 HTTP(S) ロードバランサ リソースログ（resource.type=http_load_balancer）のログベースの指標のエクスポートを構成できます。作成される指標は、Cloud Monitoring ダッシュボードにある「Google Cloud HTTP 負荷分散ルール（ログベースの指標）」リソース（l7_lb_rule）に基づきます。https_lb_rule リソースには基づきません。
ログの内容
HTTP(S) 負荷分散ログエントリには、HTTP(S) トラフィックのモニタリングおよびデバッグに役立つ情報が含まれています。ログエントリには次のタイプの情報が含まれています。
- 重大度、プロジェクト ID、プロジェクト番号、タイムスタンプなどの一般情報。
- HttpRequest ログフィールド。ただし、
HttpRequest.protocolは HTTP(S) 負荷分散の Cloud Logging ログには含まれません。 structPayload内のstatusDetailsフィールド。このフィールドには、ロードバランサが行った、HTTP のステータスを返した理由を説明する文字列が入ります。これらのログの文字列については下の表で詳しく説明します。- ロードバランサから発行されたリダイレクト（HTTP レスポンス ステータ スコード 302 Found）は記録されません。バックエンド インスタンスから発行されたリダイレクトはログに記録されます。
statusDetail HTTP 正常終了メッセージ
| statusDetails（正常終了） | 意味 | 一般的に記録されるレスポンス コード |
|---|---|---|
byte_range_caching
|
HTTP リクエストが Cloud CDN のバイト範囲キャッシュを使用して提供されました。 | 任意のキャッシュ可能なレスポンス コード。 |
response_from_cache
|
HTTP リクエストが Cloud CDN キャッシュから提供されました。 | 任意のキャッシュ可能なレスポンス コード。 |
response_from_cache_validated
|
リターンコードは、バックエンドによって検証された Cloud CDN キャッシュ済みエントリから設定されました。 | 任意のキャッシュ可能なレスポンス コード。 |
response_sent_by_backend
|
HTTP リクエストは、バックエンドに正常にプロキシされました。 | バックエンドから返されます - HTTP レスポンス コードは、バックエンドで実行されているソフトウェアによって設定されます。 |
statusDetail HTTP 異常終了メッセージ
| statusDetails（異常終了） | 意味 | 一般的に記録されるレスポンス コード |
|---|---|---|
aborted_request_due_to_backend_early_response
|
本文付きのリクエストは、バックエンドが早期レスポンスを送信したため中断され、エラーコードが返されました。レスポンスはクライアントに転送されました。リクエストは終了しました。 | 4XX または 5XX |
backend_connection_closed_after_partial_response_sent
|
クライアントに部分的レスポンスが送られた後、バックエンドへの接続が予期せず閉じました。 | HTTP レスポンス コードは、バックエンドで実行されているソフトウェアによって設定されます。HTTP レスポンス コード 0（ゼロ）は、バックエンドが不完全な HTTP ヘッダーを送信したことを意味します。 |
backend_connection_closed_before_data_sent_to_client
|
バックエンドは、レスポンスがクライアントにプロキシされる前に、予期せずロードバランサへの接続を閉じました。これは、ロードバランサが別のエンティティにトラフィックを送信している場合に発生します。他のエンティティは、外部 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 |
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_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 |
unsupported_method
|
クライアントは、指名されていない HTTP リクエスト メソッドを指定しました。 | 400 |
upgrade_header_rejected
|
クライアントの HTTP リクエストにはアップグレード ヘッダーが含まれ、拒否されました。 | 400 |
uri_too_long
|
HTTP リクエスト URI が許容最大長を超えていました。 | 414 |
websocket_closed
|
WebSocket 接続が切断されました。 | 101 |
websocket_handshake_failed
|
WebSocket が handshake できませんでした。 | 任意のレスポンス コード。handshake 失敗の性質によって異なります。 |
request_body_too_large
|
HTTP リクエストの本文がバックエンドでサポートされている最大長を超えています。VM バックエンドには適用されません。 | 413 |
handled_by_identity_aware_proxy
|
このレスポンスは、アクセスを許可する前のクライアントの本人確認時に、Identity-Aware Proxy によって生成されました。 | 200、302、400、401、403、500、502 |
serverless_neg_routing_failed
|
サーバーレス NEG リクエストはディスパッチできません。このエラーは、NEG で指定されたリージョンに到達できない場合、またはリソース名（Cloud Functions 名など）が見つからない場合に発生します。 | 404、502 |
Google Cloud Armor セキュリティ ポリシーのロギング
次に示すログビューアのログエントリは、Google Cloud Armor のセキュリティ ポリシーとルールのロギング用です。jsonPayload でエントリの構造は次のとおりです。HTTP リクエストの詳細は、httpRequest メッセージに含まれます。
status_details（文字列）: レスポンス コードを説明するテキストenforced_security_policy: 適用されたセキュリティ ポリシールールname（文字列）: セキュリティ ポリシーの名前priority（数値）: セキュリティ ポリシーの一致ルールの優先度configured_action（文字列）: 一致ルールで構成したアクションの名前（ALLOW、DENYなど）。outcome（文字列）: 構成されたアクションの実行結果（これはconfigured_actionと同じではありません）。preconfigured_expr_ids（文字列）: ルールをトリガーしたすべての事前構成済み WAF ルール式の ID
preview_security_policy: リクエストがプレビュー用に構成されたルールに一致する場合に入力される（プレビュー ルールが適用済みのルールよりも優先される場合にのみ表示される）name（文字列）: セキュリティ ポリシーの名前priority（数値）: セキュリティ ポリシーの一致ルールの優先度configured_action（文字列）: 一致ルールで構成したアクションの名前（ALLOW、DENYなど）。outcome（文字列）: 構成されたアクションの実行結果（これはconfigured_actionと同じではありません）。preconfigured_expr_ids（文字列）: ルールをトリガーしたすべての事前構成済み WAF ルール式の ID
Cloud Logging API を使用して外部 HTTP(S) ロードバランサのログを操作できます。Logging API では、特定のフィールドが設定されたログをインタラクティブにフィルタリングする方法を提供します。一致するログを Cloud Logging、Cloud Storage、BigQuery、または Pub/Sub にエクスポートします。Logging API の詳細については、ログの表示をご覧ください。
モニタリング
HTTP(S) 負荷分散は、モニタリング データを Cloud Monitoring にエクスポートします。
モニタリング指標は次の目的で使用します。
- ロードバランサの構成、使用状況、パフォーマンスを評価する
- 問題のトラブルシューティングを行う
- リソースの使用率とユーザー エクスペリエンスを改善する
Cloud Monitoring の事前定義されたダッシュボードに加えて、カスタム ダッシュボードの作成、アラートのセットアップ、Cloud Monitoring API を使った指標の照会を行うことができます。
Cloud Monitoring ダッシュボードの表示
Cloud Console で [Monitoring] に移動します。
Monitoring のナビゲーション パネルで、[サービス] が表示されている場合は、[サービス] > [Cloud load balancers] を選択します。特定のロードバランサのダッシュボードを表示するには、リストでロードバランサを見つけて、その名前をクリックします。
それ以外の場合は、次のように [ダッシュボード] を選択します。
Google Cloud ロードバランサのダッシュボードのリストを表示するには、[Google Cloud Load Balancers] というダッシュボードを選択します。特定のロードバランサのダッシュボードを表示するには、リストでロードバランサを見つけて、その名前をクリックします。
AWS ロードバランサのダッシュボードのリストを表示するには、[Amazon Web Services] というダッシュボードを選択します。特定のロードバランサのダッシュボードを表示するには、リストでロードバランサを見つけて、その名前をクリックします。
左側のペインでは、この外部 HTTP(S) ロードバランサのさまざまな詳細を確認できます。右側のペインには時系列のグラフが表示されます。[Breakdowns] リンクをクリックすると、特定の内訳が表示されます。
アラート ポリシーの定義
アラート ポリシーを作成して指標の値をモニタリングすると、条件に違反した場合に通知できます。
1 つ以上の Google Cloud HTTP/S 負荷分散ルール リソースをモニタリングするアラート ポリシーを作成するには、次の手順を行います。
- Google Cloud Console で、[モニタリング] ページに移動します。
Cloud Monitoring を初めて使用する場合は、Google Cloud Console の [Monitoring] への最初のアクセス時に、ワークスペースが自動的に作成され、プロジェクトがそのワークスペースに関連付けられます。それ以外の場合に、プロジェクトがワークスペースに関連付けられていないときは、ダイアログが表示され、新しいワークスペースを作成するか、このプロジェクトを既存のワークスペースに追加できるようになります。ワークスペースを作成することをおすすめします。選択したら、[Add] をクリックします。
- Monitoring のナビゲーション パネルで notifications [アラート] を選択し、次に [Create Policy] を選択します。
- [Add Condition] をクリックします。
- [Target] ペインの設定で、モニタリングするリソースと指標を指定します。[Find resource type and metric] フィールドで、[Google Cloud HTTP/S Load Balancing Rule] を選択します。次に、指標リストから指標を選択します。
- アラート ポリシーの [Configuration] ペインの設定で、アラートがトリガーされるタイミングを決定します。このペインのほとんどのフィールドにはデフォルト値が入力されています。ペインのフィールドの詳細については、アラート ポリシーのドキュメントの構成をご覧ください。
- [追加] をクリックします。
- 通知セクションに移動するには、[次へ] をクリックします。
- （省略可）アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャネルを選択し、[OK] をクリックします。
追加する通知チャネルが一覧にない場合は、[通知チャネルを管理] をクリックします。新しいブラウザタブの [通知チャネル] ページが表示されます。このページで、構成された通知チャンネルを更新できます。更新が完了したら、元のタブに戻って autorenew 更新アイコンをクリックし、アラート ポリシーに追加する通知チャンネルを選択します。
- ドキュメントのセクションに移動するには、[次へ] をクリックします。
- [名前] をクリックし、アラート ポリシーの名前を入力します。
- （省略可）[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
- [Save] をクリックします。
Cloud Monitoring のカスタム ダッシュボードの定義
HTTP(S) 負荷分散の指標に関するカスタムの Cloud Monitoring ダッシュボードを作成できます。
- Cloud Console で [Monitoring] に移動します。
[Monitoring] に移動 - [ダッシュボード] > [ダッシュボードを作成] を選択します。
- [Add Chart] をクリックします。
- グラフにタイトルを付けます。
- 指標とフィルタを選択します。指標の場合、リソースタイプは Cloud HTTP ロードバランサです。
- [保存] をクリックします。
指標報告の頻度と保持
外部 HTTP(S) ロードバランサの指標は、1 分単位のバッチで Cloud Monitoring にエクスポートされます。モニタリング データは 6 週間保持されます。ダッシュボードでは、1H（1 時間）、6H（6 時間）、1D（1 日）、1W（1 週間）、6W（6 週間）のデフォルト間隔でデータ分析の結果を確認できます。また、6W から 1 分までの任意の間隔で手動で分析を行うこともできます。
外部 HTTP(S) ロードバランサのモニタリング指標
外部 HTTP(S) ロードバランサの次の指標が、Cloud Monitoring に報告されます。
| 指標 | 名前 | 説明 |
|---|---|---|
| リクエスト数 | https/request_count |
外部 HTTP(S) ロードバランサによって配信されるリクエスト数 |
| リクエスト バイト数 | https/request_bytes_count |
クライアントから外部 HTTP(S) ロードバランサへのリクエストとして送信されたバイト数 |
| レスポンス バイト数 | https/response_bytes_count |
外部 HTTP(S) ロードバランサからクライアントへのレスポンスとして送信されたバイト数 |
| 総レイテンシ | https/total_latencies |
レイテンシの分布。レイテンシは、GFE がリクエストの最初のバイトを受信してから、要求側のクライアントから ACK の最後のレスポンス バイトの受信するまで測定されます。総レイテンシは、リクエスト/レスポンスによって測定されます。Connection: keep-alive を使った同じ接続上のリクエスト間の休止は測定に影響しません。この測定値は通常、Cloud Monitoring ビューで 95 パーセンタイルに縮小されます。例: ロードバランサが、英国から 1 秒間に 1 件のリクエスト（すべて 100 ms のレイテンシ）と、米国から 1 秒間に 9 件のリクエスト（すべて 50 ms のレイテンシ）を処理しています。1 分間では、英国から 60 件、米国から 540 件のリクエストが発生することになります。モニタリング指標には、すべてのディメンションにわたる分散が保存されます。次のような情報をリクエストできます。
|
| フロントエンド RTT（*） | https/frontend_tcp_rtt |
クライアントと GFE 間の接続ごとに測定された平滑化された RTT の分布（GFE の TCP スタックによって測定）。 |
| バックエンド レイテンシ（*） | https/backend_latencies |
GFE がバックエンドに最初のリクエスト バイトを送信してから、バックエンドから最後のレスポンス バイトを受信するまでのレイテンシの分布。 |
| レスポンス コードクラス比 | 各レスポンス コードクラス（2XX、4XX、...）にある外部 HTTP(S) ロードバランサのレスポンスの合計割合。Cloud Monitoring では、この値はデフォルトのダッシュボードでのみ取得できます。カスタム ダッシュボードでは取得できません。API を使用して、アラートを設定できます。 | |
| バックエンドのリクエスト数 | https/backend_request_count |
外部 HTTP(S) ロードバランサからバックエンドに送信されたリクエストの数。 |
| バックエンド リクエストのバイト数 | https/backend_request_bytes_count |
外部 HTTP(S) ロードバランサからバックエンドへのリクエストとして送信されたバイト数。 |
| バックエンド レスポンスのバイト数 | https/backend_response_bytes_count |
バックエンドから外部 HTTP(S) ロードバランサへのレスポンスとして送信されたバイト数。 |
（*）フロントエンド RTT とバックエンド レイテンシの合計が総レイテンシ以下であるという保証はありません。これは、HTTP レスポンスが ACK された時点で GFE からクライアントへのソケット上の RTT をポーリングしますが、これらの測定値の一部をカーネルからの報告に依存しており、指定した HTTP レスポンスの RTT 測定値がカーネルで保持されていることを保証できないためです。最終結果は、現在の HTTP リクエストの実際のタイミングに影響を与えない過去の HTTP レスポンス、SYN / ACK、および SSL ハンドシェイクの影響も受ける、平滑化された RTT 値です。
外部 HTTP(S) ロードバランサの指標のフィルタリング ディメンション
指標は、外部 HTTP(S) ロードバランサごとに集計されます。集計された指標は、次の項目（*）でフィルタ処理できます。
| プロパティ | 説明 |
|---|---|
| backend_scope | 接続を処理したバックエンド サービスのインスタンス グループの Google Cloud スコープ（リージョンまたはゾーン）。 使用可能なインスタンス グループが存在しない場合やリクエストが別のエンティティによって処理された場合は、バックエンド サービスのインスタンス グループのリージョンやゾーンではなく、次の値のいずれかが表示されます。
このオプションを選択すると、グラフにフロントエンド指標（クライアントからロードバランサへ）ではなく、バックエンド指標（ロードバランサからバックエンドへ）が表示されます。 |
| backend_scope = "backend_zone" | インスタンス グループがゾーン インスタンス グループの場合、クライアントのリクエストを処理したインスタンス グループの Google Cloud ゾーン。（たとえば、us-central1-a、europe-west1-b、asia-east1-c）このオプションを選択すると、グラフにフロントエンド指標（クライアントからロードバランサへ）ではなく、バックエンド指標（ロードバランサからバックエンドへ）が表示されます。 |
| backend_scope = "backend_region" | インスタンス グループがリージョン インスタンス グループの場合、クライアントのリクエストを処理したインスタンス グループの Google Cloud リージョン。（たとえば、us-central1、europe-west1、asia-east1）このオプションを選択すると、グラフにフロントエンド指標（クライアントからロードバランサへ）ではなく、バックエンド指標（ロードバランサからバックエンドへ）が表示されます。 |
| proxy_continent | HTTP(S) 接続を終了した HTTP(S) GFE の大陸。（たとえば、America、Europe、Asia） |
| backend_type = "INSTANCE GROUP" | クライアントのリクエストを処理したインスタンス グループの名前。 使用可能なインスタンス グループが存在しない場合やリクエストが別のエンティティによって処理された場合は、インスタンス グループではなく、次の値のいずれかが表示されます。
このオプションを選択すると、グラフにフロントエンド指標（クライアントからロードバランサへ）ではなく、バックエンド指標（ロードバランサからバックエンドへ）が表示されます。 |
| backend_target_type = "BACKEND_SERVICE" | リクエストを処理したバックエンド サービスの名前。 |
| matched_url_path_rule | HTTP(S) リクエストのプレフィックスと一致する URL マップパス ルール（最大 50 文字）。 |
| forwarding_rule_name | リクエストを送信するためにクライアントに使用された転送ルールの名前。 |
（*）現在、「レスポンス コードクラス比」指標は、ロードバランサ全体でのみ入手可能で、これ以上の内訳は入手できません。
次のステップ
- HTTP(S) 負荷分散のコンセプトについてを確認する。
- コンテンツ ベースおよびクロスリージョンの外部 HTTP(S) ロードバランサを作成する。
- コンテンツ ベースのロードバランサの設定にバックエンド バケットを追加する。
- 転送ルールについて確認する。
- URL マップの設定または URL マップのコンセプトについてを確認する。
- SSL 証明書を構成する。
- SSL ポリシーを作成する。
- ロードバランサの設定をクリーンアップする。