Torsten Weber’s Blog

Logbücher zu analysieren macht Spaß. Zum einen, weil man sieht, wie vorsintflutartig auch erfolgreichste Suchmaschinen prinzipiell arbeiten und so Suchanfragen im Blog landen, die eine ganz andere Semantik haben. Anderseits lässt sich nachverfolgen, welche Blogeinträge am häufigsten gelesen werden, wo man z. B. einen "Schlüsselwort-Treffer" für die Suchmaschinen gelandet hat. Sehr erschreckend wiederum ist, dass Öffentliche & Unternehmen IP-Adressen den Mitarbeiternamen bzw. Räumlichkeiten zuordnen:

• mitarbeitername.unternehmenoderoeffentliche.de
• raum.unternehmenoderoeffentliche.de

So lassen sich ungewollt leicht Profile erstellen, wer was mit welchen Häufigkeiten liest. Freunde, Feinde, werden so transparent – der pure Daten-GAU. Zugriffe ins Internet sollten doch mindestens über einen Proxy geleitet oder die IP-Adresse nicht mit dem Namen verknüpft werden?

Eine Analyse von Logbüchern kann dabei entweder über eine in den meisten Blogsystemen enthaltene Funktionalität erfolgen oder aber über Anwendungen für die vom Server erzeugten Logbücher. Eine solche Anwendung ist LogParser, welche Scott Hanselman einsetzt und für die es einen grafischen Aufsatz namens Visual LogParser gibt.

Das nachfolgende Bild zeigt, wie Analysen in DasBlog aussehen. Nicht intuitiv, smart oder sortierbar.

Das nachfolgende Bild zeigt, wie eine Suchabfrage bei Visual LogParser aussieht. Das Besondere ist also, dass Abfragen in SQL-Syntax auf Logbücher abgefeuert werden können.

So lassen sich exakte Suchabfragen absetzen und nur die entsprechenden Treffer werden angezeigt. Das nachfolgende Bild zeigt das Ergebnis der Suchabfrage "liste jede Abfrage einer ASPX-Datei, die jeweils von *.name.de kam, auf".

Das sind bisher damit zwei Werkzeuge. Eines, DasBlog-Funktionalität, was grob den Verlauf des Erfolgs eines Blogs anzeigt, eines, welches präzise Suchabfragen ermöglicht, aber für große Datenmengen nicht wirklich gebrauchbar ist. Finde ich zumindest. Scott Hanselman meint zu LogParser^{1, 2}:

... a super-psycho command-line tool, and we all know how I love those. But, it's also got a COM Interface so it programmable/scriptable as well. ...

Quelle: hanselman.com, Parsing my IIS Log Files with LogParser 2.2 to learn more about Blogs stats from NewsGator and NewsGatorOnline

Ich möchte es dagegen lieber smart. Ich möchte eine unmittelbar verfügbare Analyse. Der andere Weg ist Logbücher herunterzuladen, eine Anwendung zu starten, sich Gedanken über Suchabfragen zu machen, Logbücher zu parsen (+ zu warten) und eventuell noch einen grafischen Aufsatz dafür zu benötigen. Das kostet Zeit, viel zu kostbare Zeit. Welche Lösungen gibt es also für einen automatischen Ansatz?

Nihuo Web Log Analyzer

Nihuo Web Log Analyzer kann ich als Werkzeug nur empfehlen. Es kostet nicht die Welt, bringt viel Funktionalität mit und reicht bestimmt für die meisten Betreiber von Blogs & Webseiten. aus.

Was ist alles dabei? Neben Statistiken wie die Darstellung aller Zugriffe unterteilt in Gesamt, Normal, Spider und Gestohlen, geht es weiter mit Statistiken wie "Anzal Seitenaufrufe pro Besucher" oder "Besuche nach Tageszeit" bis hin zu "Aktivität pro Tag". Dieser Blog wird beispielweise am häufigsten am Mittwoch und am wenigsten am Samstag gelesen. In der Zeit von 8 - 15 Uhr finden wiederum die meisten Zugriffe statt, mit den zwei Spitzenwerten um 9 und 12 Uhr. Um das mit einem Werkzeug wie einem Parser herauszubekommen, geht sicherlich einige kostbare Zeit verloren. Als Kritikpunkt könnte man anführen, dass die Statistiken keinen interessieren. Das könnte sein, aber sie sind nur ein kleiner Teil der Möglichkeiten zur Analyse mit Nihuo Web Log Analyer.

Interessant sind z. B. die Verweise: Von welchen Domains kommen die meisten Links; von welchen Seiten dieser Domains kommen sie. So kann beispielsweise ermittelt werden, woher Traffic – Stichwort gestohlene Objekte – kommt. Bei mir sorgte Anfang Oktober, siehe Gesamtstatistik in der Nähe vom 19.10., ein Bild von einer Kaffeetasse, die für Kaffee und aber auch als Aschenbecher verwendet wird, für hohen externen Traffic. Das Bild hat sich fast geradezu viral in Gästebüchern vermehrt – einmal umbenannt, von der Indexierung bei Suchmaschinen ausgeschlossen und schon ist das Problem gelöst.

So sieht eine Gesamtstatistik von Nihuo Web Log Analyzer aus. Seit der Geburtsstunde meines Blogs am 02.05.2007 hat sich viel getan. Konkrete Zahlen sagen hier nichts, darum habe ich sie weggelassen.

Weitere sinnvolle Übersichten und Analysen sind z. B.

• die meist gelesenen Seiten (die könnte man z. B. mit Inhalt ausbauen, besonders pflegen etc.)
• die Wege, über die Traffic auf den Blog, die Webseiten kommt (z. B. häufigste Suchanfragen)
• Top Fehler (404-Fehler, fehlerhafte Links, Grafiken etc.)
• andere Clientfehler wie z. B. fehlgeschlagene Login-Versuche, Serverattacken

Die Analysen können dabei

• Jährlich,
• Monatlich,
• Wöchentlich und
• Täglich

skaliert werden. Wöchentlich und Täglich sollten dabei für die meisten Anwender nicht notwendig sein.

Letztendlich steht eine ganze Reihe Analysen zur Verfügung, von denen einige standardmäßig nicht mal aktiviert sind. Die Analysen können mit Filtern und Tracking verbunden werden.

Sehr gut ist, dass die Logbücher der IIS in eine eigene Datenbank geschrieben werden und prinzipiell so dann in bestimmten Zeitabständen auch automatisiert gelöscht werden können.

Mit Nihuo Web Log Analyzer können Analysen auf Bedarf erstellt werden. Besser ist aber, die Erstellung dieser in einen Zeitraum zu legen, in dem es potentiell wenig Traffic gibt – z. B. nachts um 4 Uhr. Denn sowohl die Ersterstellung der Analysen als auch Aktualisierung erzeugt auf Server bzw. Rechner viel Last, auch wenn nur für einige Minuten pro einzelnem Projekt (Webseite). Das für eine Automatisierung Nihuo Web Log Analyzer als Service gestartet werden kann, ist offensichtlich.

Dabei ist zu beachten, dass bei Analysen bei täglichen Aspekten Nihuo Web Log Analyzer nichts verkehrt macht, sondern am 14.12.2007 bei der Aktualisierung der Analysen um 4 Uhr auch nur 4 von 24 Stunden einbezogen werden. Vielleicht kommt ja in einer nächsten Version "nur komplette Tage" als Option.

Wird  ein Crossposting verwendet, muss unter Site URL in den Projekteigenschaften die Adresse davon eingetragen werden. Ansonsten wird es als externer Traffice erkannt.

Um es jetzt gegenüber Scott Hanselmans Lösung à la VisualLogParser bequem zu haben, muss nur noch bei jedem Projekt eingestellt werden, dass die Ergebnisse unterhalb jeder Webseite gespeichert werden.

Also z. B. domain.de/stats und dieses Verzeichnis sollte logischerweise noch mit einer Authentifizierung gesichert werden. Schon reicht ab sofort ein einziger Login der z. B. mit RoboForm ebenfalls noch automatisiert werden kann. Das ist User Experience und smart.

¹ VisualLogParser ist der grafische Aufsatz für LogParser
² vgl. VisualLogParser, IIS Logs – Anzahl heruntergeladene Dateien, Datenverkehr ermitteln