🍳 💃🏼 🏔️ नग्नेक्स-एसएलए का उपयोग करके अपस्ट्रीम के विस्तारित आंकड़ों का संग्रह 🙎🏼 🎅🏾 💒

परिचय

ग्राहक सेवा की गुणवत्ता में लगातार सुधार करने से उनकी उच्च निष्ठा होती है। इसके अलावा, न केवल एक निश्चित ऑनलाइन उत्पाद के पालन के अर्थ में, बल्कि इसकी कमियों के लिए सहिष्णुता के अर्थ में भी, बशर्ते, कि लाभ गति, प्रयोज्य, कार्यक्षमता आदि हैं। - वे पल्ला झाड़ रहे हैं।

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

हमारे इंजीनियरिंग के दृष्टिकोण से, ऐसी विशेषताएँ प्रतिक्रिया समय और HTTP अपस्ट्रीम प्रतिक्रिया कोड हैं। वास्तव में, डिजाइन, उत्पाद की कार्यक्षमता, विपणन प्रयास और ग्राहक बज हमारी क्षमता से परे हैं। इसलिए, हमें इस बात पर ध्यान केंद्रित करने की आवश्यकता है कि हमारी शक्ति में क्या है - एप्लिकेशन के बुनियादी ढांचे में तेजी और क्लाइंट अनुरोधों को संसाधित करना।

कुछ एकत्रित सांख्यिकीय आधार के आधार पर प्रतिक्रिया और HTTP कोड का विश्लेषण करना सुविधाजनक है, और यहां हम लेख के विषय पर आसानी से दृष्टिकोण करते हैं।

हम क्या और क्यों मापते हैं

जैसा कि ऊपर उल्लेख किया गया है, हमारा कार्य अनुप्रयोग की गुणवत्ता का आकलन करना है, न कि इसकी गति (रूपरेखा) या अनुकूलन का वास्तविक माप। इसके लिए विशेष उपकरण हैं। एप्लिकेशन की गुणवत्ता के मुख्य संकेतक अपस्ट्रीम रिस्पांस टाइम और HTTP रिस्पांस कोड हैं, क्योंकि यह अपस्ट्रीम है जो प्रोडक्ट कंटेंट जेनरेट करने और यूजर रिक्वेस्ट को प्रोसेस करने का मुख्य कार्य करता है।

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

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

इस प्रकार, दो बुनियादी मानकों के अनुसार आंकड़े एकत्र किए जाने चाहिए:

अनुरोध के लिए अपस्ट्रीम प्रतिक्रिया समय।
इस पैरामीटर पर आंकड़ों का विश्लेषण करके, हम न केवल अपस्ट्रीम के समग्र प्रदर्शन का आकलन करने में सक्षम होंगे, बल्कि लोड परिवर्तनों में कुछ पैटर्न (पैटर्न) की पहचान करने के लिए, दिन के अलग-अलग समय पर औसत प्रतिक्रिया समय को बदलते हुए, आदि।
HTTP प्रतिक्रिया कोड
यह स्पष्ट है कि सभी त्रुटियों को पहचानना और समाप्त करना संभव नहीं होगा - किसी ने भी घुमावदार बाहरी लिंक को रद्द नहीं किया है। हालांकि, त्रुटियों की संख्या को कम करने का प्रयास निस्संदेह इसके लायक है। दोनों "अस्पताल में औसत तापमान" (कोड 2xx, 4xx) और सभी HTTP कोड के लिए सटीक लेआउट संग्रहीत और विश्लेषण किया जाना चाहिए। उदाहरण के लिए, आंकड़ों में 5xx कोड हमारी त्रुटि को इंगित करेगा (जिसका अर्थ है कि आवेदन की गुणवत्ता में कमी), जिसे ठीक करने की आवश्यकता है।

मापन सुविधाएँ

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

AJAX का अनुरोध - 200 मी
पेज जनरेशन - 1s
त्रुटि - 5 एस
टाइमआउट या कोई प्रतिक्रिया नहीं - 7s

दुर्भाग्यवश, इन या उन कार्य परिदृश्यों को स्पष्ट रूप से अलग करना हमेशा संभव होता है। उदाहरण के लिए, एक ही स्क्रिप्ट अलग-अलग सामग्री उत्पन्न कर सकती है, जो काम करने की स्थिति पर निर्भर करती है, जिससे माप परिणामों की गलत व्याख्या हो जाएगी।

इस मामले में, प्रतिशत समय सीमाओं के आधार पर प्रतिक्रिया समय का अनुमान लगाने के लिए सामान्य नियम तैयार करना संभव है। उदाहरण के लिए:

90% <200ms
95% <500ms
99% <1 s
100% <2s

इस प्रकार, श्रेणियों में से एक की सीमाओं से परे सांख्यिकीय मानों का निकास आवेदन की गुणवत्ता में कमी के एक संकेतक के रूप में काम करेगा।

माप परिणाम का मूल्यांकन कैसे करें

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

ESD / MITER (ESD-TR-86-278, "डिजाइनिंग यूजर इंटरफेस सॉफ्टवेयर के लिए दिशानिर्देश", 1986, www.dfki.de/~jameson/hcida/papers/smith-mosier.pdf )
TAFIM (सूचना प्रबंधन के लिए तकनीकी वास्तुकला ढांचा, 1996, खंड 8, DoD मानव कंप्यूटर इंटरफ़ेस शैली गाइड, www.everyspec.com/DoD/DOD-General/DISA_TAFIM_VOL8_7545 )
MIL-STD 1472 (2012 का संशोधन G, www.everyspec.com/MIL-STD/MIL-STD-1400-1499/MIL-STD-1472F_208 )

इन मानकों के अनुसार, अधिकतम उपयोगकर्ता प्रतीक्षा समय 10-15 सेकंड से अधिक नहीं होना चाहिए, औसत अनुरोध प्रसंस्करण समय 2-5 सेकंड से अधिक नहीं होना चाहिए, और सिस्टम प्रतिक्रिया समय 0.2-0.5 सेकंड होना चाहिए (मानकों को उन समय के उपकरणों की गणना के आधार पर लिखा गया था, जिसने आज अपनी उत्पादकता में अच्छी वृद्धि की है)।

एक अन्य स्रोत, "डिजाइनिंग और इंजीनियरिंग का समय: सॉफ्टवेयर में समय की धारणा का मनोविज्ञान" (2008, www.amazon.com/Designing-Engineering-Time-Psychology-Perception/dp/0321509188 ), यूजर टाइमआउट के आधार पर एक दृष्टिकोण पर विचार करता है:

बटन दबाते समय, मेनू को कॉल करते हुए, अन्य इंटरफ़ेस तत्वों के साथ बातचीत करते हुए सिस्टम को एक त्वरित प्रतिक्रिया (0.1 - 0.2 एस) दिखाना चाहिए।
एक साधारण उपयोगकर्ता के अनुरोध के जवाब में एक तत्काल प्रतिक्रिया (0.5 - 1 एस) का पालन करना चाहिए।
एक सतत प्रतिक्रिया (2 - 5 एस) वह समय है जिसके दौरान उपयोगकर्ता कार्य पर केंद्रित रहता है, दूसरे शब्दों में, प्रतिक्रिया समय।
प्रेरक प्रतिक्रिया (7 - 10 एस) - जब 7 सेकंड के बाद उपयोगकर्ता किसी अन्य कार्य पर स्विच करता है या पृष्ठ को छोड़ देता है।

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

चलो सीधे माप पर चलते हैं।

कैसे करें उपाय

लोकप्रिय नगनेक्स सर्वर के लिए आंकड़े एकत्र करने के कार्य के समाधान पर विचार करें।

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

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

दूसरा दृष्टिकोण अतिरिक्त मॉड्यूल का उपयोग है। कई विकल्पों पर विचार करें।

nginx-statsd
Nginx के लिए एक मॉड्यूल जो आंकड़े एकत्र करता है और उन्हें UDP का उपयोग करके StatsD डेमन पर पुनर्निर्देशित करता है। यह दृष्टिकोण, सबसे पहले, एक अलग सर्वर की आवश्यकता है, और दूसरी बात, सेवा यातायात में वृद्धि की ओर जाता है। इसके अलावा, StatsD ग्रेफाइट से बंधा है, और इसके साथ अन्य निगरानी प्रणालियों का एकीकरण मुश्किल है।
pinba
निग्नेक्स के लिए एक मॉड्यूल जो अनुरोध पूरा होने के समय आँकड़े एकत्र करता है और उन्हें यूडीपी के माध्यम से एक अलग सांख्यिकी संग्रह सर्वर में भेजता है। वास्तव में, इस समाधान के नुकसान इसके संचालन के बहुत सिद्धांत के कारण हैं: एक अलग सर्वर, "अतिरिक्त" यूडीपी यातायात की आवश्यकता। इसके अलावा, मॉड्यूल वास्तव में उस समय को पकड़ लेता है जब अनुरोध पूरा होने (बंद) के लिए समय मिलता है, अर्थात। उस समय को मापता है जब किसी अनुरोध को निष्पादित करने में समय लगता है, न कि हमें उस अपस्ट्रीम के प्रतिक्रिया समय की आवश्यकता होती है।
nginx-SLA
एक अतिरिक्त सर्वर को शामिल किए बिना nginx-sla मॉड्यूल अपस्ट्रीम सांख्यिकी संग्रह को लागू करता है। सादा पाठ प्रारूप में nginx के अनुरोध पर सांख्यिकी डेटा उत्पन्न होता है, इसलिए, न तो एक अलग सर्वर और न ही यूडीपी की आवश्यकता होती है।

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

नग्नेक्स-एसएलए के लाभ

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

डिफ़ॉल्ट कॉन्फ़िगरेशन के साथ nginx-sla द्वारा एकत्रित उदाहरण आँकड़े:

main.all.http = 1024 main.all.http_200 = 914 ... main.all.http_xxx = 2048 main.all.http_2xx = 914 ... main.all.time.avg = 125 main.all.time.avg.mov = 124 main.all.300 = 233 main.all.300.agg = 233 main.all.500 = 33 main.all.500.agg = 266 main.all.2000 = 40 main.all.2000.agg = 306 main.all.inf = 0 main.all.inf.agg = 306 main.all.25% = 124 main.all.75% = 126 main.all.90% = 126 main.all.99% = 130

जैसा कि आप देख सकते हैं, डेटा विभिन्न स्थितियों के साथ सभी संसाधित HTTP प्रतिक्रियाओं के आंकड़े प्रदर्शित करता है। उदाहरण के लिए, मान main.all.http_200 (main.all.http_404, main.all.http_500) संबंधित स्थिति के साथ संसाधित प्रतिक्रियाओं की संख्या को इंगित करता है।
और फ़ील्ड main.all.http_2xx में उन सभी अपस्ट्रीम प्रतिक्रियाओं की संख्या होती है जिनकी स्थिति "सफलता" है।

प्रतिक्रिया समय के आँकड़े चर में जमा किए जाते हैं main.all.300 (main.all.200, main.all.500, main.all.2000)। उदाहरण के लिए, 300 मिलीसेकंड से 500 मिलीसेकंड तक के समय के लिए संसाधित किए गए अनुरोधों की संख्या 33 है। और 500 एमएस या उससे कम के लिए संसाधित अनुरोधों की कुल संख्या 266 है।

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

आँकड़ों का प्रतिशत प्रतिशत, साथ ही औसत (main.all.time.avg) और मूविंग औसत (main.all.time.avg.mov) प्रतिक्रिया समय हमें विभिन्न लोड परिदृश्यों के तहत अपस्ट्रीम के व्यवहार का विश्लेषण करने की अनुमति देता है। उदाहरण के लिए:

निष्कर्ष और निष्कर्ष

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

यहां दो सरल कानूनों को याद करना उचित है:

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

30 एस तक की अवधि के लिए, अंतर को मानने की दहलीज लगभग 20% है। दूसरे शब्दों में, उपयोगकर्ताओं को वास्तविक मूल्य के 20% के भीतर प्रतिगमन या त्वरण की सूचना नहीं है। उपयोगकर्ता 20% से अधिक के अंतर का पता लगा सकता है, लेकिन यदि यह अंतर समय मानने के लिए न्यूनतम सीमा से कम हो जाता है, तो यह किसी का ध्यान नहीं जाएगा।

निष्कर्ष

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

पुनश्च मॉड्यूल उत्पादन वातावरण में काम कर रही शिकायतों के बिना पर्याप्त समय है। प्रतिक्रिया, बग, पुल-अनुरोधों का स्वागत है।

नग्नेक्स-एसएलए का उपयोग करके अपस्ट्रीम के विस्तारित आंकड़ों का संग्रह