Slashdot Mirror


Web Log Analyzers?

sammy.lost-angel.com asks: "What's the best web log analyzer out there today? It's time to upgrade our horribly out of date one and I'm not sure what's good out there at this time. Our site receives about 50,000 hits a day, so things like remembering what's already been analyzed can save a lot of time." What about log analyzers that can work on more than one type of web server? An analyzer that could parse access data for, say, IIS and Apache would be a nice tool!

7 of 31 comments (clear)

  1. Webalizer by Anonymous Coward · · Score: 1, Informative

    http://www.mrunix.net/webalizer/

    I've had good luck running several million hits through Webalizer. It works pretty well.

  2. What's it matter what server generates the logs? by barzok · · Score: 2, Informative

    Last I checked, both IIS and Apache generate (or can be set to generate) W3C standard format logfiles. Part of the reason for having/using that standard is so that you don't get locked into a proprietary tool.

  3. Re:Analog and Webalizer by Anonymous Coward · · Score: 1, Informative

    We use webalizer and its very cool. Nice graphs and break downs. Check it out for sure!

  4. webalizer & awstats by EvilStein · · Score: 2, Informative

    awstats (awstats.sourceforge.net) for the IIS logs, but it's kind of funky to set up...

    and webalizer (www.mrunix.net/webalizer) for the Apache logs.

    awstats is Perl, too...

    I've used them both and since I have only Apache to log, I've stuck with webalizer. Plus, you can easily customize it for each user/domain with its own webalizer.conf file.

  5. AWstats rocks! by OctaneZ · · Score: 3, Informative

    I have been running AWStats since July, and I absolutely love it. It does not provide the fine-grain detail that many people need, and which can be provided by Analog. But it does provide exactly what 90% percent of us need, in an easy to view package. It creates an easy to understand page about many aspects of your site, including, users, page hits, countries, languages, OS, browser, spiders/robots, access times; it's great! It is also a GPLed perl script! The developement team is over at Source Forge and is actively releasing new code all the time. It also has the added benefit of allowing cgi updating through a web page; simply putting the script in your /www/cgi-bin/ directory and adding appropriate permissions allows you to get up to the second information about your sight without having to dig up a terminal! Definately check this package out!
    -OctaneZ

  6. Analog by Stephen · · Score: 5, Informative
    I'd like to plug analog. I'm the author, so read my comments in that light. :-)

    First, as others have commented, the commercial programs suck, especially Webtrends.

    Analog is over six years old, but it's still actively developed, and I think it's still the leading free log analyser. The main contender is the Webalizer. To some extent it depends what you want (why not try out both?). The Webalizer's biggest advantage is that it produces prettier pictures. Some of analog's advantages are that it is more configurable; that it runs on any OS (the Webalizer is Unix only); and that it can analyse logfiles from any web server.

    Besides, analog's author reads Slashdot.

    --
    11.00100100001111110110101010001000100001011010001 1000010001101001100010011
  7. Re:Analog and Webalizer by Stephen · · Score: 3, Informative
    ...it can be hard to dig through the [analog] documentation.
    I (the author) have some sympathy with this; but the main problem is that it's so configurable that there just are a lot of commands.

    I have done some work recently on presenting the documentation in different ways. As well as the main topic-based documentation, there's now a page with only the most basic commands for beginners; a comprehensive index; all the commands on a single page with a BNF-type grammar; and two sample configuration files with all the commands in, one in topic order and one in report order. There's also the beginnings of a collection of third-party HOWTO's (for which I need more volunteers, HINT HINT!).

    I do take a lot of time and trouble over documentation, I suspect much more than most open source projects. My rule is that no change can be committed until it's fully documented. So you will never find the documentation lagging behind the reality, or options missed out of the documentation. I also spend a lot of time rephrasing the existing documentation.

    --
    11.00100100001111110110101010001000100001011010001 1000010001101001100010011