सहायता से संपर्क करें

हम ईमेल से जवाब देते हैं, आम तौर पर दो दिन के अंदर।

Google reCAPTCHA दुरुपयोग से बचाव के लिए इस सबमिशन की जाँच करता है; इसके लिए डेटा Google को भेजा जाता है। स्क्रिप्ट तभी लोड होती है, जब यह फ़ॉर्म खोला जाता है।

← सभी पोस्ट

एक्सेस लॉग को गलत गिनने के दो तरीके

यहाँ एक हफ़्ते के बदलाव एक्सेस लॉग के एक दिन से ली गई गिनतियों पर टिके थे: दस लाख लाइनें, जिनमें से एक लाख हमारी। यह पता लगाने के लिए कि इनमें से कुछ काम आया या नहीं, वही गिनतियाँ बाद में फिर से करनी होंगी — और हाथ से दूसरी बार जोड़ी गई गिनतियाँ कभी ठीक पहली बार वाली नहीं होतीं। बॉट की अलग सूची, तारीखों की अलग सीमा, एक अलग grep।

इसलिए गिनती एक टूल में चली गई, जिसमें बेसलाइन एक स्थिर मान के रूप में लिखी हुई है। पहली बार इसे ठीक उसी लॉग पर चलाया गया जिससे बेसलाइन आई थी। सब कुछ बराबर निकलना चाहिए था।

दो लाइनें बराबर नहीं निकलीं। दोनों बार टूल सही था और मूल गिनती गलत।

गिना गयाअसल मेंमालिक टोकन10साप्ताहिक फ़ीड0398दोनों गिनतियाँ उल्टी दिशाओं में गलत थीं

grep पूरी लाइन पढ़ता है

हफ़्ते की सबसे बड़ी खोज यह थी कि मालिक टोकन पूरे एक दिन में सिर्फ़ एक बार आया। इसे एक ऐसे पैटर्न से गिना गया था जो पूरी लॉग लाइनों पर मिलाया गया — और लॉग लाइन में अनुरोध तो होता है, लेकिन रेफ़रर और यूज़र एजेंट भी।

अकेला मैच एक &t= था, जो एक सर्च इंजन के रेफ़रर URL के अंदर था। कोई व्यक्ति मोबाइल सर्च के एक नतीजे से आया था, जिसके पते में संयोग से ये दो अक्षर थे। खुद अनुरोधों में टोकन शून्य बार आया।

खोज और मज़बूत हो गई, जो गलत होने का एक अजीब तरीका है। फिर भी यह गलत है। पहले अनुरोध वाला फ़ील्ड अलग निकालें — combined लॉग लाइन में यह उद्धरण चिह्नों के बीच वाला दूसरा फ़ील्ड है — और उसी के अंदर खोजें।

else-if की कड़ी खास मामले को निगल जाती है

दूसरी गिनती के मुताबिक साप्ताहिक फ़ीड के लिए एक भी अनुरोध नहीं आया था। वर्गीकरण ठीक-ठाक लग रहा था:

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

इस वेबसाइट पर फ़ीड के पते इस तरह के होते हैं: /live/<number>/feed.xml। हर एक पता पहली शाखा से मेल खा गया और दूसरी तक कभी पहुँचा ही नहीं। असली संख्या 398 थी।

गलत संख्या से निकाला गया नतीजा संयोग से बच गया: वे 398 अनुरोध सभी ग्यारह भाषा प्रीफ़िक्स पर बराबर बँटे हैं, ब्राउज़र की तीन आम पहचान स्ट्रिंग के साथ, यानी यह हर अनुवाद को उठाता एक क्रॉलर है, कोई सब्सक्राइबर नहीं। किसी ने सब्सक्राइब नहीं किया था। लेकिन “किसी ने सब्सक्राइब नहीं किया” और “शून्य अनुरोध” दो अलग बातें हैं, और दूसरी बात किसी के जाँचने से पहले कई बार दोहराई जा चुकी थी।

वह जाँच जो दोनों को पकड़ लेती है

गिनती वाले टूल को ठीक उसी दिन के लॉग पर चलाएँ जिससे बेसलाइन आई थी। हर लाइन बराबर निकलनी चाहिए। जो बराबर नहीं निकलती, वह या तो टूल की गड़बड़ी है या मूल गिनती की, और कौन-सी है, यह बात मायने रखने से पहले ही सामने आ जाती है, बाद में नहीं।

इसमें एक बार चलाना और लगभग चार मिनट लगे। तब तक दोनों संख्याएँ लिखित रूप में सामने आ चुकी थीं, और कोड को ज़्यादा ध्यान से पढ़कर इनमें से कोई भी पकड़ में नहीं आती — सिर्फ़ माप को खुद अपना हिसाब देने पर मजबूर करके ही।

विज्ञापन