Classic Load Balancer のアクセスログ - エラスティックロードバランシング
アクセスログファイルアクセスログのエントリアクセスログの処理

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Classic Load Balancer のアクセスログ

Elastic Load Balancing は、ロードバランサーに送信されるリクエストに関する詳細情報をキャプチャしたアクセスログを提供します。各ログには、リクエストを受け取った時刻、クライアントの IP アドレス、レイテンシー、リクエストのパス、サーバーレスポンスなどの情報が含まれます。これらのアクセスログを使用して、トラフィックパターンの分析や、問題のトラブルシューティングを行うことができます。

アクセスログの作成は、Elastic Load Balancing のオプション機能であり、デフォルトでは無効化されています。ロードバランサーのアクセスログの作成を有効にすると、Elastic Load Balancing はログをキャプチャし、そのログを指定した Amazon S3 バケット内に保存します。アクセスログの作成はいつでも無効にできます。

各アクセスログファイルは、S3 バケットに保存される前に、SSE-S3 を使用して自動的に暗号化され、アクセス時に復号化されます。お客様によるアクションは必要はありません。暗号化と復号は透過的に実行されます。各ログファイルは一意のキーで暗号化されます。この一意のキー自体が、定期的に更新される KMS キーで更新されます。詳細については、「Amazon S3-managed暗号化キーによるサーバー側の暗号化 (SSE-S3) を使用したデータの保護」を参照してください。 Amazon S3

アクセスログに対する追加料金はありません。Amazon S3 のストレージコストは発生しますが、Amazon S3 にログファイルを送信するために Elastic Load Balancing が使用する帯域については料金は発生しません。ストレージコストの詳細については、Amazon S3 の料金を参照してください。

目次

アクセスログファイル

Elastic Load Balancing は、指定した間隔で各ロードバランサーノードにログファイルを発行します。ロードバランサーのアクセスログを有効にするときに、5 分または 60 分の発行間隔を指定できます。デフォルトでは、Elastic Load Balancing は 60 分間隔でログを発行します。間隔を 5 分に設定すると、ログは、1:05、1:10、1:15、のように発行されます。ログの配信開始は、間隔が 5 分に設定されている場合は最大 5 分の遅延があり、間隔が 60 分に設定されている場合は最大 15 分の遅延があります。発行間隔はいつでも変更できます。

ロードバランサーでは、同じ期間について複数のログが発行されることがあります。これは通常、サイトのトラフィックが大量である場合、ロードバランサーノードが複数ある場合、およびログ発行間隔が短い場合に発生します。

アクセスログのファイル名には次の形式を使用します。

amzn-s3-demo-loadbalancer-logs[/logging-prefix]/AWSLogs/aws-account-id/elasticloadbalancing/region/yyyy/mm/dd/aws-account-id_elasticloadbalancing_region_load-balancer-name_end-time_ip-address_random-string.log
amzn-s3-demo-loadbalancer-logs

S3 バケットの名前。

prefix

（オプション）バケットのプレフィックス (論理階層)。指定するプレフィックスに文字列 AWSLogs を含めることはできません。詳細については、「プレフィックスを使用してオブジェクトを整理する」を参照してください。

AWSLogs

指定したバケット名とオプションのプレフィックスの後に、AWSLogs で始まるファイル名部分が追加されます。

aws-account-id

所有者の AWS アカウント ID。

region

ロードバランサーおよび S3 バケットのリージョン。

yyyy/mm/dd

ログが配信された日付。

load-balancer-name

ロードバランサーの名前。

end-time

ログ作成の間隔が終了した日時。例えば、発行間隔が 5 分の場合、終了時刻が 20140215T2340Z であれば 23:35 から 23:40 の間に作成されたリクエストに関するエントリが含まれています。

ip-address

リクエストを処理したロードバランサーノードの IP アドレス。内部ロードバランサーの場合、プライベート IP アドレスです。

random-string

システムによって生成されたランダム文字列。

「my-app」をプレフィックスとするログファイル名の例を次に示します。

s3://amzn-s3-demo-loadbalancer-logs/my-app/AWSLogs/123456789012/elasticloadbalancing/us-west-2/2018/02/15/123456789012_elasticloadbalancing_us-west-2_my-loadbalancer_20180215T2340Z_172.160.001.192_20sg8hgm.log

プレフィックスが付いていないログファイル名の例は次のようになります。

s3://amzn-s3-demo-loadbalancer-logs/AWSLogs/123456789012/elasticloadbalancing/us-west-2/2018/02/15/123456789012_elasticloadbalancing_us-west-2_my-loadbalancer_20180215T2340Z_172.160.001.192_20sg8hgm.log

必要な場合はログファイルを自身のバケットに保管できますが、ログファイルを自動的にアーカイブまたは削除するにように Amazon S3 ライフサイクルルールを定義することもできます。詳細については、Amazon S3ユーザーガイド」の「オブジェクトライフサイクル管理」を参照してください。

アクセスログのエントリ

Elastic Load Balancing は、バックエンドのインスタンスに到達しなかったリクエストを含め、ロードバランサーに送信されたリクエストを記録します。例えば、クライアントが誤った形式のリクエストを送信した場合や、応答できる正常に動作しているインスタンスがない場合も、そのリクエストは記録されます。

重要

Elastic Load Balancing はベストエフォートベースでリクエストを記録します アクセスログは、すべてのリクエストを完全に報告するためのものではなく、リクエストの本質を把握するものとして使用することをお勧めします。

構文

各ログエントリには、ロードバランサーに対する 1 件のリクエストの詳細が含まれます。ログエントリのすべてのフィールドはスペースで区切られています。ログファイルの各エントリは次の形式になります。

timestamp elb client:port backend:port request_processing_time backend_processing_time response_processing_time elb_status_code backend_status_code received_bytes sent_bytes "request" "user_agent" ssl_cipher ssl_protocol

次の表は、アクセスログのエントリのフィールドを示しています。

フィールド 説明

time

ロードバランサーがクライアントからリクエストを受け取った時刻 (ISO 8601 形式)。

elb

ロードバランサーの名前

client:port

リクエストを送信したクライアントの IP アドレスとポート。

backend:port

このリクエストを処理した登録済みインスタンスの IP アドレスとポート。

ロードバランサーが登録されたインスタンスにリクエストを送信できない場合、または応答が送信される前にインスタンスが接続を閉じた場合、この値は - に設定されます。

登録済みインスタンスからアイドルタイムアウトまで応答がない場合にも、この値は - に設定される場合があります。

request_processing_time

[HTTP リスナー] ロードバランサーがリクエストを受け取った時点から登録済みインスタンスに送信するまでの合計経過時間 (秒単位)。

[TCPリスナー] ロードバランサーがクライアントから TCP/SSL 接続を受け入れた時点から、ロードバランサーがデータの最初のバイトを登録されたインスタンスに送信するまでの合計経過時間 (秒単位)。

ロードバランサーがリクエストを登録されたインスタンスにディスパッチできない場合、この値は -1 に設定されます。この状況が発生するのは、登録済みインスタンスがアイドルタイムアウト前に接続を閉じた場合か、クライアントが誤った形式のリクエストを送信した場合です。さらに、TCP リスナーの場合、クライアントがロードバランサーと接続を確立するが、データを送信しない場合にもこの状況が発生する可能性があります。

登録済みインスタンスからアイドルタイムアウトまで応答がない場合にも、この値は -1 に設定される場合があります。

backend_processing_time

(HTTP リスナーの場合) ロードバランサーが登録済みインスタンスにリクエストを送信した時点から、そのインスタンスが応答ヘッダーの送信を開始した時点までの合計経過時間 (秒単位)。

[TCP リスナー] ロードバランサーが、登録済みインスタンスへの接続を正常に確立するまでの合計経過時間 (秒)。

ロードバランサーがリクエストを登録されたインスタンスにディスパッチできない場合、この値は -1 に設定されます。この状況が発生するのは、登録済みインスタンスがアイドルタイムアウト前に接続を閉じた場合か、クライアントが誤った形式のリクエストを送信した場合です。

登録済みインスタンスからアイドルタイムアウトまで応答がない場合にも、この値は -1 に設定される場合があります。

response_processing_time

(HTTP リスナーの場合) ロードバランサーが登録済みインスタンスから応答ヘッダーを受け取った時点から、クライアントへの応答の送信を開始した時点までの合計経過時間 (秒単位)。これには、ロードバランサーでの待機時間と、ロードバランサーからクライアントへの接続の取得時間の両方が含まれます。

(TCP リスナーの場合) ロードバランサーが登録済みインスタンスから最初のバイトを受け取った時点から、クライアントへの応答の送信を開始した時点までの合計経過時間 (秒単位)。

ロードバランサーがリクエストを登録されたインスタンスにディスパッチできない場合、この値は -1 に設定されます。この状況が発生するのは、登録済みインスタンスがアイドルタイムアウト前に接続を閉じた場合か、クライアントが誤った形式のリクエストを送信した場合です。

登録済みインスタンスからアイドルタイムアウトまで応答がない場合にも、この値は -1 に設定される場合があります。

elb_status_code

(HTTP リスナーの場合) ロードバランサーからの応答のステータスコード。

backend_status_code

(HTTP リスナーの場合) 登録済みインスタンスからの応答のステータスコード。

received_bytes

クライアント (リクエスタ) から受け取ったリクエストのサイズ (バイト単位)。

(HTTP リスナーの場合) この値にはリクエストの本文が含まれますがヘッダーは含まれません。

(TCP リスナーの場合) この値にはリクエストの本文とヘッダーが含まれます。

sent_bytes

クライアント (リクエスタ) に返される応答のサイズ (バイト単位)。

(HTTP リスナーの場合) この値には応答の本文が含まれますがヘッダーは含まれません。

(TCP リスナーの場合) この値にはリクエストの本文とヘッダーが含まれます。

リクエスト

クライアントからのリクエスト行は二重引用符で囲まれており、次の形式でログに記録されます。HTTP メソッド + プロトコル://ホストヘッダー:ポート + パス + HTTP バージョン。ロードバランサーは、リクエスト URI を記録するときに、クライアントから送信された URL をそのまま保持します。アクセスログファイルのコンテンツタイプは設定されません。このフィールドを処理するときは、クライアントが URL を送信した方法を考慮してください。

(TCP リスナーの場合) URL は、3 個のダッシュをそれぞれスペース 1 個で区切り、末尾がスペースになります ("- - - ")。

user_agent

[HTTP/HTTPS リスナー] リクエスト元のクライアントを特定する User-Agent 文字列。この文字列は、1 つ以上の製品 ID (製品[/バージョン]) から構成されます。文字列が 8 KB より長い場合は切り捨てられます。

ssl_cipher

[HTTPS/SSL リスナー] SSL 暗号。正常なネゴシエーションの後に受信 SSL/TLS 接続が確立した場合にのみ、この値が記録されます。それ以外の場合、値は - に設定されます。

ssl_protocol

[HTTPS/SSL リスナー] SSL プロトコル。正常なネゴシエーションの後に受信 SSL/TLS 接続が確立した場合にのみ、この値が記録されます。それ以外の場合、値は - に設定されます。

例

HTTP エントリ例

次の例は、HTTP リスナーのログエントリです (ポート 80 からポート 80)。

2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.000073 0.001048 0.000057 200 200 0 29 "GET http://www.example.com:80/ HTTP/1.1" "curl/7.38.0" - -
HTTPS エントリ例

次の例は、HTTPS リスナーのログエントリです (ポート 443 からポート 80)。

2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.000086 0.001048 0.001337 200 200 0 57 "GET https://www.example.com:443/ HTTP/1.1" "curl/7.38.0" DHE-RSA-AES128-SHA TLSv1.2
TCP エントリ例

次の例は、TCP リスナーのログエントリです (ポート 8080 からポート 80)。

2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.001069 0.000028 0.000041 - - 82 305 "- - - " "-" - -
SSL エントリ例

次の例は、SSL リスナーのログエントリです (ポート 8443 からポート 80)。

2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.001065 0.000015 0.000023 - - 57 502 "- - - " "-" ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2

アクセスログの処理

ウェブサイトの需要が大きい場合は、ロードバランサーによって数 GB のデータ量のログファイルが生成されることがあります。このような大容量のデータは、行単位で処理できない場合があります。このため、場合によっては、並列処理ソリューションを提供する分析ツールを使用する必要があります。例えば、次の分析ツールを使用するとアクセスログの分析と処理を行うことができます。

  • Amazon Athena はインタラクティブなクエリサービスで、Amazon S3 内のデータを標準 SQL を使用して簡単に分析できるようになります。詳細については、Amazon Athena ユーザーガイドの「Classic Load Balancer ログのクエリ」を参照してください。

  • Loggly

  • Splunk

  • Sumo Logic