Bye-bye, webserver-basierte Statistikauswertung.

Seit den Anfangstagen von netplanet habe ich in Sachen Webserver-Auswertung fast durchgehend serverseitige Anwendungen am Start und immerhin seit 2004 den Webalizer. Webserver-seitige Statistiken haben den großen Vorteil, dass das Schreiben von Logfiles nahezu geräuschlos im Hintergrund des Webservers vonstatten geht und eine serverseitige Auswertung einst auch sehr lässig anzuschauen war.

Das funktionierte so lange, bis Weblogs und Kommentar-Spam kamen. Seit diesem Zeitpunkt beschäftigt sich früher oder später ein Webserver mit einem zu hostenden Weblog weitgehend nur noch mit Kommentar-Spam. Und „weitgehend“ ist ernst gemeint, denn als ich spaßeshalber einmal einen halben Tag dazu gebracht habe, die echten Apache-Weblogs nach eindeutigen Spuren von Versuchen, Kommentar-Spam abzulassen, durchforstete, traf mich der berühmt-berüchtigte Schlag – ich hätte eher nach Einträgen suchen sollen, die offensichtlich nicht Spam-Versuche sind, denn während dieses Weblog in der Woche normalerweise 3.000 bis 5.000 Pageviews zustandebringt, waren die Seitenaufrufe im Serverlog für die gleichen Zeiträume rund um den Faktor 10 höher. Wir reden davon, dass auf meinem Webserver für alle hier gehosteten Weblogs rund 90 % aller Seitenaufrufe purer Müll sind. Und ja, in dieser Rechnung ist berücksichtigt, dass Pageviews nicht Hits sind (Grafiken, RSS-Feed-Aufrufe und sonstige Dateien habe ich nicht mitgezählt). Solche Erkenntnisse erden. 🙁

Nun gibt es zwar für alle gängigen Web-Statistikprogramme auch mehr oder weniger ausführliche Filtermöglichkeiten, mit denen sich bekannte IP-Adressen von Kommentar-Spammer ausfiltern lassen, ebenso bestimmte Muster in den URL-Aufrufen. Nur: Was nützt diese Arbeit, wenn sich gerade die Liste der IP-Adressen ständig ändert? Schon zu meiner Zeit als Sysadmin bei einem ISP habe ich sehr schnell gelernt, dass die Pflege einer Installation einer Web-Statistik ein höchst undankbarer Job ist und einer gewaltigen Feineinstellung bedarf, um mit der Berechnung nicht den gesamten Server auszulasten. Bedanken tut sich für die Arbeit maximal der Chef, die meisten Kunden haben nicht ansatzweise eine Ahnung davon, was da im Hintergrund passieren muss, um eine aktuelle Web-Statistik zu produzieren.

Noch fataler wird es, wenn man der eigene Chef ist und man sich dann auch die Frage stellen darf, warum man eigentlich gegen eine elend mächtige Spammer-Front anzukämpfen versucht. Diese Frage habe ich vor einigen Wochen damit beantwortet, dass ich alles netplanetare nebenbei von unserer unternehmenseigenen Piwik-Installation auswerten lasse, also einem System, dass nach dem „Google-Analytics-Prinzip“ arbeitet: Im Seiten-Template meines Weblogs steckt ganz unten im Seitenfuß ein kleines Code-Schnipsel, der einen Aufruf in der Piwik-Installation erzeugt und alle notwendigen Aufrufparameter übermittelt.

Piwik bringt gleich eine ganze Reihe von Vorteilen mit: Die Spam-Aufrufe werden nicht mitgezählt, zudem pflegt die Piwik-Community solche Dinge wie Browser-, Betriebssystem- und Providerlisten. Alles Dinge, mit denen man sich einst mal gern beschäftigt hat. In der Zwischenzeit macht das alles nur noch wenig Spaß. Und noch weniger Sinn.

Update zu den Logfile-Manipulationen von 1&1.

Auf meine Anfrage hin kam vom herkömmlichen 1&1-Support nach 1,5 Tagen dann auch eine Antwort:

“Aus Datenschutzgründen werden die Log-Dateien der vergangenden Wochen von uns anonymisiert. Nur die Log-Dateien der aktuellen Woche werden unberührt gelassen, damit Sie Ihre Auswertungen anfertigen können.”

So weit bin ich dann auch selbst schon gekommen, auch wenn es nach wie vor eine Reihe von Fragen nicht beantwortet:

  1. Warum hat man die Kundschaft nicht vorher informiert?
  2. Warum hat man offensichtlich ein Datenschutzproblem, wo man doch die Logfiles sowieso nach sechs Wochen löscht?
  3. Wer hat diese doofe Idee erdacht, dass die Logs der aktuellen Woche noch nicht anonymisiert sind und man das als Entgegenkommen an die Kundschaft verkaufen könnte? Das Problem hierbei ist nämlich, dass war die Logfiles der aktuellen Woche vorliegen, aber ausgerechnet das letzte Logfile, nämlich das des Sonntages, kaum so schnell gesichert werden kann, da nämlich einige Minuten später ein Automatismus beginnt, die Logfiles der aktuellen Woche zusammenzufassen (und hier dann wohl auch zu anonymisieren).

Auf eine Nachfrage hin kam dann das hier:

“Leider ist es nicht möglich, die Änderungen zurückzunehmen, bzw. Ausnahmen zu machen. Ich habe Ihren Verbesserungsvorschlag jedoch an zuständige Stelle weitergeleitet.”

In meinem Fall nicht mehr nötig.

1&1 manipuliert Webserver-Logfiles.

Wer bisher von der Möglichkeit Gebrauch gemacht hat, sich in einem 1&1-Webhosting-Paket die automatisch bereitgestellten Webserver-Logfiles regelmäßig herunterzuladen und diese in einem eigenen Statistikprogramm auszuwerten, darf sich vermutlich kurzfristig einen neuen Webhoster suchen.

Denn 1&1 ist tatsächlich seit Anfang letzte Woche auf die bescheuerte Idee gekommen, in die Logfiles seiner Kunden hineinzupfuschen. Eine Zeile gefällig? Bitte sehr:

70.50.191.x – – [18/Jan/2010:00:02:28 +0100] „GET / HTTP/1.1“ 200 69250 blog.netplanet.org „-“ „Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en)“ „-„

Das Problem offenbart sich schon ganz am Anfang einer jeden solchen Zeile, denn die erste Angabe ist die IP-Adresse des Absenders, der in meinem Webhosting-Paket eine Aktivität verrichtet. Und diese IP-Adresse manipuliert 1&1 nun so, dass im letzten Quad nicht mehr eine Zahl steht, sondern nur noch ein „x“. Offensichtlich anonymisiert.

Das Problem hierbei ist nur, dass ich mit so einem Logfile nichts mehr sinnvolles anfangen kann, denn im Normalfall löst ein Statistikprogramm IP-Adressen von Absendern zu ihren Hostnamen auf, um so beispielsweise feststellen zu können, wie viele Besucher von T-Online etc. zugegriffen haben. Mit so einer manipulierten IP-Adresse fällt das nun flach.

Erheblich bedenklicher ist, was sich 1&1 eigentlich dabei gedacht hat, denn die Logfiles meines bezahlten Webhosting-Paketes entstehen durch das Bereithalten von meinen Inhalten, gehören also definitiv mir und nicht 1&1! Und diese Manipulation ohne meine Genehmigung vorzunehmen und über diesen drastischen Eingriff auch (wie üblich) überhaupt nicht zu informieren, halte ich für ein herbes Stück.

Ich habe mal eine Mail an den Support losgelassen mit der Bitte, diese Manipulation rückgängig zu machen. Mal sehen, was da für eine Erklärung kommt.

Zugriffsstatistiken.

Gestern habe ich mich endlich wieder einmal um die Webstatistiken von netplanet (also sowohl von den Lexikonseiten, als auch von diesem Blog) gekümmert und das aktuelle Release des Webalizer-Forks von Stone Steps heruntergeladen und installiert. Stone Steps ist eine kleine, kanadische Firma, die sich vor Jahren erbarmt hat, den damals brachliegenden Code des originalen Webalizers aufzuräumen und weiter zu entwickeln. Und das ist ihnen auch gelungen, denn dieser Fork ist der beste und gepflegteste von allen und übertrifft den originalen Webalizer, der nun seit letztem Dezember auch wieder gelegentlich gepflegt wird, um Universen.

Nachdem das getan war, habe ich der frischen Installation mal meinen Bestand an alten netplanet-Logfiles zum Fressen daherdrapiert und nach rund zwei Stunden waren fünf Jahre netplanet-Zugriffe von Lexikon und knapp zwei Jahre Zugriffe dieses Blogs verwurstet. Der alte Käse ist dabei gar nicht so interessant, eher erschüttert haben mich die aktuellen Werte der letzten Monate. In der Zwischenzeit ist es nämlich so, dass das Blog in praktisch allen Vitalwerten das Lexikon schon längst hinter sich gelassen hat. Hier mal die Werte vom März 2009 im direkten Vergleich:

Lexikon Blog
Hits 1.017.000 680.000
Pageimpressions 72.300 176.000
Übertr. Dateien 933.000 630.000
Datenverkehr 2,7 GB 6,5 GB

Die höhere Zahl von Hits und übertragenen Dateien vom Webserver des Lexikons ergeben sich durch den Umstand, dass eine Lexikonseite deutlich mehr Grafikelemente lädt, als im Blog. Das könnte man sicherlich optimieren, wenn ich mich endlich mal dazu aufraffen würde, das Lexikon auf ein CMS umzustellen.