基本のアクセスパターンは、ゾーン Z の、分 M のログをすべて返す です。ここで分 M は、ログエントリが Cloudflare のログ集約システムにディスク書き込みされた時刻を指します。
まずは 1 分ごとにクエリを実行します。レスポンスが小さすぎる場合は、間隔を 5 分に広げます。多くのゾーンでは 5 分が適切です。レスポンスが大きすぎる場合は、15 秒に下げます。
1 分分のログを読むのに 1 分以上かかるほどログが多いゾーンでは、2 つのワーカーをずらして動かします。それぞれが 2 分ごとに 1 分分のログを要求します。
API が返すデータは、同じクエリを繰り返しても変わりません。レスポンス内のメッセージ順序は変わることがありますが、レスポンスコードが 200 で、レスポンス本文の読み取りにエラーがなければ、メッセージの件数と内容は常に同じです。
ログ処理システムはデータをバッチで取り込みます。そのため、1 分あたりのリクエストが 100 万件未満のゾーンでは、「空」の分が発生することがほとんどです。そのような分へのクエリは、ステータス 200 で本文にデータがないレスポンスになります。これは、その分に Cloudflare がプロキシしたリクエストがなかったことを意味しません。その分に、そのゾーンのログバッチが処理されなかっただけです。
logs/received API エンドポイントは、受信時刻でデータを公開します。受信時刻は、イベントが Cloudflare Logs の集約システムにディスク書き込みされた時刻です。
ログ生成時刻ではなくログ集約時刻で並べると、ログパイプラインのレイテンシが下がり（速くなり）、決定的なログ取得ができます。機能的には、ログファイルを tail する、または rsyslog から読む操作に近いです（ただしチャンク単位です）。
つまり、ある時間範囲のログを取るには、連続する各分（またはほかの時間範囲）に対して 1 回ずつ呼び出します。ログ行は受信時刻でバッチ化されて公開されるため、遅延到着データはありません。ある分のレスポンスは、あとから変わることがありません。集約システムにログが収束するのを待つために、同じ時間範囲を繰り返しポーリングする必要はありません。
Logpull API は NDJSON 形式でデータを返します。各ログ行は有効な JSON オブジェクトです。Google BigQuery や AWS Kinesis などの主要な分析ツールは、この形式を必要とします。
得られたログデータを、1 ログ行につき 1 要素の JSON 配列にするには、jq ツールを使えます。API レスポンスを jq にパイプし、slurp（または単に s）フラグを付けます。
<API request data> | jq -s
jq の入手とインストールは Download jq ↗ を参照してください。
次は、デフォルトフィールドのサンプルログです。
{
"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 の利用を推奨します。