Webformular-Tracking mit ASP.NET

Obwohl der Gebrauch von IIS-Logs sehr zu empfehlen ist, kann es vorkommen, dass Entwickler keinen Zugriff auf sie haben. Dies kann passieren, wenn der Entwickler die Website auf einem externen Webserver hostet (Shared Hosting). Dies ist eine gängige Praxis, besonders für kleinere Websites. Ein einzelner IIS-Server kann mehrere Sites hosten.

Systemadministratoren geben Entwicklern normalerweise keinen Zugang zu Log-Dateien, und das ist auch richtig so, wie man leicht einsehen kann. Die Log-Dateien enthalten schließlich auch Logging-Informationen anderer Sites auf dem Server. Daher müssen die Log-Dateien gefiltert werden, bevor man die Informationen an einen Entwickler weitergeben kann. Dies stellt ein Problem dar, wenn der Entwickler Zugriff auf die Log-Dateien in Echtzeit benötigt.

Und es gibt noch einen weiteren Fall, in dem die IIS-Logs nicht direkt verfügbar sind. Hierbei ist die Konfiguration genau entgegengesetzt: Statt mehrere Sites auf einem Webserver zu hosten, ist auch eine Konfiguration denkbar, bei der eine Website auf mehreren Servern gehostet ist. Dieses Vorgehen ist als „Web-Farm“ bekannt und wird für Sites mit einem hohen Datenaufkommen verwendet. Bei diesem Szenario verfügt möglicherweise jeder IIS-Server über seine eigenen Log-Dateien. Um auf die Logging-Informationen zuzugreifen, müssen die einzelnen IIS-Logs zu einer Gesamt-Log-Datei zusammengefasst werden.

In beiden Situationen könnte es von Vorteil sein, die Anfragen in einer Datenbank zu loggen, da diese eine zeitnahe, zusammengefasste Ansicht der Daten bietet. So war es auch im Fall des Kunden, der den Besuchern seiner Website die Benutzungsstatistiken in Echtzeit bieten wollte. Um diese Anforderung erfüllen zu können, entwickelten wir einen generischen Code, mit dem jedes ASP.NET-Webformular jede Anfrage in einer Datenbank loggen konnte. Man muss nicht extra erwähnen, dass diese Lösung gewisse Performance-Einbußen mit sich bringt, da jede Seitenanfrage zu einem neuen Datenbankeintrag führt. Wir konnten den Code allerdings so weit wie möglich optimieren um die Performance-Nachteile möglichst gering zu halten. Außerdem ist anzumerken, dass das Loggen von Anfragen in einer Datenbank zu Duplikaten der Informationen führt, wenn IIS die Daten gleichzeitig auch in einer Datei loggt. Wenn man die IIS-Logs mit denen in der Datenbank vergleicht, sollte man auf sich überschneidende Aktivitäten achten und vor allem auf Unstimmigkeiten.