एसआरई (साइट विश्वसनीयता इंजीनियरिंग) वेब परियोजनाओं की उपलब्धता सुनिश्चित करने का एक दृष्टिकोण है। इसे DevOps के लिए एक रूपरेखा माना जाता है और DevOps प्रथाओं को लागू करने में सफलता कैसे प्राप्त की जाए, इसके बारे में बात करता है। इस लेख में अनुवाद अध्याय 6 वितरित प्रणालियों की निगरानी पुस्तकें साइट विश्वसनीयता इंजीनियरिंग गूगल से. मैंने यह अनुवाद स्वयं तैयार किया और निगरानी प्रक्रियाओं को समझने में अपने अनुभव पर भरोसा किया। टेलीग्राम चैनल में @monitorim_it и माध्यम पर ब्लॉग मैंने सेवा स्तर के लक्ष्यों के बारे में उसी पुस्तक के अध्याय 4 के अनुवाद का एक लिंक भी प्रकाशित किया।

बिल्ली द्वारा अनुवाद. मन लगाकर पढ़ाई करो!

सफल निगरानी और अधिसूचना प्रणाली बनाने के लिए Google की SRE टीमों के पास बुनियादी सिद्धांत और सर्वोत्तम प्रथाएँ हैं। यह अध्याय इस बात पर मार्गदर्शन प्रदान करता है कि एक वेब पेज विज़िटर को किन समस्याओं का सामना करना पड़ सकता है और उन समस्याओं को कैसे हल किया जाए जो वेब पेजों को प्रदर्शित करना कठिन बनाती हैं।

को परिभाषित

निगरानी से संबंधित विषयों पर चर्चा करने के लिए कोई एकल शब्दावली का उपयोग नहीं किया जाता है। यहां तक ​​कि Google पर भी, नीचे दिए गए शब्दों का आमतौर पर उपयोग नहीं किया जाता है, लेकिन हम सबसे आम व्याख्याओं को सूचीबद्ध करेंगे।

निगरानी

सिस्टम के बारे में वास्तविक समय में मात्रात्मक डेटा का संग्रह, प्रसंस्करण, एकत्रीकरण और प्रदर्शन: अनुरोधों की संख्या और अनुरोधों के प्रकार, त्रुटियों की संख्या और त्रुटियों के प्रकार, अनुरोध प्रसंस्करण समय और सर्वर अपटाइम।

व्हाइट-बॉक्स निगरानी

आंतरिक सिस्टम घटकों द्वारा प्रदर्शित मेट्रिक्स पर आधारित निगरानी, ​​जिसमें लॉग, जावा वर्चुअल मशीन प्रोफाइलिंग मेट्रिक्स, या HTTP हैंडलर मेट्रिक्स शामिल हैं जो आंतरिक आंकड़े उत्पन्न करते हैं।

ब्लैक-बॉक्स निगरानी

उपयोगकर्ता के दृष्टिकोण से एप्लिकेशन व्यवहार का परीक्षण करना।

डैशबोर्ड

एक इंटरफ़ेस (आमतौर पर वेब) जो सेवाओं के प्रमुख स्वास्थ्य संकेतकों का अवलोकन प्रदान करता है। डैशबोर्ड में फ़िल्टर, दिखाए गए संकेतकों का चयन करने की क्षमता आदि हो सकती है। इंटरफ़ेस को उन संकेतकों की पहचान करने के लिए डिज़ाइन किया गया है जो उपयोगकर्ताओं के लिए सबसे महत्वपूर्ण हैं। डैशबोर्ड तकनीकी सहायता कर्मचारियों के लिए जानकारी भी प्रदर्शित कर सकता है: अनुरोधों की एक कतार, उच्च प्राथमिकता वाली त्रुटियों की एक सूची, और जिम्मेदारी के किसी दिए गए क्षेत्र के लिए एक निर्दिष्ट इंजीनियर।

चेतावनी (सूचना)

किसी व्यक्ति द्वारा ईमेल या अन्य माध्यमों से प्राप्त की जाने वाली सूचनाएं, जो त्रुटियों या अनुरोध कतार में वृद्धि के कारण उत्पन्न हो सकती हैं। सूचनाओं को इस प्रकार वर्गीकृत किया गया है: टिकट, ईमेल अलर्ट और त्वरित मैसेंजर संदेश।

मूल कारण

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

नोड और मशीन (नोड और मशीन)

भौतिक सर्वर, वर्चुअल मशीन या कंटेनर पर चल रहे एप्लिकेशन के एकल उदाहरण को संदर्भित करने के लिए विनिमेय शब्द। एक मशीन कई सेवाओं की मेजबानी कर सकती है। सेवाएँ हो सकती हैं:

• एक दूसरे से जुड़े हुए: उदाहरण के लिए, एक कैशिंग सर्वर और एक वेब सर्वर;
• हार्डवेयर के एक टुकड़े पर असंबंधित सेवाएँ: उदाहरण के लिए, एक कोड रिपॉजिटरी और कॉन्फ़िगरेशन सिस्टम के लिए एक विज़ार्ड, जैसे कठपुतली या महाराज.

धक्का

सॉफ़्टवेयर कॉन्फ़िगरेशन में कोई भी परिवर्तन।

निगरानी की आवश्यकता क्यों है?

ऐसे कई कारण हैं जिनकी वजह से अनुप्रयोगों की निगरानी की आवश्यकता होती है:

दीर्घकालिक रुझानों का विश्लेषण

डेटाबेस कितना बड़ा है और यह कितनी तेजी से बढ़ रहा है? उपयोगकर्ताओं की दैनिक संख्या कैसे बदलती है?

प्रदर्शन तुलना

क्या अजाक्स डीबी 2.72 की तुलना में बाइट्स 3.14 के एक्मे बकेट पर अनुरोध तेज़ हैं? अतिरिक्त नोड की उपस्थिति के बाद कैश किए गए अनुरोध कितने बेहतर हैं? क्या साइट पिछले सप्ताह की तुलना में धीमी चल रही है?

सूचना देने वाले

कुछ टूट गया है और किसी को इसे ठीक करने की ज़रूरत है। या कुछ जल्द ही टूट जाएगा और किसी को जल्द ही इसकी जांच करने की ज़रूरत है।

डैशबोर्ड बनाना

डैशबोर्ड में बुनियादी प्रश्नों का उत्तर होना चाहिए और इसमें से कुछ शामिल होना चाहिए "4 सुनहरे संकेत" - विलंब (विलंबता), ट्रैफ़िक (यातायात), त्रुटियां (त्रुटियां) और लोड आकार (संतृप्ति)।

पूर्वव्यापी विश्लेषण का संचालन (डीबगिंग)

अनुरोध प्रसंस्करण में देरी बढ़ गई है, लेकिन उसी समय के आसपास और क्या हुआ?
निगरानी प्रणालियाँ व्यावसायिक खुफिया प्रणालियों के लिए डेटा के स्रोत के रूप में और सुरक्षा घटनाओं के विश्लेषण की सुविधा के लिए उपयोगी हैं। क्योंकि यह पुस्तक उन इंजीनियरिंग क्षेत्रों पर केंद्रित है जिनमें एसआरई के पास विशेषज्ञता है, हम यहां निगरानी तकनीकों पर चर्चा नहीं करेंगे।

निगरानी और अलर्ट सिस्टम को आपको यह बताने की अनुमति देते हैं कि यह कब खराब हो गया है या खराब होने वाला है। जब कोई सिस्टम स्वचालित रूप से स्वयं की मरम्मत नहीं कर सकता है, तो हम चाहते हैं कि एक मानव अलर्ट का विश्लेषण करे, यह निर्धारित करे कि क्या समस्या अभी भी सक्रिय है, इसे हल करें और मूल कारण निर्धारित करें। यदि आप सिस्टम घटकों का ऑडिट नहीं करते हैं, तो आपको कभी भी केवल इसलिए अलर्ट प्राप्त नहीं होगा क्योंकि "कुछ थोड़ा अजीब लगता है।"

किसी व्यक्ति पर सूचनाओं का बोझ डालना किसी कर्मचारी के समय का काफी महंगा उपयोग है। यदि कर्मचारी काम कर रहा है, तो अलर्ट कार्य प्रक्रिया को बाधित करता है। यदि कर्मचारी घर पर है, तो अलर्ट व्यक्तिगत समय और संभवतः नींद में बाधा डालता है। जब अलर्ट बहुत बार आते हैं, तो कर्मचारी उन पर नज़र रखते हैं, उन्हें बंद कर देते हैं, या आने वाले अलर्ट को अनदेखा कर देते हैं। समय-समय पर वे वास्तविक चेतावनी को नजरअंदाज कर देते हैं, जो शोर की घटनाओं के कारण छिप जाती है। सेवा में रुकावट लंबे समय तक रह सकती है क्योंकि शोर की घटनाएँ समस्या का शीघ्र निदान और सुधार करने से रोकती हैं। प्रभावी चेतावनी प्रणालियों में सिग्नल-टू-शोर अनुपात अच्छा होता है।

निगरानी प्रणाली के लिए उचित अपेक्षाएँ निर्धारित करना

किसी जटिल एप्लिकेशन के लिए निगरानी स्थापित करना अपने आप में एक जटिल इंजीनियरिंग कार्य है। संग्रह, प्रदर्शन और अलर्टिंग टूल के महत्वपूर्ण बुनियादी ढांचे के साथ भी, 10-12 सदस्यों की Google SRE टीम में आम तौर पर एक या दो लोग शामिल होते हैं जिनका प्राथमिक उद्देश्य निगरानी प्रणाली बनाना और बनाए रखना है। समय के साथ यह संख्या कम हो गई है क्योंकि हम निगरानी बुनियादी ढांचे को समेकित और केंद्रीकृत करते हैं, लेकिन प्रत्येक एसआरई टीम में आम तौर पर कम से कम एक व्यक्ति होता है जो पूरी तरह से निगरानी के लिए समर्पित होता है। हमें यह कहना होगा कि मॉनिटरिंग सिस्टम डैशबोर्ड देखना काफी दिलचस्प है, एसआरई टीमें उन स्थितियों से बचने के लिए सावधान रहती हैं जिनके लिए समस्याओं की निगरानी के लिए किसी को स्क्रीन देखने की आवश्यकता होती है।

कुल मिलाकर, Google इष्टतम तथ्य-पश्चात विश्लेषण टूल के साथ सरल और तेज़ निगरानी प्रणालियों की ओर बढ़ गया है। हम "जादुई" प्रणालियों से बचते हैं जो सीमा की भविष्यवाणी करने या स्वचालित रूप से मूल कारण का पता लगाने की कोशिश करते हैं। अंतिम-उपयोगकर्ता अनुरोधों में अनपेक्षित सामग्री का पता लगाने वाले सेंसर ही एकमात्र प्रति-उदाहरण हैं; जब तक ये सेंसर सरल रहेंगे, वे गंभीर विसंगतियों के कारणों का तुरंत पता लगा सकते हैं। निगरानी डेटा का उपयोग करने के अन्य प्रारूप, जैसे क्षमता योजना या यातायात पूर्वानुमान, अधिक जटिल हैं। कम नमूना दर (घंटे या दिन) पर बहुत लंबी अवधि (महीनों या वर्षों) में अवलोकन से दीर्घकालिक प्रवृत्ति का पता चलेगा।

Google SRE टीम को जटिल निर्भरता पदानुक्रम के साथ मिश्रित सफलता मिली है। हम शायद ही कभी नियमों का उपयोग करते हैं जैसे "अगर मुझे पता चलता है कि डेटाबेस धीमा है, तो मुझे अलर्ट मिलता है कि डेटाबेस धीमा है, अन्यथा मुझे अलर्ट मिलता है कि साइट धीमी है।" निर्भरता-आधारित नियम आम तौर पर हमारे सिस्टम के अपरिवर्तनीय भागों को संदर्भित करते हैं, जैसे डेटा सेंटर में उपयोगकर्ता ट्रैफ़िक को फ़िल्टर करने की प्रणाली। उदाहरण के लिए, "यदि डेटा सेंटर में ट्रैफ़िक फ़िल्टरिंग कॉन्फ़िगर की गई है, तो उपयोगकर्ता अनुरोधों को संसाधित करने में देरी के बारे में मुझे सचेत न करें" डेटा सेंटर से अलर्ट के लिए एक सामान्य नियम है। Google की कुछ टीमें जटिल निर्भरता पदानुक्रम का समर्थन करती हैं क्योंकि हमारे बुनियादी ढांचे में निरंतर रिफैक्टरिंग की दर स्थिर रहती है।

इस अध्याय में वर्णित कुछ विचार अभी भी प्रासंगिक हैं: लक्षण से मूल कारण तक तेजी से आगे बढ़ने का हमेशा अवसर होता है, खासकर लगातार बदलती प्रणालियों में। इसलिए, जबकि यह अध्याय निगरानी प्रणालियों के लिए कुछ लक्ष्यों और उन लक्ष्यों को कैसे प्राप्त किया जाए, इसकी रूपरेखा बताता है, यह महत्वपूर्ण है कि निगरानी प्रणालियां टीम में सभी के लिए सरल और समझने योग्य हों।

इसी तरह, शोर के स्तर को कम और सिग्नल के स्तर को ऊंचा रखने के लिए, सतर्क संपत्तियों की निगरानी के दृष्टिकोण बहुत सरल और विश्वसनीय होने चाहिए। लोगों के लिए चेतावनी उत्पन्न करने वाले नियमों को समझना और स्पष्ट समस्या प्रस्तुत करना आसान होना चाहिए।

लक्षण बनाम कारण

आपके निगरानी तंत्र को दो प्रश्नों का उत्तर देना चाहिए: "क्या टूटा" और "यह क्यों टूटा।"
"क्या टूटा" लक्षण के बारे में बात करता है, और "यह क्यों टूटा" कारण के बारे में बात करता है। नीचे दी गई तालिका ऐसे कनेक्शनों के उदाहरण दिखाती है.

लक्षण
कारण

HTTP त्रुटि 500 ​​या 404 प्राप्त हो रही है
डेटाबेस सर्वर कनेक्शन अस्वीकार करते हैं

धीमी सर्वर प्रतिक्रियाएँ
उच्च CPU उपयोग या क्षतिग्रस्त ईथरनेट केबल

अंटार्कटिका में उपयोगकर्ताओं को कैट जीआईएफ प्राप्त नहीं हो रहे हैं
आपका सीडीएन वैज्ञानिकों और बिल्लियों से नफरत करता है, इसलिए कुछ आईपी पते काली सूची में डाल दिए गए

निजी सामग्री हर जगह से उपलब्ध हो गई है
एक नए सॉफ़्टवेयर रिलीज़ के रोलआउट ने फ़ायरवॉल को सभी ACLs को भुला दिया और सभी को अंदर आने दिया

अधिकतम सिग्नल और न्यूनतम शोर के साथ एक अच्छी निगरानी प्रणाली बनाने के लिए "क्या" और "क्यों" कुछ सबसे महत्वपूर्ण बिल्डिंग ब्लॉक हैं।

ब्लैक-बॉक्स बनाम व्हाइट-बॉक्स

हम महत्वपूर्ण मेट्रिक्स के लिए व्यापक व्हाइट-बॉक्स मॉनिटरिंग को मामूली ब्लैक-बॉक्स मॉनिटरिंग के साथ जोड़ते हैं। ब्लैक-बॉक्स की तुलना व्हाइट-बॉक्स से करने का सबसे आसान तरीका यह है कि ब्लैक-बॉक्स लक्षण-केंद्रित है और सक्रिय निगरानी के बजाय प्रतिक्रियाशील है: "सिस्टम अभी सही ढंग से काम नहीं कर रहा है।" व्हाइट-बॉक्स सिस्टम की आंतरिक सत्यापन क्षमताओं पर निर्भर करता है: इवेंट लॉग या वेब सर्वर। इस प्रकार, व्हाइट-बॉक्स आपको आसन्न समस्याओं, दोषों का पता लगाने की अनुमति देता है जो अनुरोध के पुन: प्रसारण के रूप में प्रतीत होते हैं, आदि।

ध्यान दें कि एक बहु-परत प्रणाली में, एक इंजीनियर के उत्तरदायित्व के क्षेत्र में एक लक्षण दूसरे इंजीनियर के उत्तरदायित्व के क्षेत्र में एक लक्षण होता है। उदाहरण के लिए, डेटाबेस प्रदर्शन में कमी आई है. धीमा डेटाबेस पढ़ना डेटाबेस एसआरई का एक लक्षण है जो उनका पता लगाता है। हालाँकि, एक धीमी वेबसाइट का अवलोकन करने वाले फ्रंट-एंड एसआरई के लिए, उसी धीमी डेटाबेस रीड का कारण एक धीमा डेटाबेस है। इसलिए, व्हाइट-बॉक्स मॉनिटरिंग कभी-कभी लक्षण-केंद्रित होती है और कभी-कभी कारण-केंद्रित होती है, यह इस बात पर निर्भर करता है कि यह कितनी व्यापक है।

डिबगिंग के लिए टेलीमेट्री एकत्र करते समय, व्हाइट-बॉक्स मॉनिटरिंग की आवश्यकता होती है। यदि वेब सर्वर डेटाबेस प्रश्नों का उत्तर देने में धीमे हैं, तो आपको यह जानना होगा कि वेब सर्वर डेटाबेस के साथ कितनी तेजी से संचार करता है और कितनी तेजी से प्रतिक्रिया देता है। अन्यथा, आप धीमे डेटाबेस सर्वर और वेब सर्वर और डेटाबेस के बीच नेटवर्क समस्या के बीच अंतर नहीं कर पाएंगे।

अलर्ट भेजते समय ब्लैक-बॉक्स मॉनिटरिंग का एक महत्वपूर्ण लाभ होता है: आप प्राप्तकर्ता को अधिसूचना तब ट्रिगर करते हैं जब समस्या पहले से ही वास्तविक लक्षणों के रूप में सामने आती है। दूसरी ओर, ब्लैक-बॉक्स समस्या के लिए निगरानी बेकार है जो अभी तक उत्पन्न नहीं हुई है लेकिन आसन्न है।

चार सुनहरे संकेत

चार सुनहरे निगरानी संकेत विलंबता, यातायात, त्रुटियां और संतृप्ति हैं। यदि आप केवल चार उपयोगकर्ता सिस्टम मेट्रिक्स माप सकते हैं, तो उन चार पर ध्यान केंद्रित करें।

देरी

अनुरोध पर कार्रवाई करने के लिए आवश्यक समय. सफल और असफल अनुरोधों की विलंबता के बीच अंतर करना महत्वपूर्ण है। उदाहरण के लिए, किसी डेटाबेस या अन्य बैकएंड से कनेक्शन के नुकसान के कारण होने वाली HTTP 500 त्रुटि का बहुत जल्दी निदान किया जा सकता है, हालाँकि, HTTP 500 त्रुटि एक विफल अनुरोध का संकेत दे सकती है। समग्र विलंबता पर 500 त्रुटि के प्रभाव का निर्धारण करने से गलत निष्कर्ष निकल सकते हैं। दूसरी ओर, एक धीमी त्रुटि भी एक तेज़ त्रुटि है! इसलिए, केवल त्रुटियों को फ़िल्टर करने के बजाय त्रुटि विलंबता की निगरानी करना महत्वपूर्ण है।

यातायात

आपके सिस्टम के अनुरोधों की संख्या उच्च-स्तरीय सिस्टम मेट्रिक्स में मापी जाती है। किसी वेब सेवा के लिए, यह माप आम तौर पर प्रति सेकंड HTTP अनुरोधों की संख्या का प्रतिनिधित्व करता है, जो अनुरोधों की प्रकृति (उदाहरण के लिए, स्थिर या गतिशील सामग्री) से विभाजित होता है। एक ऑडियो स्ट्रीमिंग सिस्टम के लिए, यह माप नेटवर्क I/O गति या एक साथ सत्रों की संख्या पर ध्यान केंद्रित कर सकता है। कुंजी-मूल्य भंडारण प्रणाली के लिए, यह माप प्रति सेकंड लेनदेन या खोज परिणाम हो सकता है।

त्रुटियाँ

यह उन विफल अनुरोधों की दर है जो स्पष्ट हैं (उदाहरण के लिए HTTP 500), अंतर्निहित (उदाहरण के लिए HTTP 200 लेकिन अमान्य सामग्री के साथ संयुक्त) या नीति (उदाहरण के लिए "यदि आपने एक सेकंड में प्रतिक्रिया कैप्चर की है, तो कोई भी एक सेकंड एक त्रुटि है")। यदि HTTP प्रतिक्रिया कोड सभी विफलता स्थितियों को व्यक्त करने के लिए पर्याप्त नहीं हैं, तो आंशिक विफलता का पता लगाने के लिए माध्यमिक (आंतरिक) प्रोटोकॉल की आवश्यकता हो सकती है। ऐसे सभी विफल अनुरोधों की निगरानी करना जानकारीपूर्ण नहीं हो सकता है, जबकि एंड-टू-एंड सिस्टम परीक्षण यह पता लगाने में मदद करेंगे कि आप गलत सामग्री संसाधित कर रहे हैं।

परिपूर्णता

मीट्रिक दिखाता है कि आपकी सेवा का कितनी गहनता से उपयोग किया जाता है। यह एक सिस्टम मॉनिटरिंग उपाय है जो उन संसाधनों की पहचान करता है जो सबसे अधिक बाधित हैं (उदाहरण के लिए, मेमोरी-बाधित सिस्टम पर, मेमोरी दिखाता है, I/O-बाधित सिस्टम पर, I/Os की संख्या दिखाता है)। ध्यान दें कि कई प्रणालियाँ 100% उपयोग तक पहुँचने से पहले प्रदर्शन को ख़राब कर देती हैं, इसलिए उपयोग लक्ष्य रखना महत्वपूर्ण है।

जटिल प्रणालियों में, संतृप्ति को उच्च-स्तरीय लोड माप द्वारा पूरक किया जा सकता है: क्या आपकी सेवा दोहरे ट्रैफ़िक को ठीक से संभाल सकती है, केवल 10% अधिक ट्रैफ़िक संभाल सकती है, या वर्तमान की तुलना में कम ट्रैफ़िक संभाल सकती है? सरल सेवाओं के लिए जिनमें ऐसे पैरामीटर नहीं हैं जो अनुरोध की जटिलता को बदलते हैं (उदाहरण के लिए, "मुझे कुछ न दें" या "मुझे एक अद्वितीय एकल मोनोटोनिक पूर्णांक की आवश्यकता है"), जो शायद ही कभी कॉन्फ़िगरेशन बदलते हैं, एक स्थिर लोड परीक्षण मान पर्याप्त हो सकता है। हालाँकि, जैसा कि पिछले पैराग्राफ में चर्चा की गई है, अधिकांश सेवाओं को अप्रत्यक्ष संकेतों का उपयोग करना चाहिए, जैसे सीपीयू उपयोग या नेटवर्क बैंडविड्थ, जिनकी एक ज्ञात ऊपरी सीमा होती है। बढ़ती विलंबता अक्सर संतृप्ति का एक प्रमुख संकेतक होती है। एक छोटी विंडो (उदाहरण के लिए, एक मिनट) में 99वें प्रतिशतक प्रतिक्रिया समय को मापना संतृप्ति का बहुत प्रारंभिक संकेत प्रदान कर सकता है।

अंत में, संतृप्ति आसन्न संतृप्ति के बारे में भविष्यवाणियों से भी जुड़ी है, उदाहरण के लिए: "ऐसा लगता है कि आपका डेटाबेस आपकी हार्ड ड्राइव को 4 घंटे में भर देगा।"

यदि आप सभी चार सुनहरे संकेतों को मापते हैं और जब किसी एक मेट्रिक्स (या, संतृप्ति के मामले में, निकट समस्या) के साथ कोई समस्या होती है, तो आप किसी व्यक्ति को सचेत करते हैं, आपकी सेवा कमोबेश निगरानी द्वारा कवर की जाएगी।

"पूंछ" (या उपकरण और प्रदर्शन) के बारे में चिंता

शुरुआत से एक निगरानी प्रणाली बनाते समय, औसत मूल्यों के आधार पर एक प्रणाली विकसित करने का प्रलोभन होता है: औसत विलंबता, नोड्स का औसत सीपीयू उपयोग, या औसत डेटाबेस पूर्णता। पिछले दो उदाहरणों का खतरा स्पष्ट है: प्रोसेसर और डेटाबेस का निपटान बहुत अप्रत्याशित तरीके से किया जाता है। यही बात देरी पर भी लागू होती है। यदि आप प्रति सेकंड 100 अनुरोधों के साथ 1000 एमएस की औसत विलंबता के साथ एक वेब सेवा चलाते हैं, तो 1% अनुरोधों में 5 सेकंड लग सकते हैं। यदि उपयोगकर्ता ऐसी कई वेब सेवाओं पर निर्भर हैं, तो एक बैकएंड का 99वां प्रतिशत आसानी से फ्रंटएंड का औसत प्रतिक्रिया समय बन सकता है।

धीमी औसत और अनुरोधों की बहुत धीमी पूंछ के बीच अंतर करने का सबसे आसान तरीका वास्तविक विलंबता के बजाय आंकड़ों में व्यक्त अनुरोधों के माप एकत्र करना है (प्रदर्शित करने के लिए एक अच्छा उपकरण हिस्टोग्राम है): सेवा ने कितने अनुरोध दिए जो 0 एमएस के बीच हुए और 10 एमएस, 10 एमएस और 30 एमएस के बीच, 30 एमएस और 100 एमएस के बीच, 100 एमएस और 300 एमएस के बीच, आदि। हिस्टोग्राम सीमाओं को लगभग तेजी से विस्तारित करना (3 के अनुमानित कारक द्वारा) अक्सर वितरण की कल्पना करने का एक सरल तरीका है अनुरोधों का.

माप के लिए विवरण के उचित स्तर का चयन करना

सिस्टम के विभिन्न तत्वों को विस्तार के विभिन्न स्तरों पर मापा जाना चाहिए। उदाहरण के लिए:

• समय की अवधि में सीपीयू उपयोग की निगरानी करने से दीर्घकालिक स्पाइक्स नहीं दिखाई देंगे जो उच्च विलंबता का कारण बनते हैं।
• दूसरी ओर, प्रति वर्ष 9 घंटे से अधिक डाउनटाइम (99,9% वार्षिक अपटाइम) का लक्ष्य रखने वाली वेब सेवा के लिए, एक मिनट में एक या दो बार से अधिक HTTP 200 प्रतिक्रिया की जाँच करना अनावश्यक रूप से बार-बार होने की संभावना है।
• इसी तरह, 99,9% उपलब्धता के लिए हार्ड ड्राइव स्थान की हर 1-2 मिनट में एक से अधिक बार जाँच करना संभवतः आवश्यक नहीं है।

इस बात का ध्यान रखें कि आप अपने माप की ग्रैन्युलैरिटी की संरचना कैसे करते हैं। प्रति सेकंड एक बार सीपीयू लोड एकत्र करना दिलचस्प डेटा प्रदान कर सकता है, लेकिन इस तरह के लगातार माप एकत्र करना, संग्रहीत करना और विश्लेषण करना बहुत महंगा हो सकता है। यदि आपके निगरानी लक्ष्य के लिए उच्च ग्रैन्युलैरिटी की आवश्यकता होती है और उच्च प्रतिक्रियाशीलता की आवश्यकता नहीं होती है, तो आप सर्वर पर मेट्रिक्स संग्रह स्थापित करके और फिर उन मेट्रिक्स को इकट्ठा करने और एकत्र करने के लिए एक बाहरी सिस्टम स्थापित करके इन लागतों को कम कर सकते हैं। क्या तुम:

1. हर सेकंड सीपीयू लोड मापें।
2. विवरण घटाकर 5% कर दें।
3. हर मिनट समग्र मेट्रिक्स।

यह रणनीति आपको उच्च विश्लेषण और भंडारण ओवरहेड के बिना उच्च ग्रैन्युलैरिटी पर डेटा एकत्र करने की अनुमति देगी।

जितना संभव हो उतना सरल, लेकिन उससे अधिक सरल नहीं

विभिन्न आवश्यकताओं को एक-दूसरे के ऊपर डालने से एक बहुत ही जटिल निगरानी प्रणाली बन सकती है। उदाहरण के लिए, आपके सिस्टम में निम्नलिखित जटिल तत्व हो सकते हैं:

• सभी प्रकार के अलग-अलग संकेतकों के लिए, अलग-अलग प्रतिशत में, अनुरोध प्रसंस्करण विलंबता के लिए अलग-अलग सीमा के अनुसार अलर्ट।
• संभावित कारणों का पता लगाने और पहचानने के लिए अतिरिक्त कोड लिखना।
• समस्याओं के प्रत्येक संभावित कारण के लिए संबंधित डैशबोर्ड बनाएं।

संभावित जटिलता के स्रोत कभी ख़त्म नहीं होते। सभी सॉफ्टवेयर प्रणालियों की तरह, निगरानी इतनी जटिल हो सकती है कि इसे बदलना और बनाए रखना नाजुक और कठिन हो जाता है।

इसलिए, अपने मॉनिटरिंग सिस्टम को यथासंभव सरल बनाने के लिए डिज़ाइन करें। क्या ट्रैक करना है इसका चयन करते समय निम्नलिखित बातों का ध्यान रखें:

• जो नियम अक्सर वास्तविक घटनाओं को पकड़ते हैं वे यथासंभव सरल, पूर्वानुमानित और विश्वसनीय होने चाहिए।
• डेटा संग्रह, एकत्रीकरण और अलर्टिंग के लिए कॉन्फ़िगरेशन जो कभी-कभार किया जाता है (उदाहरण के लिए, कुछ एसआरई टीमों के लिए त्रैमासिक से कम) को हटा दिया जाना चाहिए।
• जो मेट्रिक्स एकत्र किए गए हैं लेकिन किसी पूर्वावलोकन डैशबोर्ड में नहीं दिखाए गए हैं या किसी अलर्ट द्वारा उपयोग नहीं किए गए हैं, वे हटाए जाने योग्य हैं।

Google में, बुनियादी मेट्रिक्स संग्रह और एकत्रीकरण, अलर्ट और डैशबोर्ड के साथ मिलकर, एक अपेक्षाकृत स्टैंड-अलोन सिस्टम के रूप में अच्छी तरह से काम करता है (Google की निगरानी प्रणाली वास्तव में कई उप-प्रणालियों में विभाजित है, लेकिन लोग आमतौर पर इन उप-प्रणालियों के सभी पहलुओं से अवगत हैं)। जटिल प्रणालियों की जांच के लिए निगरानी को अन्य तकनीकों के साथ जोड़ना आकर्षक हो सकता है: विस्तृत सिस्टम प्रोफाइलिंग, प्रक्रिया डिबगिंग, अपवादों या विफलताओं के बारे में ट्रैकिंग विवरण, लोड परीक्षण, लॉग संग्रह और विश्लेषण, या यातायात निरीक्षण। हालाँकि इनमें से अधिकांश चीज़ों में बुनियादी निगरानी के साथ समानताएँ हैं, लेकिन उन्हें मिलाने से बहुत अधिक परिणाम प्राप्त होंगे और एक जटिल और नाजुक प्रणाली तैयार हो जाएगी। सॉफ्टवेयर विकास के कई अन्य पहलुओं की तरह, स्पष्ट, सरल, शिथिल युग्मित एकीकरण बिंदुओं के साथ विभिन्न प्रणालियों का समर्थन करना सबसे अच्छी रणनीति है (उदाहरण के लिए, एक प्रारूप में एकत्रित डेटा को पुनः प्राप्त करने के लिए वेब एपीआई का उपयोग करना जो लंबे समय तक सुसंगत रह सकता है) ).

सिद्धांतों को एक साथ बांधना

इस अध्याय में चर्चा किए गए सिद्धांतों को एक निगरानी और चेतावनी दर्शन में जोड़ा जा सकता है जिसका Google SRE टीमों द्वारा समर्थन और पालन किया जाता है। इस निगरानी दर्शन का पालन करना वांछनीय है, यह आपकी चेतावनी पद्धति को बनाने या संशोधित करने के लिए एक अच्छा प्रारंभिक बिंदु है, और आपके संगठन के आकार या सेवा या प्रणाली की जटिलता की परवाह किए बिना, आपके संचालन कार्य के सही प्रश्न पूछने में आपकी सहायता कर सकता है।

निगरानी और चेतावनी नियम बनाते समय, निम्नलिखित प्रश्न पूछने से आपको झूठी सकारात्मकता और अनावश्यक अलर्ट से बचने में मदद मिल सकती है:

• क्या यह नियम सिस्टम की ऐसी अज्ञात स्थिति का पता लगाता है जो अत्यावश्यक है, कार्रवाई की मांग करती है और अनिवार्य रूप से उपयोगकर्ता को प्रभावित करती है?
• क्या मैं इस चेतावनी को यह जानते हुए भी अनदेखा कर सकता हूँ कि यह सौम्य है? मैं इस चेतावनी को कब और क्यों अनदेखा कर सकता हूं और इस परिदृश्य से कैसे बच सकता हूं?
• क्या इस चेतावनी का मतलब यह है कि उपयोगकर्ताओं पर नकारात्मक प्रभाव पड़ रहा है? क्या ऐसी स्थितियाँ हैं जहाँ उपयोगकर्ताओं पर नकारात्मक प्रभाव नहीं पड़ता है, जैसे ट्रैफ़िक फ़िल्टरिंग के माध्यम से या परीक्षण प्रणालियों का उपयोग करते समय जिसके लिए अलर्ट फ़िल्टर किए जाने चाहिए?
• क्या मैं इस चेतावनी के जवाब में कार्रवाई कर सकता हूँ? क्या ये उपाय अत्यावश्यक हैं या सुबह तक इंतजार किया जा सकता है? क्या कोई कार्रवाई सुरक्षित रूप से स्वचालित की जा सकती है? क्या यह कार्रवाई दीर्घकालिक समाधान होगी या अल्पकालिक समाधान?
• कुछ लोगों को इस समस्या के लिए कई अलर्ट मिल रहे हैं, तो क्या अलर्ट की संख्या कम करने का कोई तरीका है?

ये प्रश्न अलर्ट और चेतावनी प्रणालियों पर मौलिक दर्शन को दर्शाते हैं:

• जब भी कोई अलर्ट आता है, मुझे तुरंत प्रतिक्रिया देनी होती है। मैं थकने से पहले दिन में कई बार तत्काल प्रतिक्रिया कर सकता हूं।
• प्रत्येक चेतावनी प्रासंगिक होनी चाहिए.
• किसी चेतावनी की प्रत्येक प्रतिक्रिया के लिए मानवीय हस्तक्षेप की आवश्यकता होनी चाहिए। यदि अधिसूचना स्वचालित रूप से संसाधित की जा सकती है, तो उसे नहीं आना चाहिए।
• अलर्ट किसी नई समस्या या घटना के बारे में होना चाहिए जो पहले मौजूद नहीं था।

यह दृष्टिकोण कुछ भेदों को धुंधला कर देता है: यदि अलर्ट पिछली चार शर्तों को पूरा करता है, तो इससे कोई फर्क नहीं पड़ता कि अलर्ट व्हाइट-बॉक्स या ब्लैक-बॉक्स मॉनिटरिंग सिस्टम से भेजा गया है या नहीं। यह दृष्टिकोण कुछ अंतरों को भी पुष्ट करता है: कारणों की तुलना में लक्षणों की पहचान करने पर अधिक प्रयास करना बेहतर है; जब कारणों की बात आती है, तो आपको केवल अपरिहार्य कारणों के बारे में चिंता करने की ज़रूरत है।

दीर्घकालिक निगरानी

आज के उत्पादकता परिवेश में, निगरानी प्रणालियाँ बदलती सॉफ़्टवेयर वास्तुकला, कार्यभार विशेषताओं और प्रदर्शन लक्ष्यों के साथ लगातार विकसित हो रही उत्पादन प्रणाली की निगरानी करती हैं। जिन अलर्ट को स्वचालित करना फिलहाल मुश्किल है, वे आम हो सकते हैं, शायद संबोधित करने लायक भी। इस बिंदु पर, किसी को समस्या के मूल कारणों को ढूंढना और समाप्त करना होगा; यदि ऐसा समाधान संभव नहीं है, तो अलर्ट की प्रतिक्रिया के लिए पूर्ण स्वचालन की आवश्यकता होती है।

यह महत्वपूर्ण है कि निगरानी संबंधी निर्णय दीर्घकालिक लक्ष्यों को ध्यान में रखकर लिए जाएं। आज चलने वाला प्रत्येक अलर्ट एक व्यक्ति को कल सिस्टम में सुधार करने से विचलित करता है, इसलिए लंबी अवधि में निगरानी प्रणाली को बेहतर बनाने के लिए आवश्यक समय के लिए उत्पादक प्रणाली की उपलब्धता या प्रदर्शन में अक्सर कमी होती है। आइए इस घटना को स्पष्ट करने के लिए दो उदाहरण देखें।

बिगटेबल एसआरई: ए टेल ऑफ़ ओवर-अलर्ट

Google के आंतरिक बुनियादी ढांचे को आम तौर पर सेवा स्तर (SLO) के आधार पर प्रावधानित और मापा जाता है। कई साल पहले, बिगटेबल की सेवा एसएलओ एक लाइव क्लाइंट का अनुकरण करने वाले सिंथेटिक लेनदेन के औसत प्रदर्शन पर आधारित थी। बिगटेबल में समस्याओं और स्टोरेज स्टैक के निचले स्तरों के कारण, औसत प्रदर्शन एक "बड़ी" पूंछ द्वारा संचालित होता था: सबसे खराब 5% क्वेरीज़ अक्सर बाकी की तुलना में काफी धीमी थीं।

एसएलओ सीमा के करीब पहुंचने पर ईमेल सूचनाएं भेजी गईं, और एसएलओ पार होने पर मैसेंजर अलर्ट भेजे गए। दोनों प्रकार के अलर्ट अक्सर भेजे जाते थे, जिसमें अस्वीकार्य मात्रा में इंजीनियरिंग समय लगता था: टीम ने उन अलर्ट को छांटने में काफी समय बिताया जो वास्तव में प्रासंगिक थे। हम अक्सर ऐसे मुद्दे से चूक जाते हैं जो वास्तव में उपयोगकर्ताओं को प्रभावित करता है क्योंकि केवल कुछ अलर्ट उस विशिष्ट मुद्दे के लिए होते थे। बुनियादी ढांचे में समझ में आने वाली समस्याओं के कारण कई अलर्ट अत्यावश्यक नहीं थे और उन्हें मानक तरीके से संसाधित किया गया था, या बिल्कुल भी संसाधित नहीं किया गया था।

स्थिति को सुधारने के लिए, टीम ने तीन-आयामी दृष्टिकोण अपनाया: बिगटेबल के प्रदर्शन को बेहतर बनाने के लिए कड़ी मेहनत करते हुए, हमने अस्थायी रूप से क्वेरी प्रतिक्रिया विलंबता के लिए अपना एसएलओ लक्ष्य 75वां प्रतिशत निर्धारित किया। हमने ईमेल अलर्ट भी बंद कर दिए क्योंकि उनमें से बहुत सारे थे कि उनका निदान करने में समय बर्बाद करना असंभव था।

इस रणनीति ने हमें सामरिक मुद्दों को लगातार ठीक करने के बजाय बिगटेबल और स्टोरेज स्टैक की निचली परतों में दीर्घकालिक मुद्दों को ठीक करना शुरू करने की अनुमति दी। इंजीनियर वास्तव में हर समय अलर्ट की बमबारी के बिना काम कर सकते हैं। अंततः, अलर्ट प्रोसेसिंग को अस्थायी रूप से स्थगित करने से हमें अपनी सेवा की गुणवत्ता में सुधार करने में मदद मिली।

जीमेल: पूर्वानुमेय, एल्गोरिदमिक मानवीय प्रतिक्रियाएँ

अपनी स्थापना के समय, जीमेल एक संशोधित वर्कक्यू प्रक्रिया प्रबंधन प्रणाली पर बनाया गया था जिसे एक खोज सूचकांक के बैच प्रक्रिया खंडों के लिए डिज़ाइन किया गया था। वर्कक्यू को लंबे समय तक चलने वाली प्रक्रियाओं के लिए अनुकूलित किया गया था और बाद में जीमेल पर लागू किया गया था, लेकिन अपारदर्शी शेड्यूलर कोड में कुछ बग को ठीक करना बहुत मुश्किल साबित हुआ।

उस समय, जीमेल मॉनिटरिंग को इस तरह से संरचित किया गया था कि वर्कक्यू का उपयोग करके व्यक्तिगत कार्यों को रद्द किए जाने पर अलर्ट चालू हो जाए। यह दृष्टिकोण आदर्श नहीं था, क्योंकि उस समय भी, जीमेल ने कई हजारों कार्य किए थे, जिनमें से प्रत्येक हमारे कुछ प्रतिशत उपयोगकर्ताओं को प्रदान किया गया था। हम जीमेल उपयोगकर्ताओं को अच्छा उपयोगकर्ता अनुभव प्रदान करने के बारे में बहुत चिंतित थे, लेकिन इतने सारे अलर्ट को संभालना हमारी पहुंच से बाहर था।

इस समस्या को हल करने के लिए, जीमेल एसआरई ने उपयोगकर्ताओं पर प्रभाव को कम करने के लिए शेड्यूलर को यथासंभव सर्वोत्तम तरीके से डीबग करने में मदद करने के लिए एक टूल बनाया। टीम ने इस बारे में कुछ चर्चा की कि क्या समस्या की खोज से लेकर उपचार के माध्यम से दीर्घकालिक समाधान मिलने तक पूरे चक्र को स्वचालित किया जाए, लेकिन कुछ को चिंता थी कि इस तरह के समाधान से वास्तव में समस्या को ठीक करने में देरी होगी।

यह तनाव टीम में आम था और अक्सर आत्म-अनुशासन में विश्वास की कमी को दर्शाता था: जबकि कुछ टीम के सदस्य सही समाधान के लिए समय देना चाहते हैं, दूसरों को चिंता है कि अंतिम सुधार को भुला दिया जाएगा और अस्थायी सुधार में हमेशा के लिए समय लगेगा। यह मुद्दा ध्यान देने योग्य है क्योंकि स्थिति को स्थायी बनाने के बजाय समस्याओं को अस्थायी रूप से ठीक करना बहुत आसान है। प्रबंधक और तकनीकी कर्मचारी प्रारंभिक "दर्द" कम होने के बाद भी दीर्घकालिक सुधारों को लागू करने, संभावित दीर्घकालिक सुधारों का समर्थन करने और प्राथमिकता देने में महत्वपूर्ण भूमिका निभाते हैं।

नियमित, दोहराए जाने वाले अलर्ट और एल्गोरिथम प्रतिक्रियाएं एक खतरे का संकेत होनी चाहिए। इन अलर्ट को स्वचालित करने में आपकी टीम की अनिच्छा का मतलब है कि टीम में आत्मविश्वास की कमी है कि वे एल्गोरिदम पर भरोसा कर सकते हैं। यह एक गंभीर समस्या है जिसका समाधान किया जाना आवश्यक है।

दीर्घकालिक

एक सामान्य विषय बिगटेबल और जीमेल उदाहरणों को जोड़ता है: अल्पकालिक और दीर्घकालिक उपलब्धता के बीच प्रतिस्पर्धा। अक्सर, एक मजबूत प्रयास एक नाजुक प्रणाली को उच्च उपलब्धता प्राप्त करने में मदद कर सकता है, लेकिन यह रास्ता आमतौर पर अल्पकालिक होता है, टीम के थकावट और उसी वीर टीम के सदस्यों की एक छोटी संख्या पर निर्भरता से भरा होता है।

उपलब्धता में नियंत्रित, अल्पकालिक कमी अक्सर दर्दनाक होती है, लेकिन सिस्टम की दीर्घकालिक स्थिरता के लिए रणनीतिक रूप से महत्वपूर्ण है। यह महत्वपूर्ण है कि प्रत्येक अलर्ट को अलग से न देखा जाए, बल्कि इस पर विचार किया जाए कि क्या अलर्ट वॉल्यूम का समग्र स्तर एक व्यवहार्य टीम और अनुकूल पूर्वानुमान के साथ एक स्वस्थ, उचित रूप से सुलभ प्रणाली की ओर ले जाता है। हम प्रबंधन को त्रैमासिक रिपोर्ट में अलर्ट आवृत्ति आंकड़ों (आमतौर पर प्रति शिफ्ट की घटनाओं के रूप में व्यक्त किए जाते हैं, जहां एक घटना में कई संबंधित घटनाएं शामिल हो सकती हैं) का विश्लेषण करते हैं, जिससे निर्णय निर्माताओं को अलर्ट सिस्टम लोड और समग्र टीम स्वास्थ्य के बारे में निरंतर दृष्टिकोण रखने की अनुमति मिलती है।

निष्कर्ष

स्वस्थ निगरानी और चेतावनी का मार्ग सरल और स्पष्ट है। यह समस्या के लक्षणों पर ध्यान केंद्रित करता है जो अलर्ट ट्रिगर करता है, और कारण की निगरानी करना समस्याओं को दूर करने में सहायता के रूप में कार्य करता है। आपके नियंत्रण वाले स्टैक में आप जितने ऊंचे स्थान पर हैं, लक्षणों की निगरानी करना उतना ही आसान है, हालांकि डेटाबेस के लोड और प्रदर्शन की निगरानी सीधे डेटाबेस पर ही की जानी चाहिए। ईमेल सूचनाओं की उपयोगिता बहुत सीमित होती है और ये आसानी से शोर बन जाती हैं; इसके बजाय, आपको एक डैशबोर्ड का उपयोग करना चाहिए जो ईमेल अलर्ट ट्रिगर करने वाले सभी मौजूदा मुद्दों पर नज़र रखता है। ऐतिहासिक सहसंबंधों का विश्लेषण करने के लिए डैशबोर्ड को इवेंट लॉग के साथ भी जोड़ा जा सकता है।

लंबी अवधि में, लक्षणों और आसन्न वास्तविक समस्याओं के बारे में अलर्ट के सफल रोटेशन को प्राप्त करना आवश्यक है, यह सुनिश्चित करने के लिए लक्ष्यों को अपनाना कि निगरानी तेजी से निदान का समर्थन करती है।

अनुवाद को अंत तक पढ़ने के लिए धन्यवाद. निगरानी के बारे में मेरे टेलीग्राम चैनल की सदस्यता लें @monitorim_it и माध्यम पर ब्लॉग.

स्रोत: www.habr.com