IIS LOGS auswerten mit SQL performance

[U-- °LoneWolf°]

Hi zusammen,

ich befasse mich gerade ein wenig mit den LOG-Daten des IIS.

Zur auswertung würde ich die Daten gerne in eine SQL Datenbank einlesen.

Das einlesen ist schon mal kein problem.

Meine frage ist eher bei einem ca. 90 MB großen logfile pro tag könnte die datenbank nach kurzer zeit sehr langsam werden oder?

Könntet Ihr mir eventuell tips geben bzw. sollte man besser die Finger davon lassen?

Grüße

Wolf

Bearbeitet 2. Juni 2008 von U[[ °LoneWolf°

[Amstelchen]

IIS unterstützt explizit ODBC-datenbanken.

wenn du regelmässig SQL-basierte auswertungen auf IIS-zugriffe machen musst ist das ok, ansonsten lass die finger davon und nimm ein echtes loganalyseprogramm.

ansonsten würd ich halt sicherstellen, dass das ding bei INSERTs keinen index-overhead erzeugt.

s'Amstel

[U-- °LoneWolf°]

Naja das problem bei den standard tools ist, das die zwar die grundsätzlich gute ergebnisse bringen aber bei unseren cryptischen URL's sind sie dann im detail nciht so optimal.

(z.b. nav\irgendwas?A=1234567890abcdef&B=123456789abcdef)

auswertung läuft aktuell einmal im monat und ich möchte einfach das die ausertung täglich abrufbar ist.

[geloescht_JesterDay]

Meine frage ist eher bei einem ca. 90 MB großen logfile pro tag könnte die datenbank nach kurzer zeit sehr langsam werden oder?

Wenn du nicht gerade Access nimmst sollte das nicht der Fall sein Genau dafür sind RDBS ja gemacht, ein schneller Zugriff auf Daten einer großen Datenmenge. Wenn du die Indizes richtig anlegst sollte das kein Problem sein (nur eben u.U. weit mehr als nur 90 MB Platz brauchen pro Tag).

Vorrausgesetzt der DB-Server ist nicht der ausrangierte Bürorrechner von vor 5 Jahren...

[U-- °LoneWolf°]

alles klar danke für die infos dann werd ich das wohl mit ner mssql datenbank umstezen und nach 2 jahren immer ein jahr löschen, so das immer ein vorjahres vergleich vorhanden ist.

[geloescht_JesterDay]

Noch ein kleiner Hinweis. Die Datenmenge wird ja wohl vorallem durch die URLs und Referer zustandekommen. Ich kenn das IIS Log jetzt nicht, aber viel anderes als beim Apache wird da ja auch nicht stehen. Du könntest sehr sehr viel Platz sparen, wenn du die URLs zerlegst und wiederverwendest. Ich denke ja mal nicht, dass sich der Webauftritt so oft ändert. Also dass du das ähnlich wie ein Filesystem aufbaust, sprich: Du zerlegst die URL und speicherst die einzelnen Werte (mit Vorgänger).

Also zum Beispiel:

ich.bin.eine/url/mit/datei.html

Die Serveradresse wird sich wohl noch seltener ändern, von daher kann man die komplett in eine Datei speichern. U.U. hat dir nur einen Eintrag:

[B]Index  host[/B]

   1      ich.bin.eine

Den PFad zerlegst du in die Einzelteile (also url und mit). Die speicherst du in eine andere Datei (Tabelle):

[B]index  parent  name[/B]

  1        null     url

  2        1        mit

jeweils mit verweis auf den Vorgänger (der ja auch in der Tabelle ist). die eigentliche Datei kannst du da denke ich mal auch reinlegen, mit Vorgänger. (3, 2, datei.html) Für die o.g. URL hättest du also in einer Tabelle die die Aufrufe speichert dann vielleicht das:

[B]index host_id  file_id[/B]

  1        1           3

Plus ein Bezug auf das Datum und die Zeit und weiteren Dingen.

Über die file_id 3 bekommst du den kompletten Pfad raus (parent jeweils bis parent == null). Die url ich.bin.eine/url/mit/datei.html

würde 11 Byte belegen, die Version von mir 8 Byte (host_id + file_id).

Wenn du dafür 32Bit Integer verwendest (und ist ja nur ein kleines Bsp. U.U. langen 16bit, weil soooo viele Pfade oder Dateien habt ihr bestimmt nicht).

Da du scheinbar viele Parameter hast in den URLs musst du dir dafür vielleicht noch was überlegen oder das über URL-Umschreibung machen (geht ja beim IIS auch).

Nur mal als Idee in den Raum geworfen. Denke damit kannst du ne Menge Platz sparen, wenn du das so für das Log umsetzen kannst.

Nachtrag: Natürlich müsste das beim Import jeweils aufgelöst und gesucht werden ob es die Datei mit entsprechendem Pfad schon gibt. Wenn ja nimmst du die id, wenn nein trägst du sie neu mit Pfad ein. Bei der Auswertung dann andersrum.

Wenn nicht noch eine weitere, u.U. einfachere, Methode:

Speicher die Texte (URLs etc.) gezippt in die DB. Der Import und die auswertung müssen dass dann jeweils erst handlen, aber auch damit würdest du ne Menge Platz sparen denke ich.

Bearbeitet 3. Juni 2008 von JesterDay

[U-- °LoneWolf°]

naja ich würde einen aktullen stand von ca. 95000 Contents und einenen zuwach von etwa 1000 Contents pro Monat nicht wenig nennen

aber was das aufteilen der url angeht hört sich gut an werd ich mir mal ansehen

was ich sowieso splitten wollte waren url parameter und pfad.

thx für den denk anstoß