“Webserver haben die Aufgabe, auf Anfragen von Web Clients Dateien (HTML- und sonstige Dateien) zur Anzeige zur Verfügung zu stellen. Um die Zugriffe auf die bereitgestellten Dateien nachvollziehbar zu machen, zeichnet jede Web-Server-Software Anfragen von Clients in einem oder mehreren Logfiles (i. d. R. Textdateien) auf.” In den Logfiles sind also die gesamte Kommunikation des Servers mit dem Internet, insbesondere die eingegangenen Anfragen und die übertragenen Inhalte, protokolliert.

Grundlage: Die Datenübertragung im WWW

Die Datenübertragung im WWW basiert auf einem Client-Server-Ansatz. Alle vom Besucher initiierten Aktionen werden von seinem Computer (Client) in Anforderungen (Requests) umgewandelt und an einen anderen Computer, z.B. einen Webserver weitergeleitet, der die angeforderten Ressourcen liefert (Response).

HTML-Dokumente werden mittels HTTP (Hypertext Transfer Protocol) an den Client übertragen. Das HTTP ist ein verbindungsloses Protokoll, bei dem die Datenpakete aus Performancegründen einzeln versandt werden. Die Verbindung zwischen Client und Server wird nach jeder Ãœbertragung wieder getrennt, weshalb ein Logfile keinen zusammenhängenden Nutzungsstrom, sondern lediglich eine Auflistung aller bearbeiteten Anfragen zeigt. So resultiert der Aufruf einer einzigen HTML-Seite in der Regel in zahlreichen Logfile-Einträgen, wobei jede eingehende Anfrage (Dokument, Bilder, CSS-Dateien, etc.) in einer neuen Zeile des Logfiles gespeichert wird. Dies hat zur Folge, dass Logfiles immense Ausmaße annehmen können.

Formate und Inhalte von Webserver-Logfiles

Es existieren derzeit etwa 30 standardisierte Logfile-Formate, die mehr oder minder weit verbreitet sind. Die Formate unterscheiden sich in den Angaben, die der Server pro Zeile (Hit) festhält. Felder zu Anfragen, die in einem bestimmten Log-Format festgehalten werden könnten, aber nicht verfügbar sind, werden in den Logfiles mit einem „-“ gekennzeichnet.

Im Allgemeinen werden folgende Werte in den Logfiles festgehalten:

• der Zugriffszeitpunkt
• die angeforderten Inhalte
• der zugreifende Browser
• die Adresse des Clients
• eventuell auftretende Fehler.

In Anlehnung an diese Inhalte haben sich vier Grundformen herausgebildet: Access Log, (Browser) Agent Log, Referrer Log und Error Log. Diese Dateien können je nach Systemkonfiguration getrennt oder in Kombination angelegt werden.

Als Standardformat des Access Log wurde das Common Logfile Format (CLF) entwickelt. Das Combined Logfile-Format (oder auch Extended Common Logfile Format – ECLF) erweitert das CLF um die Inhalte des Agent- und Referrer Log. Die folgende Abbildung zeigt zusätzlich die Unterteilung der Inhalte in Grunddaten über den Besucher und Interaktionsdaten über die ausgelieferten Inhalte.

 

 

Eine Zeile aus dem Log des Formats ECLF könnte zum Beispiel so aussehen:

 88.217.105.216 - - [24/Jul/2008:12:31:57  +0200]
 "GET /wp-admin/ HTTP/1.1" 200 50484 "http://www.georg-weidner.de/"
 "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.1)  Gecko/2008070208 Firefox/3.0.1"

 

Die einzelnen Bestandteile (Felder eines Webserver-Logfiles des Formats ECLF) sind:

 

Eine Analyse der Daten zeigt, dass am 24 Juli 2008 um 12:31 Uhr und 57 Sekunden das Verzeichnis wp-admin von der IP-Adresse 88.217.105.216 aufgerufen wurde. Dabei fanden weder eine Clientidentifizierung noch eine Clientauthentifizierung statt, weshalb die entsprechenden Felder frei geblieben sind (mit einem „-“ gekennzeichnet). Das transferierte Datenvolumen belief sich auf 50.484 Bytes. Am Status-Code 200 ist zu erkennen, dass die Übertragung erfolgreich war.

Im Referrer- und User-Agent-Zusatz ist zudem festgehalten, dass der Aufruf von der Seite http://www.georg-weidner.de aus erfolgte, der Besucher Windows NT 5.1 (Windows XP) nutzt, mit dem Firefox-Browser Version 3.0.1 surft und als bevorzugte Sprache Deutsch (de) angegeben hat.

Statusinformationen

Ein wichtiger Bestandteil, welcher in fast allen Logfile-Formaten vorgesehen ist, ist die Angabe von Statusinformationen. Dem HTTP folgend verwenden Server eine dreistellige Zahl, die angibt wie die Anfrage serverseitig bearbeitet werden konnte. Den so genannten Status Code sendet der Webserver zum anfragenden Browser und schreibt ihn zudem in das Logfile. Es gilt zu beachten, dass die meisten Browser nicht alle in HTTP/1.0 definierten Status Codes unterstützen.

 

Beispiele für HTTP Status-Codes:
200 OK – Erfolgreiche Bearbeitung der Anfrage (wie im Beispiel oben)
304 Das Dokument wurde seit dem letzten Abruf nicht modifiziert: Abruf vom Browser-Cache
404 Dokument wurde nicht gefunden
500 Interner Server Error

 

Die Systematik des Codes leitet sich von der ersten Ziffer her:
1xx Gegenwärtig nicht benutzt, reserviert für zukünftige Erweiterungen des HTTP
2xx Erfolgreiche Bearbeitung der Anfrage
3xx Weitere Aktionen zur Bearbeitung der Anfrage erforderlich
4xx Clientseitiger Error (z.B. Syntaxfehler in der Anfrage)
5xx Serverseitiger Error (z.B. Ãœberlastung des Servers)

 

Mit Server-Logfiles lassen sich umfangreiche Daten erheben:

• Wer besuchte wann die Webseite
• Woher kommen die Besucher
• Wie navigieren die Besucher durch die Webseite
• Hinweise auf mögliche technische Probleme

 

Allerdings haben Server-Logfiles einige entscheidende Nachteile:

• Große Probleme bei der Datenspeicherung in Caches
• Zugriff von virtuellen Nutzern wie Spidern und Robots gehen mit in die Logfiles ein
• Der Umfang der Logdateien wächst sehr schnell
• Eine Identifikation wiederkehrender Besucher kann problematisch sein

 

Eine genauere Erläuterung der Probleme von Webserver-Logfiles und entsprechende Maßnahmen wird im später unter “Datenaufbereitung” näher behandelt.

Von grundlegendem Vorteil jedoch ist, dass Logfiles sowieso vom Server erzeugt werden. Es müssen also keine zusätzlichen Anstrengungen unternommen werden um Daten zu erheben. Weiterhin handelt es sich um eine nicht-reaktive Erhebung von Daten: Der Nutzer erfährt hiervon nichts und hat auch keine Möglichkeit die Logfile-Einträge zu beeinflussen.

Dieser Artikel entstammt meiner Diplomarbeit zum Thema “Usertracking”. Ich habe lange überlegt wie und in welcher Form ich die Arbeit veröffentlichen könnte und bin zum Schluss gekommen, dass meine Erkenntnisse daraus, über diesen Blog veröffentlicht, dem größten Publikum dienen können.

Eine Ãœbersicht über weitere Artikel und ein Quellenverzeichnis sind unter
http://www.georg-weidner.de/usertracking zu finden.

31. März 2010, 23:39 - Usertracking, Web Analytics