𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗮 𝗠𝘂𝗹𝘁𝗶-𝗥𝗲𝗴𝗶𝗼𝗻 𝗛𝗲𝗮𝗹𝘁𝗵-𝗖𝗵𝗲𝗰𝗸 𝗔𝗴𝗴𝗿𝗲𝗴𝗮𝘁𝗼𝗿
साओ पाउलोमधील (São Paulo) एक वापरकर्ता एका निकामी (dead) एज नोडवर पोहोचतो. तो कोणताही बग रिपोर्ट दाखल करत नाही. तो टॅब बंद करतो आणि दुसरे काहीतरी पाहू लागतो.
एक सामान्य अपटाइम मॉनिटर (uptime monitor) हे लक्षात घेऊ शकत नाही. बहुतेक मॉनिटर्स एकाच ठिकाणाहून तपासणी (probe) करतात. त्या एका ठिकाणाहून सर्व काही व्यवस्थित (green) दिसते.
आमचे स्टेटस पेज १००% अपटाइम दाखवत असे, तर प्रत्यक्ष वापरकर्त्यांना टाइमआउट्स (timeouts) जाणवत होते. एक जागतिक हेल्थ चेक आम्हाला चुकीची माहिती देत होता.
सत्य सांगणारी अशी प्रणाली आम्ही कशी तयार केली, ते खाली दिले आहे.
समस्या: सॅम्पलिंग बायस (Sampling Bias) जर तुमचा मॉनिटर एकाच डेटा सेंटरमध्ये असेल, तर त्याला फक्त एकच वास्तव दिसते. तुमचे सिंगापूर आणि साओ पाउलो एज कनेक्शन ड्रॉप करत असूनही तुम्ही सर्व काही 'ग्रीन' (व्यवस्थित) असल्याचे रिपोर्ट करू शकता.
व्हिडिओ ट्रॅफिकमुळे ही समस्या अधिक गंभीर होते. सामान्य प्रादेशिक त्रुटींमध्ये (regional failures) खालील गोष्टींचा समावेश होतो:
- एका खंडावर परिणाम करणारे खराब BGP रूट्स.
- कॅशे इव्हिक्शनमुळे (Cache evictions) ओरिजिन फॉलबॅक स्लो होणे.
- डिस्क एररमुळे TLS हँडशेक टाइमआउट होणे.
- विशिष्ट स्थानिक रिझॉल्व्हर्समधील (local resolvers) DNS समस्या.
एक "200 OK" प्रतिसाद तुम्हाला जवळजवळ काहीच सांगत नाही.
आरोग्यासाठी (Health) आमचे तीन नियम: आम्ही केवळ स्टेटस कोड्सपुरते मर्यादित न राहता, तीन मेट्रिक्सचा वापर करून 'हेल्थ' परिभाषित केली आहे:
- पोहोचण्यायोग्यता (Reachability): TCP आणि TLS हँडशेक्स ८००ms च्या आत पूर्ण झाले पाहिजेत.
- लॅटन्सी (Latency): आम्ही p95 Time-to-First-Byte (TTFB) ट्रॅक करतो. सरासरी (Averages) मूल्ये त्या संथ वेगाला (slow tail) लपवून ठेवतात ज्यामुळे वापरकर्ते त्रस्त होतात.
- अचूकता (Correctness): रिस्पॉन्स बॉडीमध्ये अपेक्षित मार्कर असणे आवश्यक आहे. जर 200 OK प्रतिसाद एरर पेज दाखवत असेल, तर ती एक त्रुटी (failure) आहे.
उपाय: मल्टी-रीजन प्रोबिंग (Multi-Region Probing) आम्ही एक मोठा मॉनिटर वापरणे थांबवले. त्याऐवजी, आम्ही स्वस्त प्रादेशिक VPS इन्स्टन्सेसवर लहान Go बायनरीज (binaries) तैनात करतो.
प्रत्येक प्रोबर (prober):
- स्थानिक दृष्टिकोनातून (vantage point) एज तपासतो.
- वास्तविक TTFB डेटा मिळवण्यासाठी
httptraceवापरतो. - निकाल एका मध्यवर्ती अॅग्रिगेटरला (central aggregator) पोस्ट करतो.
आम्ही स्टोरेजसाठी SQLite वापरतो. ते साधे आहे आणि कोणत्याही अतिरिक्त ओव्हरहेडशिवाय (zero overhead) आमचा वर्कलोड हाताळते. आम्ही प्री-अॅग्रिगेटेड डेटाऐवजी रॉ सॅम्पल्स (raw samples) साठवतो. यामुळे आम्हाला नंतर इतिहास पुन्हा स्कोर करण्यास किंवा विशिष्ट त्रुटी शोधण्यास (debug) मदत होते.
गुपित: कोरम (Quorum) नेटवर्कमध्ये गोंधळ (noise) असू शकतो. एक पॅकेट ड्रॉप होणे म्हणजे आउटेज (outage) नाही.
चुकीचे अलार्म (false alarms) टाळण्यासाठी आम्ही कोरम सिस्टम वापरतो. जेव्हा अनेक प्रदेश सहमत होतात, तेव्हाच आम्ही एज "डाऊन" (down) घोषित करतो. जर एका प्रदेशात त्रुटी दिसत असेल पण इतरत्र नसेल, तर आम्ही टीमला पेज (page) करत नाही. या डिझाइन निवडीमुळे आमचे ९०% चुकीचे अलर्ट्स कमी झाले.
महत्त्वाचे धडे:
- वापरकर्ते ज्या मार्गाचा वापर करतात त्याचे प्रोबिंग करा, केवळ कृत्रिम (synthetic) मार्गाचे नाही.
- सरासरीऐवजी टेल लॅटन्सी (tail latency - p95) ट्रॅक करा.
- अनेक प्रदेशांमध्ये स्वस्त आणि तात्पुरते (disposable) प्रोबर्स वापरा.
- पेजर फॅटीग (pager fatigue) टाळण्यासाठी कोरम वापरा.
- तुमचे स्टोरेज स्टॅक साधे ठेवा.
तुम्हाला एखाद्या जड ऑब्झर्व्हेबिलिटी प्लॅटफॉर्मची गरज नाही. तुम्हाला स्थानिक प्रोब्स, कच्चा डेटा आणि गोंधळामुळे (noise) घाबरणार नाही असा एक नियम हवा आहे.