वितरित और क्लाउड बुनियादी ढांचे की निगरानी

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

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

ऐसा कभी नहीं होता

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

• अंतर्निहित मॉनिटरिंग जो सर्वर (डिस्क, मेमोरी, प्रोसेसर, नेटवर्क, सिस्टम, आदि) के भौतिक मापदंडों पर डेटा प्रदान करती है। मुनिन को अक्सर एक समाधान के रूप में प्रयोग किया जाता है ( हैबे ने पहले से ही इसके बारे में बहुत कुछ लिखा है ) प्लग-इन के एक बड़े सेट के साथ जो आपको हर समस्या बिंदु को नियंत्रित करने की अनुमति देता है। प्लगइन्स, वास्तव में, कंसोल स्क्रिप्ट हैं जो किसी दिए गए आवृत्ति के साथ एक विशिष्ट सिस्टम पैरामीटर की जांच करते हैं। सैद्धांतिक रूप से, इस स्तर पर भी, आप सर्वर के साथ "अनलोडिंग" क्रियाओं को करने के लिए ट्रिगर तंत्र का उपयोग कर सकते हैं। लेकिन व्यवहार में, निगरानी के अगले स्तर का उपयोग निर्णय लेने के लिए किया जाता है, अंतर्निहित निगरानी केवल आंकड़ों को इकट्ठा करने और अंदर से सिस्टम मापदंडों का विश्लेषण करने के लिए उपयोग किया जाता है।
• आंतरिक निगरानी में बुनियादी ढांचे के स्तर पर संपूर्ण बुनियादी ढांचे की स्थिति या इसके हिस्से की रोकथाम शामिल है। इसका मतलब है कि, काम करने वाले सर्वर (एप्लिकेशन, डेटाबेस) के साथ, सिस्टम में ऐसे सर्वर होने चाहिए जो इसकी स्थिति की निगरानी करते हैं और इस जानकारी (महत्वपूर्ण मामलों में) को पते पर भेजते हैं (उदाहरण के लिए, एसएमएस के माध्यम से सूचनाएं भेजना, या नए एप्लिकेशन सर्वर लॉन्च करना, या बैलेंसर के लिए काम करने वाले एप्लिकेशन सर्वरों के बारे में जानकारी दर्ज करना)। यहां सबसे अधिक उपयोग किया जाने वाला समाधान है नागाओस ( हैबे पर लेख ) बड़ी संख्या में चेक (कई सौ या हजारों आमतौर पर) के साथ। इसके अलावा, Pinba ( हैबर ) भी समस्याओं के अधिक सटीक विश्लेषण के लिए PHP अनुप्रयोगों के मामले में इससे जुड़ा हुआ है।
• आमतौर पर, दो पिछले निगरानी स्तर बुनियादी ढांचे के साथ सभी समस्याओं का पता लगाने और हल करने के लिए पर्याप्त हैं, लेकिन अक्सर (बादलों के मामले में) सभी बुनियादी ढांचे के सर्वर की स्थिति की निगरानी करते समय मध्यवर्ती निगरानी होती है, साथ ही साथ बादल में आवंटित शक्ति से गुजरने वाले सभी अनुरोधों का विश्लेषण करते हैं। मध्यवर्ती निगरानी का उपयोग सेवा गुणवत्ता नियंत्रण के एक अतिरिक्त स्तर के रूप में किया जाता है (उदाहरण के लिए, 500 त्रुटियों की संख्या को ट्रैक करना आसान है, भले ही एप्लिकेशन सर्वर सामान्य रूप से काम कर रहे हों) और भू-समूहों के बीच स्विचिंग क्षमताओं पर निर्णय लें (उदाहरण के लिए, यह अमेज़ॅन के लिए संभव है)।
• अंत में, उपयोगकर्ताओं की ओर से स्थिति का विश्लेषण करने के लिए बाहरी निगरानी का उपयोग किया जाता है। यहां तक ​​कि अगर सिस्टम ठीक से काम कर रहा है, तो सर्वर के बीच कनेक्टिविटी टूटी नहीं है, सर्वर जल्दी और सख्ती से प्रतिक्रिया करते हैं, उपयोगकर्ताओं को सेवा का उपयोग करने में समस्या आ सकती है, और यह नेटवर्क की सामान्य स्थिति पर निर्भर करेगा। इस स्तर पर, अतिरिक्त ट्रिगर्स उपयोगकर्ताओं को अन्य भू-समूहों में बदलने के बारे में निर्णय लेने के लिए संभव हैं (उदाहरण के लिए, यूरोपीय बिट्रिक्स 24 उपयोगकर्ताओं को यूरोपीय डेटा सेंटर, और अमेरिकी उपयोगकर्ताओं को अमेरिकी में भेजा जाना चाहिए)। इसके अलावा, आंतरिक और मध्यवर्ती निगरानी के परिणामों को अतिरिक्त रूप से सत्यापित करने के लिए इस निगरानी स्तर का उपयोग किया जा सकता है।

एकीकृत निगरानी

मुनिन आवश्यक सर्वर की स्थिति के बारे में बड़ी मात्रा में जानकारी प्रदान करता है। सबसे अधिक बार चेक किए गए बिंदुओं में शामिल हैं:

• PHP चेक (रनटाइम, मेमोरी उपयोग, हिट्स प्रति प्रक्रिया, आदि)
• Nginx जाँच (प्रतिक्रिया कोड, स्मृति उपयोग, प्रक्रियाओं की संख्या)
• मैसकल चेक (प्रश्नों की संख्या, मेमोरी उपयोग, क्वेरी निष्पादन समय)
• डिस्क की जाँच
• मेल डेमॉन की जाँच
• नेटवर्क की जाँच
• सिस्टम की जाँच

एक वास्तविक प्रणाली की निगरानी के कुछ चित्र (डाउनलोड और डेटाबेस)





उदाहरण के लिए, एक स्क्रिप्ट जो एक InnoDB MySQL तालिका में खाली स्थान की जांच करने के लिए है

  चूक के साथ ## ट्यून करने योग्य पैरामीटर
 MYSQL = "$ {mysql: - / usr / bin / mysql}"
 MYSQLOPTS = "$ {mysqlopts: --- user = munin --password = munin --host = localhost}"

 चेतावनी = $ {चेतावनी: -2147483648} # 2 जीबी
 CRITICAL = $ {आलोचनात्मक: -1073741824} # 1GB

 ## नीचे कोई उपयोगकर्ता सेवित भागों नहीं
 अगर ["$ 1" = "विन्यास"];  तो
     गूंज 'graph_title MySQL InnoDB मुफ्त तालिकाओं'
     प्रतिध्वनि 'graph_args --base 1024'
     गूंज 'ग्राफ_vlabel बाइट्स'
     गूंज 'ग्राफ_श्रेणी mysql'
     इको 'graph_info इनोबीडी टेबलस्पेस में मुफ्त बाइट्स की राशि'
     इको free free.label बाइट्स फ्री ’
     गूंज 'free.type GAUGE'
     इको 'फ्री.मिन 0'
     इको 'फ्री.वरिंग' $ चेतावनी:
     इको 'फ्री.क्रिटिकल' $ क्रिटिकल:
     बाहर निकलें 0
 फाई

 # Mysql से आज़ादी पाएं
 freespace = $ ($ MYSQL $ MYSQLOPTS --batch --skip-column-names --execute \)
     "टेबल से चयन करें टेबल से। TABLE_SCHEMA = 'munin_innodb'"
     INFORMATION_SCHEMA);
 रिटवल = $?

 # स्वच्छता की जाँच
 यदि ((रिटेल> 0));  तो
     इको "त्रुटि: mysql कमांड ने स्टेटस $ रिटवल लौटाया" 1> & 2
     बाहर निकलें -1
 फाई
 अगर [-z "$ फ्रीस्पेस"];  तो
     गूंज "त्रुटि: mysql कमांड ने कोई आउटपुट नहीं दिया" 1> & 2
     बाहर निकलें -1
 फाई

 # वापसी मुक्त
 इको $ फ्रीस्पेस |  awk '/ InnoDB मुक्त: / {प्रिंट "free.value", $ 3 * 1024} " 

जीआईटी रिपॉजिटरी में लोकप्रिय प्लगइन्स की एक बड़ी सूची पाई जा सकती है।

आंतरिक निगरानी

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

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

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

इंटरमीडिएट की निगरानी

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

निम्नलिखित सत्यापन विकल्प Amazon ( CloudWatch ) के लिए उपलब्ध हैं:

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

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

बाहरी निगरानी

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

बाहरी निगरानी के अतिरिक्त लाभों में सर्वर साइड (या वास्तविक नेटवर्क देरी) पर वास्तविक समय की प्रतिक्रिया की जांच करना शामिल है। आप इस पैरामीटर के लिए सूचनाएं भी कॉन्फ़िगर कर सकते हैं। CDN का उपयोग करने के मामले में एक अतिरिक्त अवसर के रूप में: आप सेवा पृष्ठों के कुल लोड समय को ट्रैक कर सकते हैं और विभिन्न क्षेत्रों के लिए CDN को अक्षम या सक्षम कर सकते हैं।

पुनश्च समीक्षा लेख, बड़ी परियोजनाओं की निगरानी की वास्तुकला के बारे में अधिक। मैं आपको निम्नलिखित लेखों में विशिष्ट लागू चीजों के बारे में बताऊंगा।