EASLOG

Alle Skripte sind Muster ohne jede Gewährleistung oder Funktionsgarantie. für Schäden bin ich nicht verantwortlich. Achten Sie auf Zeilenumbrüche bei der Übernahme.

Dieses Skript ist aktuell nicht als öffentlicher Download erhältlich. Sie erhalten diese nur im Rahmen von Support oder Dienstleistung. Informationen, warum diese Skripte nicht öffentlich sind, finden Sie auf nicht public.

EASLog und Exchange 2007
Exchange 2007 schreibt andere Logdateien. Eine entsprechende Anpassung ist noch nicht erfolgt. Daher funktioniert EASLOG noch nicht mit Exchange 2007/2010.

Mit dem Commandlet "Export-ActiveSyncLog" enthält Exchange 2010 selbst eine Option, einfach Statistiken zu generieren. Als Ergebnis werden mehrere Dateien angelegt: Users.csv, Servers.csv, HoURLy.csv, StatusCodes.csv, PolicyCompliance.csv und UserAgents.csv

ActiveSync ist der Weg, um mobile Endgeräte mit dem Exchange Server zu koppeln. Wie ich schon auf Exchange ActiveSync Server beschrieben habe, nutzt der Client dazu HTTP/HTTS, um mit dem IIS zu kommunizieren. Nun hat mobile Kommunikation natürlich das Problem, dass die Datenmenge relativ teuer bezahlt wird und man als Administrator natürlich die Daten auswerten möchte. So kann man aus den Logs z.B. herausfinden.

  • Datenmenge pro Benutzer
    Diese Auswertung ist natürlich interessant um die Kosten der Anbindung zu sehen. Natürlich sieht man hier nicht, wenn ein Anwender mit dem PDA noch im Internet surft, aber zumindest die Kosten bezüglich Exchange sind so zentral zu ermitteln
  • Benutzer, Endgerät und Typ
    Auch interessant ist die Übersicht, welche Benutzer mit welchen Endgeräten arbeiten. Über die DeviceID bzw. den Gerätetyp kann man schon gut erkennen, was wie genutzt wird.
  • Ping-Time
    Sehr interessant ist natürlich die Zeit zwischen zwei Anfragen eines bestimmten Clients. So kann man erkennen, ob Push sauber funktioniert oder ob ein Client sehr oft Daten abruft.
  • Replizierte Elemente
    Im Log steht sogar, wie viele Elemente welchen Typs repliziert werden.

Das Auswerteskript hat für mich primär das Ziel, die "Ping-Time" und Datenmenge zu ermitteln und ist natürlich keine weitergehende Auswertung, auch wenn die Daten dies sicher hergeben würden.  Das Skript erstellt auch keine schönen Bilder und Grafiken, wie dies einige Programme zur Auswertung von Webserverprotokollen tun.

Ausgabe

Das Skript analysiert die angegebenen LOG-Dateien und erzeugt dann eine XML-Datei, welche auch im Internet Explorer angezeigt werden kann.

Für jede Benutzer/Device-ID-Kombination wird der Device-Typ die gesendeten und empfangenen Bytes angezeigt. Wenn der Anwender Anlagen nachfordert, dann wird diese Datenmenge gesondert ausgewiesen. Das Feld "Last-Sync" hilft bei der schnellen Klärung von Rückfragen durch Anwender.

Eine Besonderheit sind die beiden farblich markierten Blöcke

  • Roter Block
    Zwischen zwei Anfragen des Clients vergeht einige Zeit. Hier finden Sie die verschiedenen Abstände pro Benutzer. Der primäre Nutzen dieser Tabelle ist die Kontrolle ihrer Firewall-Einstellungen. Wenn dort ein sehr kurzer TCP/IP-Timeout konfiguriert ist, dann haben sie sehr viele "kurze" Intervalle. Diese Werte sind aber zu relativieren, da natürlich ein aktiver Benutzer aufgrund der Übertragung von Nachrichten kurze Intervalle hat und lange Intervalle können auch auftreten, wenn der Mitarbeiter das Endgerät häufiger für einige Zeit abschaltet.
  • Blauer Block
    Hier wird für jede volle Stunde die Anzahl der Hits und die Anzahl der "Pings" darunter aufgelistet. Zum einen finden Sie so heraus, welche Endgeräte überhaupt die "Push"-Funktion zu welcher Zeit eingeschaltet haben. Zum anderen sehen Sie aber auch wie aktiv ein Client zu welchen Zeiten ist bzw. wann ActiveSync auf "manuell" oder deaktiviert gestellt ist.

Für einen ersten Überblick reichen diese einfachen Auswertungen schon einmal aus.

Achtung: Die Zeiten basieren auf den Werten des IIS. Insofern muss die uhrzeit des Server "stimmen" und Sie müssen die Zeitzone berücksichtigen, da der IIS per Default in "GMT" protokolliert.

Für weitere Auswertungen generiert das Script zusätzlich eine CSV-Datei mit einem Auszug der ActiveSync betreffenden Daten, welche sehr einfach in Excel oder anderen Anwendungen oder Datenbanken geöffnet und ausgewertet werden kann. So können z.B. Grafiken zu den übertragenen Daten entstehen.

Besonders interessant sind hierbei natürlich die Summen der übertragenen Daten und das "Ping-Delta", welches nur so einfach auswertbar ist. Aber auch die Version von ActiveSync (eas-version) und der Device-Typ sind für Auswertungen interessant. Danke Excel Pivot-Tabellen sind ebenfalls schnelle Auswertungen möglich

Im linken Zeilenbereich werden "User" und "Device-ID" eingetragen und in die Spalten die Summen von sc-bytes und cs-bytes und der Mittelwert von "Ping-Delta". Wenn Ping-Delta z.B. nie über 2 Minuten (120 Sek) kommt, dann sollten Sie ihre Konfiguration (Firewall, Router, Endgerät) überprüfen, da irgend ein Prozess dann die TCP/IP-Verbindung nach kurzer Inaktivität zurück setzt.

Nutzt man die Felder "Ping-Delta" und "Zeit" der tabellarischen Datenquelle und filtert nach einem Benutzer, dann kann darüber eine Grafik erstellt werden, (X-Achse = Zeit, Y-Achse = Ping-Delta)

Über mehrere Tage sieht man so, wann der Benutzer aktiv ist und wie die Intervalle sind. Hier ist gut zu erkennen, dass in diesem Fall bei ca. 1700Sekunden (28Min) eine Obergrenze zu erkennen ist. Dazwischen ist normale Aktivität zu sehen während die Punkte darüber Ausreißer sind, z.B. Gerät ausgeschaltet, länger nicht online oder auf manuelle Synchronisation gestellt ist.

Wenn man nun genau ein kleines Zeitintervall genauer auseinander zieht, dann kann man tatsächlich das "Hochschaukeln" von ActiveSync erkennen. (Siehe auch Always up-to-date (AUTD))

Leider bin ich zuwenig Fachmann um Excel beizubringen, dass die X-Achse linear sein soll. Das Bild wäre um einiges schicker, wenn die X-Abstände auch der Zeit entsprechend würden und der Abstand von 08:01:13 und 08:09:19 entsprechend breiter wäre. Excel 2003 kann dies nur mit "Tagen" als Basiseinheit und nicht Stunden oder Minuten.

Ein ähnliches Bild ergibt sich, wenn Sie Datenmengen (sc-bytes und cs-bytes) aufeinander aufsetzend addieren lassen:

Das dürfte dann in etwa den Daten entsprechen, die auch ein GRPS-Monitor auf dem PDA ermitteln sollte. Leider sieht man auch hier, dass zwischen 21:00 und 05:00 uhr eigentliche ein "Lücke" klaffen müsste. Excel unterstützt zwar X/Y-Diagramme aber nicht in Verbindung mit der hier gewünschten Ausgabe.

Einschränkungen

Leider ist die Auswertung nicht wirklich 100% korrekt, denn es gibt Sachverhalte, die das Skript nicht auflösen kann bzw. in den Daten nicht vorhanden sind, z.B.

  • Datenvolumen
    Anfangs habe ich die Datenvolumen aus den ActiveSync Daten im IISLog und den Angaben im Exchange Blog ermittelt. Aber diese Daten können nicht stimmen, da Sie um ein vielfaches zu hoch sind. Daher sollten Sie auf jeden Fall in den IIS-Logs die beiden Felder "cs-bytes" und "sc-bytes" aktivieren. Oder sollte ein Ping wirklich 8204 Bytes senden und 7860 Bytes empfangen ?
&Cmd=GetI&Log=V4TNASNC:0A0C0D0FS:0A0C0D0SP:1C9I6266S17298R0S0L0H0P
&Cmd=Ping&Log=V4TNASNC:0A0C0D0FS:0A0C0D0SP:2C17I8204S27860R0S0L480H0P
&Cmd=Ping&Log=V4TNASNC:0A0C0D0FS:0A0C0D0SP:2C17I8204S27860R0S0L480H0P
&Cmd=Ping&Log=V4TNASNC:0A0C0D0FS:0A0C0D0SP:1C17I8204S28788R0S0L480H0P
  • Datenquelle
    Das Volumen im IISLog erlaubt nicht immer eine saubere Differenzierung, ob die Daten wirklich über GRPS o.ä. übertragen wurden. Auch eine Synchronisation über WiFi oder Craddle nutzt den gleichen Weg. Wenn dann alle den gleichen Zugangspunkt (z.B. ISA2004 als Reverse Proxy) nutzen, dann "sieht" EAS nur die IP-Adresse des Proxy. Nur wenn die mobilen Clients einen anderen Zugangspunkt wählen oder die Firewall die Client-IP-Adressen bis zum EAS-Server durchreicht, könnte hier eine unterscheidung vorgenommen werden
  • Ping Timing
    Das Skript wertet pro Benutzer und Gerät die Zeit zwischen zwei Anfragen aus. So kann ermittelt werden, in welchen Abständen die Anfragen ankommen und z.B.: eine Fehlkonfiguration der Firewall erkannt werden. Allerdings ist bei den Zeiten zu beachten, dass die 28 Minuten (Siehe Always up-to-date (AUTD)) nicht erreicht werden, wenn alle 10 Minuten eine Mail empfangen wird. Wenn das Gerät ausgeschaltet wird oder einige Zeit keinen Empfang hat, dann werden natürlich Pingzeiten über 2 oder sogar über 30 Minuten gemessen. Das darf Sie nicht in der Sicherheit wiegen, dass ActiveSync wirklich sparsam arbeitet. Ideal ist es daher, ein Endgerät mit einem Postfach ohne Änderungen zu verbinden und einfach mal ein paar Stunden "liegen" zu lassen. Dann sind die Pingzeiten besser zu beurteilen.
  • Unbekannte Logs
    Ich habe Anfragen auf die URL "/Microsoft-Server-ActiveSync" gesehen, bei denen es keinen "&Log"-Eintrag gegeben hat. Solche und andere nicht auswertbare Zeilen werden mit einer Warnung übersprungen

Konfiguration

Zuerst müssen Sie natürlich sicherstellen, dass der IIS die entsprechenden Logs generiert. Konfigurieren Sie den IIS daher so, dass er Ein W3S-konformes Log schreibt, in welchem die erforderlichen Felder enthalten sind.

Hier sind die folgenden Felder besonders wichtig:

  • "Date" und "Time"
    Damit das Skript die Abstände der Anfragen pro Benutzer und Device ermitteln kann.
  • "URI-Stem" (cs-uri-stem)
    Hier steht "/Microsoft-Server-ActiveSync" drin und dient zur Erkennung der Zeile. Nur solche Zeilen werden ausgewertet. Alles anderen sind nicht für ActiveSync relevant.
  • "URI Query" (cs-uri-query)
    Dieses Feld enthält den eigentlichen ActiveSync Datenbereich, welcher ausgewertet wird.
  • "Bytes Sent" und "Bytes Received"
    Diese beiden Spalten enthalten die übertragenen Datenmengen. Diese Daten sind anscheinend sehr viel zuverlässiger als die Daten innerhalb des EAS-Datenblocks, welche ich nicht nachvollziehen kann.

Skript aufrufen

Das Skript ist einfach gehalten und erwartet folgende Parameter beim Aufruf:

cscript easlog.vbs /file:iislogname /csvfile:csvdatei [/User:xxx] [/device:deviceid] [/xmlfile:xmldateiname]
  • /iisfile:lw:\pfad\Dateiname
    Geben Sie hier den Pfad und Dateinamen der Quelldatei des IIS an. Aktuell kann leider nur genau eine Datei angegeben werden. Es ist aber natürlich kein Problem, wenn Sie vorab ihre Dateien "zusammenkopieren". Denke Sie aber daran, dass Sie die Dateien in der richtigen Reihenfolge aneinanderhängen. Die Datei wird nur gelesen aber darf natürlich nicht gesperrt sein. Wenn sie einfach einen Bindestrich "-" als Dateiname angeben, dann liest das Skript die Daten von STDIN.
    Tipp: Über die Funktion STDIN können Sie problemlos auch mehrere Dateien an das Skript übergeben oder Dateien schon vorfiltern. So könnte ein TAIL die Daten direkt an das Skript übergeben oder ein FIND eine Vorfilterung erreichen. Denken Sie aber daran, dass zumindest die Headerinformation weiter enthalten bleiben muss.
REM Auswertung mehrerer Logs über STDIN
type ex*.log | cscript.exe easlog.vbs /iisfile:- csvfile:auswertung.csv
  • /csvfile:lw:\pfad\Dateiname
    In diese Datei werden die konvertierten Daten als CSV-Datei abgelegt. Sie können dann in Datenbanken oder anders weiter verarbeitet werden. Achtung: Die Datei wird per Default ohne Warnung überschrieben".
  • /xmlfile:lw:\pfad\Dateiname (optional)
    In diese Datei wird der XML-Report geschrieben. Wird keine Datei angegeben, dann erstellt das Skript selbst eine Datei in der Form "easconvert-tt-mm-jjjj-hh-mm-ss.xml".
  • /User: (optional)
    Über diesen Parameter können Sie die Ausgabe auf einen bestimmen Benutzer einschränken. Suchen Sie sich dazu einfach im bestehenden Log den Usernamen (Steht hinter User=)
  • /device:IMEI oder ID (Optional)
    Sie können die Auswertung auch auf ein Endgerät beschränken, wenn Sie die Device-ID haben.

Die meisten Anwender werden das Skript als schnelle Analyse eines Logfiles über die XML-Datei nutzen. Über die zusätzlich generierte CSV-Datei können Sie dann weitere Details ermitteln. Der Code kann auch Ausgangsbasis für eigene Abrechnungslösungen sein.

Das Skript legt zum Debugging eine Textdatei mit Details zur Verarbeitung ab, die gefahrlos gelöscht werden kann. Die Detailtiefe dieses Logs kann im Skript selbst angepasst werden.

Aufruf mit CSCRIPT
Bitte das Skript mit CSCRIPT starten, damit die Diagnoseausgaben auf dem Bildschirm nicht als "Messagebox" erscheint, die mühsam bestätigt werden müssen.

Details zur Größe

Da die Menge der übertragenen Daten besonders "wichtig" (da teuer) ist. stellt sich natürlich die Frage, wie zuverlässig die Werte auch im IISLog sind. Ich habe daher mit Packetyzer die Pakete zwischen Client und Server mitgeschnitten und ein PING-Paket heraus gezogen:

Das Paket wurde also 12:14:29 vom Client an den Server gesendet, welcher dann 12:19:30 darauf geantwortet hat. Weitere Pakete sind nicht aufgefallen. Die entsprechende Zeile im LOG war auch schnell gefunden (verkürzt)

#Fields: date time cs-uri-query sc-bytes cs-bytes
2006-11-09 12:14:35 User=msx&DeviceId=xx&DeviceType=PocketPC&Cmd=Ping&Log 300 435

Das Log weist aus, dass sc-bytes = 300 und cs-bytes=435 sind. Die 435 Bytes kann man oben im Capture natürlich wieder finden. Allerdings ist die nur die Größe des TCP-Inhalts. Das eigentliche Ethernetpaket ist natürlich schon etwas größer und dürfte auch in der vollen Größe (501 Bytes) über GRPS übertragen werden. Insofern sind die Datenmengen im IISLog um ca. 66 Bytes zu klein sind. Da GRPS aber nicht bit-genau sondern blockweise (meist 10k oder 100k) abgerechnet wird, dürfte diese ungenauigkeit vernachlässigt werden. Auch Anfragen des Clients, die nie beim IIS landen, z.B. der Handshake bei der Anmeldung mit Erlangung einer DHCP-Adresse, werden bei GRPS ja mit abgerechnet aber nie auf dem IIS protokolliert. Wie jedoch die 300 Bytes "Antwort" sich zusammen setzen, kann ich nicht erkennen, da diese TCP-Session nur eine TCP-Quittung zurück sendet und selbst zusammen mit dem Handshake nur 224 Bytes zusammen kommen.

Generell kann man also davon ausgehen, dass die Volumenermittlung zwar in die richtige Richtung geht aber keine bytegenaue Ermittlung nicht wirklich möglich ist.

Wenn man etwas mehr zur Paketübertragung erfahren möchte, dann müssen Sie dafür sorgen, dass Sie im Log auch die offizielle IP-Adresse des Clients enthält. Dann nämlich könnte man neben dem Zeitpunkt und Datenmenge auch die IP-Adresse des Clients mit auswerten. Ich nehme an, dass ein Wechsel der IP-Adresse auch immer mitteilt, dass ein Wechsel der Zone erfolgt ist und der vorherige Datenblock entsprechend voll berechnet werden dürfte. Würde man dies mit einer Logfunktion auf dem PDA verbinden, welcher die GPS-Koordinaten mit der Zeit protokolliert, dann könnten Sie sogar herausfinden, wo ein Zonenwechsel stattfindet.

Performance und Skalierung

Natürlich stellt sich auch die Frage, wie schnell so ein VBScript mit Textdateien umgehen kann. Ist das überhaupt ein gangbarer Weg zur Verarbeitung von Logfiles? Dazu habe ich mal ein paar Messungen auf meinem Notebook gemacht. (IDE-Festplatte, Pentium 4, 2 GHz und nicht wirklich unbelastet)

Zeilen Davon EAS Eingabe CPU-Last / RAM Dauer in Sek Lines/Sek

23059

898

Datei

100% / 10-20-MB

51

452

114153

4933

STDIN mittels "type *.log"

100% / 10-20-MB

232

492

4933

4933

STDIN mit vorgefilterten ´Daten

100% / 10-20-MB

26

189

4933

4933

Datei mit vorgefilterten ´Daten

100% / 10-20-MB

27

182

Die schlechtere Performance bei "vorgefilterten" Daten ist natürlich erklärbar, da hierbei ja jede Zeile "verarbeitet" werden muss, während bei ungefilterten Quellen die meisten Zeile schon sehr früh übersprungen werden. Es gibt keinen signifikanten unterschied zwischen dem direkten Lesen der Datei oder Nutzung einer PIPE

Wenn die Datenmenge bei ihnen aber doch zu groß für diese Art Auswertung ist, dann gibt es weitere Optionen. für die Auswertung von ActiveSync müssen eigentlich nur die Hits ausgewertet werden, welche auf cs-uri-stem= "/Microsoft Server-ActiveSync" verweisen. Leider kann man im IIS die Protokollierung nicht pro Verzeichnis konfigurieren, so dass der IIS auf jeden Fall alle Zugriffe in das Log schreibt. Aber es gibt auch hier Lösungen:

  • Eigener IIS
    Die Datenmenge kann man nun reduzieren, indem für ActiveSync z.B. ein eigener virtueller IIS verwendet wird. dann ist der normale OWA-Traffic nicht mehr im LOG enthalten.
  • Frontend
    Weniger Probleme haben Firmen mit "Frontend/Backend"-Strukturen. Hier entfallen Prinzip bedingt schon die die Anfragen von MOBSYNC an den Exchange Postfachserver aus dem Log.
  • SQL und Stored Procedure zum Löschen
    Dann  Man kann die Daten auch auf einen SQL-Server schreiben lassen und dort über eine "Stored Procedure" die überflüssigen Einträge gleich entfernen lassen. So bleibt die Datenbank etwas kleiner
  • SQL und Realtime Auswertung
    Viele mag auch das Prinzip des "Batchlaufs" stören. Dann könnte die Ganze Logik als "Stored Procedure" in SQL ablaufen, so dass beim Eintreffen eines neuen Logs gleich die Daten extrahiert und in eine Statistiktabelle übernommen werden

Sie sehen also, dass es mit IIS, SQL und etwas Entwicklung sehr einfach sein wird, die Auswertung auch hoch zu skalieren. Allerdings übersteigt dies den Umgang der MSXFAQ bei weitem.

EAS-Log Auswertung
Wenn Sie nur ein paar IIS-Logs haben, dann senden Sie mir doch einfach die fraglichen IIS-Logs. Um die Datenmenge zu reduzieren sollten Sie diese erst durch einen Filter in der Art laufen lassen.

type ex*.log | find "/Microsoft-Server-ActiveSync > easlog.log

So enthält das easlog.log nur die ActiveSync -Anfragen und kein OWA etc. mehr. Kopieren Sie dann nur noch die Header einer Datei mit hier herein.

Unterstützung durch Net at Work:
Wenn Sie hierzu eine Lösung brauchen, dann können wir von Net at Work sie aktiv unterstützen. Wir haben sowohl das Exchange und IIS Know-how als auch SQL-Erfahrung und qualifizierte Entwickler.

Exchange 2007

Mit Exchange 2007 hat Microsoft selbst ein PowerShell Commandlet addiert, welches aus den IISLogs die ActiveSync-spezifischen Zeilen heraus fischt und entsprechende Reports erstellt.

dir w3*.log | export-activesynclog -OutputPath "c:\logs"

Diese Zeile listet alle Logfiles im aktuellen Verzeichnis (z.B. c:\windows\system32\logfiles\w3svc1) auf und übergibt die Namen an das Commandlet, welches dann die Logfiles auswertet. Im Verzeichnis C:\Logs landen dann 6 CSV-Dateien mit weiteren Informationen

  • HoURLy.csv
    Nach Tag und Stunde gruppierte Ausgabe der Geräteanzahl und Anzahl der Sync's. Leider ohne Datum, so dass eine Auswertung über vielen Wochen nur bedingt tauglich ist.
  • PolicyCompliance.csv
    Anzahl und Prozentsatz der Geräte nach "Compliant, Partial, None und Unknown"
  • Servers.csv
    Summenstatistik pro Server (Anzahl der Geräte und übertragene Datenmenge
  • StatusCodes.csv
    Sammelmeldung der HTTP Statusmeldungen und prozentualer Anteil, am Gesamtverkehr.
  • UserAgents.csv
    Übersicht welche HTTP-Agenten sich am ActiveSync melden. Quasi wie eine Browserstatistik bei Webseiten.
  • Users.csv
    Summenstatistik pro Benutzer über seinen Geräteeinsatz

Da die Ausgaben hier nur Summen sind, muss man für genauere Auswertungen das Commandlet mehrfach aufrufen und entweder die Eingabedaten filtern oder über Parameter den Zeitraum einschränken.

Dieses Commandlet macht EASLOG keineswegs überflüssig aber erlaubt zumindest mit Bordmitteln einfache Summenermittlungen.

Ich habe aber schon vor, EASLOG auch mit Exchange 2007 "kompatibel" zu machen. Dazu sind allerdings zwei Dinge noch zu tun. Allerdings muss ich dazu erst noch Details erfahren, wie ich die "LOG="-Daten interpretieren muss

2008-07-19 00:04:43 W3SVC1 192.168.100.11 POST /Microsoft-Server-ActiveSync/default.eas User=testUser&DeviceId=abc123&DeviceType=PocketPC&Cmd=Ping&
    Log=V120_Sst72_Sst15_LdapC0_LdapL0_RpcC39_RpcL156_Hb1680_Erq1_S2_ 443 netatwork\testUser 192.168.100.12 MSFT-PPC/5.2.203 200 0 0 220 438

Die Beschreibung hierzu habe ich auf Exchange 2007 Exchange ActiveSync Reporting Services (http://technet.microsoft.com/en-us/library/bb201675(EXCHG.80).aspx) gefunden aber noch nicht umgesetzt.

Weiterentwicklung

Die hier vorgestellte Auswertung über ein VBScript ist natürlich nichts für größere Umgebungen und einen automatisierten Betrieb. Daher habe ich mir schon Gedanken über EASLOG 2.0 gemacht, aber hatte bislang noch keine Zeit zur Umsetzung. Die nächste Stufe der Entwicklung sieht wie folgen aus:

  • IIS protokolliert per ODBC in SQL
    Damit entfallen die Logfiles und das ganze Handling drum herum (Dateinamen, Aktualität etc.)
  • SQL Stored Prcedure
    Ein Stück Code als Stored Procedure im SQL-Server wird immer dann angetriggert, wenn der IIS einen Eintrag dort hinein schreibt. Diese Code kann die "überflüssigen Zeilen bei Bedarf sogar gleich löschen um Platz zu sparen. primär muss der Code aber die Daten auswerten und z.B. in eine zweite "Statistik-Tabelle" übertragen.
  • Auswertung
    Mit den seit SQL2005 mitgelieferten Reporting Services sollte es ein einfaches sein, die Daten der Statistiktabelle ansprechend als Webseite aufzubereiten.

Eine schematische Erläuterung der Zusammenhänge liefert das folgende Bild.

Diese Lösung hätte natürlich noch einige weitere Vorteile:

  • Echtzeit
    Der IIS protokolliert die Zugriffe direkt in die Datenbank worauf das Skript die Daten sofort verarbeiten kann. Es entsteht also gar nicht erst eine Verzögerung der Verarbeitung wie beim normalen Batchbetrieb.
  • Platz sparend
    Die Stored Procedure selbst kann ihrerseits natürlich die eingegangenen Daten nicht nur weiter verarbeiten, sondern die überflüssigen Daten in der Tabelle gleich entsorgen. Dies geht zumindest, wenn die virtuelle Webseite in diesem IIS sonst keine Funktionen ausführt.
  • Skalierbar
    Aufgrund der sofortigen Konsolidierung dürfte diese Lösung auch sehr viel besser skalieren.
  • NLB-tauglich
    Der größte Vorteil ist aber gleich die Konsolidierung der Logs mehrerer Server. Speziell wenn Sie mehrere Frontendserver mit Loadbalancing betreiben, ist es normal, dass ein Client mal auf dem einen und mal auf dem anderen Server landet.
  • Erkennen von "Funkverbindungen"
    Bislang addiert das Skript alle Daten. Auch ein PDA, der im Craddle von "intern" oder per WIFI repliziert, wird mit addiert. Das ist natürlich keine Basis für GPRS-Kosten. Bei "passender Konfiguration" kann das schon heute erkannt werden, aber vielleicht gibt es auch einen Weg aus dem Log selbst diese Daten zu erhalten. Zumal auch die S/R-Daten im LOG ja nicht gültig sind.

Sie sehen, dass es noch einiges zu tun gibt. Aktuell fehlt mir aber die Zeit dieses Projekt weiter zu verfolgen. Aber vielleicht habe ich ihnen ja eine Anregung für eine eigene Umsetzung oder die Beauftragung gegeben.

Weitere Links