यह आलेख nginx के लिए एक नए मॉड्यूल पर चर्चा करेगा, जिसका उद्देश्य उपयोगकर्ता को बैकएंड पर सर्वर एक्सेस के आंकड़ों के साथ इकट्ठा करना और प्रदान करना है। कटौती के तहत - विवरण, उपयोग के उदाहरण, स्क्रीनशॉट, लिंक, साथ ही निर्माण का इतिहास।
कहानी
इतना समय पहले नहीं, हमारी कंपनी का सर्वर सपोर्ट डिपार्टमेंट इस नतीजे पर पहुंचा था कि कुछ बदलने का समय आ गया है। अधिक सटीक रूप से, बढ़ते लोड के वितरण के साथ समस्याओं को हल करना आवश्यक था - हमारे मोर्चों ने कठिनाई के साथ अपने कार्य का सामना करना शुरू कर दिया।
JMeter की मदद से, हमने स्टैंड पर nginx, HAProxy, Brocade Server Iron ADX 1000 और कई अन्य बैलेन्सर चलाए। मुख्य चयन मानदंड पीरियड पीरियड्स में लगभग 50 हजार एक साथ एसएलएल सत्रों को समाप्त करने की क्षमता थी। लंबी अवधि के परीक्षण के बाद, विभिन्न कारणों से, नगनेक्स और इसके लोहे के प्रतियोगी ब्रोकेड सर्वर को छोड़कर सभी विकल्प गायब हो गए, और अंत में उनमें से केवल पहले ही बने रहे। अन्य चीजें समान होने के नाते, संभवत: नगनेक्स के पक्ष में निर्णायक कारक इसके विन्यास और लपट के लचीलेपन थे।
समस्या
पहले, हमने कुछ मोर्चों पर एक बैलेंसर के रूप में हाप्रोसी का उपयोग किया था। नगनेक्स पर स्विच करने के बाद, यह स्पष्ट हो गया कि हमारे पास इसमें बैकएंड के साथ काम करने पर किसी भी जानकारीपूर्ण आंकड़ों का अभाव था। तथ्य यह है कि उसी हैप्रॉक्सी के पास ऐसे आंकड़े थे, और इसकी मदद से हमने उन समस्याओं को ट्रैक किया जो बैकएंड पर उत्पन्न होती हैं और जल्दी से उन्हें जवाब दिया जाता है। नए बैलेंसर के साथ, हम इन आंकड़ों के बिना समाप्त हो गए, जैसे बिना हाथों के। stub_status और इसी तरह के मॉड्यूल ने हमें सूट नहीं किया, क्योंकि उनका कार्य आंकड़ों को अलग-अलग अपस्ट्रीम के संदर्भ में नहीं बल्कि पूरे सर्वर के रूप में दिखाना है। प्रत्येक अपस्ट्रीम / बैकएंड के लिए, हम ऐसे मापदंडों पर डेटा चाहते थे जैसे प्रत्येक बैकएंड पर कॉल की संख्या और HTTP त्रुटियों की संख्या 499/500/503 और TCP , और बाद में इस सूची का विस्तार हुआ।
निर्णय
चूंकि हमें अपनी समस्या के लिए कोई तैयार समाधान नहीं मिला, इसलिए एक मॉड्यूल लिखने का प्रयास किया गया, जो दृश्य रूप में आवश्यक जानकारी प्रदान करेगा। प्रयास, यह मुझे लगता है, एक सफलता थी, और काम का परिणाम ustats ( अपस्ट्रीम सांख्यिकी ) मॉड्यूल था।
आँकड़े क्या हैं?
Ustats के साथ, आप बैकेंड मेट्रिक्स जैसे आँकड़े रख सकते हैं
- अनुरोधों की संख्या ।
- त्रुटियों की संख्या 499/500/503 है ।
- HTTP की संख्या टाइमआउट को पढ़ती और लिखती है ।
- टीसीपी कनेक्शन त्रुटियों की संख्या ।
- विफलता टाइमर (असफल_ टाइमआउट) । नेगनेक्स में, यह पैरामीटर उसी नाम के निर्देश द्वारा कॉन्फ़िगर किया गया है और उस समय की अवधि निर्धारित करता है जिसके दौरान बैकएंड में कई असफल कॉल उत्तराधिकार में होने चाहिए (सटीक संख्या max_fails निर्देश द्वारा निर्दिष्ट की गई है), जिसके बाद बैकएंड को ब्लैकलिस्ट किया गया है और इसके लिए कॉल नहीं किए गए हैं समय विफल_समय आमतौर पर प्रशासक स्वयं इस बात से अवगत होता है कि उसके सर्वर कॉन्फिगरेशन में कौन से टाइमआउट्स लिखे गए हैं, लेकिन फिर भी यह हमें अपनी आँखों के सामने रखना अच्छा लगता है।
- बैकएंड के साथ काम करने के असफल प्रयासों की संख्या (गिनती में विफल रहता है) । नगीनक्स के अंदर, प्रत्येक बैकेंड के लिए, असफल प्रयासों का एक काउंटर बनाए रखा जाता है। यह संख्या बताती है कि समय के दौरान कितनी बार असफल समय समाप्त नोगेंक्स ने बैकएंड पर दस्तक देने की कोशिश की और विफल रहा (असफलता पर विचार करने के लिए, प्रॉक्सी_पास निर्देश का विवरण देखें)। काउंटर के संचालन का सिद्धांत काफी सरल है। जब नेगनेक्स किसी अनुरोध को पुनर्निर्देशित करने वाला होता है, तो यह पहली बार यह देखता है कि कौन सी बैकएंड लाइन में है (यदि हम राउंड रॉबिन को संतुलित करने की बात कर रहे हैं), इसकी स्थिति की जाँच करता है (ब्लैकलिस्ट किया गया है या नहीं), और यदि बैकएंड को "अनदेखा" किया जाता है, तो सर्वर अपनी अंतिम विफलता के समय को देखता है। । यदि उसके बाद से विफल_ समय समाप्त हो चुका है, तो बैकएंड के असफल प्रयासों का काउंटर रीसेट हो गया है, और अनुरोध भेजा गया है। यदि बैकएंड काली सूची में नहीं था, तो अनुरोध तुरंत भेजा जाता है, और काउंटर उस समय के आधार पर रीसेट किया जा सकता है जो पहली असफल कॉल के बाद से पारित हो गया है।
- विफल कॉल की अधिकतम संख्या (max_fails) । बैकएंड के साथ काम करने के असफल प्रयासों की संख्या के लिए सीमा को परिभाषित करता है, जिस पर पहुंचने पर बैकएंड को विफल_समय के लिए ब्लैकलिस्ट किया जाता है। यह पैरामीटर nginx config में भी निर्दिष्ट है, और हमने स्पष्टता के लिए आंकड़ों में इसका प्रदर्शन जोड़ा है।
- बैकएंड पर अंतिम असफल कॉल का समय । इसका उद्देश्य पिछले पैराग्राफ से स्पष्ट होना चाहिए :)
अतिरिक्त कार्य
इसके अलावा, ustats दिखा सकते हैं कि कौन से बैकएंड वर्तमान में काली सूची में हैं। मैं ध्यान देता हूं कि बैकएंड को समझा नहीं जाता है कि सर्वर निर्देश द्वारा nginx config में निर्दिष्ट क्या है, लेकिन सीधे उस पते पर जिसे निर्देश में निर्दिष्ट नाम हल किया गया है। यदि DNS में एक नाम के तहत कई पते सूचीबद्ध हैं, तो मॉड्यूल उन्हें अलग-अलग बैकेंड के रूप में प्रदर्शित करता है (यह इंगित करने के लिए कि वे किस नाम से आए थे, यह भूलकर भी)।
ब्लैकलिस्ट से बैकएंड को हाइलाइट करने के अलावा, ustats सर्वर से हाइलाइट करता है, अर्थात। के रूप में nginx विन्यास में वर्णित है
... सर्वर some.server.name नीचे; ...
और अंत में, मॉड्यूल का उपयोग करते हुए, आप वेब इंटरफ़ेस के माध्यम से सर्वर को उसके ऑपरेशन के दौरान सीधे nginx टोपोलॉजी से चालू और बंद कर सकते हैं। परिवर्तन कॉन्फ़िगरेशन में सहेजे नहीं जाते हैं और उन के कार्यान्वयन को सुविधाजनक बनाने के लिए डिज़ाइन किए गए हैं। बैकएंड के अस्थायी डिस्कनेक्ट को शामिल करने के लिए काम करता है। मैं आपको चेतावनी देना चाहता हूं: ustats इस कार्रवाई के अनधिकृत निष्पादन के खिलाफ कोई सुरक्षा प्रदान नहीं करता है, इसलिए आपको यह सुनिश्चित करना होगा कि एक यादृच्छिक व्यक्ति आपकी साइट के आधे बैकेंड को काम से बाहर न रखे :)
मामलों का उपयोग करें
उनमें से दो हैं। सबसे पहले, मॉड्यूल एक तालिका के साथ एक वेब पेज के रूप में सभी आंकड़े प्रदान करता है, जिसमें से किसी भी स्थान पर प्रदर्शन किया जा सकता है, जैसे कि stub_status:
स्थान / ustats {
ustats on;
...
}
पृष्ठ स्वचालित रूप से अपडेट किया जाता है, और अपडेट अंतराल (मिलीसेकंड में) को कॉन्फ़िगर में कॉन्फ़िगर किया जा सकता है:
... ustats_refresh_interval 7000 ...
दूसरे परिदृश्य में अन्य निगरानी उपयोगिताओं के लिए डेटा स्रोत के रूप में मॉड्यूल का उपयोग करना शामिल है। इस मामले में, इसके अनुरूप अनुरोध किए जाते हैं, जिसके जवाब में यह आवश्यक जानकारी के साथ एक साधारण xml देता है। आप एक अपस्ट्रीम या एक बैकएंड के लिए डेटा का अनुरोध कर सकते हैं। उदाहरण के लिए, अनुरोध
/ ustats? यू = ऑफ़लाइन
अपस्ट्रीम ऑफ़लाइन और अनुरोध पर सभी बैकेंड के लिए डेटा लौटाएगा
/ ustats? यू = ब्रेक और बी = the_old
अपस्ट्रीम ब्रेक में the_mold बैकएंड पर डेटा वापस आ जाएगा। यदि अपस्ट्रीम या बैकएंड नहीं मिला है, तो प्रतिक्रिया xml यह कहेगी।
कुछ तस्वीरें
निराधार नहीं होने के लिए, मैं मॉड्यूल के परिणाम पृष्ठ के कुछ स्क्रीनशॉट दे दूंगा। पहले स्नैपशॉट से nginx में, 2 अपस्ट्रीम कॉन्फ़िगर किए गए हैं, जिसमें सभी सर्वर स्थानीय हैं, एक ही nginx पर उठाया गया है, www सर्वर के अपवाद के साथ - यह यैंडेक्स पते को हल करता है:
तस्वीर में आप ग्रे लाइनों को देख सकते हैं - ये नगीनस विन्यास में "डाउन" के रूप में चिह्नित बैकएंड हैं, या मॉड्यूल पृष्ठ के माध्यम से बंद हो गए हैं। अब तक, कोई संख्या नहीं।
दूसरे स्क्रीनशॉट में, लाल रेखाओं ने पहली अपस्ट्रीम से तीन बैकएंड को हाइलाइट किया, जो कि ब्लैक लिस्ट में थे, जो अनुरोधों को उनके पास भेजे जाने से रोकते थे।
इस तथ्य के साथ कि तीन और बैकएंड को बंद कर दिया गया था, केवल शेष एक ने लोड पर लिया।
अंत में, अंतिम शॉट हमारी साइट से काम कर रहे दृश्यपटल पर लिया गया था:
तस्वीर एक और विशेषता दिखाती है जिसका मैंने अभी तक उल्लेख नहीं किया है। नीचे से ऊपर की ओर थोड़ा उज्जवल है - यह एक संकेत है कि वे स्पष्ट रूप से विन्यास में परिभाषित हैं, अर्थात। ऐसा नहीं है
अपस्ट्रीम give_me_a_name {
...
}
और ऐसा है
स्थान / व्हेरेमी {
...
प्रॉक्सी_पास http://192.168.0.75:8080
...
}
परिणाम
हमने मॉड्यूल के स्रोत कोड को Google कोड पृष्ठ पर पोस्ट किया है । रिपॉजिटरी में nginx के लिए पैच फ़ाइल होती है, स्रोत + कॉन्फ़िगरेशन फ़ाइल के साथ फ़ाइल। मॉड्यूल पृष्ठ पर इंस्टॉलेशन निर्देश हैं, अतिरिक्त कॉन्फ़िगरेशन निर्देश भी वहां वर्णित हैं। मॉड्यूल के वर्तमान संस्करण को क्रोम, फ़ायरफ़ॉक्स और ओपेरा में nginx संस्करण 0.8.53 के साथ परीक्षण किया गया था। अंत में, मुझे यह कहना होगा कि बैकस्ट के साथ काम करने के लिए डेटा प्रदर्शित करने के लिए ustats सिर्फ सबसे बुनियादी तंत्र को जोड़ने का प्रयास है। भविष्य में, मैं ऐसे बेकार मॉड्यूल को मुख्य सर्वर शाखा में देखना चाहूंगा, जैसे कि, उदाहरण के लिए, स्वास्थ्य जांच में आगे।