The Truth is in /var/log

Let’s be honest for a second. If you rely solely on JavaScript-based trackers like Google Analytics to understand your server's health, you are flying blind. JavaScript tags don't fire when a bot hits your site. They don't fire when your server throws a 500 Internal Server Error. And they certainly don't tell you why your load average spiked to 25.00 at 3:00 AM while you were sleeping.

I recently audited a client's setup in Oslo. They were convinced they were under a DDoS attack. Their frontend analytics showed zero traffic, yet the server was crawling, pushing I/O wait times through the roof. A quick tail -f /var/log/httpd/access_log revealed the culprit: a poorly written scraper from a competitor was hammering their search endpoint every 200 milliseconds. No JS tag would ever catch that. The raw logs did.

To visualize this data without grepping yourself to death, you need AWStats. It’s the industry standard for a reason. It parses the raw server logs, meaning it captures everything—bandwidth thieves, hot-linkers, 404 errors, and spiders.

Step 1: The Environment (CentOS 6.2)

We assume you are running a standard LAMP stack. While Nginx is gaining traction, Apache 2.2 remains the workhorse for most enterprise deployments in the Nordics due to its robust module support. If you are on a CoolVDS instance, you likely have the EPEL repository enabled. If not, get it done:

Step 2: Configuration that Actually Works

The default configuration file is a mess of comments. You need to strip it down to the essentials. Copy the model file to a domain-specific config:

Here are the critical parameters you must change. Do not ignore the LogFormat. If this doesn't match your Apache config exactly, AWStats will return empty data. For a standard combined log, use type 1.

# The path to your log file. crucial for accurate parsing.
LogFile="/var/log/httpd/access_log"

# 1 = Apache Combined Log Format (NCSA combined/XLF/ELF)
LogFormat=1

# Your specific domain
SiteDomain="yourdomain.com"

# Local DNS lookups can kill performance. 
# Keep this OFF unless you have a local caching nameserver.
DNSLookup=0

# Directory where stats will be stored
DirData="/var/lib/awstats"

The "NIX" Factor: Data Privacy in Norway

Operating out of Norway brings specific legal responsibilities. The Data Inspectorate (Datatilsynet) is rigorous about how personally identifiable information (PII) is handled under the Personal Data Act (Personopplysningsloven). An IP address is considered PII.

If you are storing logs for long periods to analyze trends, you should obfuscate the last octet of the IP addresses in your reports to stay on the safe side of compliance. AWStats has a plugin for this, but a quick internal hack in the config is often cleaner:

Pro Tip: Ensure your DirData is not world-readable. Use chmod 700 /var/lib/awstats. Leaking server stats is a massive security vulnerability that gives attackers a blueprint of your directory structure.

Step 3: Scheduling the Updates

AWStats is not real-time. It requires a Perl script execution to parse the new log lines. Do not run this every minute; the overhead is unnecessary. For a standard traffic site, updating every hour is sufficient.

Add the following script:

#!/bin/bash
/usr/bin/perl /usr/share/awstats/wwwroot/cgi-bin/awstats.pl -config=yourdomain.com -update > /dev/null

Make it executable with chmod +x /etc/cron.hourly/00awstats.

Step 4: The I/O Bottleneck

Here is the technical reality check. Log parsing is extremely I/O intensive. When AWStats reads a 2GB log file, it is trashing your disk subsystem. On traditional mechanical SAS drives, this causes "I/O Wait"—a state where your CPU sits idle, doing nothing, waiting for the disk platter to spin.

If you are running a Magento store or a high-traffic forum, running AWStats during peak hours on a standard mechanical VPS will degrade your web performance. Your site will feel sluggish, not because you lack RAM, but because the disk queue is full.

This is why we architect CoolVDS on pure SSD storage arrays. In 2012, storage speed is the single biggest differentiator in hosting performance. We don't just cache; the underlying volume is solid-state. This allows you to crunch gigabytes of logs in seconds without your visitors noticing a single millisecond of latency.

Securing the Interface

By default, AWStats might be accessible to the world. Lock it down. In your Apache configuration (/etc/httpd/conf.d/awstats.conf), use Allow from directives to restrict access to your office IP range.

<Directory /usr/share/awstats/wwwroot>
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1
    Allow from 84.211.x.x  # Your Office Static IP
    Allow from 195.159.x.x # Your VPN IP
</Directory>

Restart Apache with service httpd reload.

Final Thoughts

Logs are the heartbeat of your infrastructure. They tell you the truth when everything else is guessing. But analyzing them shouldn't cost you uptime. Configuring AWStats correctly gives you the forensic capability to detect threats and optimize content, while the right hardware ensures that the analysis process itself is invisible to your users.

If your current host chokes every time you run a log parser, it’s time to upgrade. Deploy a CoolVDS SSD instance today and see what zero-latency administration feels like.