Hoofdindex » Servers » Logs » Analyse
Computers en servers
Analyse van de server logs
Servers
Het analyseren van de server logs zal je heelwat leren over de bezoekers van je site. Zonder server logs rij je als het ware als een blinde (in een mistige nacht): je weet niet hoeveel bezoeker je hebt, hoe ze op je site terechtgekomen zijn, en welke pagina's ze opgevraagd hebben. Als je een eigen server hebt (of een virtuele server dat bij een hostingmaatschappij draait) kan je de server logs opvragen.

Hoe ziet een server log er uit?

Iedere opvraging resulteert in een regel. Als een opgevraagde pagina 10 foto's bevat, dan veroorzaakt dit bezoek 11 regels in je logs. Deze logs is opgemaakt op het ogenblik dat de server pas opgestart werd: weinig bezoekers maar veel spiders.

Het eerste deel van iedere bevat het IP adres van de bezoeker.
Daarmee ben je niet veel, maar een analyser zet dit IP adres automatisch om in een naam; zo weet je vanwaar de bezoeker afkomstig is. Analysers kunnen gewoon een reverse DNS query uitvoeren (zie informatie over het runnen van een eigen server en in het bijzonder pagina over de verschillende DNS records), maar ze kunnen ook het land van herkomst of de provider aangeven. Ieder IP hoort namelijk bij een internet provider, en deze is in een welbepaald land actief. Deze analyse kan niet in real-time gebeuren, want het opzoeken van rDNS records zou de server drastisch vertragen (de logs kunnen namelijk niet verder geschreven worden, totdat het IP adres omgezet werd).
De gevraagde pagina.
Eerst het soort opdracht:
HEAD
Opvragen van de "headers", dat is extra informatie dat met ieder bestand gestuurd wordt: het soort bestand: jpeg, gewone tekst, html, pdf, ... Niet alle operating systems gebruiken extensies, en er is dus een universele manier gevonden om het type bestand door te sturen. Ook de datum en tijd van de laatste wijziging zit in de header. Daarmee kan de browser weten of het bestand gewijzigd is sinds de laatste bezoek, en moet het bestand niet opnieuw gedownload worden.
GET
Opvragen van een resource (pagina, figuur, ...). Dit is de meest gebruikte opdracht. Ieder object (zeg maar bestand) wordt altijd voorafgegaan door een header (zelfs als die pas enkele seconden eerder reeds opgevraagd werd!). Het internet is een stateless protocol, dat wil zeggen dat ieder commando op zichzelf staat, zonder "geschiedenis".
PUT
Deze opdracht zal enkel gebruikt worden als je een ingevuld formulier terugstuurt. PUT is eigenlijk het tegenovergestelde van GET: je stuurt gegevens naar de server in plaats van omgekeerd. Na het verwerken van de PUT zal de server een antwoord geven, alsof je een GET had aangevraagd.
Dan volgt de gevraagde resource (pagina, figuur, bestand) en het protocol, HTTP/1.0 of HTTP/1.1
Response code en de grootte van het bestand.
De response code is meestal 200: (wat OK betekent) of 302/304 (niet gewijzigd sinds laatst —de vraag kan namelijk een clausule bevatten "stuur mij enkel de pagina als die gewijzigd is na een bepaalde datum"). Deze clausule maakt de HEAD opdracht eigenlijk overbodig.
Met een antwoordkode 404 moet je opletten: de gevraagde pagina bestaat namelijk niet! Je moet nu gaan zoeken vanwaar dit opdracht afkomstig is (welke pagina een dergelijke foutieve link bevat). Hier is dit niet moeilijk, de foutieve pagina (fe referer) staat rechts.
De referer bevat de pagina vanwaar de oproep gekomen is.
Voor een foto is dat meestal de pagina waarop de foto prijkt, voor een html pagina kan het een andere pagina van de site zijn, een pagina van een andere site of het resultaat van een zoekopdracht.
Bij deze log was de server pas opgestart, dus veel "referenties" kan ik nog niet voorleggen.
De User Agent is het programma dat gebruikt werd om de pagina op te vragen.
Meestal is het internet explorer, opera of een andere browser. Maar een zoekprogramma (spider) presenteert zich ook met zijn naam; Googlebot, Yahoo! Slurp, Ask Jeeves en dergelijke meer. Mozilla is de originele naam van de eerste browser (dat was toen netscape), dat zich aanmeldde met de naam 'Mozilla'. Deze naam is gebleven, en de meeste user agents gebruiken 'Mozilla' in hun naam om zich aan te melden, waarschijnlijk om aan te geven dat ze 'compatibel zijn'.

Het wordt pas interessanter als er echte bezoekers op je site komen. De eerste twee regels zijn hotlinks uit forums waaraan ik deelneem. Forums zijn een ideale manier om je site te promoten (door het adres in je signature op te nemen). Hoe technischer de forums, hoe beter (het is de bedoeling dat de spiders de links volgen en die houden niet van algemene vaagheden).
Dan komt de indexpagina /test/ met als referer een link van google. Je kan dus zien welke zoektermen de mensen gebruikt hebben om op mijn site te komen. Als verkoper zou je eigenlijk in staat moeten zijn een dynamische pagina aan te bieden dat toegespitst is op wat de bezoeker gevraagd heeft!
Deze pagina bevat een paar objecten (een cascading style sheet, een javascript en twee gifs). De response code is 304, wat betekent dat de resource reeds in de browser cache aanwezig is (de file is niet lang geleden opgevraagd geweest). Na 5 seconden wordt er een nieuwe pagina ingelezen /test/test.htm (als dat in het echt gebeurt, dan zou je je moeten afvragen waarom er reeds na 5 seconden doorgeklikt wordt).

Opgelet, de links die in de voorbeelden staan werken niet meer, de pagina's werden allemaal verplaatst.
Als ik wat tijd heb maak ik de plaatjes en de voorbeeldlogs opnieuw aan.

Mijn eigen server log is wat opgeruimd en ziet er mooier uit:

  • IP adressen van bezoekers worden omgezet naar hostnames via reverse DNS
    Zo kan je zien van waar de gebruiker gekomen is.
  • alle opvragingen voor jpeg's op één pagina worden als één regel behandeld
    De verkleint de log en zorgt voor wat meer duidelijkheid.
  • Niet-gevonden pagina's worden in reverse en vet getoont
    zodat opvragingen van onbestaande pagina's direct in het oog springen.
    De pagina die de foutieve link bevat is meestal rechts te zien.
  • Queries bij zoekmachines worden in het vet en rood getoont
    Zodat je snel kan zien welke zoekwoorden bezoekers gebruikt hebben.
De bewerking gebeurt automatisch op het einde van de dag (dus voor de logs van de dag ervoor).

Compressie

Dit merkte ik een tijdje geleden in mijn server logs... 

82.94.179.141 - - [05/May/2009:09:03:12 +0200] "GET / HTTP/1.0" 200 8330 ...
86.83.104.171 - - [05/May/2009:09:56:29 +0200] "GET / HTTP/1.1" 200 3201 ...
Vreemd dat eenzelfde bestand (de indexpagina) zowel 8330 als 3201 bytes lang kan zijn. Het heeft een paar minuten geduurd voor ik het door had. De eerste aanvraag was van een zoekrobot die het verouderde HTTP/1.0 protocol gebruikte. Bij HTTP/1.0 is er geen compressie mogelijk. Van zodra de client vermeld dat hij HTTP/1.1 en compressie ondersteunt, wordt de pagina on-the-fly gecomprimeerd. De gecomprimeerde pagina is 2.5× kleiner, en dit scheelt kwa downloadtijd en bandbreedtegebruik! De tijd die nodig is voor de compressie is miniem in vergelijking met de downloadtijd; de compressie wordt immers in het geheugen uitgevoerd en ik heb 2GB aan werkgeheugen.

Publicités - Reklame

-