वेब सेवा प्रदर्शन की निगरानी। भाग I

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



बहुत कुछ इस बात पर निर्भर करता है कि कितनी बार ऐसी समस्याएं सामने आती हैं और कितनी जल्दी वे ठीक हो जाती हैं - सेवा, डेवलपर प्रतिष्ठा, आदि के साथ उपयोगकर्ता की संतुष्टि। आप प्रदर्शन के मुद्दों से कैसे निपट सकते हैं?



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



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



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



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



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

सक्रिय निगरानी

प्रोएक्टिव मॉनिटरिंग का अर्थ है दो चीजें:

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

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



अलर्ट का उपयोग करने से स्थानीय shamans को गंभीरता से राहत मिलेगी, क्योंकि मक्खी पर एक दिन में सैकड़ों शेड्यूल को घूरने के बजाय, यह फोन को अपनी जेब में रखने के लिए पर्याप्त है। एकमात्र सवाल यह है कि निगरानी के लिए क्या और कैसे है।



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



आपको एक अनुरोध प्रसंस्करण योजना बनाकर योजना शुरू करनी चाहिए। इस तरह की योजना का एक उदाहरण हो सकता है:







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



ऐसी योजना होने पर, आपको प्रत्येक घटक के लिए संभावित समस्याओं की सूची और उन्हें हल करने के लिए एक कार्यप्रणाली को चित्रित करना चाहिए, ताकि डेवलपर्स को असाधारण मामलों में शामिल किया जाए। ऐसी सूची का एक उदाहरण निम्नलिखित हो सकता है:

#	लक्षण	कारण	प्रतिक्रिया
1।	मुक्त हैंडलर के लिए औसत निष्क्रिय समय अनुमत मूल्य से अधिक है।	उपयोगकर्ताओं की सूजन	क्षैतिज स्केलिंग
2।	औसत पढ़ा / प्रेषित अनुरोध समय पर्याप्त मूल्य से अधिक हो गया	हमने नेटवर्क संसाधनों को पार कर लिया है।	टैरिफ प्लान में बदलाव
3।	औसत अनुरोध प्रसंस्करण समय स्वीकार्य मूल्य से अधिक हो गया	कोड \ आधार \ आदि के साथ समस्या	यह डेवलपर्स को आकर्षित करने का समय है

वास्तव में, तीसरे पैराग्राफ में कई उप-अनुच्छेद होते हैं, जिनमें से कुछ को प्रशासनिक रूप से हल किया जाता है और केवल दुर्लभ मामलों में डेवलपर्स को शामिल किया जाना चाहिए।



ऐसी योजना होने का लाभ स्पष्ट है - अधिकांश समस्याओं का समाधान किया जाता है, यदि तत्काल नहीं, तो विशिष्ट समय पर। हालाँकि, आपको योजना तैयार करने और सिस्टम को अंतिम रूप देने के लिए कड़ी मेहनत करने की आवश्यकता है, लेकिन बाद में और अधिक।



जारी रखने के लिए ...