Contact met ondersteuning

Wij antwoorden per e-mail, meestal binnen twee dagen.

Google reCAPTCHA controleert deze inzending op misbruik; daarbij worden gegevens naar Google gestuurd. Het script laadt pas wanneer dit formulier wordt geopend.

← Alle berichten

Twee manieren om een toegangslogboek verkeerd te tellen

Een week vol veranderingen hier rustte op tellingen uit één dag toegangslogboek: een miljoen regels, honderdduizend daarvan de onze. Om uit te vinden of er iets van gewerkt heeft, moeten dezelfde tellingen later opnieuw gedaan worden — en tellingen die een tweede keer met de hand in elkaar gezet worden, zijn nooit helemaal de tellingen van de eerste keer. Een andere botlijst, een ander datumbereik, een andere grep.

Dus is het tellen naar een werktuig verhuisd met de nulmeting als constante erin geschreven. De eerste keer draaide het tegen juist het logboek waar de nulmeting uit kwam. Alles moest gelijk uitkomen.

Twee regels deden dat niet. Beide keren had het werktuig gelijk en de oorspronkelijke telling ongelijk.

geteldwerkelijkeigenaarstoken10weekfeed0398beide tellingen waren fout, in tegengestelde richting

grep leest de hele regel

De opvallendste bevinding van die week was dat het eigenaarstoken één keer voorkwam op een hele dag. Het was geteld met een patroon dat tegen hele logboekregels werd gehouden — en een logboekregel bevat de aanvraag, maar ook de verwijzer en de user agent.

De enige treffer was een &t= in de verwijzende URL van een zoekmachine. Iemand kwam binnen vanuit een mobiel zoekresultaat waarvan het adres toevallig die twee tekens bevatte. In de aanvragen zelf kwam het token nul keer voor.

De bevinding werd er sterker van, wat een vreemde manier is om ongelijk te hebben. Ze is nog steeds fout. Knip eerst het aanvraagveld eruit — het is het tweede veld tussen aanhalingstekens in een gecombineerde logboekregel — en zoek daarbinnen.

Een else-if-keten slokt het bijzondere geval op

De tweede telling zei dat de weekfeed nul keer was opgehaald. De indeling zag er redelijk uit:

if (url contains "/live/") ... else if (url contains "feed.xml") ...

Feedadressen op deze site zijn /live/<number>/feed.xml. Elk daarvan paste op de eerste tak en bereikte de tweede nooit. Het echte getal was 398.

De conclusie die uit het foute getal getrokken werd, hield toevallig stand: die 398 aanvragen zijn gelijkmatig verdeeld over alle elf taalvoorvoegsels onder drie algemene browsertekenreeksen, en dat is een crawler die elke vertaling neemt, geen abonnee. Niemand had zich geabonneerd. Maar "niemand geabonneerd" en "nul aanvragen" zijn verschillende uitspraken, en de tweede is meermaals aangehaald voordat iemand hem nakeek.

De controle die beide vangt

Laat het telwerktuig draaien tegen precies de dag waar de nulmeting uit komt. Elke regel moet gelijk uitkomen. Wat dat niet doet, is ofwel een fout in het werktuig ofwel een fout in de oorspronkelijke telling, en welke van de twee het is, komt eruit voordat het ertoe doet in plaats van erna.

Het kostte één keer draaien en ongeveer vier minuten. Beide getallen stonden toen al op schrift, en geen van beide zou gevangen zijn door de code zorgvuldiger te lezen — alleen door de meting zichzelf te laten verantwoorden.

Advertentie