Application Load Balancer (ALB) アクセスログの有効化と管理 - Server Load Balancer

アクセスログに基づいてユーザー行動を分析し、ユーザーの地理的分布を理解し、問題のトラブルシューティングを行うには、ALB が Simple Log Service (SLS) と連携して提供するアクセスログ機能を使用します。

ALB アクセスログは、リクエスト監査、障害診断、パフォーマンス分析といったシナリオに適しており、Nginx などの従来の Web ゲートウェイと同様のアクセスログ記録機能を提供します。アクセスログを使用して、HTTP リクエストヘッダー、ステータスコード、レイテンシー分布などの情報を照会し、リクエスト内のエラー URL、API の高レイテンシー、モニタリングデータと実際のトラフィック量の乖離といった問題をトラブルシューティングできます。アクセスログは、正常に確立された HTTP/HTTPS リクエストのみを記録し、TCP 接続の失敗、ポートスキャン、TLS ハンドシェイクの失敗などのイベントは記録しません。

課金

ALB のアクセスログが Simple Log Service に転送されると、ストレージ、読み取りトラフィック、リクエスト、データ変換、転送に対して課金されます。Simple Log Service の課金

前提条件

Simple Log Service が有効化されています。 Simple Log Service を有効化する

アクセスログの作成

ALBコンソールにログインします。
トップナビゲーションバーで、ALB インスタンスがデプロイされているリージョンを選択します。
インスタンス ページで、管理対象のインスタンスの ID をクリックします。
インスタンスの詳細ページで、アクセスログ タブをクリックし、アクセスログの作成 をクリックします。

アクセスログの作成 ダイアログボックスで、プロジェクト と Logstore のパラメーターを設定し、OK をクリックします。

パラメーター	説明
[プロジェクト]	リソースを管理する Simple Log Service プロジェクトを選択します。オプション：既存の Project の選択：ドロップダウンリストから既存のプロジェクトを選択します。 Project の新規作成：フィールドにプロジェクト名を入力します。
[Logstore]	ログデータを収集、保存、照会するログストアを選択します。オプション：既存の Logstore の選択：ドロップダウンリストから既存のログストアを選択します。 [Logstore の新規作成]: フィールドに Logstore 名を入力します。[プロジェクトの作成] を選択した場合は、[ログストアの作成] も選択する必要があります。
[サービスにリンクされたロールの作成に関する注意事項]	サービスリンクロールは自動的に作成されます。

表示されたメッセージの内容を確認し、OK をクリックします。
- ログストアを作成すると、デフォルトでインデックスとダッシュボードが有効になります。
- 既存のログストアを選択した場合、ダッシュボードは自動的に有効になります。既存のインデックスは上書きされません。インデックスは Simple Log Service コンソールで作成します。

アクセスログの表示

アクセスログ タブで、保存先パス の右側にあるリンクをクリックして Simple Log Service コンソールに移動し、ログデータを表示します。

アクセスログ タブで、モニタリングセンター、アクセスセンター、または 詳細モニタリング タブをクリックし、フィルター条件を指定してメトリックを照会します。

モジュール	説明
モニタリングセンター	リアルタイムモニタリングデータを表示：PV、リクエスト成功率、平均レイテンシー、4xx リクエスト、ステータス分布、トラフィック、P50/P90/P99/P9999 レイテンシー、およびリクエスト数、レイテンシー、失敗率別の上位ホスト/URL/バックエンド。
アクセスセンター	アクセス統計を表示：PV/UV の前日比と前週比、PV/UV 分布、本日の PV、7 日間の PV、リクエスト数が最も多い上位 10 の州、モバイルユーザーの割合、上位 10 のホスト、上位 10 のユーザーエージェント、およびリクエスト数が最も多い IP アドレス。
詳細モニタリング	一時的なジッターを特定するために 1 秒間隔で集計されたメトリクスを表示：QPS、アクセスレイテンシー、アップストリームレイテンシー、成功率、リクエストトラフィック、レスポンスボディトラフィック、ステータスコード 2xx、ステータスコード 3xx、エラーコード、アップストリームステータスコード 2xx、アップストリームステータスコード 3xx、およびアップストリームエラーコード。

モニタリングセンター、アクセスセンター、または詳細モニタリング タブの右上隅にある その他のグラフ をクリックすると、[CloudLens for ALB] ページに移動して、より多くの ALB レポートを表示できます。詳細については、「データレポート」をご参照ください。
モニタリングセンター、アクセスセンター、または 詳細モニタリング タブの右上隅で、アラートルールの設定 をクリックして [CloudLens for ALB] ページに移動し、ALB のアラートイベントを表示します。
モニタリングセンター、アクセスセンター、または詳細モニタリング タブの右上隅では、次の機能も使用できます：
- ：専用 SQL を有効にします。「専用 SQL の有効化」をご参照ください。
- Simple Log Service に配信後、アクセスログの照会、分析、ダウンロード、配信、処理、およびアラートルールの作成を行うことができます。詳細については、「サービスログの一般的な操作」をご参照ください。

カスタムヘッダーの記録

slb_headers は、リクエスト分析のためにカスタムリクエストヘッダー名と値を記録します。

アクセスログあたりのカスタムヘッダーの最大サイズは 1 KB です (4 KB まで拡張可能)。拡張をご希望の場合は、アカウントマネージャーにお問い合わせください。詳細については、「リクエスト長の制限」をご参照ください。

1 つのログエントリ内のカスタムヘッダーの合計長が上記の制限を超える場合、slb_headers フィールドは制限内に収まるヘッダーのみを記録し、フィールド値の末尾に Discarded:TooManyCustomizedHeaders を追加します。

Extensible Edition は、カスタムヘッダーの記録をサポートしていません。

アクセスログ タブで、基本情報 セクションの カスタムヘッダーの記録 をクリックします。
カスタム HTTP ヘッダーのログへの記録 ダイアログボックスで、ドロップダウンリストから ALB インスタンスに追加されているリスナーを選択します。

リスナーを作成するには、ドロップダウンリストで リスナーの作成 をクリックします。詳細については、「HTTP リスナーの追加」、「HTTPS リスナーの追加」、および「QUIC リスナーの追加」をご参照ください。

表示されるメッセージの情報を読み、OK をクリックします。

設定後、slb_headers フィールドは以下を除くすべてのリクエストヘッダーを記録します：

# slb_headers フィールドは、以下のヘッダーに関する情報を記録しません：
host
Referer
user-agent
x-forwarded-for
x-readtime
x-real-ip
uber-trace-id
X-B3-TraceId
X-B3-SpanId
X-B3-ParentSpanId
X-B3-Sampled

アクセスログの無効化

アクセスログ タブで、基本情報 セクションにある ログの無効化 をクリックします。
表示されるメッセージの内容を確認し、OK をクリックします。

ログフィールド

Standard Edition

フィールド	説明
app_lb_id	ALB インスタンス ID。
__topic__	ログトピック。デフォルト： alb_layer7_access_log。
body_bytes_sent	HTTP レスポンスボディサイズ。単位：バイト。
client_ip	クライアント IP 取得が有効な場合はクライアント IP アドレス、それ以外の場合は前のホップの IP アドレス。
host	ドメイン名または IP アドレス。解決順序：リクエストパラメーター → Host ヘッダー → バックエンドサーバー IP。
http_host	HTTP リクエストの Host ヘッダー。
http_referer	HTTP リクエストの Referer ヘッダー。
http_user_agent	HTTP リクエストの User-Agent ヘッダー。
http_x_forwarded_for	HTTP リクエストの X-Forwarded-For ヘッダー。
http_x_real_ip	HTTP リクエストの X-Real-IP ヘッダー。
read_request_time	ALB がリクエストを読み取るのにかかる時間。単位：ミリ秒。
request_length	リクエスト開始行、ヘッダー、ボディの合計サイズ。単位：バイト。
request_method	リクエストメソッド。
request_time	リクエスト受信からレスポンス送信までの時間。単位：秒。
request_uri	リクエストの URI。
scheme	リクエストスキーム：HTTP または HTTPS。
server_protocol	HTTP プロトコルバージョン。例： HTTP/1.0、HTTP/1.1。
slb_vport	ALB インスタンスのリスナーポート。
slb_xtrace	トレーシング分析用の ALB インスタンスのトレース ID。
xtrace_type	ALB インスタンスのトレーシング分析に Xtrace が使用するデータタイプ。Zipkin のみサポート。
ssl_cipher	SSL 接続に使用される暗号スイート。例： ECDHE-RSA-AES128-GCM-SHA256。
ssl_protocol	SSL 接続プロトコル。例： TLS 1.2。
status	ALB インスタンスが返す HTTP ステータスコード。
tcpinfo_rtt	TCP 接続確立時間。単位：ミリ秒。
time	ログ生成時刻 (ISO 8601 形式)： `YYYY-MM-DDThh:mm:ssZ`。
upstream_addr	バックエンドサーバーの IP アドレスとポート。
upstream_response_time	バックエンド接続確立からクローズまでの時間。単位：秒。
upstream_status	バックエンドサーバーからの HTTP ステータスコード。
vip_addr	仮想 IP アドレス。
write_response_time	レスポンス書き込み時間。単位：ミリ秒。
client_port	クライアントポート番号。
slb_headers	カスタムヘッダー。カスタムヘッダーの記録を有効にすると利用可能になります。

Extensible Edition

フィールド	説明
app_lb_id	ALB インスタンス ID。
__topic__	ログトピック。デフォルト： alb_layer7_access_log。
body_bytes_sent	HTTP レスポンスボディサイズ。単位：バイト。
client_ip	クライアント IP 取得が有効な場合はクライアント IP アドレス、それ以外の場合は前のホップの IP アドレス。
host	ドメイン名または IP アドレス。解決順序：リクエストパラメーター → Host ヘッダー → バックエンドサーバー IP。
http_referer	HTTP リクエストの Referer ヘッダー。
http_user_agent	HTTP リクエストの User-Agent ヘッダー。
http_x_forwarded_for	HTTP リクエストの X-Forwarded-For ヘッダー。ALB が書き換えた後の X-Forwarded-For の値を記録します。
http_x_real_ip	HTTP リクエストの X-Real-IP ヘッダー。
read_request_time	ALB がリクエストを読み取るのにかかる時間。単位：ミリ秒。
request_length	リクエスト開始行、ヘッダー、ボディの合計サイズ。単位：バイト。
request_method	リクエストメソッド。
request_time	リクエスト受信からレスポンス送信までの時間。単位：秒。
request_uri	リクエストの URI。
scheme	リクエストスキーム：HTTP または HTTPS。
server_protocol	HTTP プロトコルバージョン。例： HTTP/1.0、HTTP/1.1。
slb_vport	ALB インスタンスのリスナーポート。
ssl_cipher	SSL 接続に使用される暗号スイート。例： ECDHE-RSA-AES128-GCM-SHA256。
ssl_protocol	SSL 接続プロトコル。例： TLS 1.2。
status	ALB インスタンスが返す HTTP ステータスコード。
time	ログ生成時刻 (ISO 8601 形式)： `YYYY-MM-DDThh:mm:ssZ`。
upstream_addr	バックエンドサーバーの IP アドレスとポート。
upstream_response_time	バックエンド接続確立からクローズまでの時間。単位：秒。
vip_addr	仮想 IP アドレス。
write_response_time	レスポンス書き込み時間。単位：ミリ秒。
client_port	クライアントポート番号。
upstream_protocol	ALB とバックエンドサーバー間の通信に使用される HTTP プロトコルバージョン。
upstream_hostname	バックエンドサーバーの DNS ドメイン名。DNS ドメイン名が利用できない場合は、バックエンドサーバーの IP アドレスとポートが使用されます。
response_flags	レスポンスまたは接続に関する追加の詳細情報。
status_details	レスポンスステータスコードの詳細情報 (via_upstream、direct_response、route_not_found など)。
llm_log	JSON 形式でエンコードされた AI リクエストデータです。次のサブフィールドが含まれます： chat_id： LLM 会話の ID。 chat_round：現在の会話ラウンド。 first_token_duration：ストリームリクエスト送信から最初のトークンレスポンス受信までのレイテンシー (ミリ秒単位)。 input_token：リクエスト内のトークン数。 output_token：レスポンス内のトークン数。 total_token：トークンの合計数。 model：このリクエストで実際に呼び出されたモデル。 response_type：レスポンスタイプ (ストリーミングまたは非ストリーミング)。

クエリ例

Simple Log Service コンソールのログクエリページで、次の方法で ALB アクセスログをフィルタリングできます：

時間でフィルター：ページ上部のタイムピッカーを使用して、過去 15 分間、過去 1 時間、今日、またはカスタム時間範囲などの時間範囲を選択します。
URL でフィルター：クエリ入力ボックスに request_uri:/api/xxx と入力すると、リクエスト URI に /api/xxx を含むログエントリのみが表示されます。
ステータスコードでフィルター：status:200 または status:5* と入力して、特定のステータスコードのリクエストをクエリします。
リクエストメソッドでフィルター：request_method:Get* と入力して、GET リクエストをフィルタリングします。
複数条件クエリ：request_uri:/api/xxx and status:200 と入力して、特定の URI パターンに一致し、ステータスコードが 200 のリクエストをフィルタリングします。

重要

field:value 構文を使用してフィールド固有のクエリを実行する前に、Simple Log Service コンソールで対応するログフィールドのフィールドインデックスを設定してください。全文インデックスは、フィールドクエリをサポートしていません。フィールドインデックスが設定されていない場合、クエリでエラーが返されます。インデックス作成に使用できるフィールドのリストについては、上記の ログフィールド の表をご参照ください。

よくある質問

アクセスログを作成する前に、ALB インスタンスにアクセスするリクエストに関するデータを表示できますか?

いいえ、できません。

アクセスログは、有効にした時点からのデータのみをキャプチャします。アクセスログを有効にする前は、Simple Log Service は ALB からアクセスデータを収集しません。

ALB のモニタリングに異常 (4XX エラーや高トラフィック量など) やスキャン活動が表示されるのに、アクセスログにレコードが表示されないのはなぜですか?

考えられる原因は次のとおりです。

1. アクセスログが有効になっていない

詳細なエラー情報、リクエスト URL を照会し、データの正確性を検証するには、ALB アクセスログ機能を有効にする必要があります。アクセスログを有効にしていない場合、モニタリングデータのみに基づいて問題をトラブルシューティングすることは困難です。

2. TCP 接続の失敗またはポートスキャン

ALB はレイヤー 7 ロードバランサーです。アクセスログは HTTP/HTTPS リクエストのみを記録し、TCP 接続の失敗は記録しません。異常な IP アドレスを特定してブロックするには、Cloud Firewall を有効にして、ALB パブリック IP アドレスへの TCP 接続が失敗したレコードを表示してください。

3. レイヤー 4 リスナーのタイムアウト

レイヤー 4 TCP リスナーのタイムアウトは、通常 Ingress ログやアクセスログには記録されません。接続が正常に確立されたがレスポンスがタイムアウトした場合にのみ、499 または 504 ステータスコードのエントリが生成される可能性があります。

4. TLS ハンドシェイクの失敗

TLS ハンドシェイクの失敗 (証明書の不一致、プロトコルバージョンの非互換性など) は、通常アクセスログに直接反映されません。これは、ハンドシェイクが失敗した時点では HTTP リクエストが確立されていないためです。これらの問題には、バックエンドサーバーログとクライアント側のパケットキャプチャを使用した分析が必要です。

ALB アクセスログを使用して、エラー URL、高レイテンシー、または特定のリクエストレコードをトラブルシューティングするにはどうすればよいですか?

Simple Log Service コンソールにログインし、対応する ALB Logstore に移動して、次のシナリオに従ってクエリを実行します。

1. 特定のステータスコード (400 または 4XX など) を返す URL をクエリする

クエリ入力ボックスに status:400 (または別のステータスコード、例： status:5*) と入力します。結果の request_uri フィールドを確認して、エラーを返した特定の URL パスを特定します。

2. 高レイテンシーをトラブルシューティングする

upstream_response_time フィールドでフィルターします。このフィールドは、ALB がバックエンドサーバーへの接続を確立してからデータの受信を完了するまでの時間を記録します (単位：秒)。値が高い場合、レイテンシーは ALB の転送ではなくバックエンド処理に起因していることを示します。これを request_time フィールドと比較して、合計経過時間 (クライアントリクエストの受信からレスポンスの返却までの間隔、単位：秒) を確認します。

3. 特定のパスまたは送信元 IP のリクエストレコードを検証する

request_uri などのフィールドは、SLS Logstore ではデフォルトでインデックス化されていないため、パスキーワードで直接検索することはできません。client_ip (クライアント IP) や http_host (リクエスト Host) などのインデックス化されたフィールドを組み合わせクエリで使用して、ALB が指定された送信元からのリクエストを受信したかどうかを確認します。request_uri を直接検索するには、まず SLS コンソールでこのフィールドのインデックスを作成してください。

4. ログデータの正確性を検証する

ALB アクセスログは、クライアントが ALB を介してバックエンドサービスにアクセスするすべての HTTP/HTTPS リクエストトラフィックを記録します。このドキュメントの ログフィールド セクションを参照してデータ定義を確認し、ログの内容が想定されるビジネストラフィックと一致するかどうかを確認してください。