SRE (साइट विश्वसनीयता अभियांत्रिकी) वेब प्रकल्पांची उपलब्धता सुनिश्चित करण्यासाठी एक दृष्टीकोन आहे. हे DevOps साठी एक फ्रेमवर्क मानले जाते आणि DevOps पद्धती लागू करण्यात यश कसे मिळवायचे याबद्दल बोलते. या लेखातील भाषांतर अध्याय 6 वितरण प्रणालींचे निरीक्षण करणे पुस्तके साइट विश्वसनीयता अभियांत्रिकी Google कडून. मी हे भाषांतर स्वतः तयार केले आहे आणि मॉनिटरिंग प्रक्रिया समजून घेण्यासाठी माझ्या स्वतःच्या अनुभवावर अवलंबून आहे. टेलिग्राम चॅनेलमध्ये @monitorim_it и मध्यम वर ब्लॉग सेवा स्तरावरील उद्दिष्टांबद्दल मी त्याच पुस्तकाच्या चौथ्या प्रकरणाच्या अनुवादाची लिंक देखील प्रकाशित केली आहे.

मांजरीचे भाषांतर. वाचनाचा आनंद घ्या!

Google च्या SRE टीममध्ये यशस्वी मॉनिटरिंग आणि नोटिफिकेशन सिस्टम तयार करण्यासाठी मूलभूत तत्त्वे आणि सर्वोत्तम पद्धती आहेत. हा धडा वेब पेज अभ्यागतांना कोणत्या समस्या येऊ शकतात आणि वेब पेजेस प्रदर्शित करणे कठीण करणाऱ्या समस्यांचे निराकरण कसे करावे याबद्दल मार्गदर्शन प्रदान करते.

परिभाषा

निरीक्षणाशी संबंधित विषयांवर चर्चा करण्यासाठी एकही शब्दसंग्रह वापरलेला नाही. जरी Google वर, खालील संज्ञा सामान्यतः वापरल्या जात नाहीत, परंतु आम्ही सर्वात सामान्य व्याख्या सूचीबद्ध करू.

देखरेख

प्रणालीबद्दल रिअल टाइममध्ये परिमाणवाचक डेटाचे संकलन, प्रक्रिया, एकत्रीकरण आणि प्रदर्शन: विनंत्या आणि विनंत्यांची संख्या, त्रुटी आणि त्रुटींचे प्रकार, विनंती प्रक्रिया वेळ आणि सर्व्हर अपटाइम.

व्हाईट-बॉक्स निरीक्षण

लॉग, Java व्हर्च्युअल मशीन प्रोफाइलिंग मेट्रिक्स किंवा अंतर्गत आकडेवारी व्युत्पन्न करणार्‍या HTTP हँडलर मेट्रिक्ससह अंतर्गत सिस्टम घटकांद्वारे प्रदर्शित केलेल्या मेट्रिक्सवर आधारित निरीक्षण.

ब्लॅक बॉक्स मॉनिटरिंग

वापरकर्त्याच्या दृष्टिकोनातून अनुप्रयोग वर्तनाची चाचणी करणे.

डॅशबोर्ड

एक इंटरफेस (सामान्यतः वेब) जो सेवांच्या मुख्य आरोग्य निर्देशकांचे विहंगावलोकन प्रदान करतो. डॅशबोर्डमध्ये फिल्टर, दर्शविलेले निर्देशक निवडण्याची क्षमता इत्यादी असू शकतात. इंटरफेस वापरकर्त्यांसाठी सर्वात महत्वाचे असलेले निर्देशक ओळखण्यासाठी डिझाइन केलेले आहे. डॅशबोर्ड तांत्रिक सहाय्य कर्मचार्‍यांसाठी माहिती देखील प्रदर्शित करू शकतो: विनंतीची रांग, उच्च-प्राधान्य त्रुटींची सूची आणि दिलेल्या जबाबदारीच्या क्षेत्रासाठी नियुक्त अभियंता.

सूचना (सूचना)

एखाद्या व्यक्तीला ईमेल किंवा इतर माध्यमांद्वारे प्राप्त करण्याच्या उद्देशाने सूचना, ज्या त्रुटींमुळे किंवा विनंती रांगेत वाढ झाल्यामुळे ट्रिगर केल्या जाऊ शकतात. सूचनांचे वर्गीकरण खालीलप्रमाणे केले आहे: तिकिटे, ईमेल सूचना आणि इन्स्टंट मेसेंजर संदेश.

मूळ कारण

सॉफ्टवेअर दोष किंवा मानवी त्रुटी, जी एकदा दुरुस्त केली गेली, ती पुन्हा येऊ नये. समस्येची अनेक मुख्य कारणे असू शकतात: अपुरी प्रक्रिया ऑटोमेशन, सॉफ्टवेअर दोष, ऍप्लिकेशन लॉजिकचा अपुरा विस्तार. यापैकी प्रत्येक घटक मूळ कारण असू शकतो आणि त्या प्रत्येकाचे उच्चाटन करणे आवश्यक आहे.

नोड आणि मशीन (नोड आणि मशीन)

फिजिकल सर्व्हर, व्हर्च्युअल मशीन किंवा कंटेनरवर चालू असलेल्या ऍप्लिकेशनच्या एकाच प्रसंगाचा संदर्भ देण्यासाठी अदलाबदल करण्यायोग्य संज्ञा. एक मशीन अनेक सेवा होस्ट करू शकते. सेवा असू शकतात:

• एकमेकांशी कनेक्ट केलेले: उदाहरणार्थ, कॅशिंग सर्व्हर आणि वेब सर्व्हर;
• हार्डवेअरच्या एकाच तुकड्यावर असंबंधित सेवा: उदाहरणार्थ, कोड रेपॉजिटरी आणि कॉन्फिगरेशन सिस्टमसाठी विझार्ड, जसे की कठपुतळी किंवा डोके.

पुश करा

सॉफ्टवेअर कॉन्फिगरेशनमधील कोणताही बदल.

निरीक्षण का आवश्यक आहे?

अनुप्रयोगांचे परीक्षण करणे आवश्यक का अनेक कारणे आहेत:

दीर्घकालीन ट्रेंडचे विश्लेषण

डेटाबेस किती मोठा आहे आणि किती वेगाने वाढत आहे? दररोज वापरकर्त्यांची संख्या कशी बदलते?

कामगिरी तुलना

Ajax DB 2.72 च्या तुलनेत Acme Backet of Bytes 3.14 वर विनंत्या जलद आहेत का? अतिरिक्त नोड दिसल्यानंतर विनंत्या किती चांगल्या प्रकारे कॅश केल्या जातात? गेल्या आठवड्याच्या तुलनेत साइट हळू चालत आहे का?

सूचना (सूचना)

काहीतरी तुटलेले आहे आणि कोणीतरी त्याचे निराकरण करणे आवश्यक आहे. किंवा काहीतरी लवकरच खंडित होईल आणि एखाद्याला ते लवकरच तपासण्याची आवश्यकता आहे.

डॅशबोर्ड तयार करणे

डॅशबोर्डने मूलभूत प्रश्नांची उत्तरे दिली पाहिजेत आणि त्यातून काहीतरी समाविष्ट केले पाहिजे "4 सुवर्ण संकेत" — विलंब (विलंब), रहदारी (वाहतूक), त्रुटी (त्रुटी) आणि लोड आकार (संपृक्तता).

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

विनंती प्रक्रिया विलंब वाढला आहे, परंतु त्याच वेळी आणखी काय घडले?
मॉनिटरिंग सिस्टम व्यवसाय बुद्धिमत्ता प्रणालींसाठी डेटाचा स्रोत म्हणून आणि सुरक्षा घटनांचे विश्लेषण सुलभ करण्यासाठी उपयुक्त आहेत. कारण हे पुस्तक अभियांत्रिकी क्षेत्रांवर लक्ष केंद्रित करते ज्यात SRE चे कौशल्य आहे, आम्ही येथे देखरेख तंत्रांवर चर्चा करणार नाही.

मॉनिटरिंग आणि अॅलर्टमुळे सिस्टीम कधी तुटली आहे किंवा तुटणार आहे हे सांगू देते. जेव्हा एखादी प्रणाली आपोआप स्वतःची दुरुस्ती करू शकत नाही, तेव्हा आम्हाला माणसाने सतर्कतेचे विश्लेषण करावे, समस्या अद्याप सक्रिय आहे की नाही हे निर्धारित करावे, त्याचे निराकरण करावे आणि मूळ कारण निश्चित करावे असे वाटते. तुम्ही सिस्टम घटकांचे ऑडिट न केल्यास, "काहीतरी थोडे विचित्र दिसते" म्हणून तुम्हाला कधीही सूचना मिळणार नाही.

एखाद्या व्यक्तीवर अधिसूचनांवर भार टाकणे हा कर्मचाऱ्याच्या वेळेचा वापर करणे खूप महाग आहे. कर्मचारी काम करत असल्यास, अलर्ट कामाच्या प्रक्रियेत व्यत्यय आणतो. कर्मचारी घरी असल्यास, सतर्कतेमुळे वैयक्तिक वेळेत आणि शक्यतो झोपेत व्यत्यय येतो. जेव्हा अॅलर्ट खूप वारंवार येतात, तेव्हा कर्मचारी त्यामधून स्किम करतात, त्या बंद करतात किंवा येणाऱ्या सूचनांकडे दुर्लक्ष करतात. वेळोवेळी ते खर्‍या अलर्टकडे दुर्लक्ष करतात, जे आवाजाच्या घटनांनी मुखवटा घातलेले असते. सेवेतील व्यत्यय दीर्घकाळ टिकू शकतात कारण आवाजाच्या घटनांमुळे समस्येचे त्वरीत निदान आणि दुरूस्ती होण्यापासून प्रतिबंध होतो. प्रभावी चेतावणी प्रणालींमध्ये चांगले सिग्नल-टू-आवाज गुणोत्तर असते.

देखरेख प्रणालीसाठी वाजवी अपेक्षा सेट करणे

जटिल ऍप्लिकेशनसाठी मॉनिटरिंग सेट करणे हे स्वतःच एक जटिल अभियांत्रिकी कार्य आहे. संकलन, डिस्प्ले आणि अलर्टिंग टूल्सच्या महत्त्वपूर्ण पायाभूत सुविधांसह, 10-12 सदस्यांच्या Google SRE टीममध्ये विशेषत: एक किंवा दोन लोकांचा समावेश असतो ज्यांचा मुख्य उद्देश मॉनिटरिंग सिस्टम तयार करणे आणि देखरेख करणे हा आहे. आम्ही मॉनिटरिंग इन्फ्रास्ट्रक्चर एकत्रित आणि केंद्रीकृत केल्यामुळे ही संख्या कालांतराने कमी झाली आहे, परंतु प्रत्येक SRE टीममध्ये सामान्यत: किमान एक व्यक्ती केवळ देखरेखीसाठी समर्पित असते. आम्हाला असे म्हणायचे आहे की मॉनिटरिंग सिस्टम डॅशबोर्ड पाहणे खूप मनोरंजक आहे, SRE टीम काळजीपूर्वक अशा परिस्थिती टाळतात ज्यात समस्यांचे परीक्षण करण्यासाठी एखाद्याला स्क्रीनकडे पाहण्याची आवश्यकता असते.

एकंदरीत, Google ने इष्टतम आफ्टर-द-फॅक्ट अॅनालिसिस टूल्ससह साध्या आणि जलद मॉनिटरिंग सिस्टमकडे वळले आहे. आम्ही "जादू" प्रणाली टाळतो ज्या थ्रेशोल्डचा अंदाज लावण्याचा प्रयत्न करतात किंवा आपोआप मूळ कारण शोधतात. अंतिम-वापरकर्ता विनंत्यांमध्ये अनपेक्षित सामग्री शोधणारे सेन्सर हे एकमेव प्रति उदाहरण आहेत; जोपर्यंत हे सेन्सर साधे राहतात, तोपर्यंत ते गंभीर विसंगतींची कारणे त्वरीत शोधू शकतात. मॉनिटरिंग डेटा वापरण्यासाठी इतर फॉरमॅट्स, जसे की क्षमता नियोजन किंवा रहदारी अंदाज, अधिक क्लिष्ट आहेत. कमी सॅम्पलिंग दराने (तास किंवा दिवस) खूप दीर्घ कालावधीचे (महिने किंवा वर्षे) निरीक्षण केल्यास दीर्घकालीन कल दिसून येईल.

Google SRE टीमला जटिल अवलंबित्व पदानुक्रमांसह मिश्रित यश मिळाले आहे. आम्ही क्वचितच नियम वापरतो जसे की "जर मला कळले की डेटाबेस मंद आहे, तर मला अलर्ट मिळेल की डेटाबेस मंद आहे, अन्यथा मला एक अलर्ट मिळेल की साइट धीमी आहे." अवलंबित्व-आधारित नियम सामान्यत: आमच्या सिस्टमच्या अपरिवर्तनीय भागांचा संदर्भ देतात, जसे की डेटा सेंटरमध्ये वापरकर्ता रहदारी फिल्टर करण्यासाठी सिस्टम. उदाहरणार्थ, "डेटा सेंटरवर ट्रॅफिक फिल्टरिंग कॉन्फिगर केले असल्यास, वापरकर्त्याच्या विनंत्यांवर प्रक्रिया करण्यात विलंब झाल्याबद्दल मला अलर्ट करू नका" हा डेटा सेंटरच्या सूचनांसाठी एक सामान्य नियम आहे. Google वरील काही संघ जटिल अवलंबित्व पदानुक्रमांना समर्थन देतात कारण आमच्या पायाभूत सुविधांमध्ये सतत रीफॅक्टरिंगचा स्थिर दर असतो.

या प्रकरणामध्ये वर्णन केलेल्या काही कल्पना अजूनही प्रासंगिक आहेत: लक्षणांपासून मूळ कारणाकडे, विशेषत: सतत बदलणाऱ्या प्रणालींमध्ये, जलद गतीने जाण्याची संधी नेहमीच असते. म्हणून, हा धडा मॉनिटरिंग सिस्टमसाठी काही उद्दिष्टे आणि ती उद्दिष्टे कशी साध्य करायची याची रूपरेषा देत असताना, हे महत्त्वाचे आहे की मॉनिटरिंग सिस्टम टीममधील प्रत्येकासाठी सोप्या आणि समजण्यायोग्य आहेत.

त्याचप्रमाणे, ध्वनी पातळी कमी ठेवण्यासाठी आणि सिग्नल पातळी उच्च ठेवण्यासाठी, अलर्ट केलेल्या मालमत्तेचे निरीक्षण करण्याच्या पद्धती अतिशय सोप्या आणि विश्वासार्ह असणे आवश्यक आहे. लोकांसाठी चेतावणी निर्माण करणारे नियम समजण्यास आणि स्पष्ट समस्या मांडण्यास सोपे असावे.

लक्षणे विरुद्ध कारणे

तुमच्या मॉनिटरिंग सिस्टमने दोन प्रश्नांची उत्तरे दिली पाहिजेत: "काय तुटले" आणि "का तुटले."
"काय तुटले" लक्षणांबद्दल बोलते आणि "का तुटले" कारणाबद्दल बोलते. खालील सारणी अशा कनेक्शनची उदाहरणे दर्शवते.

लक्षणं
कारण

HTTP त्रुटी 500 किंवा 404 मिळवत आहे
डेटाबेस सर्व्हर कनेक्शन नाकारतात

मंद सर्व्हर प्रतिसाद
उच्च CPU वापर किंवा खराब झालेले इथरनेट केबल

अंटार्क्टिकामधील वापरकर्ते मांजरीचे GIF प्राप्त करत नाहीत
तुमचा CDN शास्त्रज्ञ आणि मांजरींचा तिरस्कार करतो, त्यामुळे काही IP पत्ते काळ्या यादीत टाकले गेले

खाजगी सामग्री सर्वत्र उपलब्ध झाली आहे
नवीन सॉफ्टवेअर रिलीझच्या रोलआउटमुळे फायरवॉल सर्व ACL विसरले आणि प्रत्येकाला आत येऊ दिले

"काय" आणि "का" हे जास्तीत जास्त सिग्नल आणि कमीत कमी आवाजासह चांगली मॉनिटरिंग सिस्टीम तयार करण्यासाठी काही महत्त्वाचे बिल्डिंग ब्लॉक्स आहेत.

ब्लॅक-बॉक्स विरुद्ध व्हाइट-बॉक्स

आम्ही गंभीर मेट्रिक्ससाठी माफक ब्लॅक-बॉक्स मॉनिटरिंगसह विस्तृत व्हाइट-बॉक्स मॉनिटरिंग एकत्र करतो. ब्लॅक-बॉक्सची व्हाईट-बॉक्सशी तुलना करण्याचा सर्वात सोपा मार्ग म्हणजे ब्लॅक-बॉक्स हे लक्षण-केंद्रित आहे आणि सक्रिय देखरेख करण्याऐवजी प्रतिक्रियाशील आहे: "सिस्टम सध्या योग्यरित्या कार्य करत नाही." व्हाईट-बॉक्स सिस्टमच्या अंतर्गत पडताळणी क्षमतेवर अवलंबून असतो: इव्हेंट लॉग किंवा वेब सर्व्हर. अशाप्रकारे, व्हाईट-बॉक्स तुम्हाला येऊ घातलेल्या समस्या, विनंतीचे पुनर्प्रसारण असल्यासारखे दिसणारे दोष इत्यादी शोधण्याची परवानगी देतो.

लक्षात घ्या की बहु-स्तर प्रणालीमध्ये, एका अभियंत्याच्या जबाबदारीच्या क्षेत्रातील लक्षण हे दुसर्‍या अभियंत्याच्या जबाबदारीच्या क्षेत्रातील लक्षण आहे. उदाहरणार्थ, डेटाबेसची कार्यक्षमता कमी झाली आहे. स्लो डेटाबेस रीड हे डेटाबेस SRE चे लक्षण आहे जे त्यांना शोधते. तथापि, स्लो वेबसाइटचे निरीक्षण करणार्‍या फ्रंट-एंड SRE साठी, त्याच स्लो डेटाबेस वाचण्याचे कारण म्हणजे स्लो डेटाबेस. म्हणून, व्हाईट-बॉक्स मॉनिटरिंग हे किती व्यापक आहे यावर अवलंबून, कधीकधी लक्षण-केंद्रित आणि कधीकधी कारण-केंद्रित असते.

डीबगिंगसाठी टेलीमेट्री गोळा करताना, व्हाईट-बॉक्स मॉनिटरिंग आवश्यक आहे. वेब सर्व्हर डेटाबेस क्वेरीस प्रतिसाद देण्यास धीमे असल्यास, वेब सर्व्हर डेटाबेसशी किती लवकर संवाद साधतो आणि किती लवकर प्रतिसाद देतो हे आपल्याला माहित असणे आवश्यक आहे. अन्यथा, तुम्ही स्लो डेटाबेस सर्व्हर आणि वेब सर्व्हर आणि डेटाबेसमधील नेटवर्क समस्या यांच्यात फरक करू शकणार नाही.

अॅलर्ट पाठवताना ब्लॅक-बॉक्स मॉनिटरिंगचा एक महत्त्वाचा फायदा आहे: जेव्हा समस्या आधीच खरी लक्षणे दिसू लागली तेव्हा तुम्ही प्राप्तकर्त्याला सूचना ट्रिगर करता. दुसरीकडे, ब्लॅक-बॉक्स समस्येसाठी देखरेख निरुपयोगी आहे जी अद्याप उद्भवलेली नाही परंतु जवळ आहे.

चार सुवर्ण संकेत

लेटन्सी, ट्रॅफिक, एरर्स आणि सॅच्युरेशन हे चार गोल्डन मॉनिटरिंग सिग्नल आहेत. जर तुम्ही फक्त चार वापरकर्ता प्रणाली मेट्रिक्स मोजू शकत असाल, तर त्या चारवर लक्ष केंद्रित करा.

विलंब

विनंतीवर प्रक्रिया करण्यासाठी लागणारा वेळ. यशस्वी आणि अयशस्वी विनंत्यांच्या विलंबात फरक करणे महत्वाचे आहे. उदाहरणार्थ, डेटाबेस किंवा इतर बॅकएंडशी कनेक्शन गमावल्यामुळे HTTP 500 त्रुटीचे निदान खूप लवकर केले जाऊ शकते, तथापि, HTTP 500 त्रुटी अयशस्वी विनंती दर्शवू शकते. एकूण विलंबतेवर 500 त्रुटीचा प्रभाव निश्चित केल्याने चुकीचे निष्कर्ष निघू शकतात. दुसरीकडे, धीमे त्रुटी ही एक जलद त्रुटी आहे! म्हणूनच, त्रुटी फिल्टर करण्याऐवजी त्रुटी विलंबतेचे निरीक्षण करणे महत्वाचे आहे.

वाहतूक

तुमच्या सिस्टीमला विनंत्यांची संख्या उच्च-स्तरीय सिस्टीम मेट्रिक्समध्ये मोजली जाते. वेब सेवेसाठी, हे मोजमाप सामान्यत: प्रति सेकंद HTTP विनंत्यांची संख्या दर्शवते, विनंत्यांच्या स्वरूपानुसार (उदाहरणार्थ, स्थिर किंवा डायनॅमिक सामग्री). ऑडिओ स्ट्रीमिंग सिस्टमसाठी, हे मापन नेटवर्क I/O गती किंवा एकाचवेळी सत्रांच्या संख्येवर लक्ष केंद्रित करू शकते. की-व्हॅल्यू स्टोरेज सिस्टमसाठी, हे मोजमाप प्रति सेकंद व्यवहार किंवा शोध परिणाम असू शकते.

चुका

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

संपृक्तता

तुमची सेवा किती तीव्रतेने वापरली जाते हे मेट्रिक दाखवते. हा एक सिस्टम मॉनिटरिंग उपाय आहे जो सर्वात मर्यादित असलेल्या संसाधनांना ओळखतो (उदाहरणार्थ, मेमरी-प्रतिबंधित प्रणालीवर, मेमरी दर्शवते, I/O-संबंधित प्रणालीवर, I/Os ची संख्या दर्शवते). लक्षात घ्या की बर्‍याच प्रणाली 100% उपयोगापर्यंत पोहोचण्यापूर्वी कार्यप्रदर्शन कमी करतात, म्हणून उपयोगाचे लक्ष्य असणे महत्वाचे आहे.

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

शेवटी, संपृक्तता येऊ घातलेल्या संपृक्ततेबद्दलच्या अंदाजांशी देखील संबंधित आहे, उदाहरणार्थ: "तुमचा डेटाबेस 4 तासात तुमची हार्ड ड्राइव्ह भरेल असे दिसते."

जर तुम्ही सर्व चार सोनेरी सिग्नल मोजले आणि मेट्रिक्सपैकी एकामध्ये समस्या आल्यास (किंवा, संपृक्ततेच्या बाबतीत, जवळची समस्या), तुम्ही एखाद्या व्यक्तीला सावध केले, तर तुमची सेवा कमी-अधिक प्रमाणात निरीक्षणाद्वारे संरक्षित केली जाईल.

"शेपटी" (किंवा इन्स्ट्रुमेंटेशन आणि कामगिरी) बद्दल काळजी

सुरवातीपासून मॉनिटरिंग सिस्टम तयार करताना, सरासरी मूल्यांवर आधारित सिस्टम विकसित करण्याचा मोह असतो: सरासरी विलंबता, नोड्सचा सरासरी CPU वापर किंवा सरासरी डेटाबेस परिपूर्णता. शेवटच्या दोन उदाहरणांचा धोका स्पष्ट आहे: प्रोसेसर आणि डेटाबेस अत्यंत अप्रत्याशित मार्गाने विल्हेवाट लावले जातात. हेच विलंबावर लागू होते. तुम्ही प्रति सेकंद 100 विनंत्यांसह 1000ms च्या सरासरी लेटन्सीसह वेब सेवा चालवल्यास, 1% विनंत्यांसाठी 5 सेकंद लागू शकतात. वापरकर्ते अशा अनेक वेब सेवांवर अवलंबून असल्यास, एका बॅकएंडचा 99 वा पर्सेंटाइल फ्रन्टएंडचा मध्य प्रतिसाद वेळ सहज बनू शकतो.

विनंत्यांची धीमी सरासरी आणि अतिशय मंद शेपटीत फरक करण्याचा सर्वात सोपा मार्ग म्हणजे आकडेवारीमध्ये व्यक्त केलेल्या विनंत्यांचे मोजमाप गोळा करणे (प्रदर्शित करण्यासाठी एक चांगले साधन म्हणजे हिस्टोग्राम आहे) वास्तविक उशीरापेक्षा: सेवेने किती विनंत्या दिल्या ज्यांना 0 एमएस दरम्यान वेळ लागला आणि 10 ms, 10 ms आणि 30 ms मध्ये, 30 ms आणि 100 ms मध्ये, 100 ms आणि 300 ms च्या दरम्यान, इ. हिस्टोग्राम सीमा अंदाजे वेगाने विस्तारणे (3 च्या अंदाजे घटकाद्वारे) वितरणाची कल्पना करण्याचा एक सोपा मार्ग आहे विनंत्या.

मोजमापासाठी योग्य तपशिलांची पातळी निवडणे

सिस्टमचे वेगवेगळे घटक तपशीलाच्या वेगवेगळ्या स्तरांवर मोजले जाणे आवश्यक आहे. उदाहरणार्थ:

• ठराविक कालावधीत CPU वापराचे निरीक्षण केल्याने दीर्घकालीन स्पाइक्स दिसून येणार नाहीत ज्यामुळे उच्च विलंब होतो.
• दुसरीकडे, दर वर्षी 9 तासांपेक्षा जास्त डाउनटाइम (99,9% वार्षिक अपटाइम) लक्ष्यित नसलेल्या वेब सेवेसाठी, HTTP 200 प्रतिसादासाठी मिनिटातून एक किंवा दोनदा तपासणे अनावश्यकपणे वारंवार होण्याची शक्यता असते.
• त्याचप्रमाणे, 99,9% उपलब्धतेसाठी हार्ड ड्राइव्हची जागा प्रत्येक 1-2 मिनिटांनी एकापेक्षा जास्त वेळा तपासणे कदाचित आवश्यक नाही.

तुम्ही तुमच्या मोजमापांची ग्रॅन्युलॅरिटी कशी तयार करता याची काळजी घ्या. प्रति सेकंद एकदा CPU लोड गोळा करणे मनोरंजक डेटा प्रदान करू शकते, परंतु अशी वारंवार मोजमाप गोळा करणे, संग्रहित करणे आणि विश्लेषण करणे खूप महाग असू शकते. तुमच्या देखरेखीच्या उद्दिष्टासाठी उच्च ग्रॅन्युलॅरिटी आवश्यक असल्यास आणि उच्च प्रतिसादाची आवश्यकता नसल्यास, तुम्ही सर्व्हरवर मेट्रिक्स संकलन सेट करून आणि नंतर ते मेट्रिक्स एकत्रित करण्यासाठी आणि एकत्रित करण्यासाठी बाह्य प्रणाली सेट करून हे खर्च कमी करू शकता. तुम्ही:

1. प्रत्येक सेकंदाला CPU लोड मोजा.
2. तपशील 5% पर्यंत कमी करा.
3. प्रत्येक मिनिटाला एकूण मेट्रिक्स.

हे धोरण तुम्हाला उच्च विश्लेषण आणि स्टोरेज ओव्हरहेड खर्च न करता उच्च ग्रॅन्युलॅरिटीमध्ये डेटा संकलित करण्यास अनुमती देईल.

शक्य तितके सोपे, परंतु सोपे नाही

एकमेकांच्या वर असलेल्या वेगवेगळ्या आवश्यकतांचे आच्छादन एक अतिशय जटिल मॉनिटरिंग सिस्टममध्ये परिणाम करू शकते. उदाहरणार्थ, तुमच्या सिस्टममध्ये खालील गुंतागुंतीचे घटक असू शकतात:

• विनंती प्रक्रियेच्या विलंबतेसाठी वेगवेगळ्या थ्रेशोल्डनुसार अलर्ट, वेगवेगळ्या टक्केवारीमध्ये, सर्व प्रकारच्या वेगवेगळ्या निर्देशकांसाठी.
• संभाव्य कारणे शोधण्यासाठी आणि ओळखण्यासाठी अतिरिक्त कोड लिहिणे.
• समस्यांच्या संभाव्य कारणांपैकी प्रत्येकासाठी संबंधित डॅशबोर्ड तयार करा.

संभाव्य गुंतागुंतीचे स्त्रोत कधीही संपत नाहीत. सर्व सॉफ्टवेअर प्रणालींप्रमाणेच, देखरेख हे इतके गुंतागुंतीचे होऊ शकते की ते नाजूक आणि बदलणे आणि देखरेख करणे कठीण होते.

म्हणून, शक्य तितक्या सुलभ करण्यासाठी तुमची मॉनिटरिंग सिस्टम डिझाइन करा. काय ट्रॅक करायचे ते निवडताना, खालील गोष्टी लक्षात ठेवा:

• नियम जे बहुतेक वेळा वास्तविक घटना पकडतात ते शक्य तितके सोपे, अंदाज करण्यायोग्य आणि विश्वासार्ह असावेत.
• डेटा संकलन, एकत्रीकरण आणि अलर्टिंगसाठी कॉन्फिगरेशन जे क्वचितच केले जाते (उदाहरणार्थ, काही SRE संघांसाठी तिमाहीपेक्षा कमी) काढून टाकले पाहिजे.
• मेट्रिक्स जे संकलित केले जातात परंतु कोणत्याही पूर्वावलोकन डॅशबोर्डमध्ये दर्शविले जात नाहीत किंवा कोणत्याही अलर्टद्वारे वापरले जातात ते हटविण्याचे उमेदवार आहेत.

Google वर, अॅलर्ट आणि डॅशबोर्डसह एकत्रितपणे मूलभूत मेट्रिक्स संकलन आणि एकत्रीकरण, तुलनेने स्वतंत्र प्रणाली म्हणून चांगले कार्य करते (Google ची देखरेख प्रणाली प्रत्यक्षात अनेक उपप्रणालींमध्ये विभागली गेली आहे, परंतु लोकांना या उपप्रणालीच्या सर्व पैलूंबद्दल सामान्यतः माहिती असते). जटिल प्रणालींचे परीक्षण करण्यासाठी इतर तंत्रांसह मॉनिटरिंग एकत्र करणे मोहक असू शकते: तपशीलवार सिस्टम प्रोफाइलिंग, प्रक्रिया डीबगिंग, अपवाद किंवा अपयशांबद्दल तपशील ट्रॅक करणे, लोड चाचणी, लॉग संग्रह आणि विश्लेषण किंवा रहदारी तपासणी. यापैकी बहुतेक गोष्टी मूलभूत देखरेखीमध्ये साम्य असल्या तरी, त्या एकत्र मिसळल्याने बरेच परिणाम होतील आणि एक जटिल आणि नाजूक प्रणाली तयार होईल. सॉफ्टवेअर डेव्हलपमेंटच्या इतर अनेक पैलूंप्रमाणे, स्पष्ट, सोप्या, सैलपणे जोडलेल्या एकत्रीकरण बिंदूंसह भिन्न प्रणालींना समर्थन देणे ही सर्वोत्तम रणनीती आहे (उदाहरणार्थ, दीर्घ कालावधीसाठी सुसंगत राहणाऱ्या फॉरमॅटमध्ये एकत्रित डेटा पुनर्प्राप्त करण्यासाठी वेब API वापरणे ).

तत्त्वे एकत्र बांधणे

या धड्यात चर्चा केलेली तत्त्वे एका निरीक्षण आणि इशारा देणार्‍या तत्त्वज्ञानात एकत्रित केली जाऊ शकतात जी Google SRE कार्यसंघांद्वारे समर्थित आणि अनुसरली जाते. या मॉनिटरिंग तत्त्वज्ञानाचे पालन करणे इष्ट आहे, तुमची अलर्टिंग पद्धत तयार करण्यासाठी किंवा सुधारित करण्यासाठी हा एक चांगला प्रारंभ बिंदू आहे आणि तुमच्या संस्थेचा आकार किंवा सेवा किंवा प्रणालीची जटिलता विचारात न घेता तुमच्या ऑपरेशन फंक्शनचे योग्य प्रश्न विचारण्यास मदत करू शकते.

मॉनिटरिंग आणि अलर्टिंग नियम तयार करताना, खालील प्रश्न विचारल्याने तुम्हाला चुकीचे सकारात्मक आणि अनावश्यक सूचना टाळण्यास मदत होईल:

• हा नियम तातडीची, कॉल टू अॅक्शन आणि अपरिहार्यपणे वापरकर्त्यावर परिणाम करणारी प्रणालीची अन्यथा न ओळखता येणारी स्थिती शोधतो का?
• ही चेतावणी सौम्य आहे हे जाणून मी त्याकडे दुर्लक्ष करू शकतो का? मी या चेतावणीकडे कधी आणि का दुर्लक्ष करू शकतो आणि मी ही परिस्थिती कशी टाळू शकतो?
• या अलर्टचा अर्थ वापरकर्त्यांवर नकारात्मक परिणाम होत आहे असा होतो का? ट्रॅफिक फिल्टरिंगद्वारे किंवा ज्यासाठी अलर्ट फिल्टर केले जावेत अशा चाचणी प्रणाली वापरताना वापरकर्त्यांवर नकारात्मक प्रभाव पडत नाही अशा परिस्थिती आहेत का?
• या इशाऱ्याला प्रतिसाद म्हणून मी कारवाई करू शकतो का? हे उपाय तातडीचे आहेत की ते सकाळपर्यंत थांबू शकतात? एखादी क्रिया सुरक्षितपणे स्वयंचलित केली जाऊ शकते का? ही कृती दीर्घकालीन उपाय असेल की अल्पकालीन उपाययोजना?
• काही लोकांना या समस्येसाठी अनेक अलर्ट मिळत आहेत, त्यामुळे अलर्टची संख्या कमी करण्याचा काही मार्ग आहे का?

हे प्रश्न अलर्ट आणि चेतावणी प्रणालीवरील मूलभूत तत्त्वज्ञान प्रतिबिंबित करतात:

• प्रत्येक वेळी इशारा आला की मला लगेच प्रतिक्रिया द्यावी लागते. मला थकवा येण्यापूर्वी मी दिवसातून अनेक वेळा त्वरित प्रतिक्रिया देऊ शकतो.
• प्रत्येक सूचना संबंधित असणे आवश्यक आहे.
• सतर्कतेच्या प्रत्येक प्रतिसादासाठी मानवी हस्तक्षेप आवश्यक आहे. सूचना स्वयंचलितपणे प्रक्रिया केली जाऊ शकत असल्यास, ती येऊ नये.
• सूचना पूर्वी अस्तित्वात नसलेल्या नवीन समस्या किंवा इव्हेंटबद्दल असाव्यात.

हा दृष्टिकोन काही फरक अस्पष्ट करतो: जर इशारा मागील चार अटी पूर्ण करत असेल, तर अॅलर्ट व्हाईट-बॉक्स किंवा ब्लॅक-बॉक्स मॉनिटरिंग सिस्टममधून पाठवला गेला आहे की नाही हे महत्त्वाचे नाही. हा दृष्टिकोन काही फरकांना देखील बळकट करतो: कारणांपेक्षा लक्षणे ओळखण्यासाठी अधिक प्रयत्न करणे चांगले आहे; जेव्हा कारणांचा विचार केला जातो, तेव्हा तुम्हाला फक्त अपरिहार्य कारणांबद्दल काळजी करण्याची आवश्यकता असते.

दीर्घकालीन देखरेख

आजच्या उत्पादकता वातावरणात, मॉनिटरिंग सिस्टम बदलत्या सॉफ्टवेअर आर्किटेक्चर, वर्कलोड वैशिष्ट्ये आणि कार्यप्रदर्शन लक्ष्यांसह सतत विकसित होत असलेल्या उत्पादन प्रणालीचे परीक्षण करतात. ज्या सूचना सध्या स्वयंचलित करणे कठीण आहे ते सामान्य होऊ शकतात, कदाचित संबोधित करण्यासारखे देखील आहे. या टप्प्यावर, कोणीतरी समस्येचे मूळ कारण शोधून काढून टाकले पाहिजे; असे रिझोल्यूशन शक्य नसल्यास, अलर्टला प्रतिसाद देण्यासाठी पूर्ण ऑटोमेशन आवश्यक आहे.

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

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

Google ची अंतर्गत पायाभूत सुविधा सामान्यत: सेवा स्तरावर (SLO) तरतूद केली जाते आणि मोजली जाते. बर्याच वर्षांपूर्वी, Bigtable ची सेवा SLO थेट क्लायंटचे अनुकरण करून सिंथेटिक व्यवहाराच्या सरासरी कामगिरीवर आधारित होती. बिगटेबलमधील समस्यांमुळे आणि स्टोरेज स्टॅकच्या खालच्या पातळीमुळे, सरासरी कार्यप्रदर्शन "मोठ्या" शेपटीने चालविले गेले: सर्वात वाईट 5% क्वेरी बहुतेक वेळा उर्वरितपेक्षा लक्षणीयरीत्या हळू होत्या.

SLO थ्रेशोल्ड जवळ आल्यावर ईमेल सूचना पाठवल्या गेल्या आणि जेव्हा SLO ओलांडली गेली तेव्हा मेसेंजर सूचना पाठवल्या गेल्या. दोन्ही प्रकारचे अलर्ट बर्‍याचदा पाठवले गेले होते, ज्यात अभियांत्रिकी वेळेचा अस्वीकार्य प्रमाण वापरला गेला: टीमने खरोखर संबंधित असलेल्या काहींना शोधण्यासाठी अलर्टद्वारे क्रमवारी लावण्यात बराच वेळ घालवला. आम्ही बर्‍याचदा वापरकर्त्यांना प्रभावित करणारी समस्या चुकवली कारण केवळ काही सूचना त्या विशिष्ट समस्येसाठी होत्या. पायाभूत सुविधांमधील समजण्याजोग्या समस्यांमुळे अनेक सूचना तातडीच्या नव्हत्या आणि मानक पद्धतीने प्रक्रिया केल्या गेल्या किंवा त्यावर अजिबात प्रक्रिया केली गेली नाही.

परिस्थितीवर उपाय करण्यासाठी, संघाने तीन-पक्षीय दृष्टीकोन घेतला: Bigtable चे कार्यप्रदर्शन सुधारण्यासाठी कठोर परिश्रम करत असताना, आम्ही तात्पुरते आमचे SLO उद्दिष्ट क्वेरी प्रतिसादाच्या लेटन्सीसाठी 75 व्या टक्केवारीसाठी सेट केले. आम्ही ईमेल अलर्ट देखील बंद केले कारण त्यापैकी बरेच होते की त्यांचे निदान करण्यात वेळ घालवणे अशक्य होते.

या रणनीतीमुळे आम्हाला दीर्घकालीन समस्यांचे निराकरण करण्यास प्रारंभ करण्याची परवानगी मिळाली बिगटेबल आणि स्टोरेज स्टॅकच्या खालच्या स्तरावर, सतत रणनीतिकखेळ समस्यांचे निराकरण करण्याऐवजी. सर्व वेळ अलर्टचा भडिमार न करता अभियंते प्रत्यक्षात काम करू शकतात. सरतेशेवटी, तात्पुरत्या स्वरुपात अलर्ट प्रक्रियेला स्थगिती दिल्याने आम्हाला आमच्या सेवेची गुणवत्ता सुधारण्याची परवानगी मिळाली.

Gmail: अंदाज करण्यायोग्य, अल्गोरिदमिक मानवी प्रतिसाद

त्याच्या स्थापनेच्या वेळी, Gmail एका सुधारित वर्कक्यू प्रोसेस मॅनेजमेंट सिस्टमवर तयार केले गेले होते जे शोध निर्देशांकाच्या प्रक्रियेच्या भागांना बॅच करण्यासाठी डिझाइन केले होते. वर्कक्‍यू दीर्घकाळ चालणार्‍या प्रक्रियेशी जुळवून घेण्यात आली आणि नंतर जीमेलवर लागू केली गेली, परंतु अपारदर्शक शेड्यूलर कोडमधील काही दोष निराकरण करणे खूप कठीण आहे.

त्या वेळी, Gmail मॉनिटरिंगची रचना केली गेली होती जेणेकरून वर्कक्यू वापरून वैयक्तिक कार्ये रद्द केल्यावर अलर्ट ट्रिगर केले जातील. हा दृष्टीकोन आदर्श नव्हता, कारण त्यावेळीही, Gmail ने हजारो कार्ये केली होती, त्यापैकी प्रत्येक आमच्या वापरकर्त्यांच्या काही टक्के लोकांना प्रदान केली गेली होती. आम्ही Gmail वापरकर्त्यांना चांगला वापरकर्ता अनुभव प्रदान करण्याबद्दल खूप चिंतित होतो, परंतु बर्याच सूचना हाताळणे आवाक्याबाहेर होते.

या समस्येचे निराकरण करण्यासाठी, Gmail SRE ने वापरकर्त्यांवरील प्रभाव कमी करण्यासाठी शक्य तितक्या सर्वोत्तम शेड्यूलर डीबग करण्यात मदत करण्यासाठी एक साधन तयार केले. दीर्घकालीन उपाय सापडेपर्यंत समस्या शोधण्यापासून संपूर्ण चक्र स्वयंचलित करायचे की नाही याबद्दल संघाने काही चर्चा केली होती, परंतु काहींना काळजी होती की अशा उपायामुळे समस्येचे निराकरण करण्यात विलंब होईल.

हा तणाव संघामध्ये सामान्य होता आणि अनेकदा स्वयं-शिस्तीवरील विश्वासाचा अभाव दिसून येतो: काही संघ सदस्य योग्य निराकरणासाठी वेळ देऊ इच्छित असताना, इतरांना काळजी वाटते की अंतिम निराकरण विसरले जाईल आणि तात्पुरते निराकरण कायमचे होईल. ही समस्या लक्ष देण्यास पात्र आहे कारण परिस्थिती कायमस्वरूपी बनवण्याऐवजी तात्पुरते निराकरण करणे खूप सोपे आहे. व्यवस्थापक आणि तांत्रिक कर्मचारी दीर्घकालीन निराकरणे अंमलात आणण्यात, प्रारंभिक "वेदना" कमी झाल्यानंतर देखील संभाव्य दीर्घकालीन निराकरणांना समर्थन आणि प्राधान्य देण्यात महत्त्वाची भूमिका बजावतात.

नियमित, पुनरावृत्ती सूचना आणि अल्गोरिदमिक प्रतिसाद लाल ध्वज असावा. या सूचना स्वयंचलित करण्यासाठी तुमच्या कार्यसंघाच्या अनिच्छेचा अर्थ असा आहे की ते अल्गोरिदमवर विश्वास ठेवू शकतात असा संघाला आत्मविश्वास नाही. ही एक गंभीर समस्या आहे ज्याकडे लक्ष देणे आवश्यक आहे.

दीर्घकालीन

एक सामान्य थीम Bigtable आणि Gmail उदाहरणांना जोडते: अल्पकालीन आणि दीर्घकालीन उपलब्धता यांच्यातील स्पर्धा. बर्‍याचदा, एक मजबूत प्रयत्न नाजूक प्रणालीला उच्च उपलब्धता प्राप्त करण्यास मदत करू शकतो, परंतु हा मार्ग सहसा अल्पकालीन असतो, संघ बर्नआउटने भरलेला असतो आणि त्याच वीर संघाच्या थोड्या सदस्यांवर अवलंबून असतो.

नियंत्रित, उपलब्धतेमध्ये अल्पकालीन घट अनेकदा वेदनादायक असते, परंतु प्रणालीच्या दीर्घकालीन स्थिरतेसाठी धोरणात्मकदृष्ट्या महत्त्वपूर्ण असते. प्रत्येक इशाऱ्याकडे एकाकीपणाने न पाहणे महत्त्वाचे आहे, परंतु अॅलर्ट व्हॉल्यूमच्या एकूण पातळीमुळे एक सक्षम टीम आणि अनुकूल रोगनिदानासह निरोगी, योग्यरित्या प्रवेशयोग्य प्रणाली बनते का याचा विचार करणे महत्त्वाचे आहे. आम्ही व्यवस्थापनास त्रैमासिक अहवालांमध्ये अलर्ट फ्रिक्वेंसी आकडेवारीचे विश्लेषण करतो (सामान्यत: प्रति शिफ्टच्या घटना म्हणून व्यक्त केले जाते, जेथे एका घटनेत अनेक संबंधित घटना असू शकतात) ज्यामुळे निर्णय घेणाऱ्यांना अॅलर्ट सिस्टम लोड आणि एकूण टीमच्या आरोग्याचा सतत दृष्टिकोन ठेवता येतो.

निष्कर्ष

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

दीर्घकालीन, लक्षणे आणि नजीकच्या वास्तविक समस्यांबद्दल सतर्कतेचे यशस्वी परिभ्रमण साध्य करणे आवश्यक आहे, निरीक्षण जलद निदानास समर्थन देते याची खात्री करण्यासाठी लक्ष्ये स्वीकारणे आवश्यक आहे.

अनुवाद शेवटपर्यंत वाचल्याबद्दल धन्यवाद. मॉनिटरिंगबद्दल माझ्या टेलिग्राम चॅनेलची सदस्यता घ्या @monitorim_it и मध्यम वर ब्लॉग.

स्त्रोत: www.habr.com