Server Load Balancer:アクセスログ

概要

前提条件

• CLB インスタンスを作成していること。

• vServer グループを作成し、その vServer グループにバックエンドサーバーを追加して、バックエンドサーバーにアプリケーションをデプロイしていること。

• CLB インスタンスに対して HTTP リスナーまたは HTTPS リスナーを設定していること。

• SLS をアクティベートしていること。

アクセスログの設定

1. CLBコンソールにログインします。

2. ナビゲーションペインで、操作ログ > アクセスログ を選択します。

3. 上部メニューで、CLB インスタンスがデプロイされているリージョンを選択します。

4. この機能を初めて使用する場合は、権限付与 をクリックします。クラウドリソースへのアクセスを許可 ページで、同意 をクリックします。

   説明

   この承認操作は一度だけ実行すれば十分です。

   RAM ユーザーの場合、プライマリ Alibaba Cloud アカウントがまず必要な権限を付与する必要があります。詳細については、「CLB のアクセスログ機能を使用するための RAM ユーザーの承認」をご参照ください。

5. アクセスログ (レイヤー 7) ページで、対象の CLB インスタンスを見つけ、操作 列の ロギングの設定 をクリックします。

6. ロギングの設定 パネルで、プロジェクト と Logstore を設定し、OK をクリックします。

   • プロジェクト： Project は、リソースを分離・制御するための SLS のリソース管理単位です。アプリケーションごとに異なる Project を使用することを推奨します。

   • Logstore： Logstore は、SLS でログデータを収集、保存、クエリするための単位です。同じアプリケーション内の異なるタイプのログには、個別のLogstoreを作成することを推奨します。

     • 既存の Logstore の選択： これを選択すると、選択した Logstore に対してデフォルトで事前設定された分析ダッシュボードが有効になります。Logstore にインデックスがすでに設定されている場合、既存のインデックス設定は上書きされます。

   説明

   • Project が CLB インスタンスと同じリージョンにあり、その名前がグローバルに一意であることを確認してください。

   • 設定後、SLS の Project と Logstore が SLS コンソールに表示されるまで数分かかる場合があります。この間、ログデータが失われることはありません。まだ表示されない場合は、後でページを更新してください。

   ロードバランサーのアクセスログを設定した後、SLS で以下のフィールドを使用してログ情報をクエリおよび取得できます。

   パラメーター	説明
   body_bytes_sent	クライアントに送信された HTTP 本文のサイズ。単位：バイト。
   client_ip	クライアント IP アドレス。
   client_port	リクエストを送信したクライアントのポート。
   host	ホストは、リクエストパラメーター、Host ヘッダー、リクエストを処理するバックエンドサーバーの IP アドレスの順で、最初に使用可能なソースから取得されます。
   http_host	リクエスト内の 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	ロードバランサーがリクエストを読み取るのにかかる時間。単位：ミリ秒。
   request_length	開始行、HTTP ヘッダー、HTTP 本文を含むリクエストの長さ。
   request_method	リクエストメソッド。
   request_time	ロードバランサーがリクエストの最初のバイトを受信してからレスポンスの最後のバイトを送信するまでの時間。単位：秒。
   request_uri	ロードバランサーが受信したリクエストの URI。
   scheme	リクエストスキーム。有効な値：http および https。
   server_protocol	ロードバランサーが受信したリクエストの HTTP バージョン (HTTP/1.0 や HTTP/1.1 など)。
   slb_vport	ロードバランサーのリスナーポート。
   slbid	ロードバランサーインスタンスの ID。
   ssl_cipher	SSL 接続の確立に使用される暗号スイート (ECDHE-RSA-AES128-GCM-SHA256 など)。
   ssl_protocol	SSL 接続の確立に使用されるプロトコル (TLSv1.2 など)。
   status	ロードバランサーからのレスポンスに含まれるステータスコード。
   tcpinfo_rtt	クライアントの TCP 接続のラウンドトリップタイム (RTT)。単位：マイクロ秒。
   time	ログエントリが記録された時刻。
   upstream_addr	バックエンドサーバーの IP アドレスとポート。
   upstream_response_time	バックエンドサーバーへの接続が確立されてから、レスポンスを受信した後に接続が閉じるまでの時間。単位：秒。
   upstream_status	ロードバランサーがバックエンドサーバーから受信するレスポンスのステータスコード。
   vip_addr	仮想 IP アドレス (VIP)。
   write_response_time	ロードバランサーがレスポンスを書き込むのにかかる時間。単位：ミリ秒。

注意事項

client_ip と http_x_forwarded_for

SLS アクセスログでリクエストソースを分析する際、これら 2 つのフィールドは異なる意味を持ちます。

• client_ip：ネットワークレイヤーで CLB が観測した、CLB への接続を確立したソース IP アドレスです。クライアントの前にプロキシがない場合、これは実際のクライアント IP アドレスです。クライアントがプロキシの背後にある場合、これは最も近いプロキシの出口 IP アドレスです。

• http_x_forwarded_for：CLB が受信したインバウンドリクエスト内の X-Forwarded-For ヘッダーの元の値です。これはクライアントまたは上流のプロキシによって書き込まれるもので、偽装される可能性があり、参考情報としてのみ使用されます。

アクセスログでリクエストソースを分析するには、client_ip を使用します。

リクエストを処理した転送ルールの特定

アクセスログには、サーバーグループ ID やトラフィック転送ルールの名前は記録されません。特定のリクエストをどの転送ルールが処理したかを判断するには、ログ内の request_uri と http_host の値を、CLB コンソールで設定された転送ルールと関連付ける必要があります。これにより、転送ルールが期待どおりに機能しているかをさらに確認できます。

• アクティブでない転送ルールの特定： slbid、request_uri、および時間範囲を組み合わせて、特定の時間範囲内で転送ルールが一致した回数をクエリします。結果が 0 の場合、その期間中にルールはどのリクエストにも一致しませんでした。ビジネスニーズに基づいて、クリーンアップするかどうかを評価してください。

  slbid: <instance-ID> and request_uri: <forwarding-rule-path> | select count(*) as hit_count

• 転送が期待どおりであることを確認： ログ内の upstream_addr の値 (リクエストが実際に転送されたバックエンドサーバーの IP アドレスとポート) を、CLB コンソール内の対応するリスナーのサーバーグループメンバーと比較し、リクエストが意図したバックエンドサーバーに転送されていることを確認できます。

TLS ポリシーによる傍受

TLS セキュリティポリシーによってブロックされた接続は、TLS ハンドシェイクを完了しないため、アクセスログエントリは生成されません。アクセスログには、CLB との接続が正常に確立されたリクエストのみが記録されます。

アクセスログのクエリ

アクセスログ機能を設定した後、SLS コンソールでログをクエリできます。

1. CLBコンソールにログインします。

2. ナビゲーションペインで、操作ログ > アクセスログ を選択します。

3. 上部メニューで、CLB インスタンスがデプロイされているリージョンを選択します。

4. アクセスログ (レイヤー 7) ページで、対象のインスタンスを見つけ、操作 列の ログの表示 をクリックします。SLS コンソールにリダイレクトされます。

5. SLS が設定されると、CLB インスタンスにアクセスした任意のクライアントのログエントリを表示できます。

6. SQL 文を入力して、特定のアクセスログをクエリします。

   たとえば、次の SQL 文を実行して上位 20 のクライアントを検索します。結果は、トラフィックソースを分析し、ビジネス上の意思決定に役立ちます。

   * | select http_user_agent, count(*) as pv group by http_user_agent order by pv desc limit 20

   たとえば、次の SQL 文を実行して、ソース IP アドレスとレスポンスステータスコードでログをフィルタリングすることにより、特定の IP アドレス範囲からのアクセスリクエストをクエリします。

   * | select * where client_ip like '172.17.%' and status=200

   複数の CLB インスタンスが Logstore を共有する場合のログのフィルタリング

   複数の CLB インスタンスが同じ SLS Logstore を共有している場合、ドメインまたはポートのみでフィルタリングするクエリは、不完全または誤解を招く結果を返す可能性があります。特定の CLB インスタンスとリスナーにログを絞り込むには、クエリで slbid (インスタンス ID) と slb_vport (リスナーポート) フィールドを組み合わせてください。

   たとえば、特定のインスタンスとリスナーポートの 5xx エラーをクエリするには、次の SQL 文を実行します。

   slbid: <instance-ID> and slb_vport: <port> and status: 5*

   クエリが結果を返さない場合は、以下を確認してください。

   • slbid の値は、(インスタンス名ではなく) CLB コンソールに表示されるインスタンス ID と完全に一致する必要があります。

   • slb_vport の値は、リスナーのポート番号 (たとえば、80 や 443) と一致する必要があります。

   • ログエントリはわずかな遅延で書き込まれることがあるため、クエリの時間範囲を広げてください。

   説明

   ログの更新動作と同一タイムスタンプのエントリについて、次の点に注意してください。

   • ログの更新動作： SLS のフィールドインデックス統計は、ログエントリが書き込まれるとリアルタイムで更新されます。固定の更新間隔はありません。コンソールでクエリの時間範囲を切り替えた場合は、クエリボタンをクリックして結果を再読み込みしてください。

   • 同じタイムスタンプを持つ複数のエントリ： 同じ time 値を共有する複数のログエントリが表示される場合、これは期待される動作であり、クライアントが同じ秒内に複数のリクエストを送信したことを示します。これは高頻度クライアントの正常なパターンであり、システムエラーを示すものではありません。繰り返されるリクエストが異常であると判断した場合は、アクセス制御ポリシーを設定してソース IP アドレスを制限してください。

アクセスログの分析

SLS のダッシュボードを使用してアクセスログを分析できます。ダッシュボードは、豊富なデータの視覚化とインサイトを提供します。

1. SLS ページで、ナビゲーションペインの アイコンをクリックし、[ダッシュボード] をクリックします。

2. CLB インスタンスのアクセスログに対応するダッシュボードの名前 (たとえば slb_layer7_access_center_en など) をクリックして、分析レポートを表示します。

slbid: <instance-ID> and slb_vport: <port> | select count(*) as total_requests

* | select http_host, sum(request_length) as total_bytes, round(sum(request_length) * 100.0 / sum(sum(request_length)) over(), 2) as traffic_pct group by http_host order by total_bytes desc

* | select upstream_addr, count(*) as request_count, sum(request_length) as total_bytes group by upstream_addr order by request_count desc limit 20

異常なリクエストの特定

CLB アクセスログには、ロードバランサーインスタンスを通過するすべての外部リクエストが記録されます。ログに未知のソースからのリクエストが見つかった場合、以下の主要なフィールドを使用して、それらが異常な外部リクエストであるかどうかを判断し、適切な保護措置を講じることができます。

* | select client_ip, request_method, request_uri, count(*) as cnt group by client_ip, request_method, request_uri order by cnt desc limit 50

アクセスログの無効化

アクセスログ機能を無効にして、CLB アクセスログの収集を停止できます。

1. CLBコンソールにログインします。

2. ナビゲーションペインで、操作ログ > アクセスログ を選択します。

3. 上部メニューで、CLB インスタンスがデプロイされているリージョンを選択します。

4. アクセスログ (レイヤー 7) ページで、対象のインスタンスを見つけ、操作 列の ログの無効化 をクリックします。

5. 表示されたダイアログボックスで OK をクリックして、インスタンスのアクセスログを無効にします。

関連ドキュメント

• SLS の詳細については、「Simple Log Service とは」をご参照ください。

• レイヤー 7 負荷分散を使用しているときにバックエンドサーバーが異常であると疑われる場合は、「CLB アクセスログを使用した異常なバックエンドサーバーの迅速な特定」をご参照ください。

よくある質問