Access logs, already in columns.

Take a file

This is the widest and heaviest dataset in the collection per row, mostly because of the user agent column. The 1,000-row CSV is about 170 KB.

Log volumes that mean something

A hundred thousand log lines is a quiet hour on a real site and about 17 MB of CSV. A million is roughly a busy day and lands near 190 MB, which is the size at which the difference between a tool that streams and a tool that loads becomes obvious.

Eight columns, and what each one holds

What it models

A web access log after the parsing step, which is the form most people want and almost nobody publishes. Raw combined-format log lines are easy to find and annoying to work with; the interesting analysis starts once the line has been split into a timestamp, a client, a request, a response code, a size and a duration.

Fifteen paths appear, including two with query strings and three static assets. Methods are weighted toward GET the way real traffic is, with a tail of POST, PUT, DELETE and HEAD. The window is fourteen days and the rows ascend in time, so a requests-per-hour chart works without any preparation.

The commas inside the fields

User agent strings contain commas. So does one of the query strings. Both are correctly quoted in the CSV, which makes this file a compact test of whether a parser is a real CSV parser or a line splitter with ambitions. If your import produces nine or ten columns instead of eight, you have found the bug this dataset exists to find.

It is a common bug. Splitting on comma is the first thing anybody writes, it works on every clean sample file, and it breaks the first time a real log or a real address book arrives. Having a small file that exercises it in the first eight rows is worth more than a large clean file that never does.

Status codes and latency

About 86 percent of requests return 200, then 304, 301, 404, 429, 500 and 503 in decreasing order. That mix is close enough to a real site that an error rate chart looks familiar, and it includes 429 specifically because rate limiting is the status people forget to handle in a dashboard.

Response size is zero on every 304, which is correct and which catches a certain kind of bug in a bandwidth calculation. Response time is fast for most requests with a six percent tail that runs from 900 milliseconds to 14 seconds, so a mean latency and a 95th percentile latency tell you very different stories. Comparing the two on this file is a good way to explain to somebody why the mean is the wrong number to alert on.

Open it somewhere useful

The validator is the interesting one here, because it will tell you the file is well formed despite the commas inside fields.

Questions people ask about this file