eCDN Logpush

eCDN Logpush は、eCDN ログをバッチ単位で指定した宛先に配信します。eCDN ログには、クライアントの IP アドレス、リクエストされた URL、ユーザーエージェント文字列、ファイアウォールイベントの詳細 (ブロックされたリクエスト、ファイアウォールルールのトリガーなど) をはじめとする有用な情報が含まれます。

eCDN Logpush を使用して Logpush ジョブを作成する場合、http_requestsfirewall、および pageshield イベントで使用可能なフィールドのリストを表示できます。また、HTTP リクエストやファイアウォールイベントなど、配信するログタイプを指定できるほか、さまざまな宛先タイプを指定することもできます。

Amazon S3 宛先へのログプッシュを有効にするには、次の手順を実行します。

  • S3 バケットを作成します。詳細については、AWS S3 のドキュメントを参照してください。
  • Amazon S3 コンソールで、S3 > Bucket > Permissions > Bucket Policy に移動し、ポリシーを編集して貼り付け、「Resource」(リソース) の値を自分のバケットパスに置き換えます。AWS Principal は CDN プロバイダーが所有しているため、変更しないでください。

不完全なファイルを回避し、ストレージコストを最小限に抑えるため、eCDN Logpush を使用して S3 マルチパートアップロード用のルールを設定する際は、AbortIncompleteMultipartUpload アクションを使用してください。詳細については、マルチパートアップロードを使用したオブジェクトのアップロードとコピー_を参照してください。

eCDN Logpush は、CDN-API Logpush API を介して eCDN ログを Amazon S3 に直接プッシュすることをサポートしています。

ただし、ログを AWS S3 バケットに直接プッシュする eCDN Logpush ジョブを作成する前に、その S3 バケットの所有権を証明する必要があります。これを行うには、所有権トークンファイルをバケットの宛先に書き込みます。また、同じバケット内の宛先パスごとに、一意の所有権チャレンジトークンを作成する必要があります。

宛先パスで特別な文字列 {DATE} を使用して、ログを日別のサブディレクトリに分けることができます。たとえば、s3://customer-bucket/logs/{DATE}?region=us-east-1\&sse=AES256 のように指定します。ログが保存されると、ディレクトリの名前は YYYYMMDD 形式の日付に置き換えられます (例: 20230215)。

リクエストの例:

レスポンスの例:

{ "data": { "destinationPath": "s3://example-bucket/log?region=us-east-1", "fileName": "log/ownership-challenge-072fd6be.txt" } }

前のセクションで行われた呼び出しに基づいて `ownershipChallengeToken` を設定します。destinationPath は、所有権トークンの生成時に指定したものと同じである必要があります。詳細については、パラメーターオプションのパラメーター、および制限の各セクションを参照してください。

Logpush ジョブ API 呼び出しの例:

API 呼び出しレスポンスの例: 201 ステータスコード

GCS 宛先へのログプッシュを有効にするには、次の手順を実行します。

  • GCS バケットを作成します。
  • Cloudflare は、Google Cloud Identity and Access Management (IAM) を使用して Google Cloud Storage バケットにアクセスします。Cloudflare の IAM サービスアカウントには、そのバケットに対する管理者権限が必要です。logpush@cloudflare-data.iam.gserviceaccount.com を、Storage Object Admin (ストレージオブジェクト管理者) 権限を持つメンバーとして追加します。これにより、Cloudflare は所有権の確認とログを GCS バケットにプッシュできるようになります。

eCDN Logpush は、CDN Logpush APIを介して eCDN ログを Google Cloud Storage (GCS) に直接プッシュすることをサポートしています。

ただし、ログを GCS バケットにプッシュする eCDN Logpush ジョブを作成する前に、GCS バケットの所有権を証明する必要があります。これを行うには、所有権トークンファイルをバケットの宛先に書き込みます。また、同じバケット内の宛先パスごとに、一意の所有権チャレンジトークンを作成する必要があります。
宛先パスで特別な文字列 {DATE} を使用して、ログを日別のサブディレクトリに分けることができます。たとえば、gs://customer-bucket/logs/{DATE} のように指定します。ログが保存されると、ディレクトリの名前は YYYYMMDD 形式の日付に置き換えられます (例: 20230215)。

リクエストの例:`

レスポンスの例:

{ "data": { "destinationPath": "gs://cflogpushtest/http_requests/20251008", "fileName": "http_requests/20251008/ownership-challenge-072fd6be.txt" } }

前のセクションで実行した呼び出しに基づいて、ownershipChallengeToken を設定します。`destinationPath` は、所有権トークンの生成時に指定したものと同じである必要があります。詳細については、パラメーターオプションのパラメーター、および制限の各セクションを参照してください。

Logpush ジョブ API 呼び出しの例:

API 呼び出しレスポンスの例: 201 ステータスコード

Azure 宛先に対してログプッシュを有効にするには、次の手順を実行します。

  • Blob Storage コンテナを作成します。詳細については、Azure の手順 ↗ を参照してください。
  • Blob Storage コンテナへのアクセスを保護し、制限するために、Shared Access Signature (共有アクセス署名: SAS) ↗ を作成します。
  • Storage Explorer ↗ を使用してコンテナに移動し、コンテナを右クリックして署名を作成します。署名の有効期限を現在の日付から少なくとも 5 年後に設定し、書き込み権限のみを付与します。
  • destinationPath 属性の一部として SAS URL を指定します。
  • SAS トークンの有効期限が切れると Logpush はログのプッシュを停止するため、有効期限は少なくとも 5 年に設定する必要があります。

Azure 用宛先構成の例:

Cloudflare は、指定された Azure 宛先にテストデータをプッシュするテスト呼び出しを行います。成功した場合、Logpush ジョブが作成されます。失敗した場合は、Logpush ジョブの作成は失敗します。

次の例では、Azure の宛先パスを使用して Logpush ジョブを作成します。詳細については、パラメーターオプションのパラメーター、および制限の各セクションを参照してください。

API 呼び出しレスポンスの例: 201 ステータスコード

Datadog 宛先へのログプッシュを有効にするには、次の手順を実行します。

  • 宛先構成のホスト名として、http-intake.logs.datadoghq.com/v1/input または http-intake.logs.datadoghq.com/api/v2/logs のいずれかを指定します。
  • Datadog ドキュメントを使用して Datadog API キーを取得します。これは必須フィールドです。
  • サービス、ホスト名、Datadog の ddsource フィールド、および ddtags フィールドを URL パラメーターとして設定できます。これらのパラメーターは オプション ですが、ログのインデックス作成や処理に役立つ場合があります。詳細については、Datadog ドキュメント の Logs セクション ↗を参照してください。なお、これらのパラメーターの値には特殊文字を含めることができ、その場合は URL エンコードする必要があります。

Datadog 用宛先構成の例:

Cloudflare は、指定された Datadog 宛先構成にテストデータをプッシュするテスト呼び出しを行います。成功した場合、Logpush ジョブが作成されます。失敗した場合は、Logpush ジョブの作成は失敗します。

次の例では、Datadog の宛先パスを使用して Logpush ジョブを作成します。詳細については、パラメーターオプションのパラメーター、および制限の各セクションを参照してください。

API 呼び出しレスポンスの例: 201 ステータスコード

次の値を使用して Splunk 宛先を構成します。

  • <SPLUNK_ENDPOINT_URL>: ポートを含む Splunk の Raw HTTP Event Collector URL。例: splunk.cf-analytics.com:8088/services/collector/raw
    • Logpush ジョブの構成および設定時、Cloudflare は Splunk エンドポイントが /services/collector/raw であることを想定しています。
  • <SOURCE_TYPE>: Splunk のソースタイプ。例: cloudflare:json
  • <SPLUNK_AUTH_TOKEN>: URL エンコードされた Splunk 認証トークン。例: Splunk%20e6d94e8c-5792-4ad1-be3c-29bcaee0197d
    • Splunk で HEC が有効になっていることを確認します。詳細については、Splunk Analytics Integrations を参照してください。
    • 不正な URL を追加すると、API リクエストは 504 エラーで失敗します。通常、Splunk Cloud エンドポイント URL には、ホスト名の前に http-inputs- のような文字列が含まれます。
  • <SPLUNK_CHANNEL_ID>: 一意のチャネル ID。これはランダムな GUID で、次のいずれかの方法で生成できます。
    • GUID Generator ↗ などのオンラインツール。
    • コマンドライン。例: python \-c 'import uuid; print(uuid.uuid4())'
  • <INSECURE_SKIP_VERIFY>: ブール値。Cloudflare では、この値を false に設定することを推奨しています。true に設定すると、Splunk の例に示されている curl の -k オプションを使用するのと同等になるためです。これは、HEC が自己署名証明書を使用している場合を除き、推奨されません

Splunk 用宛先構成の例:

Cloudflare は、指定されたエンドポイントにテストデータをプッシュするテスト呼び出しを行います。成功した場合、Logpush ジョブが作成されます。失敗した場合は、Logpush ジョブの作成は失敗します。

次の例では、Splunk の宛先パスを使用して Logpush ジョブを作成します。詳細については、パラメーターオプションのパラメーター、および制限の各セクションを参照してください。

API 呼び出しレスポンスの例: 201 ステータスコード

HTTPS 宛先を構成します。

  • 宛先の検証時に行われるファイルアップロードで、圧縮された内容 {"content":"tests"} を含む gzip 形式の test.txt.gz ファイルを受け入れられることを確認します。そうでない場合は、たとえば error validating destination: error writing object: error uploading のようなエラーが返されます。
  • リクエストヘッダーを設定するには、“header_*” URL パラメーターを指定します。
    • HTTPS エンドポイントには、設定した “header_*” URL パラメーターと競合するカスタム URL パラメーターを含めることはできません。
    • これらのパラメーターは、適切に URL エンコードする必要があります。たとえば、空白には “%20” を使用します。そうしないと、一部の特殊文字が正しくデコードされない可能性があります。
  • destinationconf では、特殊な “header*” パラメーターに加えて、URL パラメーターを指定できます。
    • URL エンコードされていない特殊文字は、アップロード時にエンコードされます。

HTTPS エンドポイント用宛先構成の例:

Cloudflare は、指定されたエンドポイントにテストデータをプッシュするテスト呼び出しを行います。成功した場合、Logpush ジョブが作成されます。失敗した場合は、Logpush ジョブの作成は失敗します。

この例では、HTTPS 宛先エンドポイントを使用して Logpush ジョブを作成します。詳細については、パラメーターオプションのパラメーター、および制限の各セクションを参照してください。

API 呼び出しレスポンスの例: 201 ステータスコード

Kinesis 宛先を構成します。

  • 次の信頼関係を使用して、Cloudflare Logpush が引き受ける IAM ロールを作成します。
  • IAM ロールに、Kinesis ストリームに対して PutRecord アクションを実行する権限があることを確認します。
  • <AWS_REGION>、<YOUR_AWS_ACCOUNT_ID>、<STREAM_NAME> を実際の値に置き換えます。
  • (オプション) STS Assume Role を使用する場合は、Logpush ジョブのリクエストで sts-external-iddestination_conf パラメーターとして含めることができます。詳細については、Securely Using External ID for Accessing AWS Accounts Owned by Others ↗ (外部 ID を使用した他者所有の AWS アカウントへの安全なアクセス) を参照してください。

AWS Kinesis への Logpush 設定用宛先構成の例: kinesis://<STREAM_NAME>?region=<AWS_REGION>&sts-assume-role-arn=arn:aws:iam::<YOUR_AWS_ACCOUNT_ID>:role/<IAM_ROLE_NAME>

次の例では、Kinesis を使用して Logpush ジョブを作成します。詳細については、パラメーターオプションのパラメーター、および制限の各セクションを参照してください。

API 呼び出しレスポンスの例: 201 ステータスコード

  • Name: サイト名。ジョブの作成後に変更することはできません。
  • Destination Path: ログの受信先となる宛先パス。各宛先タイプの前提条件には、destinationPath 属性の取得方法が記載されています。
  • Ownership Challenge Token: この属性は、AWS S3 および Google Cloud Storage の宛先に必須です。HTTPS、Datadog、Azure、Splunk、Kinesis などのその他の宛先では不要です。
  • Log Type: S3 バケットで受信するログのタイプ。現在、使用可能なタイプは http_requestsfirewall_eventspage_shield_events です。
  • Log Fields: 使用可能なログフィールド。ログのタイプによって異なります。詳細については、eCDN Logpush ログフィールドを参照してください。
  • Filter: フィルターを使用すると、ログに含める特定のタイプのイベントを選択したり、分析に不要なイベントを削除したりできます。ログにフィルターを適用することで、最も重要なデータに注力して、不要なノイズを避けることができます。

詳細については、eCDN Logpush フィルターを参照してください。

ゾーンごとに作成できる Logpush ジョブは最大 2 つです。

eCDN Logpush ジョブは、作成時点では有効になっていません。ログの受信を開始するには、Logpush ジョブを有効にする必要があります。詳細は、CDN Zones API の概要を参照してください。

成功した場合は、200 が返されます。

この例は、eCDN Logpush ジョブから出力される JSON ログを示しています。

詳細は、CDN Zones API の概要を参照してください。

成功した場合は、200 が返されます。

詳細は、CDN Zones API の概要を参照してください。

成功した場合は、204 が返されます。

  • Logpush ジョブが誤って無効になってしまい、一定期間のログを取り逃しました。取り逃したログを取得する方法はありますか?
    • いいえ。eCDN Logpush は、ログが利用可能になり次第、それらを S3 バケットにプッシュするため、欠落したログを後から補完することはできません。
  • ログのプッシュ頻度を調整できますか?
    • eCDN Logpush は、可能な限り早いタイミングで、指定された宛先にログをバッチでプッシュします。
  • 所有権トークンを作成しましたが、S3 バケットにファイルが表示されません。
    • eCDN Logpush がバケットにファイルを書き込めるように、S3 バケットポリシーを確認してください。Amazon S3 への eCDN Logpush の有効化セクションに示されているとおりに Resource の値を置き換えてポリシーを編集し、そのポリシーを S3 > Bucket > Permissions > Bucket Policy に貼り付けてください。