Två sätt att räkna fel i en åtkomstlogg
En veckas ändringar här vilade på räkningar gjorda på en dags åtkomstlogg: en miljon rader, varav hundratusen var våra. För att ta reda på om något av det fungerade måste samma räkningar göras igen senare — och räkningar som sätts ihop för hand en andra gång blir aldrig riktigt desamma som första gången. En annan botlista, ett annat datumintervall, en annan grep.
Därför flyttades räkningen in i ett verktyg, med utgångsläget inskrivet som en konstant. Den första körningen gjordes mot just den logg som utgångsläget kom från. Allt måste bli lika.
Två rader blev det inte. Båda gångerna hade verktyget rätt och den ursprungliga räkningen fel.
grep läser hela raden
Veckans huvudfynd var att ägartoken förekom en gång under en hel dag. Den räknades med ett mönster som matchades mot hela loggrader — och en loggrad innehåller förfrågan, men också den hänvisande adressen och user agent-strängen.
Den enda träffen var &t= inuti en sökmotors hänvisnings-URL. Någon kom från ett mobilt sökresultat vars adress råkade innehålla just de två tecknen. I själva förfrågningarna förekom token noll gånger.
Fyndet blev starkare, vilket är ett märkligt sätt att ha fel på. Det är fortfarande fel. Klipp först ut förfrågefältet — det är det andra fältet inom citattecken i en loggrad i combined-format — och sök inuti det.
En else-if-kedja sväljer specialfallet
Den andra räkningen sa att veckoflödet hade hämtats noll gånger. Klassificeringen såg rimlig ut:
if (url contains "/live/") ... else if (url contains "feed.xml") ...
Flödesadresserna på den här webbplatsen är /live/<number>/feed.xml. Varenda en matchade den första grenen och nådde aldrig den andra. Den verkliga siffran var 398.
Slutsatsen som drogs av den felaktiga siffran råkade hålla: de 398 förfrågningarna är jämnt fördelade över alla elva språkprefix under tre generiska webbläsarsträngar, vilket är en sökrobot som hämtar varje översättning, inte en prenumerant. Ingen hade prenumererat. Men ”ingen prenumererade” och ”noll förfrågningar” är olika påståenden, och det andra citerades upprepade gånger innan någon kontrollerade det.
Kontrollen som fångar båda
Kör räkneverktyget mot exakt den dag som utgångsläget kom från. Varje rad måste bli lika. Allt som inte blir det är antingen ett fel i verktyget eller ett fel i den ursprungliga räkningen, och vilket det är kommer fram innan det spelar roll i stället för efteråt.
Det tog en körning och ungefär fyra minuter. Båda siffrorna hade vid det laget redan hunnit hamna i text, och ingen av dem hade upptäckts genom att läsa koden noggrannare — bara genom att låta mätningen stå till svars för sig själv.