AWStats Advanced Web Statistics (AWStats) is a free powerful Web server logfile analyzer (Perl script) that shows you all your Web statistics including visits, unique visitors, pages, hits, rush hours, search engines, keywords used to find your site, robots, broken links, and more. The benefit of the integrated awstats over many plugins is the security. Some awstats plugins use chmod 777 for many files and folders, meaning anyone on the system has the ability to change things around. With this setup, files are chowned to root, and chmod to a. AWStats is an open-source advanced web analytics tool that generates advanced web, streaming, FTP, or mail server statistics graphically. It is written using the Perl language and works as a CGI or from the command line.
- AWStats is a powerful tool that creates graphical reports from your website’s access logs. It’s great for taking a quick look at things such as visits to your site per day and the number of pages viewed on your website.
- # AWStats can do reverse DNS lookups through a DNS cache file that was created # by a previous run of AWStats. This file is erased and recreated after each # statistics update process. You don't need to create and/or edit it. # AWStats will read and save this file in DirData directory. # This option is used only if DNSLookup=1.
[Update Sept 2019: I still use this, but I also use Matomo as well (I also played with Fathom, but it didn’t grab me). Self-hosting, combined with pretty good privacy controls, mean I can get the extra data of Matomo and still preserve visitor anonymity. When I check my stats though, AWStats is still first.]
If you’d like some basic data about your site’s visitors, but don’t want to let spyware vendors track them around the web, AWStats makes a good solution. It parses your server log files and tells you who came by and what they did. There’s no spying, no third-party code bloat. AWStats just analyzes your visitors’ footprints.
Here’s how I got AWStats up and running on an Ubuntu 18.04 VPS server running over at Vultr.com (non-affiliate link if you prefer).
AWStats with GeoIP
The first step is to install the AWStats package from the Ubuntu repositories:
This will install the various tools and scripts AWStats needs. Because I like to have some geodata in my stats, I also installed the tools necessary to use the AWStats geoip plugin. Here’s what worked for me.
First we need build-essential and libgeoip:
Next you need to fire up the cpan shell:
If this is your first time in cpan you’ll need to run two commands to get everything set up. If you’ve already got cpan set up, you can skip to the next step:
Once cpan is set up, install GeoIP:
That should take care of the GeoIP stuff. You can double-check that the database files exist by looking in the directory /usr/share/GeoIP/ and verifying that there’s a file named GeoIP.dat.
Now, on to the log file setup.
Optional Custom Nginx Log Format
This part isn’t strictly necessary. To get AWStats working the next step is to create our config files and build the stats, but first I like to overcomplicate things with a custom log format for Nginx. If you don’t customize your Nginx log format then you can skip this section, but make a note of where Nginx is putting your logs, you’ll need that in the next step.
Open up /etc/nginx/nginx.conf and add these lines:
Awstats Documentation
Now we need to edit our individual nginx config file to use this log format. If you follow the standard nginx practice, your config file should be in /etc/nginx/sites-enabled/. For example this site is served by the file /etc/nginx/sites-enabled/luxagraf.net.conf. Wherever that file may be in your setup, open it and add this line somewhere in the server block.
Configure AWStats for Nginx
As I said in the beginning, AWStats is ancient, it hails from a very different era of the internet. One legacy from the olden days is that AWStats is very strict about configuration files. You have to have one config file per domain you’re tracking and that file has to be named in the following way: awstats.domain.tld.conf. Those config files must be placed inside the /etc/awstats/ directory.
If you go take a look at the /etc/awstats directory you’ll see two files in there: awstats.conf and awstats.conf.local. The first is a main conf file that serves as a fallback if your own config file doesn’t specify a particular setting. The second is an empty file that’s meant to be used to share common config settings, which really doesn’t make much sense to me.
I took a tip from this tutorial and dumped the contents of awstats.conf into awstats.local.conf. That way my actual site config file is very short. If you want to do that, then all you have to put in your config file are a few lines.
Using the naming scheme mentioned above, my config file resides at /etc/awstats/awstats.luxagraf.net.conf and it looks like this (drop your actual domain in place of “yourdomain.com”):
Save that file and open the fallback file awstats.conf.local. Now set a few things:
Then delete the LogFile, SiteDomain, DirData, and HostAliases settings in your awstats.conf.local file. We’ve got those covered in our site-specific config file.
Okay, that’s it for configuring things, let’s generate some data to look at.
Building Stats and Rotating Log Files
Now that we have our log files, and we’ve told AWStats where they are, what format they’re in and where to put its analysis, it’s time to actually run AWStats and get the raw data analyzed. To do that we use this command:
Alternately, if you have a bunch of config files you’d like to update all at once, you can use this wrapper script conveniently located in a completely different directory:
You’re going to need to run that command regularly to update the AWStats data. One way to do is with a crontab entry, but there are better ways to do this. Instead of cron we can hook into logrotate, which rotates Nginx’s log files periodically anyway and conveniently includes a prerotate directive that we can use to execute some code. Technically logrotate runs via /etc/cron.daily under the hood, so we haven’t really escaped cron, but it’s not a crontab we need to keep track of anyway.
The main things we’ve changed here are the frequency, moving from weekly to daily rotation in line 2, keeping 30 days worth of logs in line 4, and then calling AWStats in line 11.
One thing to bear in mind is that if you re-install Nginx for some reason this file will be overwritten.
Now do a dry run to make sure you don’t have any typos or other problems:
Serving Up AWStats
Now that all the pieces are in place, we need to put our stats on the web. I used a subdomain, awstats.luxagraf.net. Assuming you’re using something similar here’s an nginx config file to get you started:
This config is pretty basic, it passes requests for icons to the AWStats icon dir and then sends the rest of our requests to php-fpm. The only tricky part is that AWStats needs to call a Perl file, but we’re calling a PHP file, namely /etc/nginx/cgi-bin.php. How’s that work?
Well, in a nutshell, this script takes all our server variables and passes them to stdin, calls the Perl script and then reads the response from stdout, passing it on to Nginx. Pretty clever, so clever in fact that I did not write it. Here’s the file I use, taken straight from the Arch Wiki:
Save that mess of PHP as /etc/nginx/cgi-bin.php and then install php-fpm if you haven’t already:
Next we need to create the password file referenced in our Nginx config. We can create a .htpasswd file with this little shell command, just replace yourdomain.com with the same domain you used in your AWStats config and use an actual username in place of username:
Enter your password when prompted and your password file will be created in the expected format for basic auth files.
Then move that file to the proper directory:
Now we have an Nginx config, a script to pass AWStats from PHP to Perl and some basic password protection for our stats site. The last, totally optional, step is to serve it all over HTTPS instead of HTTP. Since we have a password protecting it anyway, this is arguably unnecessary. I do it more out of habit than any real desire for security. I mean, I did write an article criticizing the push to make everything HTTPS. But habit.
I have a separate guide on how to set up Certbot for Nginx on Ubuntu 18.04 that you can follow. Once that’s installed you can just invoke Certbot with:
Select the domain name you’re serving your stats at (for me that’s awstats.luxagraf.net), then select 2 to automatically redirect all traffic to HTTPS and certbot will append some lines to your Nginx config file.
Now restart Nginx:
Visit your new site in the browser at this URL (changing yourdomain.com to the domains you’ve been using): https://awstats.yourdomain.com/cgi-bin/awstats.pl?config=yourdomain.com. If all went well you should see AWStats with a few stats in it. If all did not go well, feel free to drop whatever your error message is in a comment here and I’ll see if I can help.
Motivations
And now the why. The “why the hell don’t I just use —insert popular spyware here—” part.
My needs are simple. I don’t have ads. I don’t have to prove to anyone how much traffic I get. And I don’t really care how you got here. I don’t care where you go after here. I hardly ever look at my stats.
When I do look all I want to see is how many people stop by in a given month and if there’s any one article that’s getting a lot of visitors. I also enjoy seeing which countries visitors are coming from, though I recognize that VPNs make this information suspect.
Since I don’t track you I certainly don’t want third-party spyware tracking you, so that means any hosted service is out. Now there are some self-hosted, open source spyware packages that I’ve used, Matomo being the best. It is nice, but I don’t need or use most of what it offers. And I really dislike running MySQL on the cheap, minimally powered VPS servers I use. It just uses way too much memory. Unfortunately Matomo requires MySQL, as does Open Web Analytics.
By process of elimination (no MySQL), and my very paltry requirements, the logical choice is a simple log analyzer. I went with AWStats because I’d used it in the past. Way in the past. But you know what, AWStats ain’t broke. It doesn’t spy, it uses no server resources, and it tells you 95 percent of what any spyware tool will tell you (provided you actually read the documentation)
In the end, AWStats is good enough without being too much. But for something as simple as it is, AWStats is surprisingly complex to get up and running, which is what inspired this guide.
Awstats
Shoulders stood upon: