HTTP(S) 負荷分散のロギングとモニタリング

このドキュメントでは、HTTP(S) 負荷分散における Stackdriver のロギングとモニタリングについて説明します。

ロギング

HTTP 負荷分散のロギングのバックエンド サービスを有効化、無効化、表示できます。

デフォルトでは、HTTP(S) ロードバランサはすべてのリクエストを Stackdriver Logging にロギングします。バックエンド サービスの設定を変更することで、ロギングを完全に無効にするか、ランダムにサンプリングされたリクエストのみをログに記録して容量とコストを節約するかを選択できます。

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

Console

  1. Google Cloud Platform Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. ロードバランサの名前をクリックします。
  3. [編集] をクリックします。
  4. [バックエンドの設定] をクリックします。
  5. バックエンド サービスの横にある鉛筆アイコンをクリックします。
  6. [高度な構成(セッション アフィニティ、接続ドレインのタイムアウト)] をクリックします。
  7. ロギングを完全に無効にするには、[ロギングを有効にする] をオフにします。
  8. ロギングを有効にした場合、[サンプルレート] に異なる値を設定できます。0.0 から 1.0 まで(デフォルト)の任意の値に設定できます。保存されるログの数を 20% に減らすには、値を 0.2 に設定します。
  9. [更新] をクリックします。

gcloud

ロギングの完全な無効化

gcloud beta compute backend-services update [BACKEND_SERVICE] \
 --no-enable-logging

ここで

  • --no-enable-logging はバックエンド サービスのロギングを無効にします。

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

gcloud beta compute backend-services update [BACKEND_SERVICE] \
 --logging-sample-rate=[VALUE]

ここで

  • --logging-sample-rate には、0.0 から 1.0 までの値を指定できます。0.0 を設定すると、パケットはまったくロギングされません。1.0 を設定すると、すべてのパケットがロギングされます。

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

Console

  1. Google Cloud Platform Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. ロードバランサの名前をクリックします。
  3. [編集] をクリックします。
  4. [バックエンドの設定] をクリックします。
  5. バックエンド サービスの横にある鉛筆アイコン / 編集リンクをクリックします。
  6. [高度な構成(セッション アフィニティ、接続ドレインのタイムアウト)] をクリックします。
  7. [ロギングを有効にする] をクリックします。
  8. [サンプルレート] の値を選択します。0.0 から 1.0 まで(デフォルト)の任意の値に設定できます。
  9. [更新] をクリックします。

gcloud

gcloud beta compute backend-services update [BACKEND_SERVICE] \
 --enable-logging \
 --logging-sample-rate=[VALUE]

ここで

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

ログの表示

ログを表示するには、ログビューアに移動します。

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

  • すべてのログを表示するには、最初のプルダウン メニューで [Cloud HTTP Load Balancer] > [すべての転送ルール] を選択します。
  • 単一の転送ルールのログだけ確認するには、一覧から単一の転送ルール名を選択します。
  • 転送ルールで使用される 1 つの URL マップのログだけを確認するには、転送ルールをハイライト表示して、必要な URL マップを選択します。

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

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

Cloud HTTP(S) Load Balancer のリソースログ(resource.type=http_load_balancer)の Stackdriver ログベースの指標のエクスポートを構成できます。作成される指標は、「Google Cloud HTTP 負荷分散ルール(ログベースの指標)」リソースに基づきます(l7_lb_rule)。これは、https_lb_rule リソースではなく、Stackdriver Monitoring ダッシュボードで使用できます。

[モニタリング] に移動

ログの内容

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

  • 重大度、プロジェクト ID、プロジェクト番号、タイムスタンプなど、ほとんどの GCP ログで表示される一般情報。
  • HttpRequest ログフィールド しかし、HttpRequest.protocolHttpRequest.latency は、HTTP(S) Load Balancing Stackdriver のログには入力されません。
  • structPayload 内の statusDetails フィールド。このフィールドは、ロードバランサが行った、HTTP のステータスを戻した理由を説明する文字列を保持しています。以下のテーブルには、これらのログの文字列の詳しい説明が記載されています。

statusDetail HTTP 正常終了メッセージ

statusDetails(正常終了) 意味 共通のレスポンス コード
byte_range_caching HTTP リクエストがバイト範囲キャッシュを使用して提供されました。 任意のキャッシュ可能なレスポンス コード
response_from_cache HTTP リクエストがキャッシュから提供されました。 任意のキャッシュ可能なレスポンス コード
response_from_cache_validated リターンコードは、バックエンドによって検証されたキャッシュ済みエントリから設定されました。 任意のキャッシュ可能なレスポンス コード
response_sent_by_backend HTTP リクエストは、バックエンドに正常にプロキシされました。 VM バックエンドからの戻り値(任意のレスポンス コード)

statusDetail HTTP 異常終了メッセージ

statusDetails(異常終了) 意味 共通のレスポンス コード
aborted_request_due_to_backend_early_response 本文付きリクエストは、エラーコード付き早期レスポンスを送信するバックエンドのために、中止されました。レスポンスはクライアントに転送されました。リクエストは終了しました。 4XX または 5XX
backend_503_propagated_as_error バックエンドから 503 エラー応答が送信されました。このエラーコードは、バックエンドでのパフォーマンスや設定の問題を示しています。 503
backend_connection_closed_after_partial_response_sent バックエンドの接続は、クライアントに部分的レスポンスが送られた後、予期せず閉じました。 VM バックエンドからの戻り値(任意のレスポンス コード)0 は、バックエンドが完全なレスポンス ヘッダーを送信していないことを意味します。
backend_connection_closed_before_data_sent_to_client バックエンドは、レスポンスがクライアントにプロキシされる前に、予期せずロードバランサへの接続を閉じました。これは、VM インスタンス上で動作するサードパーティのロードバランサなど別のエンティティにロードバランサがトラフィックを送信していて、そのエンティティの TCP タイムアウトが HTTP ロードバランサのタイムアウトである 10 分(600 秒)よりも短い場合に発生します。手動でターゲット サービスの TCP タイムアウト(キープアライブ)を 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_timeout バックエンドは、レスポンスを生成中にタイムアウトしました。 502
body_not_allowed クライアントは、本文付き HTTP リクエストが送信しましたが、使用される HTTP メソッドは本文を許可していません。 400
byte_range_caching_aborted ロードバランサは、バイト範囲の不一致によりレスポンスを中止しました。 2XX
byte_range_caching_forwarded_backend_response ロードバランサはバイト範囲のキャッシュを使用してレスポンスを処理できませんでしたが、バックエンドからのレスポンスを処理できました。 バックエンドからの戻り値(任意のレスポンス コード)。
byte_range_caching_retrieval_abandoned ユーザーが Cloud CDN によって開始されたバイト範囲リクエストまたは検証リクエストをキャンセルしました。 バックエンドからの戻り値(任意のレスポンス コード)。
byte_range_caching_retrieval_from_backend_failed_after_partial_response Cloud CDN によって開始されたバイト範囲リクエストまたは検証リクエストでエラーが発生しました。Cloud CDN によって開始されたリクエストに対応する Stackdriver Logging のログエントリを参照して、バックエンドの詳細を確認してください。 2XX
cache_lookup_failed_after_partial_response ロードバランサは、内部エラーのため、キャッシュから完全なレスポンスを提供することができませんでした。 2XX
cache_lookup_timeout_after_partial_response クライアントがコンテンツをタイムリーに取得しなかったため、キャッシュ検索ストリームがタイムアウトになりました。 2XX
client_disconnected_after_partial_response ロードバランサが部分的レスポンスを送信した後で、クライアントへの接続が切断されました。 VM バックエンドからの戻り値(任意のレスポンス コード)
client_disconnected_before_any_response ロードバランサが、何らのレスポンスも送信する前に、クライアントへの接続が切断されました。 0
client_timed_out ロードバランサは、要求またはレスポンスのいずれかをプロキシ処理する間に、進捗がないため、クライアント接続をアイドル状態にしました。 0 または 408
denied_by_security_policy 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_http2_client_header_format クライアントからの HTTP/2 ヘッダーが無効です。 400
malformed_chunked_body リクエストの本文のチャンク エンコードが不適切です。 411
request_loop_detected ロードバランサがリクエスト ループを検出しました。これは、構成ミスにより生じた可能性があります。具体的には、バックエンドがロードバランサにリクエストを戻したという場合です。 502
required_body_but_no_content_length HTTP リクエストは本文を要求していますが、リクエスト ヘッダーにコンテンツ長が含まれていないか、または転送エンコーディングされたチャンク形式ヘッダーです。 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 接続が切断されました。
websocket_handshake_failed WebSocket が handshake できませんでした。 任意のレスポンス コード。handshake 失敗の性質によって異なります。

IP 拒否リストまたは許可リストのロギング

次に示すログビューアのログエントリは、HTTP(S) IP 拒否リストまたは IP 許可リストのロギングのためのものであり、jsonPayload 内の次のような構造を含んでいます。HTTP リクエストの詳細は、httpRequest メッセージに含まれます。

  • status_details(文字列) - レスポンス コードのテキスト記述
  • enforced_security_policy - 実際に適用されたセキュリティ ポリシールール。
    • outcome(文字列) - ACCEPTDENYUNKNOWN_OUTCOME
    • configured_action(文字列) - outcome と同じ
    • name(文字列) - セキュリティ ポリシーの名前
    • priority(数値) - 一致するルールの優先度
  • preview_security_policy - リクエストがプレビュー用に構成されたルールに該当した場合に構成されます(プレビュー ルールが適用済みのルールよりも優先される場合にのみ表示されます)
    • outcome(文字列) - ACCEPTDENYUNKNOWN_OUTCOME
    • configured_action(文字列) - outcome と同じ
    • name(文字列) - セキュリティ ポリシーの名前
    • priority(数値) - 一致するルールの優先度

Stackdriver Logging API を使用すると、HTTP(S) Load Balancer のログを操作できます。このロギングの API は、特定のフィールドが設定されたログをインタラクティブにフィルタリングし、一致するログを Stackdriver コンソール、Google Cloud Storage、BigQuery、または Cloud Pub/Sub にエクスポートする方法を提供します。Stackdriver Logging API の詳細については、ログの表示をご覧ください。

モニタリング

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

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

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

Stackdriver の事前に定義されたダッシュボードに加えて、カスタム ダッシュボードを作成して、アラートをセットアップし、Stackdriver Monitoring API を通して指標を照会できます。

Stackdriver Monitoring ダッシュボードの表示

  1. Google Cloud Platform Console で、[モニタリング] に移動します。
    [モニタリング] に移動
  2. [Resources] > [Google Cloud Load Balancers] を選択します。
  3. ロードバランサの名前をクリックします。

左側のペインでは、この HTTP(S) ロードバランサのさまざまな詳細を確認できます。 右側のペインでは時系列のグラフを表示できます。[Breakdowns] リンクをクリックすると、特定の内訳が表示されます。

Stackdriver アラートの定義

Stackdriver アラートは、さまざまな HTTP(S) 負荷分散指標に基づいて定義できます。

  1. Google Cloud Platform Console で、[モニタリング] に移動します。
    [モニタリング] に移動
  2. [Alerting] > [Create a Policy] を選択します。
  3. [Add Condition] をクリックし、条件タイプを選択します。
  4. 指標とフィルタを選択します。指標のリソースタイプは HTTP(S) Load Balancer です。
  5. [Save Condition] をクリックします。
  6. ポリシー名を入力し、[Save Policy] をクリックします。

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

HTTP(S) 負荷分散指標に基づくカスタム Stackdriver ダッシュボードを作成できます。

  1. Google Cloud Platform Console で、[モニタリング] に移動します。
    [モニタリング] に移動
  2. [Dashboards] > [Create Dashboard] を選択します。
  3. [Add Chart] をクリックします。
  4. グラフにタイトルを付けます。
  5. 指標とフィルタを選択します。指標のリソースタイプは HTTP(S) Load Balancer です。
  6. [Save] をクリックします。

指標報告の頻度と保持

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

HTTP(S) ロードバランサのモニタリング指標

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

指標 説明
リクエスト数 HTTP(S) ロードバランサによって処理されるリクエストの数
リクエスト バイト数 ユーザーから HTTP(S) ロードバランサにリクエストとして送信されたバイト数
レスポンス バイト数 HTTP(S) ロードバランサからユーザーにレスポンスとして送信されたバイト数
総レイテンシ ロードバランサ プロキシが最初のリクエスト バイトを受信してから、最後のレスポンス バイトで要求側のクライアントからの ACK を受信するまでのレイテンシの分布。 総レイテンシはリクエスト / レスポンスによって測定されるので、`Connection: keep-alive` を使った同じ接続上のリクエスト間の休止は測定に影響しません。通常、Stackdriver ビューでは 95 パーセンタイルに縮小されます。
例: ロードバランサが、英国から 1 秒間に 1 件のリクエスト(すべて 100 ms のレイテンシ)と、米国から 1 秒間に 9 件のリクエスト(すべて 50 ms のレイテンシ)を処理しています。1 分間では、英国から 60 件、米国から 540 件のリクエストが発生することになります。モニタリング指標には、すべてのディメンションにわたる分散が保存されます。この場合、以下を要求することができます。
  • 平均全体レイテンシ(300/600) - 50ms
  • 平均英国レイテンシ(30/60) - 100ms
  • 95 パーセンタイル全体レイテンシ(570/600) - 100ms
  • その他
フロントエンド RTT(*) クライアントとプロキシ間の接続ごとに測定された平滑化された RTT の分布(プロキシの TCP スタックによって測定)。通常、Stackdriver ビューでは 95 パーセンタイルに縮小されます。
バックエンド レイテンシ(*) プロキシがバックエンドに最初のリクエスト バイトを送信してから、バックエンドから最後のレスポンス バイトを受信するまでのレイテンシの分布。通常、Stackdriver ビューでは 95 パーセンタイルに縮小されます。
レスポンス コードクラス比 各レスポンス コードクラスにある HTTP(S) ロードバランサのレスポンスの合計の割合(2XX、4XX、...)。Stackdriver では、この値はデフォルトのダッシュボードでのみ使用できます。カスタム ダッシュボードでは取得できません。 それに関するアラートを API 経由で設定できます。
バックエンドのリクエスト数 HTTP(S) ロードバランサからバックエンドに送信されたリクエストの数。
バックエンド リクエストのバイト数 HTTP(S) ロードバランサからバックエンドにリクエストとして送信されたバイト数。
バックエンド レスポンスのバイト数 バックエンドから HTTP(S) ロードバランサへのレスポンスとして送信されたバイト数。

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

HTTP(S) ロードバランサ指標のディメンションのフィルタ処理

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

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

使用可能なインスタンス グループが存在しない場合やリクエストが別のエンティティによって処理された場合は、バックエンド サービスのインスタンス グループのリージョンまたはゾーンではなく、次の値のいずれかが表示されます。
  • FRONTEND_5XX - プロキシがバックエンドを選択する前に内部エラーが発生しました。プロキシからクライアントに 5XX が返されました。
  • INVALID_BACKEND - リクエストを割り当て可能な正常なバックエンドが見つからなかったため、プロキシからリクエスト送信元に 5XX レスポンスが返されました。
  • NO_BACKEND_SELECTED - バックエンドを選択する前にエラーまたはその他の割り込みが発生しました。
  • INVALID_BACKEND - プロキシが有効な正常バックエンドを見つけられなかったため、リクエスト元に 5xx を返しました。
  • SERVED_FROM_BACKEND_BUCKET - リクエストがバックエンド サービスのインスタンス グループではなく、バックエンド バケットによって処理されました。
  • SERVED_FROM_CACHE - リクエストがプロキシ キャッシュによって処理されたため、バックエンドは割り当てられませんでした。
  • MULTIPLE_BACKENDS - リクエストが複数のバックエンドによって処理されました。

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

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

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

使用可能なインスタンス グループが存在しない場合やリクエストが別のエンティティによって処理された場合は、インスタンス グループではなく、次の値のいずれかが表示されます。
  • FRONTEND_5XX - プロキシがバックエンドを選択する前に内部エラーが発生しました。プロキシからクライアントに 5XX が返されました。
  • INVALID_BACKEND - リクエストを割り当て可能な正常なバックエンドが見つからなかったため、プロキシからリクエスト送信元に 5XX レスポンスが返されました。
  • NO_BACKEND_SELECTED - バックエンドを選択する前にエラーまたはその他の割り込みが発生しました。
  • INVALID_BACKEND - プロキシが有効な正常バックエンドを見つけられなかったため、リクエスト元に 5xx を返しました。
  • SERVED_FROM_BACKEND_BUCKET - リクエストがバックエンド サービスのインスタンス グループではなく、バックエンド バケットによって処理されました。
  • SERVED_FROM_CACHE - リクエストがプロキシ キャッシュによって処理されたため、バックエンドは割り当てられませんでした。
  • MULTIPLE_BACKENDS - リクエストが複数のバックエンドによって処理されました。

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

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

次のステップ