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

बिल्ली द्वारा अनुवाद। अच्छा पढ़ लो!

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

परिभाषित

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

निगरानी

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

सफेद बॉक्स निगरानी

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

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

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

डैशबोर्ड (डैशबोर्ड)

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

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

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

मूल कारण

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

नोड और मशीन

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

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

धक्का

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

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

कई कारणों से अनुप्रयोगों की निगरानी की जानी चाहिए:

लॉन्ग ट्रेंड एनालिसिस

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

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

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

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

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

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

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

एक पूर्वव्यापी विश्लेषण का आयोजन (डिबगिंग)

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

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

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

एक निगरानी प्रणाली से उचित उम्मीदों को परिभाषित करना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

विलंब

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

यातायात

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

त्रुटियों

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

परिपूर्णता

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

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

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

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

पूंछ के बारे में चिंता (या इंस्ट्रूमेंटेशन और प्रदर्शन)

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

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

माप के लिए सही विवरण स्तर चुनना

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

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

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

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

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

जितना संभव हो उतना आसान है, लेकिन आसान नहीं है

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

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

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

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

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

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

सिद्धांतों को एक साथ जोड़ना

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

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

• क्या यह नियम सिस्टम की अन्यथा अवांछनीय स्थिति का पता लगाता है, जो जरूरी है, कार्रवाई के लिए बुला रहा है और उपयोगकर्ता को अनिवार्य रूप से प्रभावित कर रहा है?
• , , ? ?
• , ? , , , - , ?
• ? ? ? ?
• , ?

ये प्रश्न अलर्ट और अलर्ट सिस्टम के मूलभूत दर्शन को दर्शाते हैं:

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

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

लंबे समय तक निगरानी

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

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

बिगटेबल एसआरई: अलर्ट इतिहास

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

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

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

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

जीमेल: लोगों से अनुमानित, एल्गोरिदम प्रतिक्रियाएं

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

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

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

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

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

कालान्तर में

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

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

निष्कर्ष

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

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

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