Technical
Log file
Also called access log.
Log file is the plain-text record a web server writes for every request it handles, one line per hit. It exists whether or not any tracking script ever ran.
How it is measured
A typical line holds the client IP, time, method and path, status, bytes sent, Referer, and user-agent. Count a day's lines with `wc -l`, or filter by status with `awk '$9==404'`. Each line is one request, not one person or one page.
Rotation decides what you can look at. Logs roll daily or at a size, get compressed to `.gz`, and are deleted after some number of days. Know your retention, and know that a CDN's logs and the origin's logs record different things.
Worked example
An origin behind a CDN logs 1.2 million lines for Tuesday. About 1.05 million show the CDN's address, not the visitor's, because the real client is in `X-Forwarded-For`. A log format change adds that field, and the top-IP list goes from three CDN nodes to a long tail.
The same file shows 38,000 requests to `/wp-login.php` from 210 addresses, traffic that a browser script on the public pages would never have seen.
How it differs
A log file is the raw record at the server. Server-log analytics is the practice of turning those lines into reports. The file is the evidence, and the analysis is the sorting and counting, which inherits every gap in the file.
Common errors
Letting the disk fill because logs never rotate. Reading the CDN edge address as the visitor. Keeping IPs for years with no reason. Treating each line as a person. Forgetting that an HTTP/2 page loads many assets, each logged separately. Leaving the Host header out on a multi-site server.
In practice
Check today that your logs rotate, how long they are kept, and whether the format includes the real client IP and the Host. Tail the file during a test visit to see your own request. Delete or anonymise IPs after the window you actually need.