🐆 👆 ⛑️ सेवा नेटवर्क कनेक्टिविटी निगरानी ⏩ 👩🏼‍💻 👐🏾

प्रस्तावना

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

नेटवर्क संरचना: फ्रंटएंड, बैकएंड, सेवाएं

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

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

CMDB जानकारी का दो तरह से उपयोग किया जा सकता है। पहली - सशर्त रूप से "ऑफ़लाइन", इस तथ्य में शामिल है कि, हर कुछ मिनटों में, स्क्रिप्ट सीएमडीबी से आवश्यक जानकारी का चयन करती है और अप-टू-डेट कॉन्फ़िगरेशन का निर्माण करती है, उदाहरण के लिए, नगणक्स के लिए, उनमें आवश्यक अपस्ट्रीम शामिल हैं। CMDB कार्यों तक पहुंचने का दूसरा तरीका अगले भाग में कैसे है।

CMDB, संक्षिप्त नाम, नाम से एक सेवा की खोज करें

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

Host58 पर स्थित be5 बैकएंड को डेटाबेस से कनेक्ट करने की आवश्यकता है, डेटाबेस सेवा का नाम db1 (छोटा DNS नाम) है
Db1.be5.host58.example.com नाम db1 नाम से बनाया गया है, resolv.conf के डेटा से। रिज़ॉल्वर PowerDNS अनुरोध भेजता है
Db1.be5.host58 नाम के pDNS प्लगइन का निष्कर्ष है कि host58 पर स्थित be5 कंटेनर db1 सेवा की तलाश में है
CMDB डेटा का उपयोग होस्ट 58 के निकटतम db1 सेवा प्रदान करने वाले कंटेनरों के IP को सूचीबद्ध करने के लिए किया जाता है
बी 5 पर सेवा प्राप्त सूची से एक मनमाना पते का चयन करती है और db1 सेवा तक पहुंचती है

मध्यवर्ती परिणाम को सारांशित करना: सीएमडीबी जानकारी के एकल स्रोत का उपयोग करके फ़्रंट, बैकएंड, सेवाएं एक-दूसरे को ढूंढते हैं। पते प्राप्त करने के लिए दो तरीके हैं: भवन विन्यास के माध्यम से और DNS प्रश्नों के माध्यम से।

भौतिक नेटवर्क संरचना, संचार समस्याएं

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

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

ऐसे समय में जब हमारे सर्वरों की संख्या दर्जनों तक सीमित थी, हमने परेशान नहीं किया, हमने प्रत्येक मेजबान से हर किसी को भेजे गए पिंग्स के माध्यम से कनेक्टिविटी की जाँच की और नुकसान पर नज़र रखी। जैसे ही मेजबानों की संख्या एक हजार के करीब पहुंचती है, यह सरल तरीका काम करना बंद कर देता है:

पिंग समय बहुत लंबा हो जाता है, या:
निगरानी के लिए नेटवर्क खपत ध्यान देने योग्य हो जाती है (मानक सर्वर एक सेकंड में एक हजार सर्वर से भेजे जाने वाले बैंडविड्थ की मेगाबिट के बारे में लेगा, यदि यह पूरे हजार सर्वरों द्वारा किया जाता है तो यह पहले से ही बहुत अधिक है)
प्रसंस्करण और विश्लेषण के लिए मेजबान पर सीपीयू की खपत "जो देखता है या नहीं देखता है" जो बड़ा हो जाता है
कंटेनरों के बीच कनेक्टिविटी की निगरानी नहीं की जाती है - हम ipsec समस्याओं या रूट कॉन्फ़िगरेशन को नहीं देखते हैं, जिससे कंटेनर स्तर पर समस्याएं होती हैं

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

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

निगरानी, परीक्षण

हम एक जगह कंटेनर के बीच प्रासंगिक कनेक्शन की पूरी सूची को संकलित कर रहे हैं, संचार की निगरानी के कार्य के लिए, यह एक जगह "सर्वर" की भूमिका निभाता है। सभी जानकारी एक शब्दकोश के रूप में सर्वर पर प्रस्तुत की जाती है:

पात्र	लिंक सूची
be5.host58	192.168.5.1 192.168.5.2 10.1.2.3 10.2.3.4
be8.host1000	10.0.0.1 10.0.100.5

सर्वर यह जानकारी REST इंटरफ़ेस के माध्यम से उपलब्ध कराता है।

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

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

परिणामों की निगरानी, प्रस्तुति और विश्लेषण

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

नाम	डिस्कनेक्ट	डीसी	भूमिका	भार	nginxErrRate	कनेक्टिविटी	nginxAccessRate
be1.host123	0	टेक्सास	होना	0.21	15.55		31.38
be1.host122	0	टेक्सास	होना	0.11 \|	18.28		34.61
fo1.host161	2	वीए	के लिए	0.02	0.11	10.1.1.4,10.1.2.4	14.1
fo1.host160	0	वीए	के लिए	0.0	0.00		0.0
fo1.host162	2	वीए	के लिए	0.01	0.18	10.2.1.4,10.2.4.3	17.56

इस तालिका में जानकारी का हिस्सा एजेंटों द्वारा भेजा गया था (डिस्कनेक्ट, लोड, नेग्नेक्स ...), भाग (डीसी, भूमिका) सीएमडीबी से आबादी है। चूँकि इस तालिका में डेटा बहुत अल्पकालिक है और इसमें पंक्तियों की संख्या हज़ारों के क्रम पर है, इसलिए यह इसे ": मेमोरी:" के वर्गलाइट डेटाबेस के भाग के रूप में डिजाइन करने के लिए समझ में आता है।

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

हमारे पास कभी-कभी ऐसी स्थिति होती है जिसमें सिस्टम में त्रुटियों का समग्र स्तर बढ़ने लगता है। यह हमारी परिचालन संबंधी समस्याओं और हमारे लिए बाहरी कारणों से संबंधित विभिन्न कारणों से हो सकता है। एक सार उदाहरण - डेटा केंद्रों के बीच रूटिंग बदल गया है, क्रॉस-डेटा सेंटर अनुरोधों के परिणामस्वरूप अब समय सीमा में फिट नहीं होता है, जो कि नेगनेक्स में 504 त्रुटियों की वृद्धि की ओर जाता है। क्वेरी "SELECT SUM (nginxAccessRate), SUM (nginxErrorRate), dataCenter से डेटा ग्रुप द्वारा डेटा सेंटर ORDER BY SUM (nginxAccessRate) हमें डेटा केंद्रों द्वारा अलग की गई त्रुटियों की एक सामान्य तस्वीर देता है। इस समग्र चित्र को केवल 504 त्रुटियों आदि के साथ काम करने वाले प्रश्नों का उपयोग करके विस्तृत किया जा सकता है।

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

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

यह आँकड़े + ग्रेफाइट जैसे बंडलों की जगह एक समाधान नहीं है, अगर केवल इसलिए कि कोई इतिहास नहीं है, सिस्टम के व्यवहार के विभिन्न वर्गों को जल्दी से प्राप्त करने की क्षमता सेवाओं के बीच कनेक्टिविटी का विश्लेषण करने के लिए सिर्फ एक बोनस है।

निष्कर्ष

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

सेवा नेटवर्क कनेक्टिविटी निगरानी