इंफ्रास्ट्रक्चर मॉनिटरिंग
इंफ्रास्ट्रक्चर की चौबीसों घंटे निगरानी: उपलब्धता, लोड, स्पीड, SSL और डोमेन की वैधता। गड़बड़ी का पता आपको ग्राहकों से पहले लगता है — चेतावनी Telegram में आती है।
सेवा में क्या शामिल है
हम आपकी साइटों और सर्वरों को चौबीसों घंटे निगरानी में रखते हैं और ऐसा करते हैं कि किसी गड़बड़ी का पता आपको ग्राहकों से पहले लगे, न कि उनके फ़ोन कॉल से। इसमें संसाधनों की उपलब्धता की निगरानी, सर्वर लोड की मेट्रिक्स — प्रोसेसर, मेमोरी, डिस्क — पेज के जवाब की स्पीड, SSL सर्टिफ़िकेट और डोमेन रजिस्ट्रेशन की वैधता शामिल है। हम थ्रेशोल्ड और Telegram में अलर्ट सेट करते हैं ताकि चेतावनी तुरंत और सिर्फ़ काम की आए, शोर न बने। हम एक ही डैशबोर्ड बनाते हैं, जहाँ पूरे इंफ्रास्ट्रक्चर की स्थिति एक स्क्रीन पर दिखे। हम आपकी होस्टिंग की जगह नहीं लेते और साइटों के काम में दख़ल नहीं देते — हम आपके पास जो पहले से है उसके ऊपर एक अलग निगरानी सर्किट खड़ा करते हैं।
यह असल में कैसे काम करता है
मॉनिटरिंग कलेक्टरों और नियमों की एक जोड़ी की तरह बनी होती है। सर्वर पर एक एजेंट लगाया जाता है, जो मेट्रिक्स लेता है — लोड, मेमोरी, डिस्क पर जगह, सर्विसेज़ की स्थिति — और उन्हें केंद्रीय मॉनिटरिंग सर्वर को देता है; कुछ जाँचें बाहर से चलती हैं, असली उपयोगकर्ता के साइट पर आने की नकल करते हुए। जमा किए गए डेटा के ऊपर ट्रिगर काम करते हैं: ये थ्रेशोल्ड नियम होते हैं जैसे «उपलब्धता गिर गई», «डिस्क 90 प्रतिशत भर गई», «सर्टिफ़िकेट एक हफ़्ते में एक्सपायर होगा»। जब नियम चलता है, तो सिस्टम तय किए गए चैनल पर अलर्ट भेजता है — हमारे मामले में Telegram में — यह बताते हुए कि किस नोड पर क्या टूटा। ऐतिहासिक ग्राफ़ संग्रहित रहते हैं, इसलिए सिर्फ़ गड़बड़ी का तथ्य ही नहीं, बल्कि उस तक ले जाने वाला ट्रेंड भी दिखता है, जिससे फ़ेल होने से पहले ही कारण ठीक किया जा सके।
मॉनिटरिंग कहाँ से आई
व्यवस्थित नेटवर्क मॉनिटरिंग SNMP प्रोटोकॉल से बढ़ी, जिसके पहले स्पेसिफ़िकेशन 1988 में RFC के रूप में आए और नेटवर्क डिवाइसों की स्थिति एक समान ढंग से पूछने की सुविधा दी। सर्वरों और सर्विसेज़ की मॉनिटरिंग की व्यापक प्रथा NetSaint प्रोजेक्ट ने तय की: इंजीनियर एथन गाल्स्टाड ने पहला वर्ज़न 14 मार्च 1999 को जारी किया, और 2002 में ट्रेडमार्क विवाद के कारण प्रोजेक्ट का नाम बदलकर Nagios कर दिया गया, जिसके तहत वह डी-फ़ैक्टो स्टैंडर्ड बन गया। इसी धारा ने इंडस्ट्री की बुनियादी अवधारणाएँ — नोड, जाँच, थ्रेशोल्ड, अलर्ट — तय कीं, जिन्हें हम आज भी इस्तेमाल करते हैं। आगे के सिस्टमों ने टाइम-सीरीज़ स्टोरेज, नोड्स की ऑटो-डिस्कवरी और सुविधाजनक विज़ुअलाइज़ेशन जोड़ा, पर नींव SNMP और NetSaint ने रखी। इस इतिहास की समझ कोई सजावट नहीं, बल्कि इस बात का संकेत है कि हम निगरानी को सोच-समझकर बनाते हैं, न कि निर्देश देखकर कोई रैंडम एजेंट लगाते हैं।
सेटिंग की सटीकता क्यों अहम है
गलत तरीके से सेट की गई मॉनिटरिंग उसके न होने से भी ख़तरनाक है, क्योंकि यह नियंत्रण का झूठा एहसास पैदा करती है। बहुत संवेदनशील थ्रेशोल्ड चैनल को झूठी चेतावनियों से भर देते हैं, टीम उन्हें नज़रअंदाज़ करने की आदी हो जाती है — और असली गड़बड़ी चूक जाती है; बहुत मोटे थ्रेशोल्ड तब तक चुप रहते हैं जब तक साइट गिर न जाए। सेवा की इंजीनियरिंग वैल्यू ठीक इसी कैलिब्रेशन में है: किन मेट्रिक्स को क्रिटिकल माना जाए, किन मानों पर इंसान को जगाया जाए, और किन घटनाओं को बस ग्राफ़ में दर्ज किया जाए। अलर्ट स्पष्ट अर्थ के साथ आना चाहिए — क्या और कहाँ टूटा — वरना विश्लेषण में वह समय लगता है जो गड़बड़ी के दौरान नहीं होता। इसीलिए हम थ्रेशोल्ड आपके असली लोड के हिसाब से सेट करते हैं और अलर्ट की डिलीवरी जाँचते हैं, न कि डिफ़ॉल्ट मान सेट करके चले जाते हैं।
हम किस स्टैक पर काम करते हैं
मुख्य औज़ार — Zabbix: एजेंटों, सर्वर जाँचों, ट्रिगरों और इतिहास संग्रह वाली ओपन मॉनिटरिंग सिस्टम, जो उपलब्धता, हार्डवेयर मेट्रिक्स, SSL और डोमेन को एक ही सर्किट में कवर करती है। बहुत सारी डायनामिक मेट्रिक्स वाले प्रोजेक्टों के लिए हम Prometheus इस्तेमाल करते हैं — कंटेनर और क्लाउड माहौल के लिए बनी टाइम-सीरीज़ संग्रह प्रणाली। विज़ुअलाइज़ेशन हम Grafana में बनाते हैं: एक जैसे डैशबोर्ड, जहाँ पूरे इंफ्रास्ट्रक्चर की स्थिति एक स्क्रीन पर दिखे। अलर्ट हम Telegram में सेट करते हैं ताकि चेतावनी वहाँ आए जहाँ टीम उसे सचमुच देखे। स्टैक ओपन है और आपकी ओर खड़ा होता है, इसलिए आपके इंफ्रास्ट्रक्चर का डेटा आपके पास रहता है, न कि किसी बाहरी पेड सर्विस में चला जाता है।
प्रमुख औज़ार कब आए
मॉनिटरिंग के औज़ार तीन दशकों से ज़्यादा में बने हैं। SNMP प्रोटोकॉल, जिससे नेटवर्क की मानकीकृत निगरानी शुरू हुई, 1988 में RFC में आकार पाया। NetSaint, भावी Nagios, 14 मार्च 1999 को आया और सर्विस मॉनिटरिंग की व्यापक प्रथा तय की। Zabbix, हमारा मुख्य औज़ार, अलेक्सेय व्लादिशेव ने बनाया: प्रोजेक्ट 2001 में शुरू हुआ, और डेवलपर कंपनी रीगा में स्थित है। Prometheus 2012 में SoundCloud कंपनी के भीतर उभरा और बाद में Cloud Native Computing Foundation का प्रोजेक्ट बना। Grafana, हमारा विज़ुअलाइज़ेशन औज़ार, इंजीनियर टोरकेल ओडेगोर ने जनवरी 2014 में Graphite पर काम के विकास के रूप में जारी किया। हम इन सिस्टमों के मौजूदा वर्ज़न पर काम करते हैं और समझते हैं कि कौन-सा किस काम के लिए उपयुक्त है।
यह हम पर क्यों भरोसा किया जा सकता है
हमारी टीम का IT में कुल अनुभव 45 साल से ज़्यादा है, और मॉनिटरिंग हमारे लिए एक काम करने वाली प्रथा है, न कि एक-बारगी सेटिंग: हम खुद दस से ज़्यादा प्रोडक्शन साइटों को Zabbix के ज़रिए Telegram अलर्ट के साथ निगरानी में रखते हैं। हम इस काम को इंजीनियरों की तरह देखते हैं: नोड्स का इन्वेंट्री बनाते हैं, मेट्रिक्स चुनते हैं, थ्रेशोल्ड आपके लोड के हिसाब से कैलिब्रेट करते हैं और ज़रूर जाँचते हैं कि चेतावनी सचमुच इंसान तक पहुँचती है। निगरानी सर्किट हम आपकी ओर खड़ा करते हैं, इसलिए डेटा आपके पास रहता है, न कि किसी और के क्लाउड में। हम सीधे कहेंगे कि कौन-सी जाँचें फ़ायदा देंगी और कौन-सी फ़ालतू शोर होंगी, और सिर्फ़ दिखावे के लिए मॉनिटरिंग नहीं बेचेंगे। नतीजे में आपको गड़बड़ियों की जल्दी चेतावनी और इंफ्रास्ट्रक्चर की स्थिति की साफ़ तस्वीर मिलती है, न कि बेकार सूचनाओं का सैलाब।
क्या शामिल है
हम कैसे काम करते हैं
गड़बड़ियों की जल्दी चेतावनी और इंफ्रास्ट्रक्चर की साफ़ तस्वीर एक स्क्रीन पर। चेतावनी — सिर्फ़ काम की।
सवाल और जवाब
अलर्ट कहाँ आते हैं?+
Telegram में — तुरंत और सिर्फ़ सेट किए थ्रेशोल्ड पर, बिना शोर के।
मॉनिटरिंग का डेटा किसके पास रहता है?+
आपकी ओर — सर्किट हम आपके पास खड़ा करते हैं, किसी बाहरी पेड सर्विस में कुछ नहीं जाता।
आप वास्तव में क्या ट्रैक करते हैं?+
उपलब्धता, सर्वर लोड, जवाब की स्पीड, SSL और डोमेन की वैधता — आपके क्रिटिकल थ्रेशोल्ड के हिसाब से।