Console Login
Home / Blog / Server Administration / Stop Guessing: Forensic Server Log Analysis with AWStats in 2011
Server Administration 9 views

Stop Guessing: Forensic Server Log Analysis with AWStats in 2011

@

The Truth is in the Logs: Configuring AWStats for High-Traffic Nodes

Most webmasters live in a fantasy world painted by JavaScript-based analytics. They see "visits" and "bounce rates," but they remain blind to the raw reality of their infrastructure. If you are relying solely on external trackers, you are missing 40% of the picture: the leechers, the scrapers, the hotlinkers, and the brute-force bots hammering your login.php.

Real system administrators trust one thing: /var/log/httpd/access_log. But staring at raw text streams is inefficient. You need to parse it, visualize it, and act on it. That is where AWStats comes in. It is not new, but it is battle-tested, parses logs server-side, and doesn't rely on a client executing a script.

The I/O Bottleneck Warning

Before we touch the config, a warning. Log analysis is heavy. It requires reading massive text files and writing statistical databases. On over-sold shared hosting, running a full update on a 2GB log file will likely get your process killed or your account suspended for abusing disk I/O.

This is a scenario where the underlying architecture matters. At CoolVDS, we moved away from the "burstable" myths of OpenVZ and standard HDD arrays for our performance tier. We use Xen virtualization with dedicated resource allocation. When you crunch logs on a CoolVDS instance, you are utilizing dedicated CPU cycles and high-performance storage (RAID-10 SAS or the new Enterprise SSDs we are rolling out), meaning your web server doesn't choke while your stats generate.

Step 1: Installation (CentOS / RHEL 5 & 6)

Forget compiling from source unless you have specific patch needs. The EPEL repository is your friend here.

# rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm # yum install awstats

For Debian 6 (Squeeze) users, it’s a simple apt-get install awstats.

Step 2: Configuration for Accuracy

The default config is garbage for a high-traffic production environment. You need to edit /etc/awstats/awstats.yourdomain.conf. Specifically, pay attention to the LogFormat.

If you are running Apache 2.2, ensure your httpd.conf has the combined log format enabled, then set:

LogFormat=1

Handling the "Exclude" List

You don't want your own uptime monitors skewing the data. Add your monitoring IPs (like Nagios or Zabbix agents) to the skip list:

SkipHosts="127.0.0.1 REGEX[^192\.168\.]"

War Story: The "Invisible" DDoS

Last month, a client hosted on a legacy provider came to us. Their site was sluggish, but Google Analytics showed flat traffic. We migrated them to a CoolVDS unit and fired up AWStats. Immediately, we saw the anomaly: a massive spike in bandwidth usage from a specific subnet in Eastern Europe targeting image assets.

It wasn't a standard DDoS; it was aggressive hotlinking on a high-traffic forum. The client was paying for bandwidth used by someone else. We implemented a simple .htaccess rewrite rule to block the referrers, and load dropped instantly. You can't fix what you can't see.

Pro Tip: Automated log rotation is critical. Ensure logrotate is configured to run after AWStats updates, or you will lose data. We recommend scheduling the cron job to run at 23:55, just before the midnight log rotation.

Data Sovereignty and Datatilsynet

Here in Norway, privacy is not just a suggestion; it is codified in the Personopplysningsloven (Personal Data Act). When you use third-party US-based analytics, you are shipping user IP addresses across the Atlantic. By using self-hosted AWStats on a server located physically in Oslo, you maintain tighter control over your data.

CoolVDS infrastructure is located in local datacenters with direct peering to NIX (Norwegian Internet Exchange). This ensures that not only is your data legally compliant under the EU Data Protection Directive, but your latency to Nordic customers is often under 10ms.

Executing the Update

Once configured, do not wait for the cron. Test it immediately:

/usr/bin/perl /usr/share/awstats/wwwroot/cgi-bin/awstats.pl -update -config=yourdomain.com

If you see parsing errors, check your LogFile path. If it takes more than a few seconds for a day's worth of logs, it is time to upgrade your I/O throughput.

Conclusion

Knowledge is power. Don't let your server be a black box. Install AWStats, configure it right, and ensure your hosting platform has the disk speed to handle the analysis. If you are tired of I/O wait times stalling your shell, deploy a CoolVDS Xen instance today. High-speed storage and root access shouldn't be a luxury.

/// TAGS

/// RELATED POSTS

Surviving the Spike: High-Performance E-commerce Hosting Architecture for 2012

Is your Magento store ready for the holiday rush? We break down the Nginx, Varnish, and SSD tuning s...

Read More →

Automate or Die: Bulletproof Remote Backups with Rsync on CentOS 6

RAID is not a backup. Don't let a typo destroy your database. Learn how to set up automated, increme...

Read More →

Nginx as a Reverse Proxy: Stop Letting Apache Kill Your Server Load

Is your LAMP stack choking on traffic? Learn how to deploy Nginx as a high-performance reverse proxy...

Read More →

Apache vs Lighttpd in 2012: Squeezing Performance from Your Norway VPS

Is Apache's memory bloat killing your server? We benchmark the industry standard against the lightwe...

Read More →

Stop Guessing: Precision Server Monitoring with Munin & Nagios on CentOS 6

Is your server going down at 3 AM? Stop reactive fire-fighting. We detail the exact Nagios and Munin...

Read More →

The Sysadmin’s Guide to Bulletproof Automated Backups (2012 Edition)

RAID 10 is not a backup strategy. In this guide, we cover scripting rsync, rotating MySQL dumps, and...

Read More →
← Back to All Posts