Analyze Apache Logs Without Leaving Your Desktop

Before you can analyze anything, you have to find the files — and the path depends on how your distribution packages Apache:

Virtual hosts routinely override those defaults with their own directives, so a busy server can write access logs to a dozen different paths. Find every configured log location in one command:

$ grep -r CustomLog /etc/apache2/sites-enabled/    # Debian, Ubuntu
$ grep -r CustomLog /etc/httpd/conf.d/            # RHEL, CentOS, Fedora

In Grep Badger, connect over SSH and browse to the path from the table — no scp, no mounting, no download. The log opens where it lives.

Apache writes access logs in two standard shapes. The Common Log Format (CLF) is the baseline; the combined format — Apache's default — appends the referer and user agent:

# Common Log Format (CLF)
LogFormat "%h %l %u %t \"%r\" %>s %b" common

# Combined: CLF plus referer and user agent (the default)
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

A combined line in the wild:

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (Win98; I ;Nav)"

Field by field, that is:

Status codes cluster into families you will filter on constantly: 2xx success, 3xx redirects, 4xx client errors like 404 and 429, and 5xx server errors — usually the ones you are hunting.

One detail that trips everyone up: %t records server-local time with the UTC offset baked in. If the box runs UTC and the incident report says 3pm Berlin time, convert first — otherwise you grep the wrong hour and conclude nothing happened.

Once you can read one line, you can read a million of them. The real work is filtering down to the few that matter — and there are two honest ways to do that.

You don't need a GUI to ask an access log basic questions. awk answers them in one line — here is the status code histogram:

$ awk '{print $9}' /var/log/apache2/access.log | sort | uniq -c | sort -rn
   4231 200
    806 304
    512 404
     37 500

$9 is the status code because awk splits on whitespace and the quoted request — method, path, protocol — fills fields 6 through 8. Top client IPs are the same trick on $1:

$ awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -5

And the question you actually care about during an incident: which URLs are 500ing?

$ awk '$9 == 500 {print $7}' /var/log/apache2/access.log | sort | uniq -c | sort -rn

Where one-liners start to cost you:

• A space inside a request path shifts every field after it, so $9silently becomes something else.
• A custom LogFormat moves the goalposts — every server gets its own field positions to derive and remember.
• Counts and lines live in separate commands. You can't click the 37 and see the requests behind it.

The same investigation in Grep Badger: open the log over SSH, add an include filter for " 500 " — the surrounding spaces keep it from matching stray digits in paths or byte counts — and you are looking at the actual failing requests. Refine or widen the filter without re-deriving field positions, then select a block of lines and ask the AI what they have in common.

A ticket lands Monday morning: checkout errors spiked Saturday around 02:00. You tail the live access.log and see nothing but clean traffic — because Apache handed Saturday to logrotate days ago. The evidence still exists; it just lives in a different file now.

On a schedule, logrotate shifts access.log to access.log.1, compresses older files to .gz, and deletes them once the retention count runs out. Your schedule and retention are configured here:

$ cat /etc/logrotate.d/apache2     # Debian, Ubuntu
$ cat /etc/logrotate.d/httpd       # RHEL, CentOS, Fedora

On this box, the family looks like:

$ ls -lh /var/log/apache2/access.log*
-rw-r----- 1 root adm 4.2M Oct 26 09:41 access.log
-rw-r----- 1 root adm  15M Oct 26 06:25 access.log.1
-rw-r----- 1 root adm 3.1M Oct 19 06:25 access.log.2.gz
-rw-r----- 1 root adm 3.0M Oct 12 06:25 access.log.3.gz

Saturday the 25th falls inside access.log.1 — still plain text, so the drill is familiar:

$ grep '25/Oct/2026:02:' /var/log/apache2/access.log.1 | grep -c ' 500 '
214

Cross one more rotation boundary and the files are compressed — grepbecomes zgrep:

$ zgrep '18/Oct/2026:02:' /var/log/apache2/access.log.2.gz

One caveat: logrotate's retention count is a hard limit. If that ticket had arrived two weeks later, the Saturday evidence would already be deleted.

In Grep Badger, each log opens in its own tab — access.log andaccess.log.1 in the same window, the same search in each tab, and the timeline a click away. The older .gz archives still need a quickgunzip first — one command, and they open like any other file.