基本を理解する

アクセスパターン

基本的なアクセスパターンは ゾーン Z のすべてのログを分 M でください です。ここで、分 M は Cloudflare のログ集約システムにログエントリがディスクに書き込まれた時間を指します。

まず、毎分クエリを実行してみてください。応答が小さすぎる場合は、ほとんどのゾーンに適しているため、5分に増やしてください。応答が大きすぎる場合は、15秒に減らしてみてください。

ゾーンにログが非常に多く、1分分のログを読むのに1分以上かかる場合は、2つのワーカーを交互に実行し、それぞれが2分ごとに1分分のログを要求します。

APIから返されるデータは、繰り返し呼び出しても変わりません。応答内のメッセージの順序は異なる場合がありますが、応答コードが 200 であり、応答ボディの読み取りにエラーがない限り、特定のクエリに対するメッセージの数と内容は常に同じです。

私たちのログ処理システムはデータをバッチで取り込むため、1分あたり100万件未満のリクエストを持つほとんどのゾーンには「空の」分があります。そのような分のクエリは、ステータス 200 の応答を返しますが、ボディにはデータがありません。これは、その分に対して Cloudflare によってプロキシされたリクエストがなかったことを意味するものではありません。単に、その分に対して私たちのシステムがそのゾーンのログのバッチを処理しなかったことを意味します。

返されるデータの順序

logs/received API エンドポイントは、Cloudflare Logs 集約システムにディスクに書き込まれたイベントの時間でデータを公開します。

ログ生成時間ではなくログ集約時間で順序付けることで、ログパイプラインのレイテンシが低下（高速化）し、決定論的なログ取得が実現します。機能的には、ログファイルを尾行することや rsyslog から読み取ることに似ています（ただし、チャンク単位で）。

これは、特定の時間範囲のログを取得するために、各連続する分（または他の時間範囲）ごとに1回の呼び出しを行うことができることを意味します。ログ行は受信時間でバッチ処理され、利用可能にされるため、遅れて到着するデータはありません。特定の分に対する応答は決して変わりません。ログが私たちの集約システムに収束するにつれて、特定の時間範囲を繰り返しポーリングする必要はありません。

返されるデータの形式

Logpull API は NDJSON 形式でデータを返します。ここで、各ログ行は有効な JSON オブジェクトです。Google BigQuery や AWS Kinesis のような主要な分析ツールはこの形式を必要とします。

結果として得られたログデータを、各ログ行ごとに1つの配列要素を持つ JSON 配列に変換するには、jq ツールを使用できます。基本的には、API 応答を slurp（または単に s）フラグを使用して jq にパイプします：

<API request data> | jq -s

以下は、デフォルトフィールドを持つサンプルログです：

{
    "ClientIP": "89.163.242.206",
    "ClientRequestHost": "www.theburritobot.com",
    "ClientRequestMethod": "GET",
    "ClientRequestURI": "/static/img/testimonial-hipster.png",
    "EdgeEndTimestamp": 1506702504461999900,
    "EdgeResponseBytes": 69045,
    "EdgeResponseStatus": 200,
    "EdgeStartTimestamp": 1506702504433000200,
    "RayID": "3a6050bcbe121a87"
}

データ保持期間

過去1分からログをクエリすることができ（実際にクエリを行う時間に対して）、少なくとも3日、最大7日まで遡ることができます。より長い期間については、Logpush の使用をお勧めします。