Weiter zum Inhalt

Webseitenstatistiken

Es ist geschafft, die eigene Webseite wurde endlich umgesetzt – das Layout gefällt, die Texte sidnn knackig und interessant, die Suchmaschinen über die neue Topadresse informiert. Aber kommen die Besucher auch in Scharen? Von wo kommen all die wissendurstigen Surfer, die meine Texte begierig lesen? Wie viele Bots, egal ob gut- oder bösartig, graben sich durch meine Webpräsenz?
All das sind typische Fragen, die sich wohl so gut wie jeder Webseitenbetreiber stellt. Lösungen gibt es dann auch gleich so viele wie Frage: Piwik / phpMyVisites, Google Analytics, webalizer, awstats….

Unterschiede und Gemeinsamkeiten

Bevor der fleißige Webmaster jetzt zu einem Tool greift sollte er sich darüber im Klaren sein, wie die verschiedenen Helferlein funktionieren. Es gibt hier durchaus gravierende Unterschiede. Es beginnt bei der Überlegung ob die Statistik und vor allem die dafür benötigten Daten auf dem eigenen Server vorgehalten werden oder ob ein Tool zum Einsatz kommt, was als Dienst über das Web verfügbar ist.
Google Analytics ist ein Beispiel für die Haltung der Daten auf einem entfernten Server. Das das nicht ohne rechtliche Probleme einhergeht wird auf Website Boosting gut beschrieben.
Die Alternative zu einer rein externen Anwendung ist natürlich das Installieren von Tools wie awstats und piwik auf dem eigenen Server. Diese werten die Daten aber auch wieder verschieden aus. So werten webalizer und awstats die Logdateien des Servers aus, piwik setzt hingegen auf Javascript und das Einbinden von Bildern. Und damit gibt es auch bei diesen Programmen Unterschiede, nämlich die Art und Weise, wie und welche Daten gesammelt werden.
Beim Einbinden von Javascript und externen Bildern sind die Programme vom Client abhängig. Vorteil ist, das gerade bei der Javascript Lösungen sehr granular festgestellt werden kann, was der Nutzer so alles auf der eigenen Seite macht. So genannte Heat-Maps, wie sie unter anderem auf Webmaster Pro beschrieben werden, können dank Javascript genauso erstellt werden wie eine genauere Auswertung der Ausstattung des Nutzers darüber erstellt werden kann.
Nachteil von Javascript und dem Nachladen von Bilddateien ist jedoch, das der Client es aktiv unterbinden kann. Plugins wie AdBlock Pro für den Firefox, ohne das ich auch nicht mehr online gehe, unterbinden recht zuverlässig solche Trackingversuche.
Was der Client nicht unterbinden kann sind Logeinträge. Diese kann er zwar bis zu einem gewissen Grad beeinflussen, aber Zugriffszahlen bekommen wir darüber recht zuverlässig. Hier setzen Programme wie webalizer und awstats an. Sie analysieren zyklisch die Logdateien des Servers und werten die Daten grafisch aus. Während webalizer einige Zeit nicht weiterentwickelt wurde, scheint 2008 wieder etwas Schwung in die Entwicklung gekommen zu sein, wie die “Whats New” Seite vermuten lässt. Für meinen Geschmack ist webalizer trotz seiner guten Dienste mittlerweile eher historisch interessant. Aktueller, mehr gepflegt und auch optisch – wie gesagt, meiner Meinung nach – ansprechender kommt hier awstats daher. Worin sich die Tools unterscheiden, stellt das awstats Projekt recht übersichtlich auf einer eigenen Seite gegenüber.

Installation von awstats

Um nun endlich mal etwas praktischer zu werden, schauen wir uns doch einfach mal zusammen an, wie awstats installiert wird. Voraussetzung für das Ausführen von awstats ist das Vorhandensein von Perl in Version 5.00503 oder höher. Außerdem muss der Webserver natürlich das Ausführen von Perl unterstützen, beim Apache reicht hier das Modul mod_perl aus. Unter Debian ist die Installation mit

apt-get install libapache2-mod-perl2 perl

schon erledigt. Wer es gern noch etwas ausführlicher haben möchte, kann noch

apt-get install libnet-dns-perl libnet-ip-perl libgeo-ipfree-perl

ausführen. Damit werden eventuelle Hostnamen in IPs aufgelöst und das geographische Einordnen der Besucher ist ebenfalls möglich. Beides kann später aber in der eigentlichen awstats Konfiguration konfiguriert werden.
Werfen wir noch einen Blick auf die Apache-Konfiguration. Es gibt ja schon fast Glaubenskriege, wie und wo Logdateien des Häuptlings abgelegt werden sollen. Einige Administratoren wollen ein großes Logfile, wo sie alles an einem Ort haben. Andere Serverhüter wollen die Logs in der relativen Nähe des eigentlichen Document Root vom dazugehörigen virtuellen Host und eine strikte Trennung der Logdateien pro Domain bzw. virtuellem Host.
Ich liege bei dieser Diskussion dazwischen. Ich finde schon, das Logdateien in ein separates Verzeichnis weit außerhalb der Dokumentenwurzel gehören. Aber es muss nicht eine große Datei sein, die ich durchforsten müsste, um an Daten zu kommen. Daher favorisiere ich folgende Struktur: Alle Logfiles sind unter /var/log/apache2 zu finden. Hier gibt es weiterhin 2 grundsätzlich verschiedene Logfiletypen – Zugriffs- und Fehlerlog. Diese Typen gibt es jeweils einmal pro virtuellem Host. Für den namensbasierten vhost, der zum Beispiel für diese Seite zuständig ist, sieht die Konfiguration so aus:

<VirtualHost *:80>
  # .... was auch immer da noch so konfiguriert ist
  ServerName www.holger-librenz.de
  CustomLog /var/log/apache2/access-www.holger-librenz.de.log combined
  ErrorLog /var/log/apache2/error-www.holger-librenz.de.log
</VirtualHost>

Das “combined” gibt übrigens das Logformat an. Combined ist bei den Debianinstallationen meist schon definiert und loggt die wichtigsten Daten mit. Falls der Apache beim Testen der Konfigration mittels

apache2ctl -t

meckern sollte, das er combined nicht kennt, hier die Definition aus der apache2.conf:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

Warum wir uns das Ganze anschauen? Nun, auf irgendeiner Grundlage muss awstats später die Statistiken ermitteln können. Mit den eben beschriebenen Schritten haben wir ein Access-Log definiert, welches uns schon einmal mehrere Informationen zur Verfügung stellt, mit denen awstats später arbeiten kann.

Nun aber wirklich zu awstats. Für die meisten Distributionen existieren bereits Pakete. Diese Installationsweise hat den Vorteil, das beim routinemäßigen Update des System awstats auch mit aktualisiert wird. Allerdings kommt man bei einigen Distributionen so nicht unbedingt an die aktuellste stabile Version. Gut, “Bleeding Edge” muss ja nicht immer sein. Aber neben sicherheitskritischen Bugfixes kommen meist auch kleine, aber feine Verbesserungen – sei es in Form von aktualisierten Clientidentifikatoren (also dem Auswerten des User Agents und der Schlussfolgerung auf den genutzen Browser / Dienst), einer verbesserten Geo-Lokalisierung oder oder oder. Daher habe ich mich entschlossen, awstats manuell zu installieren. Dank der Perl-Implementierung und der recht guten Dokumentation funktioniert das auch recht einfach. So genügt es folgende kleine Liste abzuarbeiten:

  1. Download der aktuellsten Version von awstats
    Beispiel auf der Konsole wäre für die aktuelle Version 6.9:

    wget "http://prdownloads.sourceforge.net/awstats/awstats-6.9.tar.gz"
  2. heruntergeladenes Archiv entpacken, zum Beispiel mit:
    tar xzf awstats-6.9.tar.gz
  3. Das Verzeichnis wwwroot, welches unterhalb des entpackten Verzeichnisses zu finden ist, an eine “zentrale” Stelle kopieren. Bei mir landet die Installation meist dort, wo die virtuellen Hosts ihre “Wurzel” haben. Dafür muss ich folgenden Kopierbefehl, für die hier beispielhaft genannte Version 6.9, benutzen:
    cp -R awstats-6.9/wwwroot /var/www/awstats

    Danach sollte der Inhalt von wwwroot direkt unter /var/www/awstats zu finden sein.

  4. Verzeichnis data innerhalb von /var/www/awstats erzeugen. Natürlich nur, wenn awstats gerade das erste Mal installiert wird. Der magische Befehl:
    mkdir /var/www/awstats/data
  5. Zugriffsrechte so setzen, das der Webserver die Perlscripte lesen und ausführen kann.
  6. Aus dem Verzeichnis, welches nach dem Entpacken entstanden ist, sollte das tools Verzeichnis noch kopiert werden. Dafür würde ich unter /opt ein Unterverzeichnis awstats erstellen und das tools-Verzeichnis dort hinein kopieren:
    mkdir /opt/awstats
    cp -R awstats-6.9/tools /opt/awstats

So, der größte Teil ist nun erledigt. Jetzt werden wir noch einige Aliase beim Apache konfigurieren, damit können wir später einfacher die Konfigurationsdateien pflegen. Dafür einfach folgende Zeilen der apache2.conf (unter Debian, manchmal heißt die Datei auch httpd.conf oder einfach nur apache.conf) hinzufügen:

    ## awstat aliases
    Alias /awstatsclasses "/var/www/awstats/classes/"
    Alias /awstatscss "/var/www/awstats/css/"
    Alias /awstatsicons "/var/www/awstats/icon/"
    ScriptAlias /awstats "/var/www/awstats/cgi-bin/"
 
    <Directory "/var/www/awstats">
        AddHandler cgi-script .pl
        Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
        AllowOverride None
        Order allow,deny
        Allow from all
    </Directory>

Der zusätzliche <Directory> Eintrag kümmert sich dann noch darum, das die Perlscripte auch ausgeführt werden. Der Zugang wird hier übrigens absichtlich von mir generell erlaubt. Die eigentliche Beschränkung werden wir nämlich später pro Host definieren.
Sollte der Apache Konfigurationstest mittels

apache2ctl -t

die Aliase nicht kennen, muss das Apache-Modul mod_alias noch installiert und geladen werden.
Wenn der Konfigurationstest problemlos durchläuft, kann der Häuptling neu gestartet werden:

/etc/init.d/apache2 restart

Da ich bis jetzt immer mit Servern zu tun hatte, die mehrere unabhängige Domains hosteten, werde ich hier auch nur diesen Fall betrachten. Andere Konfigurationen sind aber recht einfach zu adaptieren.
Weiter oben, in der allgemeinen Apache-Konfiguration, habe ich den Zugriff für alle erlaubt (allow from all). Da Statistiken nicht unbedingt für jedes Auge gedacht sind und die Domains auch nicht unbedingt die gleichen Personen zu interessieren haben, werde ich in den virtuellen Hosts, die ich in separaten Files pflege, eine HTTP Authentifizierung definieren.
Zuerst wollen wir den virtuellen Host anpassen. Die awstats-spezifischen Anpassungen sehen da bei mir immer so aus:

  <Location /awstats>
    AuthType Basic
    AuthName "Statistik-Bereich"
    AuthUserFile /path/to/htpasswd/des/vhosts
 
    Require valid-user
  </Location>

Diese Anweisungen bewirken, das beim Aufruf von /awstats eine Basic Authentifizierung stattfindet. Der Pfad “/path/to/htpasswd/des/vhosts” muss jetzt noch angepasst werden. Hier sollte die htpasswd referenziert werden, die für diesen virtuellen Host genutzt werden soll. Bei mir sähe das zum Beispiel so aus: “/var/www/holger-librenz.de/www/.htpasswd”.
Diese htpasswd kann mit folgendem Befehl einfach erzeugt werden:

htpasswd -c /var/www/holger-librenz.de/www/.htpasswd hlibrenz

Der Befehl legt die neue htpasswd Datei an (das bewirkt das -c im Befehl) und erzeugt einen Nutzer mit dem Namen hlibrenz. Das dazu gehörende Passwort wird danach zweimal abgefragt. Existiert die htpasswd bereits, funktioniert der selbe Befehl ebenso, nur das -c sollten Sie dann weg lassen, denn sonst überschreibt das Programm die gesamte Datei. Htpasswd fügt bei erneuten Aufruf, ohne -c, den Nutzer hinzu oder ändert das Passwort des Nutzers, wenn der angegebene Nutzername bereits existiert.

So, nun muss awstats noch wissen für was es Statistiken erzeugen soll. Dazu werden bei awstats pro Domain, für die es arbeiten soll, eigene Konfigurationsdateien gepflegt. Diese werden in einem bestimmten Verzeichnis gesucht. Dieses ist im Normalfall /etc/awstats. Wenn das Verzeichnis noch nicht existiert, wäre jetzt ein guter Zeitpunkt es zu erstellen:

mkdir /etc/awstats

In dem Verzeichnis, welches aus dem heruntergeladenen Archiv entpackt wurde (im Beispiel hier immer awstats-6.9) , gibt es eine Vorlage für die Konfigurationsdatei. Die Datei heißt “awstats.model.conf” und sollte, der Übersichtlichkeit halber, in das eben angelegte Verzeichnis kopiert werden. Nun geht es ans eingemachte. Awstats verbindet die Domain mit der zu lesendenen Konfigurationsdatei mittels des Dateinamens. Dieser setzt sich wie folgt zusammen:

awstats.<domain>.conf

Der Domainname sollte dabei auch eventuelle Subdomains, also zum Beispiel www oder extranet, beinhalten. Für meine Domain ist folgender Dateiname notwendig:

awstats.www.holger-librenz.de.conf

Bleiben wir doch einfach bei dem Beispiel. Erstellen wir für meine Seite die Konfigurationsdatei aus dem Modell, was uns awstats mitgeliefert hat. Führen dazu im Verzeichnis /etc/awstats folgenden Befehl aus:

cp awstats.model.conf awstats.www.holger-librenz.de.conf

Dann können wir die Datei bearbeiten. Der erste Wert, den ich für mich anpassen muss, ist der Pfad zur Logdatei des Apache. Dazu muss der Wert LogFile berichtigt werden. Für meine Domain und die dahinter liegende Verzeichnisstruktur ergibt sich folgender Wert:

LogFile="/var/log/apache2/access-www.holger-librenz.de.log"

Die Werte für LogType, LogFormat und LogSeparater können, wenn das “combined” Log genutzt wird, einfach so belassen werden. Der nächste Wert, den wir ändern, definiert den Seitennamen. Dafür muss der Wert SiteDomain gesetzt werden. Dieser sollte die Hauptdomain beinhalten. Für mich wäre das also wie folgt:

SiteDomain="www.holger-librenz.de"

Da aber viele Seiten auch Aliasnamen besitzen, kann das natürlich auch awstats mitgeteilt werden. Dafür kann der Wert HostAliases gesetzt werden. Dieser enthält, getrennt durch ein Leerzeichen, die Aliasnamen und kann auch reguläre Ausdrücke beinhalten. Für meine Domain gibt es momentan “nur” die Kombination mit und ohne www. Da es aber ggf. auch andere Subdomains geben kann, setze ich einen regulären Ausdruck der das beschreibt:

HostAliases="REGEX[holger-librenz\.de$]"

Soweit zu den Domain-spezifischen Angaben. Jetzt kommen wir zu den Angaben, die awstats zum Arbeiten benötigt. Diese können aber auch der allgemeinen Performance zuträglich sein. Das zeigt auch der erste Wert. Der Wert DNSLookup legt fest, ob zu den IP Adressen, von welchen die Seite aufgerufen wurde, die Hostnamen ermittelt werden sollen. Das kann entweder ganz deaktiviert, nur aus dem lokalen DNS Cache oder immer geschehen. Schön ist natürlich, wenn wir die Hostnamen angezeigt bekommen. Wenn die eigene Seite allerdings ordentlich frequentiert ist, kann das sehr schnell zu ordentlich spürbaren DNS Abfragen führen. Bis es soweit ist, können wir das komplette Auflösen aktivieren. Ich freue mich aber schon auf den Tag, wo ich den Wert anpassen muss.

DNSLookup=1

So, jetzt kommen wir zu einigen organisatorischen Werten. Damit awstats weiß, wo es Dateien findet und wo es andere evtl. ablegen soll, wird in der Konfiguration festgehalten, was im Filesystem so für awstats bereit gehalten wird.
Zu allererst legen wir den Ort fest, wo awstats die Datenbanken mit den ermittelten Zugriffszahlen ablegt und findet. Das wird über die Option DirData erledigt. Die Angaben können entweder absolut, also von der Wurzel des Dateisystems aus, oder relativ zur awstats.pl Datei geschehen. Ich habe mich für die relative Angabe entschieden:

DirData="../data"

Diese Einstellung beschreibt nun das data-Verzeichnis, welches wir weiter oben angelegt haben.
Die noch folgenden Werte passen wir einfach mal so an:

DirCgi="/awstats"
DirIcons="/awstatsicons"

Hier wird definiert, das die weiter oben definierten Aliase genutzt werden sollen.

Jetzt ist es auch gleich geschafft. Zwei Werte sind noch Pflicht, nämlich das Setzen der Rechte auf das Aktualisieren der Datenbank über das Web und den Zugriff auf die Jahresstatistik via Kommandozeile und via Web.
Das erste Recht, also ob die Datenbank über das Web aktualisiert werden darf, unterdrücken wir mit folgendem Wert:

AllowToUpdateStatsFromBrowser=0

Damit kann uns der Nutzer nicht den Tag vermiesen, in dem er bei stark frequentierten Seiten immer wieder auf “Neu generieren” klickt und damit den Server beschäftigt. Das Aktualisieren werden wir völlig automatisiert über Cronjobs erledigen. Wenn Sie allerdings keine Cronjobs zur Verfügung haben, sollten Sie den Wert auf 1 setzen oder einmal einen Blick auf cron-job.org werfen.
Das zweite Recht, nämlich das Auswerten für ein gesamtes Kalenderjahr, können wir mit folgendem Wert sowohl für die Kommandozeile (CLI) als auch für das Web (CGI) erlauben:

AllowFullYearView=3

Es gibt noch einige weitere Einstellungsmöglichkeiten. Diese sind aber auch in der gut kommentierten Konfigurationsdatei als “optional” gekennzeichnet. Einzig eine Option möchte ich noch kurz vorstellen. Und zwar soll das Aufrufen der Statistiken nur für angemeldete Nutzer möglich sein. Den Status “angemeldet” hat ein Nutzer, der erfolgreich eine HTTP Authentifizierung hinter sich gebracht hat. Um awstats dazu zu bringen, das es nur berechtigten Usern seine Wahrheiten offenbart, setzen wir einfach AllowAccessFromWebToAuthenticatedUsersOnly auf 1:

AllowAccessFromWebToAuthenticatedUsersOnly=1

So. Nun ist auch awstats konfiguriert. Natürlich gibt es da noch verschiedene weitere Schräubchen, die das Verhalten verändern / verbessern, aber für die ersten Aufrufe sind wir nun gewappnet. Ob auch wirklich alles geklappt hat werden wir jetzt sehen. Wir rufen jetzt nämlich das erste Mal awstats auf:

/opt/awstats/tools/awstats_updateall.pl now -awstatsprog=/var/www/awstats/cgi-bin/awstats.pl

Sollten Probleme in der Konfiguration oder bei den Dateirechten bestehen, sollte das in den Ausgaben zu sehen sein.

Ok, wäre das auch erledigt. Jetzt legen wir noch einen Cronjob an. Dafür habe ich eine kleines Shellscript geschrieben:

#!/bin/sh
CUR_DIR=`pwd`
 
cd /var/www/awstats/cgi-bin
 
/opt/awstats/tools/awstats_updateall.pl now -awstatsprog=/var/www/awstats/cgi-bin/awstats.pl > /dev/null
 
cd $CUR_DIR

Das Skript habe ich in /opt/awstats/cron/update-all.sh gespeichert. Das Unterverzeichnis cron muss natürlich vorher angelegt und das Skript ausführbar gemacht werden.
Dieses Skript rufe ich dann über den Cron 2 mal in der Stunde auf und zwar immer zur vollen und zur halben Stunde. Dafür steht in der neuen Dateien /etc/cron.d/awstats:

##
## updates all awstats statitistics
##
0,30 * * * * root /opt/awstats/cron/update-all.sh

Ok. Jetzt kann es los gehen. Rufen Sie Ihre awstats Installation mal über den Webbrowser auf. Zu finden ist es unter http://<ihre.konfigurierte.domain>/awstats/awstats.pl.

Gehts nicht noch schöner?

Im Gegensatz zu webalizer ist die awstats Oberfläche schon sehr ansehnlich und übersichtlich geworden. Wer es aber noch einen Tick “schicker” will, sollte sich das noch rechte junge Projekt jawstats ansehen. Das Projekt nutzt PHP, Javascript und Flash um die statistischen Werte von awstats zu visualisieren und als kleines Schmankerl ist die Oberfläche von jawstats über Templates anpassbar.

Wo Licht ist, fällt aber auch bekanntlich Schatten. So möchte ich nicht unerwähnt lassen, dass das Projekt noch in der frühen Entwicklungsphase steckt. Die Konfiguration ist leider noch nicht wirklich “massentauglich” und die eine oder andere Einstellung und Programmierung sollte noch angepasst werden. Aber ich bin mir sicher, das bei reger Beteiligung und Rückmeldung von Nutzern jawstats einen festen Platz finden wird.

Installieren lässt es sich wirklich, wie auf der Webseite auch angepriesen, simpel. Sie brauchen lediglich einen Webserver und PHP. Sind die Voraussetzungen erfüllt, können Sie das Paket herunterladen. Entpacken Sie den Inhalt in ein Verzeichnis, was für den Webserver erreichbar ist:

tar czf jawstats-<version>.tar.gz -C <Zielverzeichnis>

Dann kopieren Sie die Datei config.dist.php und benennen die neue Datei config.php:

cp config.dist.php config.php

Ist auch diese Aufgabe gemeistert, geht es ans Editieren der eben erstellten Konfigurationsdatei. Wir die Dateiendung bereits vermuten lässt, handelt es sich bei der Datei um ein PHP Skript. Um zum Beispiel die Daten für holger-librenz.de ein wenig aufzuwerten, muss der Inhalt wie folgt aussehen:

<?php

  // core config parameters
  $sDefaultLanguage      = "de-DE";
  $sConfigDefaultView    = "thismonth.all";
  $bConfigChangeSites    = true;
  $bConfigUpdateSites    = true;
  $sUpdateSiteFilename   = "xml_update.php";

  // individual site configuration
  $aConfig["holger-librenz.de"] = array(
    "statspath"   => "/var/www/awstats/data/",
    "updatepath"  => "/var/www/awstats/cgi-bin/awstats.pl",
    "siteurl"     => "http://www.holger-librenz.de",
    "sitename"    => "",
    "theme"       => "default",
    "fadespeed"   => 250,
    "password"    => "very secret password",
    "includes"    => "",
    "language"    => "de-DE"
  );

Die ersten Variablen (unter “core config parameters”) geben Standardwerte an. Hier lege ich fest, das ich gern Deutsch als Standardsprache, die Monatsübersicht bei Start sehen möchte und das ein Aktualisieren und evtl. Seitenwechseln möglich ist.

Danach folgt die eigentliche Konfiguration der Seite. Der Array-Feldschlüssel “holger-librenz.de” (Zeile 11) wird für die Anzeige genutzt. Die enthaltenen Werte im Array bedeuten folgendes:

statspath
Der absolute Pfad zu den Daten.
updatepath
Der absolute Pfad zur awstats.pl Datei
siteurl
Das ist die Domain, die als Hauptdomain bei awstats in der Konfiguration genutzt wurde und wonach auch die awstats-Konfigurationsdatei benannt wurde.
sitename
Ein beschreibender Titel für die URL
theme
Hier kann der gewünschte Theme, also das Aussehen, bestimmt werden. Mit ausgeliefert wird der “default” Theme.
fadespeed
Beeinflusst die Geschwindigkeit, in der Grafiken (visuell) in neue Zustände versetzt werden.
password
Passwort, welches für das Aktualisieren der Werte auf Knopfdruck benötigt wird.
includes
Diese Option bietet die Möglichkeit, zusätzliche PHP Dateien einzubinden. Die Dateien werden als kommaseparierte Liste ohne Freizeichen erwartet.
language
Die Sprache, die standardmäßig für die Auswertung dieser Domain genutzt werden soll.

Leider existiert noch keine ausführliche Dokumentation, aber zumindest die Webseite verspricht hier Nachbesserung. Mit den wenigen Schritten, die Sie bis jetzt befolgt haben, können Sie aber schon einmal einen ersten Eindruck erhalten.

Jetzt erhalten wir Antworten auf die oben genannten Fragen. Wie Sie die einzelnen Werte richtig lesen und was es noch an Möglichkeiten gibt awstats zu nutzen erfahren Sie in der Dokumentation des Projektes.

{ 5 } Comments

  1. Christian Vogel | 8. Juni 2009 um 16:52 | Permalink

    http://www.holger-librenz.de/2009/02/webseitenstatistiken/

    Hallo,

    ich habe mir auf meinem Rechner zu Testzwecken einen Apacheserver installiert. Dieser läuft und Awstats ist bereits funktionsfähig integriert.

    Nach Ihrer Anleitung habe ich nun auch Jawstats integriert, bekomme allerdings keine Statistik angezeigt.

    Ich bin noch ziemlich neu auf dem Gebiet und hoffe Sie könnne mir da weiterhelfen.

    Wenn ich die Statistik von Awstats bekommen möchte muss ich folgenden Link aufrufen:
    http://localhost/cgi-bin/awstats.pl?config=localhost

    Welchen link muss ich aufrufen oder was muss ich tun, damit ich die Anzeige von Jawstats im Browser sehen kann?

    Die Konfiguration meines config.php skriptes sieht wie folgt aus:
    “C:/temp/xampp/cgi-bin/data/”,
    “updatepath” => “C:/temp/xampp/cgi-bin/awstats.pl”,
    “siteurl” => “http://localhost/”,
    “sitename” => “localhost”,
    “theme” => “default”,
    “fadespeed” => 250,
    “password” => “test”,
    “includes” => “”,
    “language” => “de-DE”
    );

    ?>

    Ich hoffe Sie können mir helfen.

    Mit freundlichen Grüßen,
    Christian Vogel

  2. Holger Librenz | 8. Juni 2009 um 17:53 | Permalink

    Hallo Herr Vogel.
    Ist das wirklich die komplette Konfigurationsdatei? Dann ist ihr Konfigurations-Array defekt. Es sollte ungefähr so aussehen:

    <?php
    // core config parameters
      $sDefaultLanguage      = "de-DE";
      $sConfigDefaultView    = "thismonth.all";
      $bConfigChangeSites    = true;
      $bConfigUpdateSites    = true;
      $sUpdateSiteFilename   = "xml_update.php";
     
      // individual site configuration
      $aConfig["localhost"] = array(
        "statspath"   =>  "C:/temp/xampp/cgi-bin/data/",
        "updatepath"  => "C:/temp/xampp/cgi-bin/awstats.pl",
        "siteurl"     => "http://localhost",
        "sitename"    => "localhost",
        "theme"       => "default",
        "fadespeed"   => 250,
        "password"    => "test",
        "includes"    => "",
        "language"    => "de-DE"
      );
    ?>

    Wie die URL lautet hängt von Ihrer Installation ab. Wenn Sie es im DocumentRoot als “jawstats” entpackt haben, lautet die URL http://localhost/jawstats.

    Sie sollten außerdem oben den Link “Seite aktualisieren” aufrufen und das hinterlegte Passwort (hier ‘test’) eingeben, damit die Statistikwerte geladen werden.

    Gruß
    Holger Librenz

  3. Chr Vogel | 9. Juni 2009 um 06:44 | Permalink

    Hallo Herr Librenz,

    erst einmal vielen Dank für die schnelle Antwort.

    Irgendwie bekomme ich es noch nicht ganz hin.

    ich habe jawstats unter “c:\temp\xampp\jwastats\” entpackt. Was müsste ich jetzt unter siteurl eingeben und im browser?

    ich bekomme immer den 404 errorcode – object not found :(

    Mit freundlichen Grüßen,
    Christian Vogel

  4. Chr Vogel | 9. Juni 2009 um 06:52 | Permalink

    Meine awstats config datei heißt “awstats.localhost.conf”. Daraus resultieren sollte sich die siteurl im script der config.php “http://localhost/” ergeben, oder?

    oder muss hier auch noch “/xammp/jawstats/” stehen?

    Mit freundlichen Grüßen,
    Christian Vogel

  5. Chr Vogel | 9. Juni 2009 um 07:29 | Permalink

    Problem hat sich mittlerweile gelöst. Ich hatte die documentroot im Xampp anders als ich dachte xD.

    Vielen Dank trotzdem für die Hilfe!!

Kommentar verfassen

Dein E-Mail wird nicht veröffentlicht oder weitergegeben. Pflichtfelder sind mit * markiert.