सभी को बधाई! मैं
Onlanta में एक सिस्टम इंजीनियर के रूप में काम करता
हूँ । हमारी एक परियोजना में, मैं इलास्टिक स्टैक के कार्यान्वयन और रखरखाव में शामिल था। हम लगभग एक केंद्रीकृत, स्वचालित प्रक्रिया में हाथ से लॉग एकत्र करने से चले गए। अब दो साल के लिए, हमने व्यावहारिक रूप से समाधान की वास्तुकला को नहीं बदला है और अन्य परियोजनाओं में एक सुविधाजनक उपकरण का उपयोग करने की योजना बनाई है। मैं आपके साथ इसके कार्यान्वयन का इतिहास, साथ ही साथ इस पोस्ट में कुछ ताकत और कमजोरियों को साझा करता हूं।
स्रोत2016 की शुरुआत में, हमारे प्रशासकों और डेवलपर्स के लॉग थे, इसलिए बोलने के लिए, "आपकी उंगलियों पर", यानी, उनके साथ काम करने के लिए एक अभियंता एसएसएच के माध्यम से मेजबान के लिए जुड़ा हुआ था जहां वह सेवा जिसमें वह रुचि रखते थे, ने पूंछ / grep / sed के लिए सार्वभौमिक सेट को उजागर किया / awk और उम्मीद है कि इस मेजबान पर आवश्यक डेटा ढूंढना संभव होगा।
स्रोतहमारे पास एक अलग सर्वर भी था, जहां सभी सर्वरों के लॉग वाली सभी निर्देशिकाएं एनएफएस के माध्यम से मुहिम की जाती थीं, और जिसे कभी-कभी लंबे समय तक सोचा जाता था कि हर कोई उस पर लॉग के साथ क्या करना चाहता था। खैर, कुछ सक्रिय रूप से अपडेट किए गए लॉग पर पूंछ चलने वाले कई पैनलों के साथ एक बड़े मॉनिटर पर बाहरी लोगों के लिए बहुत प्रभावशाली लग रहा था और उत्पादन के संस्कारों में शामिल होने का एक रोमांचक माहौल बनाया।
यह सब भी काम किया, लेकिन जब तक यह जल्दी से बड़ी मात्रा में डेटा को संसाधित करने के लिए आवश्यक नहीं था, और यह सबसे अधिक बार उन क्षणों में आवश्यक था जब कुछ ठेस में गिर गया था।
कभी-कभी घटनाओं की जांच के लिए अशोभनीय समय लगता था। इसका एक महत्वपूर्ण हिस्सा लॉग्स के मैनुअल एकत्रीकरण पर खर्च किया गया था, बैश और पायथन में विभिन्न लिपियों
की बैसाखी का शुभारंभ, लॉग के विश्लेषण के लिए कहीं अपलोड किए जाने की प्रतीक्षा में।
एक शब्द में, यह सब बहुत धीमा था, निराशा और असमान रूप से प्रेरित था कि यह लॉग के केंद्रीकृत भंडारण में भाग लेने का समय था।
ईमानदार होने के लिए, तकनीकी स्टैक की भूमिका के लिए उम्मीदवारों का चयन करने की कोई जटिल प्रक्रिया नहीं थी जो हमारे लिए यह सुनिश्चित करेगी: तब ईएलके बंडल उस समय पहले से ही लोकप्रिय था, अच्छे दस्तावेज थे, सभी घटकों के लिए इंटरनेट पर बड़ी संख्या में लेख थे। निर्णय तत्काल था: आपको प्रयास करने की आवश्यकता है।
स्रोतस्टैक की बहुत पहली स्थापना तीन आभासी मशीनों पर वेबिनार "लॉगस्टैश: 0-60 में 60" देखने के बाद की गई थी, जिनमें से प्रत्येक में एलीस्टेसर्च, लॉगस्टैश और किबाना का एक उदाहरण लॉन्च किया गया था।
इसके अलावा, हमें अंतिम मेजबानों से लॉगस्टैश सर्वरों तक लॉग की डिलीवरी में कुछ समस्याओं का सामना करना पड़ा। तथ्य यह है कि उस समय फ़ाइलबीट (पाठ फ़ाइलों से लॉग देने के लिए एक मानक स्टैक समाधान) ने बड़ी और जल्दी से अपडेट की गई फ़ाइलों के साथ बहुत बुरा काम किया, नियमित रूप से रैम में लीक हो गया और हमारे मामले में एक पूरे के रूप में अपने कार्य के साथ सामना नहीं कर सका।
इसके लिए IBM AIX चलाने वाली मशीनों से एप्लिकेशन सर्वर लॉग देने का तरीका खोजने की आवश्यकता को जोड़ा गया था: हमारे अनुप्रयोगों के थोक को तब WebSphere Application Server में लॉन्च किया गया था, जो विशेष रूप से इस OS के तहत काम करता था। फ़ाइलबीट को गो में लिखा गया है, 2016 में AIX के लिए अधिक या कम कुशल गो संकलक नहीं था, और मैं वास्तव में डिलीवरी के लिए लॉगस्टैश का उपयोग एजेंट के रूप में नहीं करना चाहता था।
हमने कई लॉग डिलीवरी एजेंटों का परीक्षण किया: फाइलबीट, लॉगस्टैश-फारवर्डर-जावा,
लॉग-कोरियर , पायथन-बीवर और एनएक्सलॉग। एजेंटों से, हमने उच्च प्रदर्शन, सिस्टम संसाधनों की कम खपत, लॉगस्टैश के साथ आसान एकीकरण, और एजेंट की ताकतों के साथ बुनियादी डेटा जोड़तोड़ करने की क्षमता (उदाहरण के लिए, बहु-लाइन घटनाओं की विधानसभा) की उम्मीद की।
मल्टीलाइन घटनाओं की विधानसभा के बारे में यह अलग से ध्यान देने योग्य है। प्रभावी रूप से, इसे केवल उस एजेंट के पक्ष में निष्पादित किया जा सकता है जो एक विशिष्ट फ़ाइल पढ़ता है। इस तथ्य के बावजूद कि लॉगस्टैश में एक बार मल्टीलाइन फिल्टर था और अब एक मल्टीलाइन कोडेक है, मल्टीलाइन प्रोसेसिंग के साथ कई लॉगस्टैश सर्वरों में इवेंट बैलेंसिंग को संयोजित करने के हमारे सभी प्रयास विफल रहे। यह कॉन्फ़िगरेशन कुशल घटना संतुलन को लगभग असंभव बना देता है, इसलिए, हमारे लिए, एजेंटों को चुनते समय सबसे महत्वपूर्ण कारक बहुस्तरीय समर्थन था।
विजेता इस प्रकार थे: लिनक्स के साथ मशीनों के लिए लॉग-कूरियर, AIX के साथ मशीनों के लिए NXLog। इस कॉन्फ़िगरेशन के साथ, हम बिना किसी समस्या के लगभग एक साल तक रहे: लॉग वितरित किए गए, एजेंट गिर नहीं गए (अच्छी तरह से, लगभग), हर कोई खुश था।
अक्टूबर 2016 में, बीट्स 5.0 सहित, इलास्टिक स्टैक घटकों के पांचवें संस्करण को जारी किया गया था। इस संस्करण में सभी बीट्स एजेंटों पर बहुत काम किया गया था, और हम फाइलबीट के साथ लॉग-कूरियर (जो उस समय तक अपनी समस्याएं थीं) को बदलने में सक्षम थे, जिसका हम अभी भी उपयोग करते हैं।
संस्करण 5.0 में माइग्रेट करते समय, हमने न केवल लॉग एकत्र करना शुरू किया, बल्कि कुछ मेट्रिक्स: पैकटविट का उपयोग यहां और वहां भी किया जाने लगा, जो फाइलों में एचटीटीपी रिक्वेस्ट लॉग लिखने के विकल्प के रूप में और मेट्रिकबीट ने सिस्टम मेट्रिक्स और कुछ सेवाओं के मेट्रिक्स एकत्र किए।
इस बिंदु पर, लॉग के साथ हमारे इंजीनियरों का काम बहुत सरल हो गया था: अब यह जानने की जरूरत नहीं थी कि लॉग इन करने के लिए आपको कौन सा सर्वर जाना है, जो जानकारी मिली थी, उसके बारे में सूचना का आदान-प्रदान केवल किबाना के लिंक को चैट रूम या मेल में स्थानांतरित करने के लिए सरल किया गया था, और रिपोर्ट जो पहले बनाई गई थीं कुछ ही घंटों में, कुछ ही सेकंड में बनना शुरू हुआ। यह नहीं कहा जा सकता है कि यह केवल आराम की बात थी: हमने अपने काम की गुणवत्ता में बदलाव किया, बंद कार्यों की मात्रा और गुणवत्ता में, हमारे स्टैंड पर समस्याओं की प्रतिक्रिया की गति में।
कुछ बिंदु पर, हमने इंजीनियरों को अलर्ट भेजने के लिए येल्प की इलास्टअर्ट उपयोगिता का उपयोग करना शुरू कर दिया। और फिर हमने सोचा: क्यों इसे हमारे ज़ैबिक्स के साथ एकीकृत नहीं किया गया है ताकि सभी अलर्ट का एक मानक प्रारूप हो और उन्हें केंद्र में भेजा जाए? समाधान काफी जल्दी मिल गया: इलास्टअर्ट आपको अलर्ट भेजने के बजाय किसी भी कमांड को चलाने की अनुमति देता है, जिसका हमने उपयोग किया था।
अब हमारे ElastAlert नियम, जब ट्रिगर होते हैं, तो कई लाइनों पर एक बैश स्क्रिप्ट निष्पादित करते हैं, जिसमें आवश्यक डेटा को नियम को ट्रिगर करने वाली घटना से तर्क में पारित किया जाता है, और zabbix_sender को स्क्रिप्ट से बुलाया जाता है, जो वांछित नोड के लिए Zabbix को डेटा भेजता है।
चूंकि घटना के बारे में पूरी जानकारी और एलिटिक्स खोज में हमेशा उपलब्ध रहने वाले लोगों के लिए, एकीकरण के साथ कोई कठिनाई नहीं थी। उदाहरण के लिए, हमारे पास पहले WAS एप्लिकेशन सर्वरों का स्वचालित रूप से पता लगाने के लिए एक तंत्र था, और उन घटनाओं में जो वे उत्पन्न करते हैं, सर्वर, क्लस्टर, सेल, आदि का नाम हमेशा लिखा जाता है। इसने हमें ElastAlert नियमों में query_key विकल्प का उपयोग करने की अनुमति दी ताकि नियमों की शर्तों को प्रत्येक सर्वर के लिए अलग से संसाधित किया जा सके। Zabbix_sender वाली स्क्रिप्ट को तब सर्वर के सटीक "निर्देशांक" मिलते हैं और डेटा को संबंधित नोड के लिए Zabbix में भेजा जाता है।
एक और समाधान जो हमें वास्तव में पसंद है और जिसे लॉग के केंद्रीकृत संग्रह के लिए संभव बनाया गया था, JIRA में स्वचालित रूप से कार्य लॉग बनाने के लिए एक स्क्रिप्ट है: दिन में एक बार यह लॉग से सभी त्रुटियों को पकड़ लेता है और, अगर कोई कार्य लॉग अभी तक नहीं हैं, तो उन्हें शुरू करता है। एक ही समय में, एक अद्वितीय अनुरोध आईडी द्वारा विभिन्न अनुक्रमित से, जांच में उपयोगी हो सकने वाली सभी जानकारी को कार्य में खींच लिया जाता है। परिणाम आवश्यक न्यूनतम जानकारी के साथ एक प्रकार का मानक वर्कपीस है, जो तब इंजीनियर आवश्यक होने पर पूरक कर सकते हैं।
बेशक, हम खुद को स्टैक की निगरानी के मुद्दे से सामना कर रहे थे। यह आंशिक रूप से एक ही इलास्टअर्ट का उपयोग करते हुए ज़ैबिक्स का उपयोग करके आंशिक रूप से लागू किया जाता है, और हमें स्टैक में निर्मित मानक निगरानी (एक्स-पैक में निगरानी घटक) का उपयोग करते हुए एलास्टिक्सर्च, लॉगस्टैश और किबाना के लिए मुख्य प्रदर्शन मीट्रिक मिलते हैं। इसके अलावा, स्टैक सेवाओं के साथ सर्वर पर, हमने
फायरहॉल से नेटडाटा स्थापित किया है। यह उपयोगी है जब आपको यह देखने की आवश्यकता होती है कि वास्तविक समय में और उच्च रिज़ॉल्यूशन के साथ किसी विशेष नोड में क्या होता है।
एक बार में, एलीटेसर्च निगरानी मॉड्यूल इसमें थोड़ा टूट गया था, हमने इसे पाया, इसे ठीक किया, सभी प्रकार के उपयोगी मीट्रिक जोड़े और एक पुल अनुरोध किया। इसलिए अब नेटडाटा एलिटिक्स के नवीनतम संस्करणों की निगरानी कर सकता है, जिसमें बुनियादी जेवीएम मेट्रिक्स, इंडेक्सिंग, सर्च परफॉर्मेंस इंडिकेटर्स, ट्रांजेक्शन लॉग स्टैटिस्टिक्स, इंडेक्स सेगमेंट इत्यादि शामिल हैं। हमें नेटडा पसंद है, और हमें खुशी है कि हम इसमें एक छोटा सा योगदान करने में सक्षम थे।
आज, लगभग तीन वर्षों के बाद, हमारा इलास्टिक स्टैक कुछ इस तरह दिखता है:
इंजीनियर स्टैक के साथ तीन मुख्य तरीकों से काम करते हैं:
- किबाना में लॉग और मैट्रिक्स को देखना और विश्लेषण करना;
- ग्राफाना और किबाना में डैशबोर्ड;
- SQL या बिल्ट-इन क्वेरी डीएसएल का उपयोग करके एलिटिक्सर्च के लिए प्रत्यक्ष प्रश्न।
कुल मिलाकर, इन सभी संसाधनों को आवंटित किया गया है: इलायची खोज डेटा गोदाम के लिए 146 सीपीयू, 484 जीबी रैम, 17 टीबी आवंटित किया गया है।
कुल मिलाकर, हमारे पास इलास्टिक स्टैक के भाग के रूप में काम करने वाली 13 आभासी मशीनें हैं: "हॉट" के लिए 4 मशीनें, एलिटेसर्च नोड्स, "वार्म" नोड्स के लिए 4, लॉगस्टैश के साथ 4 मशीनें और एक बैलेंसिंग मशीन। प्रत्येक गर्म नोड पर, इलास्टिक्स खोज किबाना उदाहरण चलाता है। यह शुरू से ही हुआ है, और अब तक हमें किबाना को अलग-अलग कारों में स्थानांतरित नहीं करना पड़ा है।
लेकिन लॉगस्टैश को अलग-अलग मशीनों में लेने का निर्णय स्टैक ऑपरेशन के दौरान सबसे सही और कुशल में से एक निकला: जेवीएम एलिटिक्सर्च और लॉगस्टैश के बीच सीपीयू समय के लिए उच्च प्रतिस्पर्धा ने लोड के फटने के दौरान बहुत सुखद विशेष प्रभाव नहीं डाला। कचरा बीनने वालों को सबसे ज्यादा नुकसान हुआ।
स्रोतहम क्लस्टर में पिछले 30 दिनों के लिए डेटा संग्रहीत करते हैं: अब यह लगभग 12 बिलियन की घटना है। दैनिक आधार पर, हॉट नोड्स अधिकतम संपीड़न अनुपात (शार्प-प्रतिकृति डेटा सहित) के साथ 400-500 जीबी डिस्क नए डेटा को लिखते हैं। हमारे इलास्टिक्सखोज क्लस्टर में एक गर्म / गर्म वास्तुकला है, लेकिन हमने इसे अपेक्षाकृत हाल ही में स्विच किया है, इसलिए अभी भी "गर्म" नोड्स की तुलना में "गर्म" नोड्स पर कम डेटा संग्रहीत है।
हमारे सामान्य कार्यभार:
- इंडेक्सेशन - 30,000 तक की चोटियों के साथ औसतन 13,000 आरपीएस (प्रतिकृति शार्क में अनुक्रमण को छोड़कर);
- खोज - 5200 आरपीएस।
हम ऐलिटिक्स खोज हॉट नोड्स पर 40-50% सीपीयू मार्जिन बनाए रखने की कोशिश करते हैं ताकि हम आसानी से अनुक्रमित घटनाओं की संख्या और किबाना / ग्राफाना या बाहरी निगरानी प्रणाली से भारी अनुरोधों में आसानी से अनुभव कर सकें। मेजर इलास्टिक्स नोड्स वाले मेजबानों पर लगभग 50% रैम हमेशा जेवीएम के पेज कैश और ऑफ-हाइप की जरूरतों के लिए उपलब्ध है।
पहले क्लस्टर के लॉन्च के बाद से बीते हुए समय के दौरान, हम खुद को एलास्टिक स्टैक के सकारात्मक और नकारात्मक पक्षों में से कुछ के रूप में पहचानने में कामयाब रहे, जो कि लॉग और खोज और विश्लेषणात्मक प्लेटफ़ॉर्म को एकत्रित करने का एक साधन है।
हम विशेष रूप से स्टैक के बारे में क्या पसंद करते हैं:- उत्पादों का एक एकल पारिस्थितिकी तंत्र एक दूसरे के साथ अच्छी तरह से एकीकृत होता है, जिसमें आपकी जरूरत की लगभग हर चीज होती है। बीट्स एक बार बहुत अच्छे नहीं थे, लेकिन अब हमें उनके बारे में कोई शिकायत नहीं है।
- लॉगस्टैश, इसकी सभी राक्षसी के साथ, एक बहुत ही लचीला और शक्तिशाली प्रीप्रोसेसर है और आपको कच्चे डेटा के साथ बहुत कुछ करने की अनुमति देता है (और अगर कुछ इसकी अनुमति नहीं देता है, तो आप हमेशा रूबी में एक स्निपेट लिख सकते हैं)।
- प्लगइन्स (और हाल ही में बॉक्स से बाहर) के साथ इलास्टिसर्च एक क्वेरी भाषा के रूप में एसक्यूएल का समर्थन करता है, जो अन्य सॉफ्टवेयर और एसक्यूएल के करीब लोगों के साथ एक क्वेरी लैंग्वेज के साथ इसके एकीकरण को सरल करता है।
- उच्च-गुणवत्ता वाले दस्तावेज़ जो आपको नए कर्मचारियों को परियोजना के बारे में जानने के लिए जल्दी से परिचय करने की अनुमति देते हैं। ढेर का संचालन, इसलिए, एक व्यक्ति का व्यवसाय नहीं बनता है, जिसके पास कुछ विशिष्ट अनुभव और "गुप्त ज्ञान" है।
- प्राप्त आंकड़ों की संरचना के बारे में पहले से जानने के लिए उन्हें एकत्र करने के लिए बहुत कुछ करने की आवश्यकता नहीं है: आप एकत्र होने वाली घटनाओं को शुरू कर सकते हैं जैसे कि वे हैं, और फिर, जैसा कि आप समझते हैं कि आप उनसे कौन सी उपयोगी जानकारी निकाल सकते हैं, "बैक संगतता" खोए बिना उन्हें संसाधित करने के दृष्टिकोण को बदल दें। इसके लिए स्टैक पर कई सुविधाजनक उपकरण हैं: अनुक्रमणिका, स्क्रिप्टेड फ़ील्ड, आदि में फ़ील्ड उपनाम।
- एक्स-पैक घटकों को केवल सदस्यता मॉडल के अनुसार वितरित किया जाता है और कुछ नहीं: यदि गोल्ड से, उदाहरण के लिए, केवल आरबीएसी या पीडीएफ रिपोर्ट के लिए समर्थन करते हैं, तो आपको सोने की हर चीज के लिए भुगतान करना होगा। यह विशेष रूप से निराशाजनक है जब, उदाहरण के लिए, आपको केवल प्लेटिनम से ग्राफ़ की आवश्यकता होती है, और मशीन लर्निंग और अन्य कार्यक्षमता का एक और बंडल जिसे आपको वास्तव में ज़रूरत नहीं है खरीद के लिए उपलब्ध हो सकता है। लगभग एक साल पहले व्यक्तिगत एक्स-पैक घटकों को लाइसेंस देने के बारे में लोचदार बिक्री विभाग के साथ संवाद करने के हमारे प्रयासों से कुछ भी नहीं हुआ, लेकिन शायद तब से कुछ बदल गया है।
- लगातार रिलीज जिसमें किसी भी तरह (हर बार नया) पिछड़े संगतता को तोड़ता है। आपको चैंज को बहुत ध्यान से पढ़ना होगा और पहले से अपडेट के लिए तैयार करना होगा। हर बार आपको चुनने की आवश्यकता होती है: पुराने संस्करण पर रहें, जो स्थिर रूप से काम करता है, या नई सुविधाओं और प्रदर्शन लाभ के लिए अपग्रेड करने का प्रयास करता है।
सामान्य तौर पर, हम 2016 में किए गए अपनी पसंद से बहुत खुश हैं, और हमारी अन्य परियोजनाओं के लिए लोचदार स्टैक के संचालन के अनुभव को स्थानांतरित करने की योजना बना रहे हैं: स्टैक द्वारा प्रदान किए गए उपकरण हमारे वर्कफ़्लो में बहुत कसकर एकीकृत होते हैं और अब उन्हें मना करना बहुत मुश्किल होगा।
और हमारी कंपनी में भी कई रिक्तियां खुली हैं।