メニュー
Elastic Load Balancing
クラシックロードバランサー

Classic Load Balancer のアクセスログ

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

アクセスログの作成は、Elastic Load Balancing のオプション機能であり、デフォルトでは無効化されています。ロードバランサーのログにアクセスできるようにすると、Elastic Load Balancing はログをキャプチャし、指定した 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 分の遅延があります。発行間隔はいつでも変更できます。

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

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

bucket[/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
bucket

S3 バケットの名前。

プレフィックス

バケットのプレフィックス (論理階層)。プレフィックスを指定しない場合、ログはバケットのルートレベルに配置されます。

aws-account-id

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

リージョン

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

yyyy/mm/dd

ログが配信された日付。

load-balancer-name

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

end-time

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

ip-address

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

random-string

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

ログファイル名の例は次のようになります。

s3://my-loadbalancer-logs/my-app/AWSLogs/123456789012/elasticloadbalancing/us-west-2/2014/02/15/123456789012_elasticloadbalancing_us-west-2_my-loadbalancer_20140215T2340Z_172.160.001.192_20sg8hgm.log

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

アクセスログのエントリ

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

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

フィールド 説明

timestamp

ロードバランサーがクライアントからリクエストを受け取った時刻 (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 バージョン。

(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 は、標準 SQL を使用して Amazon S3 のデータの分析を簡易化するインタラクティブなクエリサービスです。詳細については、Amazon Athena ユーザーガイドの「Classic Load Balancer ログのクエリ」を参照してください。

  • Amazon EMR を使用すると、大量のデータをすばやく効率的に処理できます。

  • Splunk

  • Sumo Logic