リアルタイムログ - Amazon CloudFront

リアルタイムログ

CloudFront リアルタイムログを使用すると、ディストリビューションに対するリクエストの情報をリアルタイムで取得できます (ログはリクエストを受信してから数秒以内に配信されます)。リアルタイムログを使用して、コンテンツ配信のパフォーマンスに基づいて監視、分析、アクションを実行できます。

CloudFront リアルタイムログは設定可能です。以下を選択することができます。

  • リアルタイムログのサンプリング率 (リアルタイムのログ記録を受信するリクエストの割合) を選択できます。

  • ログレコードで受信する特定のフィールド。

  • リアルタイムログを受信する特定のキャッシュ動作 (パスパターン)。

CloudFront リアルタイムログは、Amazon Kinesis Data Streams で選択したデータストリームに配信されます。独自の Kinesis データストリームコンシューマーを構築することも、Amazon Kinesis Data Firehose を使用して、ログデータを Amazon Simple Storage Service (Amazon S3)、Amazon Redshift、Amazon Elasticsearch Service (Amazon ES)、またはサードパーティーのログ処理サービスに送信することもできます。

Kinesis Data Streams の使用料金に加えて、CloudFront でのリアルタイムログの料金が発生します。料金の詳細については、「Amazon CloudFront の料金」および「Amazon Kinesis Data Streams の料金」を参照してください。

リアルタイムログ設定について

CloudFront リアルタイムログを使用するには、まずリアルタイムログ設定を作成します。リアルタイムログ設定には、受信するログフィールド、ログレコードの サンプリングレート、およびログを配信する Kinesis データストリームに関する情報が含まれます。

具体的には、リアルタイムログ設定には、次の設定が含まれます。

名前

リアルタイムログ設定を識別する名前。

サンプリングレート

サンプリングレートは、リアルタイムログレコードとして Kinesis Data Streams に送信されるビューワーリクエストの割合を決定する 1 ~ 100 の整数です。すべてのビューワーリクエストをリアルタイムログに含めるには、サンプリングレートに 100 を指定します。リクエストデータの代表的なサンプルをリアルタイムログに受信しながら、コストを削減するために、より低いサンプリングレートを選択することもできます。

フィールド

各リアルタイムログレコードに含まれるフィールドのリスト。各ログレコードには、最大 40 個のフィールドを含めることができます。使用可能なすべてのフィールドを受信するか、パフォーマンスのモニタリングと分析に必要なフィールドのみを受信するかを選択できます。

次のリストは、各フィールド名と、そのフィールドに保持される情報の説明を示しています。フィールドは、Kinesis Data Streams に配信されるログレコードに表示される順序で示されています。

  1. timestamp

    エッジサーバーがリクエストへの応答を終了した日時。

  2. c-ip

    リクエスト元のビューワーの IP アドレス (192.0.2.183 または 2001:0db8:85a3:0000:0000:8a2e:0370:7334 など)。ビューワーが HTTP プロキシまたはロードバランサーを使用してリクエストを送った場合、このフィールドの値はプロキシまたはロードバランサーの IP アドレスです。x-forwarded-for フィールドも参照してください。

  3. time-to-first-byte

    サーバー上で測定される、要求を受信してから応答の最初のバイトを書き込むまでの秒数。

  4. sc-status

    次のいずれかの値が含まれます。

    • サーバーのレスポンスの HTTP ステータスコード (例: 200)。

    • 000。この値は、サーバーがリクエストに応答する前に、ビューワーが接続を閉じたことを示します。サーバーがレスポンスの送信を開始した後にビューワーが接続を閉じた場合、このフィールドには、サーバーが送信を開始したレスポンスの HTTP ステータスコードが含まれます。

  5. sc-bytes

    サーバーがリクエストに応じてビューワーに送信したデータ (ヘッダーを含む) のバイトの合計数。WebSocket 接続の場合、これは接続を経由してサーバーからクライアントに送信した合計バイト数です。

  6. cs-method

    ビューワーから受信した HTTP リクエストメソッド。

  7. cs-protocol

    ビューワーリクエストのプロトコル (httphttpswswss のいずれか)。

  8. cs-host

    ビューワーが、このリクエストの Host ヘッダーに追加した値。オブジェクトの URL に CloudFront ドメイン名が使用されている場合 (d111111abcdef8.cloudfront.net など)、このフィールドにはそのドメイン名が含まれます。CNAMEs のような代替ドメイン名をオブジェクト URL (www.example.com) にお使いの場合は、このフィールドにはこの代替ドメイン名が含まれます。

  9. cs-uri-stem

    パスとオブジェクトを識別するリクエスト URL の部分 (/images/cat.jpg など)。URL 内の疑問符 (?) およびクエリ文字列はログに含まれません。

  10. cs-bytes

    ビューワーがリクエストに含めたデータ (ヘッダーを含む) のバイトの合計数。WebSocket 接続の場合、これは接続でクライアントからサーバーに送信した合計バイト数です。

  11. x-edge-location

    リクエストを処理したエッジロケーション。各エッジロケーションは、3 文字コードと、割り当てられた任意の数字で識別されます (例: DFW3)。通常、この 3 文字コードは、エッジロケーションのっ地理的場所の近くにある空港の、国際航空運送協会 (IATA) の空港コードに対応します。(これらの略語は今後変更される可能性があります。)

  12. x-edge-request-id

    リクエストを一意に識別する不透明な文字列。CloudFront では、この文字列を x-amz-cf-id レスポンスヘッダーでも送信します。

  13. x-host-header

    CloudFront ディストリビューションのドメイン名 (d111111abcdef8.cloudfront.net など)。

  14. time-taken

    サーバーが、ビューワーのリクエストを受信してからレスポンスの最後のバイトを出力キューに書き込むまでの秒数。サーバーで 1000 分の 1 秒単位まで測定されます (例: 0.082)。ビューワーから見た場合、レスポンス全体を取得する合計所要時間は、ネットワークのレイテンシーと TCP バッファリングにより、この値よりも長くなります。

  15. cs-protocol-version

    ビューワーがリクエストで指定した HTTP バージョン。指定できる値には、HTTP/0.9HTTP/1.0HTTP/1.1、および HTTP/2.0 などがあります。

  16. c-ip-version

    リクエストの IP バージョン (IPv4 または IPv6)。

  17. cs-user-agent

    リクエスト内の User-Agent ヘッダーの値。User-Agent ヘッダーでリクエスト元 (リクエスト元のデバイスとブラウザのタイプなど) が識別されます。リクエスト元が検索エンジンの場合は、どの検索エンジンかも識別されます。

  18. cs-referer

    リクエスト内の Referer ヘッダーの値。これはリクエスト元のドメインの名前です。一般的なリファラーとして、検索エンジン、オブジェクトに直接リンクされた他のウェブサイト、ユーザー自身のウェブサイトなどがあります。

  19. cs-cookie

    名前と値のペアおよび関連属性を含む、リクエスト内の Cookie ヘッダー。

    注記

    このフィールドは 800 バイトに切り捨てられます。

  20. cs-uri-query

    リクエスト URL のクエリ文字列の部分 (ある場合)。

  21. x-edge-response-result-type

    ビューワーにレスポンスを返す直前にサーバーがレスポンスを分類した方法。x-edge-result-type フィールドも参照してください。以下に示しているのは、可能な値です。

    • Hit – サーバーがキャッシュからビューワーにオブジェクトを渡しました。

    • RefreshHit – サーバーはキャッシュ内でオブジェクトを検出しましたが、オブジェクトの有効期限が切れていたため、サーバーはオリジンに問い合わせて、キャッシュ内に最新バージョンのオブジェクトがあるかどうかを確認しました。

    • Miss – キャッシュ内のオブジェクトでリクエストに対応できなかったため、サーバーはリクエストをオリジンサーバーに転送して結果をビューワーに返しました。

    • LimitExceeded – CloudFront クォータ (以前は制限と呼ばれていました) を超えたため、リクエストは拒否されました。

    • CapacityExceeded – リクエストの受信時にサーバーの容量不足でオブジェクトを渡すことができなかったために、サーバーから 503 エラーが返されました。

    • Error – 通常、これはリクエストがクライアントエラーとなった (sc-status フィールドが 4xx 範囲内の値となる)、またはサーバーエラーになった (sc-status フィールドが 5xx 範囲内の値となる) ことを意味します。

       

      x-edge-result-type フィールドの値が Error であり、このフィールドの値が Error でない場合、ダウンロードが完了する前にクライアントが切断されました。

    • Redirect – サーバーは、ディストリビューション設定に従って HTTP から HTTPS にビューワーをリダイレクトしました。

  22. x-forwarded-for

    ビューワーが HTTP プロキシまたはロードバランサーを使用してリクエストを送信した場合、c-ip フィールドの値はプロキシまたはロードバランサーの IP アドレスです。この場合、このフィールドはリクエスト元のビューワーの IP アドレスです。このフィールドには、IPv4 アドレス (192.0.2.183 など) または IPv6 アドレス (2001:0db8:85a3:0000:0000:8a2e:0370:7334 など) が含まれます。

  23. ssl-protocol

    リクエストが HTTPS を使用した場合、このフィールドには、リクエストとレスポンスを送信するためにビューワーとサーバーがネゴシエートした SSL/TLS プロトコルが含まれます。指定可能な値のリストについては、ビューワーと CloudFront との間でサポートされているプロトコルと暗号 でサポートされている SSL/TLS プロトコルを参照してください。

  24. ssl-cipher

    リクエストが HTTPS を使用した場合、このフィールドには、リクエストとレスポンスを暗号化するためにビューワーとサーバーがネゴシエートした SSL/TLS 暗号が含まれます。使用できる値のリストについては、「ビューワーと CloudFront との間でサポートされているプロトコルと暗号」で、サポートされている SSL/TLS 暗号化を参照してください。

  25. x-edge-result-type

    サーバーが、最後のバイトを渡した後で、レスポンスを分類した方法。場合によっては、サーバーがレスポンスを送る準備ができたときから、サーバーがレスポンスを送り終わるまでの間に、結果タイプが変わることがあります。x-edge-response-result-type フィールドも参照してください。

     

    例えば、HTTP ストリーミングで、サーバーがキャッシュ内でストリームのセグメントを検出するとします。そのシナリオでは、このフィールドの値は、通常 Hit になります。この場合、サーバーがセグメント全体を配信する前にビューワーが接続を閉じると、最終結果タイプ (およびこのフィールドの値) は Error になります。

     

    WebSocket 接続の場合、コンテンツがキャッシュ可能ではなく、オリジンに直接プロキシされるため、このフィールドの値は Miss になります。

     

    以下に示しているのは、可能な値です。

    • Hit – サーバーがキャッシュからビューワーにオブジェクトを渡しました。

    • RefreshHit – サーバーはキャッシュ内でオブジェクトを検出しましたが、オブジェクトの有効期限が切れていたため、サーバーはオリジンに問い合わせて、キャッシュ内に最新バージョンのオブジェクトがあるかどうかを確認しました。

    • OriginShieldHit – オブジェクトは、Origin Shield キャッシュからビューワーに渡されました。

    • Miss – キャッシュ内のオブジェクトでリクエストに対応できなかったため、サーバーはリクエストをオリジンに転送して結果をビューワーに返しました。

    • LimitExceeded – CloudFront クォータ (以前は制限と呼ばれていました) を超えたため、リクエストは拒否されました。

    • CapacityExceeded – リクエストの受信時にサーバーの容量不足でオブジェクトを渡すことができなかったために、サーバーから HTTP 503 ステータスコードが返されました。

    • Error – 通常、これはリクエストがクライアントエラーとなった (sc-status フィールドが 4xx 範囲内の値となる)、またはサーバーエラーになった (sc-status フィールドが 5xx 範囲内の値となる) ことを意味します。sc-status フィールドの値が 200 であるか、このフィールドの値が Error で、x-edge-response-result-type フィールドの値が Error でない場合は、HTTP リクエストは成功したが、クライアントがすべてのバイトを受信する前に切断されたことを意味します。

    • Redirect – サーバーは、ディストリビューション設定に従って HTTP から HTTPS にビューワーをリダイレクトしました。

  26. fle-encrypted-fields

    サーバーが暗号化してオリジンに転送したフィールドレベル暗号化フィールドの数。CloudFront サーバーは処理されたリクエストをオリジンにストリーミングするときにデータを暗号化するため、fle-status の値がエラーであっても、このフィールドに値が渡されている場合があります。

  27. fle-status

    フィールドレベル暗号化がディストリビューション用に設定されている場合、このフィールドにはリクエストボディが正常に処理されたかどうかを示すコードが含まれます。サーバーがリクエストボディを正常に処理し、指定したフィールドの値を暗号化してリクエストをオリジンに転送すると、このフィールドの値は Processed になります。x-edge-result-type の値は、この場合でもクライアント側またはサーバー側のエラーを示すことができます。

     

    このフィールドで使用できる値は次のとおりです。

    • ForwardedByContentType – コンテンツタイプが設定されていないため、サーバーは解析や暗号化を行わずにリクエストをオリジンに転送しました。

    • ForwardedByQueryArgs – フィールドレベル暗号化の設定にないクエリ引数がリクエストに含まれているため、サーバーは解析や暗号化を行わずにリクエストをオリジンに転送しました。

    • ForwardedDueToNoProfile – フィールドレベル暗号化の設定でプロファイルを指定しなかったため、サーバーは解析や暗号化を行わずにリクエストをオリジンに転送しました。

    • MalformedContentTypeClientError Content-Type – ヘッダーの値が無効な形式であるため、サーバーはリクエストを拒否し、HTTP 400 ステータスコードをビューワーに返しました。

    • MalformedInputClientError – リクエストボディが無効な形式であるため、サーバーはリクエストを拒否し、HTTP 400 ステータスコードをビューワーに返しました。

    • MalformedQueryArgsClientError – クエリ引数が空であるか無効な形式であるため、サーバーはリクエストを拒否し、HTTP 400 ステータスコードをビューワーに返しました。

    • RejectedByContentType – フィールドレベル暗号化の設定でコンテンツタイプを指定しなかったため、サーバーはリクエストを拒否し、HTTP 400 ステータスコードをビューワーに返しました。

    • RejectedByQueryArgs – フィールドレベル暗号化の設定でクエリ引数を指定しなかったため、サーバーはリクエストを拒否し、HTTP 400 ステータスコードをビューワーに返しました。

    • ServerError – オリジンサーバーがエラーを返しました。

    リクエストがフィールドレベル暗号化のクォータ (以前は制限と呼ばれていました) を超えた場合、このフィールドには次のいずれかのエラーコードが含まれ、サーバーは HTTP ステータスコード 400 をビューワーに返します。フィールドレベル暗号化に関する最新のクォータのリストについては、「フィールドレベル暗号化のクォータ」を参照してください。

    • FieldLengthLimitClientError – 暗号化されるように設定されているフィールドが最大の長さを超えています。

    • FieldNumberLimitClientError – ディストリビューションによって暗号化されるように設定されているリクエストがフィールド数の制限を超えています。

    • RequestLengthLimitClientError – フィールドレベル暗号化が設定されている場合にリクエストボディが最大の長さを超えています。

  28. sc-content-type

    レスポンスの HTTP Content-Type ヘッダーの値。

  29. sc-content-len

    レスポンスの HTTP Content-Length ヘッダーの値。

  30. sc-range-start

    レスポンスに HTTP Content-Range ヘッダーが含まれている場合、このフィールドには範囲の開始値が含まれます。

  31. sc-range-end

    レスポンスに HTTP Content-Range ヘッダーが含まれている場合、このフィールドには範囲の終了値が含まれます。

  32. c-port

    閲覧者からのリクエストのポート番号。

  33. x-edge-detailed-result-type

    x-edge-result-type フィールドが Error でない場合、このフィールドには x-edge-result-type と同じ値が含まれます。x-edge-result-type フィールドが Error の場合、このフィールドには特定のタイプのエラーが含まれます。以下に示しているのは、可能な値です。

    • AbortedOrigin – サーバーでオリジンに関する問題が発生しました。

    • ClientCommError – サーバーとビューワーとの通信の問題により、ビューワーへのレスポンスが中断されました。

    • ClientGeoBlocked – ディストリビューションは、ビューワーの地理的位置からのリクエストを拒否するように構成されています。

    • ClientHungUpRequest – リクエストの送信中にビューワーが途中で停止しました。

    • Error – エラータイプが他のどのカテゴリにも適合しないエラーが発生しました。このエラータイプは、キャッシュからのエラーレスポンスをサーバーが渡すときに発生する可能性があります。

    • InvalidRequest – サーバーがビューワーから無効なリクエストを受信しました。

    • InvalidRequestBlocked – 要求されたリソースへのアクセスがブロックされます。

    • InvalidRequestCertificate – ディストリビューションが、HTTPS 接続が確立された SSL/TLS 証明書と一致しません。

    • InvalidRequestHeader – リクエストに無効なヘッダーが含まれていました。

    • InvalidRequestMethod – ディストリビューションは、使用された HTTP リクエストメソッドを処理するように設定されていません。これは、ディストリビューションがキャッシュ可能なリクエストのみをサポートしている場合に発生します。

    • OriginConnectError – サーバーがオリジンに接続できませんでした。

    • OriginContentRangeLengthError – オリジンのレスポンスの Content-Length ヘッダーが、Content-Range ヘッダーの長さと一致しません。

    • OriginDnsError – サーバーがオリジンのドメイン名を解決できませんでした。

    • OriginError – オリジンが誤ったレスポンスを返しました。

    • OriginHeaderTooBigError – オリジンから返されたヘッダーが大きすぎてエッジサーバーで処理できません。

    • OriginInvalidResponseError – オリジンが無効なレスポンスを返しました。

    • OriginReadError – サーバーがオリジンから読み取れませんでした。

    • OriginWriteError – サーバーがオリジンに書き込めませんでした。

    • OriginZeroSizeObjectError – オリジンから送信されたサイズゼロのオブジェクトがエラーになりました。

    • SlowReaderOriginError – オリジンエラーの原因となったメッセージの読み取りに時間がかかりました。

  34. c-country

    ビューワーの IP アドレスによって決定される、ビューワーの地理的位置を表す国コード。

  35. cs-accept-encoding

    ビューワーリクエスト内の Accept-Encoding ヘッダーの値。

  36. cs-accept

    ビューワーリクエスト内の Accept ヘッダーの値。

  37. cache-behavior-path-pattern

    ビューワーリクエストに一致したキャッシュ動作を識別するパスパターン。

  38. cs-headers

    ビューワーリクエスト内の HTTP ヘッダー (名前と値)。

    注記

    このフィールドは 800 バイトに切り捨てられます。

  39. cs-header-names

    ビューワーリクエスト内の HTTP ヘッダーの名前 (値ではない)。

    注記

    このフィールドは 800 バイトに切り捨てられます。

  40. cs-headers-count

    ビューワーリクエスト内の HTTP ヘッダーの数。

エンドポイント (Kinesis データストリーム)

エンドポイントには、リアルタイムログを送信する Kinesis データストリームに関する情報が含まれています。データストリームの Amazon リソースネーム (ARN) を指定します。

Kinesis データストリームの作成の詳細については、Amazon Kinesis Data Streams 開発者ガイドの以下のトピックを参照してください。

データストリームを作成するときは、シャードの数を指定する必要があります。次の情報を使用して、必要なシャードの数を見積もることができます。

Kinesis データストリームのシャード数を推定するには

  1. ご使用の CloudFront ディストリビューションが受信する 1 秒あたりのリクエスト数を計算 (または概算) します。

    1 秒あたりのリクエストを計算するには、CloudFront の使用状況レポート (CloudFront コンソール内) と CloudFront メトリクス (CloudFront コンソールおよび Amazon CloudWatch コンソール内) を使用します。

  2. 1 つのリアルタイムログレコードの一般的なサイズを決定します。

    一般に、1 つのログレコードは約 500 バイトです。使用可能なすべてのフィールドを含む大きなレコードは、通常、約 1 KB です。

    ログレコードのサイズが不明な場合は、サンプルレートを低く (たとえば 1% に) 設定して、リアルタイムログを有効化し、Kinesis Data Streams でのデータのモニタリングを使用して平均的なレコードサイズを割り出します (レコード数の合計を受信バイト数の合計で割ります)。

  3. Amazon Kinesis Data Streams の料金のページの [Pricing calculator] (料金見積りツール) で、1 秒あたりのリクエスト (レコード) の数と 1 つのログレコードの平均レコードサイズを入力します。その後、[Show calculations] (計算を表示) を選択します。

    料金見積りツールには、必要なシャードの数が表示されます。(見積もりコストも表示されます。)

    次の例は、平均レコードサイズが 0.5 KB、1 秒あたり 50,000 リクエストの場合、50 個のシャードが必要であることを示しています。

    
                                    1 秒あたり 50,000 リクエスト、平均レコードサイズが 0.5 KB の場合、50 個のシャードが必要であることを示している Amazon Kinesis Data Streams 料金見積りツールの例。
IAM ロール

Kinesis データストリームにリアルタイムログを配信する CloudFront アクセス許可を付与するための AWS Identity and Access Management (IAM) ロール。

CloudFront コンソールでリアルタイムログ設定を作成する場合、[新規サービスロールの作成] を選択して、コンソールで IAM ロールを作成させることができます。

AWS CloudFormation または CloudFront API (AWS CLI または SDK) を使用してリアルタイムログ設定を作成する場合は、IAM ロールを自分で作成し、ロールの ARN を指定する必要があります。IAM を自分で作成するには、次のポリシーを使用します。

IAM ロール信頼ポリシー

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "cloudfront.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }

暗号化されていないデータストリーム用の IAM ロールアクセス許可ポリシー

次のポリシーを使用するには、Kinesis データストリーム ARN を Kinesis データストリームの ARN に置き換えます。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kinesis:DescribeStreamSummary", "kinesis:DescribeStream", "kinesis:PutRecord", "kinesis:PutRecords" ], "Resource": [ "Kinesis data stream ARN" ] } ] }

暗号化されたデータストリーム用の IAM ロールアクセス許可ポリシー

次のポリシーを使用するには、Kinesis データストリーム ARN を Kinesis データストリームの ARN に置き換え、AWS KMS キーを AWS Key Management Service (AWS KMS) のカスタマーマスターキーの ARN に置き換えます。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kinesis:DescribeStreamSummary", "kinesis:DescribeStream", "kinesis:PutRecord", "kinesis:PutRecords" ], "Resource": [ "Kinesis data stream ARN" ] }, { "Effect": "Allow", "Action": [ "kms:GenerateDataKey" ], "Resource": [ "AWS KMS key" ] } ] }

リアルタイムログ設定の作成と使用

リアルタイムログ設定を使用してディストリビューションに対して行われたリクエストに関する情報をリアルタイムで取得できます (ログはリクエストを受信してから数秒以内に配信されます)。リアルタイムログ設定は、CloudFront コンソール、AWS コマンドラインインターフェイス (AWS CLI)、または CloudFront API を使用して作成できます。

リアルタイムログ設定を使用するには、CloudFront ディストリビューションの 1 つ以上のキャッシュ動作にアタッチします。

リアルタイムログ設定を作成するには (コンソール)

  1. AWS マネジメントコンソールにサインインし、CloudFront コンソールで [ログ] ページ (https://console.aws.amazon.com/cloudfront/v2/home?#/logs) を開きます。

  2. [リアルタイムログ構成] を選択します。

  3. [Create configuration (設定の作成)] を選択します。

  4. リアルタイムログ設定に必要な設定を選択します。次の点に注意してください。

    • デフォルトでは、すべての [フィールド] が選択されます。フィールドを削除するには、次のいずれかの操作を行います。

      • [フィールドを選択する] ドロップダウンメニューを使用して、リアルタイムログ設定に含めないフィールドから選択を削除します。

      • 展開ボタン ( ) を使用してすべてのフィールドを表示し、削除ボタン ( ) を使用してリアルタイムログ設定に含めないフィールドを削除します。

    • [IAM ロール] については、[新規サービスロールの作成] を選択すると、コンソールで自動的に IAM ロールを作成できます。ただし、IAM ロールを作成するアクセス許可が必要です。

    • [ディストリビューション] セクションの設定を使用すると、リアルタイムログ設定にアタッチする CloudFront ディストリビューションとキャッシュの動作を選択できます。

    詳細については、「リアルタイムログ設定について」を参照してください。

  5. 完了したら、[設定を作成] を選択します。

正常に終了すると、作成したリアルタイムログ設定の詳細がコンソールに表示されます。

AWS コマンドラインインターフェイス (AWS CLI) を使用してリアルタイムログ設定を作成するには、aws cloudfront create-realtime-log-config コマンドを使用します。各パラメータをコマンドライン入力として指定するのではなく、入力ファイルを使用してコマンドの入力パラメータを指定できます。

リアルタイムログ設定を作成するには (入力ファイルを含む CLI)

  1. 次のコマンドを使用して、create-realtime-log-config コマンドのすべての入力パラメータを含む rtl-config.yaml という名前のファイルを作成します。

    aws cloudfront create-realtime-log-config --generate-cli-skeleton yaml-input > rtl-config.yaml
    注記

    yaml-input オプションは、AWS CLI のバージョン 2 でのみ使用できます。AWS CLI のバージョン 1 では、JSON 形式の入力ファイルを生成できます。詳細については、AWS コマンドラインインターフェイスユーザーガイドの「JSON または YAML 入力ファイルからの AWS CLI スケルトンと入力パラメータの生成」を参照してください。

  2. 先ほど作成した rtl-config.yaml という名前のファイルを開きます。ファイルを編集して、必要なリアルタイムログ設定を指定し、ファイルを保存します。次の点に注意してください。

    • StreamType では、唯一の有効な値は、Kinesis です。

    リアルタイムロング設定の詳細については、「リアルタイムログ設定について」を参照してください。

  3. 次のコマンドを使用して、rtl-config.yaml ファイルの入力パラメータを使用してリアルタイムログ設定を作成します。

    aws cloudfront create-realtime-log-config --cli-input-yaml file://rtl-config.yaml

成功した場合、このコマンドの出力には、作成したリアルタイムログ設定の詳細が表示されます。

リアルタイムログ設定を既存のディストリビューション (入力ファイル付き CLI) にアタッチするには

  1. 以下のコマンドを使用して、更新する CloudFront ディストリビューションのディストリビューション設定を保存します。distribution_ID をディストリビューションの ID に置き換えます。

    aws cloudfront get-distribution-config --id distribution_ID --output yaml > dist-config.yaml
    注記

    --output yaml オプションは、AWS CLI のバージョン 2 でのみ使用できます。AWS CLI のバージョン 1 では、JSON 形式で出力を生成できます。詳細については、『AWS コマンドラインインターフェイスユーザーガイド』の「AWS CLI からのコマンド出力の制御」を参照してください。

  2. 先ほど作成した dist-config.yaml という名前のファイルを開きます。ファイルを編集し、リアルタイムログ設定を使用するように更新する各キャッシュ動作に次の変更を加えます。

    • キャッシュ動作で、RealtimeLogConfigArn という名前のフィールドを追加します。フィールドの値には、このキャッシュ動作にアタッチするリアルタイムログ設定の ARN を使用します。

    • ETag フィールドの名前を IfMatch に変更しますが、フィールドの値は変更しないでください。

    完了したら、ファイルを保存します。

  3. リアルタイムログ設定を使用するようにディストリビューションを更新するには、次のコマンドを使用します。distribution_ID をディストリビューションの ID に置き換えます。

    aws cloudfront update-distribution --id distribution_ID --cli-input-yaml file://dist-config.yaml

成功した場合、コマンドの出力には、更新したディストリビューションの詳細が表示されます。

CloudFront API を使用してリアルタイムログ設定を作成するには、CreateRealtimeLogConfig を使用します。この API コールで指定するパラメータの詳細については、リアルタイムログ設定について および AWS SDK やその他の API クライアントの API リファレンスドキュメントを参照してください。

リアルタイムログ設定を作成したら、次の API コールのいずれかを使用して、それをキャッシュ動作にアタッチできます。

  • 既存のディストリビューションのキャッシュ動作にアタッチするには、UpdateDistribution を使用します。

  • 新しいディストリビューションのキャッシュ動作にアタッチするには、CreateDistribution を使用します。

これらの API コールの両方について、キャッシュ動作内で、RealtimeLogConfigArn フィールドにリアルタイムログ設定の ARN を指定します。これらの API コールで指定するその他のフィールドの詳細については、「ディストリビューションを作成または更新する場合に指定する値」と、AWS SDK やその他の API クライアントの API リファレンスドキュメントを参照してください。

Kinesis Data Streams コンシューマーの作成

リアルタイムログを読み取って分析するには、Kinesis Data Streams コンシューマーを構築または使用します。CloudFront リアルタイムログ用のコンシューマーを構築する場合、すべてのリアルタイムログレコードのフィールドが フィールド セクションに示されている一覧と常に同じ順序で配信されることを知っておくことが重要です。この固定注文に対応するためにコンシューマーを構築することを確認してください。

たとえば、time-to-first-bytesc-status、および c-country の 3 つのフィールドのみを含むリアルタイムログ設定を考えてみます。このシナリオでは、最後のフィールド、c-country は、すべてのログレコードで常にフィールド番号 3 です。ただし、後でリアルタイムログ設定にフィールドを追加すると、レコード内の各フィールドの配置が変更される可能性があります。

たとえば、フィールド sc-bytestime-taken をリアルタイムログ設定に追加した場合、これらのフィールドは、 フィールド セクションに示されている順序に従って各ログレコードに挿入されます。5 つのフィールドすべての順序は time-to-first-bytesc-statussc-bytestime-taken、および c-country です。c-country フィールドはもともとフィールド番号 3 でしたが、現在はフィールド番号 5 です。リアルタイムログ設定にフィールドを追加する場合は、コンシューマーアプリケーションがログレコード内の位置を変更するフィールドを処理できることを確認してください。

リアルタイムログのトラブルシューティング

リアルタイムログ設定を作成した後、レコードが Kinesis Data Streams にまったく配信されない (または一部のレコードが配信されない) 場合があります。この場合、まず CloudFront ディストリビューションがビューワーリクエストを受信していることを確認する必要があります。その場合は、次の設定を確認してトラブルシューティングを続行できます。

IAM ロールのアクセス許可

CloudFront では、リアルタイムログレコードを Kinesis データストリームに配信するために、リアルタイムログ設定の IAM ロールが使用されます。ロールの信頼ポリシーとロールのアクセス許可ポリシーが、IAM ロール に示されているポリシーと一致していることを確認してください。

Kinesis Data Streams のスロットリング

CloudFront によってリアルタイムログレコードが Kinesis データストリームに書き込まれる速度が、ストリームで処理できる速度を上回る場合、Kinesis Data Streams は CloudFront からのリクエストを抑制することがあります。この場合、Kinesis データストリームのシャードの数を増やすことができます。各シャードは、1 秒あたり 1,000 レコードまでの書き込みをサポートし、1 秒あたり 1 MB の最大データ書き込みをサポートします。