🤵🏿 ⬇️ 👟 नौ इलास्टिक्स खोज रेक पर मैंने कदम रखा 🗂️ 🌰 🕤

“एक प्रशिक्षित व्यक्ति भी एक रेक पर कदम रख रहा है।
लेकिन दूसरी ओर, जहां कलम है। ”

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

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

डेटा नोड्स समान होना चाहिए

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

Deprecation.log

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

[2018-07-07T14:10:26,659][WARN ][oedrRestController] Content type detection for rest requests is deprecated. Specify the content type using the [Content-Type] header. [2018-07-07T14:10:26,670][WARN ][oedrRestController] Content type detection for rest requests is deprecated. Specify the content type using the [Content-Type] header. [2018-07-07T14:10:26,671][WARN ][oedrRestController] Content type detection for rest requests is deprecated. Specify the content type using the [Content-Type] header. [2018-07-07T14:10:26,673][WARN ][oedrRestController] Content type detection for rest requests is deprecated. Specify the content type using the [Content-Type] header. [2018-07-07T14:10:26,677][WARN ][oedrRestController ] Content type detection for rest requests is deprecated. Specify the content type using the [Content-Type] header.

अनुरोध, औसतन, प्रत्येक 5-10 एमएस - और हर बार लॉग में एक नई लाइन जोड़ी जाती है। यह डिस्क सबसिस्टम के प्रदर्शन को नकारात्मक रूप से प्रभावित करता है और आयोवाइट को बढ़ाता है। Deprecation.log को बंद किया जा सकता है, लेकिन यह बहुत उचित नहीं है। इसमें लोचदार लॉग एकत्र करने के लिए, लेकिन कूड़े के लिए नहीं, मैं केवल ओडर्रस्टकंट्रोलर वर्ग के लॉग को अक्षम करता हूं।

ऐसा करने के लिए, निम्न निर्माण को log4j2.properties में जोड़ें:

 logger.restcontroller.name = org.elasticsearch.deprecation.rest.RestController logger.restcontroller.level = error

यह इस वर्ग के लॉग को त्रुटि स्तर तक बढ़ाएगा, और वे अब deprecation.log में नहीं आएंगे।

.kibana

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

 { "default": { "order": 0, "template": "*", "settings": { "number_of_shards": "1", "number_of_replicas": "0" } }, "mappings": {}, "aliases": {} }

और .kibana इंडेक्स, जहां सभी सेटिंग्स संग्रहीत हैं, एक ही कॉपी में बनाई गई है।

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

यह सब बस हल है। अब तक, कुछ भी नहीं गिर गया है:

 XPUT .kibana/_settings { "index": { "number_of_replicas": "<__>" } }

एक्सएमएक्स / एक्सएमएस

दस्तावेज कहता है, "32 जीबी से अधिक नहीं," और ठीक ही तो। लेकिन यह भी सही है कि आपको सेवा सेटिंग्स में स्थापित करने की आवश्यकता नहीं है

 -Xms32g -Xmx32g

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

 [2018-07-29T15:04:22,041][INFO][oeeNodeEnvironment][log-elastic-hot3] heap size [31.6gb], compressed ordinary object pointers [true]

उपयोग की जाने वाली मेमोरी की मात्रा निर्भर करती है, जावा के उपयोग के संस्करण पर निर्भर करती है। अपने मामले में सटीक मात्रा की गणना करने के लिए, दस्तावेज देखें।

अब मैंने लोचदार के सभी डेटा नोड्स पर स्थापित किया है:

 -Xms32766m -Xmx32766m

यह एक सामान्य तथ्य है, और दस्तावेज़ीकरण अच्छी तरह से वर्णित है, लेकिन मैं नियमित रूप से एलीस्टेकर्च इंस्टॉलेशन का सामना करता हूं जहां मैं इस बिंदु से चूक गया, और एक्सएमएस / एक्सएमएक्स 32 जी पर सेट है।

/ var / lib / elasticsearch

यह इलास्टिक्स खोज में डेटा संग्रहीत करने के लिए डिफ़ॉल्ट पथ है। YML:

 path.data: /var/lib/elasticsearch

आमतौर पर मैं एक बड़ा RAID सरणी माउंट करता हूं, और यहां बताया गया है: हम ES को डेटा स्टोर करने के कई तरीके निर्दिष्ट करते हैं, उदाहरण के लिए, इस तरह:

 path.data: /var/lib/elasticsearch/data1, /var/lib/elasticsearch/data2

डेटा 1 और डेटा 2 में विभिन्न डिस्क या छापे सरणियाँ आरोहित की जाती हैं। लेकिन लोचदार संतुलन नहीं रखता है और इन रास्तों के बीच लोड को वितरित नहीं करता है। सबसे पहले, वह एक सेक्शन भरता है, फिर दूसरे में लिखना शुरू करता है, इसलिए स्टोरेज पर लोड असमान होगा। यह जानकर, मैंने एक असंदिग्ध निर्णय लिया - मैंने RAID0 / 1 में सभी डिस्क को जोड़ दिया और इसे उस पथ में आरोहित कर दिया जो path.data में निर्दिष्ट है।

available_processors

और नहीं, मुझे अब निगेटिव नोड्स पर प्रोसेसर का मतलब नहीं है। यदि आप एक चालू नोड (_nodes API के माध्यम से) के गुणों को देखते हैं, तो आप कुछ इस तरह देख सकते हैं:

 "os". { "refresh_interval_in_millis": 1000, "name": "Linux", "arch": "amd64", "version": "4.4.0-87-generic", "available_processors": 28, "allocated_processors": 28 }

यह देखा जा सकता है कि नोड मेजबान पर 28 कोर के साथ चल रहा है, और लोचदार ने अपनी संख्या को सही ढंग से निर्धारित किया और सभी पर शुरू किया। लेकिन अगर 32 से अधिक कोर हैं, तो कभी-कभी ऐसा होता है:

 "os": { "refresh_interval_in_millis": 1000, "name": "Linux", "arch": "amd64", "version": "4.4.0-116-generic", "available_processors": 72, "allocated_processors": 32 }

आपको सेवा के लिए उपलब्ध प्रोसेसर की संख्या को मजबूर करना होगा - इससे नोड के प्रदर्शन पर अच्छा प्रभाव पड़ता है।

 processors: 72

thread_pool.bulk.queue_size

पिछले लेख के थ्रेड_पुल.बैंक। इंजेक्शन खंड में , इस तरह का एक मीट्रिक था - डेटा जोड़ने के अनुरोधों के लिए विफलताओं की संख्या की गिनती।

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

डिफ़ॉल्ट रूप से, कतार सेटिंग्स इस तरह दिखती हैं:

 "thread_pool": { "bulk": { "type": "fixed", "min": 28, "max": 28, "queue_size": 200 } }

एल्गोरिथ्म इस प्रकार है:

हम दिन के दौरान औसत कतार आकार पर आंकड़े एकत्र करते हैं (थ्रेड वैल्यू में स्टोर किया जाता है।
सक्रिय कतार के औसत आकार की तुलना में थोड़ा बड़ा आकार सावधानी से बढ़ाएं क्यूंकि - जब यह पार हो जाता है तो विफलता होती है;
हम पूल का आकार बढ़ाते हैं - यह आवश्यक नहीं है, लेकिन स्वीकार्य है।

ऐसा करने के लिए, होस्ट सेटिंग्स में ऐसा कुछ जोड़ें (आप निश्चित रूप से, आपके अपने मूल्य होंगे):

 thread_pool.bulk.size: 32 thread_pool.bulk.queue_size: 500

और नोड को पुनरारंभ करने के बाद, हम निश्चित रूप से लोड, I / O, मेमोरी खपत की निगरानी करेंगे। और यदि आवश्यक हो तो सेटिंग्स को वापस रोल करना संभव है।

महत्वपूर्ण: ये सेटिंग्स केवल नए डेटा प्राप्त करने पर काम करने वाले नोड्स पर समझ में आती हैं।

प्रारंभिक सूचकांक निर्माण

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

इसके बाद से यह माना जाता है कि हर दिन नए इंडेक्स माइक्रोसरोवर्स की संख्या द्वारा बनाए जाते हैं - इसलिए, हर रात पहले, लोचदार लगभग 8 मिनट के लिए क्लिनिक में गिर गया, जबकि एक सौ नए इंडेक्स बनाए गए, कई सौ नए शार्क, डिस्क लोड लोड शेल्फ से चले गए, कतारों में वृद्धि हुई। मेजबानों पर लोचदार को लॉग भेजने के लिए, और ज़ैबिक्स क्रिसमस के पेड़ की तरह अलर्ट के साथ खिल गए।

इससे बचने के लिए, पायथन लिपि को पूर्व बनाने के लिए सामान्य ज्ञान था। स्क्रिप्ट इस तरह से काम करती है: यह आज के लिए सूचकांकों को ढूंढती है, उनकी मैपिंग निकालती है और उसी मैपिंग के साथ नए सूचकांक बनाती है, लेकिन आने वाले दिन के लिए। यह क्रोन पर चलता है, उन घंटों के दौरान चलता है जब इलास्टिक सबसे कम लोड होता है। स्क्रिप्ट इलास्टिक्स खोज लाइब्रेरी का उपयोग करती है और GitHub पर उपलब्ध है ।

पारदर्शी माता-पिता विशाल पृष्ठ

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

यह मानक मॉनिटरिंग टूल द्वारा ग्राफ पर पकड़ा नहीं जाता है, जब तक कि गिरने के बहुत कम समय तक नियमित रूप से सेवा लॉग में - खाली नहीं होता है। इस बिंदु पर जावा मशीन की मेमोरी डंप भी संभव नहीं थी।

लेकिन, जैसा कि वे कहते हैं, "हम पेशेवर हैं, इसलिए कुछ समय बाद हमने समाधान खोज लिया।" इसी तरह की समस्या के बारे में थ्रेड पर चर्चा की गई थी ।asticastic.co और एक पारदर्शी बग के रूप में निकला जो विशाल पारदर्शी पृष्ठों से संबंधित है। Sysfsutils पैकेज का उपयोग करके कर्नेल में thp को बंद करके सब कुछ हल किया गया था।

यदि आपके पास पारदर्शी विशाल पृष्ठ हैं, तो यह जांचना सरल है:

 cat /sys/kernel/mm/transparent_hugepage/enabled always madvise [never]

यदि [हमेशा] है, तो आप संभावित रूप से जोखिम में हैं।

निष्कर्ष

यह मुख्य रेक है (वास्तव में वहाँ थे, निश्चित रूप से, अधिक), जो कि मैं एक साल के लिए और एलीस्टेकर्च क्लस्टर के व्यवस्थापक के रूप में डेढ़ साल तक चलने के लिए हुआ था। मुझे उम्मीद है कि यह जानकारी कठिन और रहस्यमय यात्रा पर आदर्श एलिस्टिक्स खोज क्लस्टर में काम आती है।

उदाहरण के लिए धन्यवाद, एंटोन गुडिम - उनके इंस्टाग्राम में अभी भी बहुत कुछ अच्छा है।

नौ इलास्टिक्स खोज रेक पर मैंने कदम रखा