Stop Grepping in the Dark: Advanced Server Log Analysis with AWStats

I still see sysadmins trying to diagnose traffic spikes using tail -f /var/log/httpd/access_log while their server load climbs past 15.0. It is a waste of time and terminal real estate. If you are running a high-traffic e-commerce site targeting the Norwegian market, raw logs are just noise until you parse them into actionable intelligence.

We are going to set up AWStats 7.0 on a RHEL/CentOS 6 environment. Not just the default install, but a configuration that respects server resources and adheres to the strict privacy expectations of Datatilsynet (The Norwegian Data Protection Authority). We will also cover why log parsing is an I/O killer and how to mitigate that.

The I/O Bottleneck: Why Your "Cloud" Feels Slow

Parsing text files is computationally expensive, but it is the disk I/O that usually kills you. When AWStats parses a 4GB log file, it is reading line-by-line, matching patterns via Perl. On a standard shared hosting platform or a budget VPS with oversold SATA drives, this process can cause iowait to spike, making your actual web application sluggish for users in Oslo or Bergen.

Pro Tip: Always schedule heavy log analysis during off-peak hours (usually 03:00 - 05:00 CET). If you are on CoolVDS, our Xen-based virtualization ensures your dedicated CPU cycles process these Perl scripts without stealing from your web server threads. Plus, our RAID-10 SAS arrays handle the read operations significantly faster than standard SATA disks.

Step 1: Installation via EPEL

Don't compile from source unless you have to. The Extra Packages for Enterprise Linux (EPEL) repository is stable.

# Install EPEL repo if not present
rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm

# Install AWStats
yum install awstats

Step 2: Configuration for Apache

Copy the model configuration file to a specific file for your domain.

cp /etc/awstats/awstats.model.conf /etc/awstats/awstats.coolvds-demo.no.conf
vi /etc/awstats/awstats.coolvds-demo.no.conf

You need to adjust these key directives. The LogFile path must match your Apache httpd.conf settings.

# Path to your access log
LogFile="/var/log/httpd/access_log"

# 1 = Apache Combined Log Format (Standard)
LogFormat=1

# DNS Lookup - Set to 0 for speed, 1 if you need hostname resolution
# Warning: Setting to 1 adds significant latency to the update process.
DNSLookup=0

# Directory where data files are stored
DirData="/var/lib/awstats"

The Norwegian Privacy Context (Datatilsynet)

In Norway, IP addresses can be considered personal data under Personopplysningsloven. While we don't have the heavy GDPR hammer yet, it is best practice to anonymize data if you don't strictly need it for security forensics. AWStats allows a plugin for this.

Uncomment this line in your config to mask the last octet of IP addresses:

LoadPlugin="hashcrypt"

Note: You may need to install the Perl module Digest::MD5 for this to work flawlessly.

Step 3: Secure the Web Interface

By default, the AWStats CGI script is accessible to the world. This is a security risk. You do not want your competitors seeing your traffic sources. Lock it down in Apache.

Edit /etc/httpd/conf.d/awstats.conf:

<Directory "/usr/share/awstats/wwwroot">
    Options None
    AllowOverride None
    Order allow,deny
    Allow from 127.0.0.1
    # Allow from your office IP only
    Allow from 84.234.xx.xx 
    
    # Or use Basic Auth
    AuthType Basic
    AuthName "Restricted Access"
    AuthUserFile /etc/awstats/htpasswd
    Require valid-user
</Directory>

Create the password file:

htpasswd -c /etc/awstats/htpasswd adminuser

Step 4: Automation and Cron

Manual updates are for amateurs. Set this up in /etc/cron.hourly or strictly at night via crontab -e to avoid impacting daytime performance.

# Run every night at 04:15 AM server time
15 04 * * * /usr/share/awstats/wwwroot/cgi-bin/awstats.pl -config=coolvds-demo.no -update > /dev/null

Why Infrastructure Matters for Log Parsing

When awstats.pl runs, it eats CPU and Disk I/O. I recently migrated a client from a budget "container" host (OpenVZ based) where their nightly log analysis was causing the MySQL database to lock up due to resource contention. The "noisy neighbor" effect was real.

We moved them to a CoolVDS instance. Because we use strict hardware virtualization (Xen/KVM), the resources are guaranteed. The script now runs in 4 minutes instead of 40, and the database never flinches.

The NIX (Norwegian Internet Exchange) Advantage

If your traffic is local, latency matters. CoolVDS peers directly at NIX in Oslo. When you are analyzing your logs, you will notice the difference in response times for your Norwegian users compared to hosting in Germany or the US. Low latency isn't just about speed; it's about the feeling of "snappiness" that keeps users on your site.

Next Steps: Check your current iowait levels during log rotation. If you are seeing wait times over 10%, your disk subsystem is failing you. Spin up a CoolVDS instance today and see what dedicated resources actually feel like.