Logfile-analyse: dit weet de logfile van een webserver over je bezoekers

Logfile

Het nut van een logfile-analyse

Om ervoor te zorgen dat een computersysteem goed functioneert, moet het besturingssysteem doorgaans meerdere processen tegelijkertijd uitvoeren. De meeste van deze "taken" vinden plaats op de achtergrond, zonder dat de gebruiker er iets van merkt. Om ervoor te zorgen dat de handelingen van uitgevoerde programma’s toch registreerbaar zijn, houden ze automatisch een protocol bij in speciale bestanden. Deze bestanden worden ook wel logbestanden of logfiles genoemd. Hierin zijn bepaalde activiteiten en gebeurtenissen van de toepassing opgenomen – bijvoorbeeld foutmeldingen, instellingswijzingen, programmatoegangen of crashberichten. Bedreven gebruikers kunnen uit deze bestanden ook informatie halen over de functionaliteit en gericht op zoek gaan naar fouten. Door het evalueren van de logfiles van een webserver kun je informatie over het algemene gedrag van bezoekers krijgen. Een log op deze manier controleren noemen we een logfile-analyse.


Wat is een logfile-analyse?

De logfile-analyse, ook wel loganalyse genoemd, omschrijft het proces van het gericht inspecteren en evalueren van een logfile. Met deze methode kun je bijvoorbeeld de oorsprong van overdrachtsfouten in databanken en e-mails achterhalen of de activiteiten van de firewall controleren. De logfile-analyse wordt echter vooral ingezet voor zoekmachineoptimalisatie. Wie namelijk moeite doet om de serverlogfiles te evalueren, kan zo nuttige informatie over bezoekers en hun activiteiten vergaren. Een blik in de logfile van de webserver kan bijvoorbeeld de volgende gebruikersgegevens openbaren:

  • IP-adres en hostnaam
  • Tijdstip van bezoek
  • De gebruikte browser
  • Het gebruikte besturingssysteem
  • Oorsprongslink of – URL
  • Gebruikte zoekmachine inclusief gebruikte keywords
  • Verblijfsduur
  • Het aantal opgeroepen pagina‘s
  • Laatst geopende pagina voor het verlaten van de website

Het handmatig evalueren van de logfiles is vanwege hun grootte simpelweg niet mogelijk. Daarom bestaan er diverse analysetools die de relevante informatie uit de logs weergeven. Het is dus de taak van analisten om uit de gevisualiseerde gegevens de juiste conclusies te trekken. Naast het controleren van websitebezoekers dient de logfile van de webserver ook voor het opsporen van technische fouten (m.b.t. het netwerk, de toepassing of individuele onderdelen), veiligheidsproblemen en automatische toegang door bots.


Analyse van de logfile van een webserver: typische problemen en benaderingen

Het grootste probleem van de analyse van webserverlogfiles is dat http een staatloos protocol is: het overdrachtsprotocol dat voor de communicatie tussen server en client verantwoordelijk is, behandelt iedere aanvraag dus afzonderlijk. De webserver wijst twee verschillende paginabezoeken van dezelfde client, daarom ook aan twee verschillende instanties toe – wat voor de analyse van het algemene gedrag van een gebruiker niet bijzonder praktisch is. Er zijn verschillende mogelijkheden om met dit probleem om te gaan:

  1. Toekennen van een sessie-ID: een sessie-ID is een door de server gegenereerd nummer dat in de browser van de gebruiker wordt opgeslagen. Zodra een bezoeker een dergelijk identificatienummer heeft gekregen, gaan alle toekomstige aanvragen van deze gebruiker aan de webserver via dit nummer. Alle acties worden dus per zitting samengevat. Voor de toewijzing van het ID-nummer bestaan er twee mogelijkheden: aan de ene kant is het inzetten van cookies denkbaar. Deze worden na de eerste aanvraag bij de client opgeslagen en vervolgens bij ieder verder contact met de server doorgegeven. Cookies zijn echter niet zichtbaar in de logfile, waardoor er voor de latere analyse een speciaal programma nodig is. Aan de andere kant kan een sessie-ID als URL-parameter worden doorgegeven. Deze links, die aan specifieke gebruikers zijn gelinkt, zijn echter veel werk voor programmeurs. Ook met het oog op zoekmachineoptimalisatie (ook wel SEO) ontstaan er problemen door de individuele URL’s. Dezelfde inhoud is bij ieder bezoek via een andere URL beschikbaar, waardoor het zou kunnen worden gezien als duplicate content.
  2. Gebruikersidentificatie via het IP-adres: zolang alle handelingen van een gebruiker te linken zijn aan hetzelfde IP-adres kunnen ze eenvoudig worden toegekend. Dit onder de voorwaarde (volgens vele gegevensbeschermingsexperts) dat de gebruiker van tevoren toestemming heeft gegeven voor het vastleggen van zijn of haar volledige IP-adres voor analysedoeleinden. Hierbij ontstaan echter problemen als bezoekers hun IP-adres dynamisch krijgen toegewezen en daardoor meerdere keren worden geteld of als meerdere gebruikers – bijvoorbeeld via proxyservers – hetzelfde IP-adres gebruiken.
  3. Inzet van serveronafhankelijke maatregelen: zogenaamde webbakens – bouwstenen van het page-tagging – die onzichtbaar aan een website kunnen worden verbonden, leveren verdere informatie, bijvoorbeeld over de beeldschermresolutie en geïnstalleerde browserplug-ins. Samen met het IP-adres en de gegevens over de browser en het besturingssysteem kunnen gebruikers tot op zekere hoogte van elkaar worden onderscheiden. Perfect onderscheid kunnen maken tussen alle gebruikers is op deze manier echter niet mogelijk. Toch kun je met behulp van Pixel Widgets of AJAX-elementen tracken. Bij een eenvoudige logfile-analyse krijg je geen bijzondere informatie over de gebruikswijze zelf. Een ander probleem van de logfile-analyse is de cachefunctie van de webbrowsers resp. de proxyservers. Deze is weliswaar van groot belang voor een snelle levering van de aangevraagde data, maar zorgt er ook voor dat gebruikers niet altijd contact maken met de webserver. Verzoeken die opgeslagen inhoud betreffen, verschijnen logischerwijze ook slechts beperkt (statuscode 304 "Not modified") in de serverlogfiles. Tot slot moet ook worden vermeld dat voor langdurige registratie, opslag en verwerking van de serverbezoeken extra bronnen nodig zijn – vooral bij webprojecten met grote bezoekersaantallen. Bovendien beschikt de logfile-analyse niet over belangrijke kencijfers zoals de verblijfsduur van bezoekers of hoe snel ze de pagina verlieten. Daarom moet deze analyse alleen als aanvulling op andere controle-instrumenten worden gebruikt en niet als enige methode voor bezoekersanalyse.

Logfiles verwerken – zo gaat het

Om een indruk te krijgen van het uitvoeren van een logfile-analyse, moet je eerst kijken naar de inhoud en de structuur van een logfile. Als voorbeeld nemen we het logboek van een Apache-webserver, dat de naam access.log heeft en automatisch wordt aangemaakt in het apache-register.


Logfile: Apache-logfile

Dit staat er in de Apache-logfile

Het register is opgeslagen in het zogeheten Common Log Format (ook NCSA Common log format genoemd). Deze formattering heeft een vaste syntax:

%h %I %u %t "%r" %>s %b

De individuele onderdelen staan daarbij voor de volgende informatie:

%h IP-adres van de client
%I Identiteit van de client die standaard niet wordt doorgegeven. Daarom staat op deze plaats vaak een minteken (-), om aan te geven dat er iets in de logfile ontbreekt
%u Gebruikers-ID van de client, dat bijvoorbeeld bij registerbescherming met http-autorisatie wordt ondergebracht; wordt normaal gesproken niet doorgegeven
%t Tijdstempel van het moment van bezoek
%r Informatie over de http-aanvraag (methode, aangevraagde bron en protocolversie)
%>s Statuscode waarmee de server op de aanvraag heeft gereageerd
%b Hoeveelheid dataoverdracht in bytes

Een volledige invoer in het access.log ziet er dus bijvoorbeeld zo uit:

203.0.113.195 - user [07/Oct/2016:10:43:00 +0200] "GET /index.html HTTP/2.0" 200 2326

In dit geval heeft de client met het IP-adres 203.0.113.195 en het gebruiker-ID user op 7 oktober 2016 om 10.43 uur de index.html opgeroepen. Daarbij gebruikte hij of zij HTTP/2.0. De server heeft met de statuscode 200 (aanvraag succesvol verwerkt, resultaat wordt doorgegeven) geantwoord en 2326 byte doorgestuurd.

In het httpd.conf-bestand kun je de invoer van logfiles bovendien met twee onderdelen uitbreiden door aan het logformaat \"%{Referer}i\" en \"%{User-agent}i\" toe te voegen. Zo kom je te weten via welke link (referrer) of welke pagina bezoekers op jouw webpagina zijn uitgekomen en welke client en welk besturingssysteem werden gebruikt. Dit laatste zorgt ervoor dat dit Combined Log Format ook externe toepassingen verifieert die gegevens van je webserver opvragen, zoals e-mailprogramma’s en ingebouwde grafieken, maar ook spiders en spambots.


Logfile: Tools

Tools maken de analyse van logregisters mogelijk

Als je voldoende rechten hebt om de logfiles van je webserver in te zien, is het in principe mogelijk om individuele client-bezoeken aan je webpagina handmatig en zonder extra hulpmiddelen te controleren. Maar als je er bijvoorbeeld van uitgaat dat je website dagelijks ongeveer 1.000 bezoekers heeft die ieder gemiddeld tien pagina’s oproepen, ontstaan er per dag 10.000 nieuwe registraties in de logfile. En daar hoort het oproepen van ingebouwde pagina-elementen nog niet eens bij – dat zijn dermate grote hoeveelheden dat je ze onmogelijk met de hand kunt verwerken. Voor de logfile-analyse heb je dus tools nodig waarmee je de data kunt exporteren en segmenteren.

Als de grootte van de logfile te overzien is, zijn gebruikelijke dataverwerkingsprogramma’s zoals Microsoft Excel goed genoeg: Hiervoor converteer je de logfile naar een CSV-bestand en importeer je het – zoals in deze handleiding van Microsoft beschreven is. In Excel structureer je de informatie over de verzamelde aanvragen en sorteer je ze bijvoorbeeld op IP-adres, statuscode of referrer. Vanwege de beperkingen m.b.t. de grootte van het geïmporteerde logboek vormen de resultaten van een Excel-logfile-analyse altijd slechts een momentopname.

Voor het langdurig onderzoeken van het siteverkeer op basis van logfiles, is het daarom aan te raden om een logfile-analysetool te gebruiken. In tegenstelling tot rekenprogramma’s zijn deze tools namelijk speciaal ontwikkeld voor de grafische weergave en verwerking van logfiles. In Dashboards, die in een gewone browser kunnen worden opgeroepen, worden de eerdergenoemde kencijfers gevisualiseerd – deels gebeurt dit zelfs zo goed als direct, zoals bij de open-sourcetool GoAccess.


Logfile-analyse en gegevensbescherming

Bij een logfile-analyse die gegevens van websitebezoekers omvat, kom je ook altijd in aanraking met aspecten van gegevensbescherming. Daarbij zijn vooral twee aspecten belangrijk: aan de ene kant scoort het analyseproces punten door de mogelijkheid om alle achterhaalde gegevens op de eigen server op te slaan. Als je een eigen webserver host – en daarmee ook de logfile – bij een externe aanbieder, moet je ervoor zorgen dat je weet wat het aanbod voor een veilige gegevensbescherming is. Het is belangrijk dat de server zich in de EU bevindt, het liefst in Duitsland, zodat je een hoge data-integriteit kunt garanderen en de privacy van je bezoekers fatsoenlijk kunt beschermen. Bij tracking-tools zoals Google Analytics ontstaan op dit gebied telkens weer twijfels – niet in de laatste plaats omdat alle gebruikersinformatie op de servers van de multinational wordt opgeslagen. Deze bevinden zich grotendeels in de VS.

Het tweede belangrijke punt heeft te maken met de vraag over verwijzingen naar personen in de gegevens van de logfile-analyse. Hoewel informatie zoals toegangstijd, opgeroepen pagina’s of de gebruikte browser nauwelijks concrete informatie over een individu geeft, ziet het er voor de opgeslagen IP-adressen heel anders uit: vooral bij statistisch toegewezen IP-adressen bekritiseren gegevensbeveiligingsexperts de op zijn minst theoretische mogelijkheid om de link met een persoon te maken. Over het algemeen wordt het webmasters aangeraden om adressen in anonieme vorm op te slaan en uiterlijk na een week te wissen als deze niet wettelijk bewaard moeten worden.

Als je de logfile wilt verwerken, heb je deze mogelijkheid echter niet, omdat het anonimiseren het bijeenbrengen van de verschillende handelingen van een individuele gebruiker zou verhinderen. Voor de zekerheid kunnen websitebeheerders de gebruikers in plaats daarvan voorlichten over het opslaan van het IP-adres voor analysedoeleinden, zoals is vastgelegd in de wet van 6 juli 2000 inzake de bescherming van persoonsgegevens.


Logfile: Serverlogfiles

Serverlogfiles verwerken: een solide basis voor je webanalyse

Het opslaan van gebruikersgegevens is een van de belangrijkste middelen om het succes van je website te meten. Alleen door de ontwikkeling van het websiteverkeer en het gedrag van bezoekers regelmatig bij te houden, kun je het aanbod op je doelpubliek afstemmen. In tegenstelling tot het gebruik van volgsoftware zoals Piwik en Google Analytics is de logfile-analyse gebaseerd op gegevens die standaard en zonder gebruik van JavaScript bij de server binnenkomen. De gegevens kunnen dus ook worden opgeslagen als de gebruiker JavaScript blokkeert. Dit voordeel is echter ook aan kleinere beperkingen gebonden: het rangschikken van individuele bezoeken tot bepaalde gebruikerssessies is weliswaar mogelijk, maar aanzienlijk complexer dan wanneer je cookies zou gebruiken. Bovendien mist de logfile-analyse een aantal kencijfers zoals de precieze verblijfsduur of hoe snel bezoekers de pagina verlieten.

Ook de cachefunctie van het clientprogramma zorgt voor moeilijkheden. Het maakt gebruikersverzoeken zonder servercontact mogelijk. Deze worden slechts beperkt in webserverlogboeken weergegeven, zoals dynamische IP-adressen die een concrete indeling van verschillende bezoeken in individuele bezoekers verhinderen. Je moet het resultaat van een logfile-analyse daarom zien als een momentopname en – afhankelijk van de grootte van de website – is het gebruik van aanvullende analysemethodes aan te raden. Als je het hosten en verwerken van de logfile zelf regelt en je de bezoekers informeert over het opslaan van het IP-adres e.d., heb je in ieder geval een solide basis voor de evaluatie van het gebruikersgedrag, die aan de privacywet voldoet. Vooral bij het onderscheiden van mobiel verkeer en desktopverkeer, maar ook bij het opsporen van bots als de Google-spider is de logfile-analyse bijzonder handig.

  • Gecertificeerde veiligheid

    Gecertificeerde veiligheid
  • Beste hostingbedrijf

    Beste hostingbedrijf
  • MKB Best Choice

    MKB Best Choice
  • Professionele support

    Professionele support
  • Hosted in Germany

    Hosted in Germany