Írjon a támogatásnak

E-mailben válaszolunk, általában két napon belül.

A Google reCAPTCHA visszaélés elleni védelemként ellenőrzi ezt a beküldést; ennek során adatok jutnak el a Google-hoz. A szkript csak az űrlap megnyitásakor töltődik be.

← Összes bejegyzés

Kétféle tévedés egy hozzáférési napló megszámolásakor

Egy hétnyi változtatás itt a hozzáférési napló egyetlen napjából vett számlálásokon alapult: egymillió sor, ebből százezer a miénk. Hogy kiderüljön, működött-e bármi belőle, később ugyanezeket a számlálásokat újra el kell végezni – és a kézzel másodszor összerakott számok sosem pontosan azonosak az elsőkkel. Más botlista, más dátumtartomány, más grep.

Ezért a számlálás átkerült egy eszközbe, amelybe az alapértékek állandóként be vannak írva. Az első futtatás pontosan azon a naplón ment, amelyből az alapértékek származtak. Mindennek egyeznie kellett.

Két sor nem egyezett. Mindkét esetben az eszköznek volt igaza, és az eredeti számlálás volt hibás.

számoltvalójábantulajdonosi token10heti hírcsatorna0398mindkét számlálás ellentétes irányban tévedett

A grep az egész sort olvassa

A hét fő megállapítása az volt, hogy a tulajdonosi token egy teljes nap alatt egyszer fordult elő. Egy olyan mintával számoltuk, amelyet teljes naplósorokra illesztettünk – egy naplósor pedig a kérést tartalmazza, de a hivatkozót és a user agentet is.

Az egyetlen találat egy &t= volt, egy keresőmotor hivatkozó URL-jében. Valaki egy mobilos keresési találatról érkezett, amelynek címében véletlenül éppen ez a két karakter szerepelt. Magukban a kérésekben a token nulla alkalommal fordult elő.

A megállapítás így még erősebb lett, ami furcsa módja a tévedésnek. Attól még tévedés. Előbb vágja ki a kérés mezőjét – a kombinált naplósor második idézőjeles mezője –, és abban keressen.

Egy else-if lánc elnyeli a specifikus esetet

A második számlálás szerint a heti hírcsatornát nullaszor kérték le. Az osztályozás észszerűnek tűnt:

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

Ezen a weboldalon a hírcsatornák címe így néz ki: /live/<number>/feed.xml. Egytől egyig az első ágra illeszkedtek, és sosem jutottak el a másodikig. A valós szám 398 volt.

A hibás számból levont következtetés véletlenül megállta a helyét: az a 398 kérés egyenletesen oszlik el mind a tizenegy nyelvi előtag között, három általános böngésző-azonosító alatt – ez egy minden fordítást lekérő robot, nem feliratkozó. Senki sem iratkozott fel. De a „senki sem iratkozott fel” és a „nulla kérés” két különböző állítás, és a másodikat többször is idézték, mielőtt bárki ellenőrizte volna.

Az ellenőrzés, amely mindkettőt kiszűri

Futtassa le a számlálóeszközt pontosan arra a napra, amelyből az alapértékek származnak. Minden sornak egyeznie kell. Ami nem egyezik, az vagy az eszköz hibája, vagy az eredeti számlálásé – és hogy melyik, az még azelőtt kiderül, hogy számítana, nem utána.

Egy futtatás és nagyjából négy perc kellett hozzá. Addigra mindkét szám írásban is megjelent már, és egyiket sem fogta volna meg a kód alaposabb olvasása – csak az, hogy a mérésnek önmagáról kellett számot adnia.

Hirdetés