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

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

पुराने स्कूल की ताकत

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

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

इस लेख से मुख्य निष्कर्ष:

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

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

जानवर बल विधि

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

मैंने Google पर इस दृष्टिकोण का उपयोग किया और इसने अच्छा काम किया। लेकिन स्केलेयर में, हम बाइट के लिए लॉग में बाइट को देखते हैं।

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

सूचकांक महान हैं, लेकिन उनकी सीमाएँ हैं। एक शब्द खोजना आसान है। लेकिन कुछ शब्द जैसे कि 'googlebot' और '404' वाले संदेश खोजना, पहले से ही बहुत अधिक जटिल है। 'अनकवर्ड अपवाद' जैसे वाक्यांशों की खोज के लिए एक अधिक बोझिल सूचकांक की आवश्यकता होती है जो न केवल उस शब्द के साथ सभी संदेशों को रिकॉर्ड करता है, बल्कि शब्द का विशिष्ट स्थान भी है।

असली कठिनाई तब होती है जब आप शब्दों की तलाश में नहीं होते हैं। मान लीजिए आप देखना चाहते हैं कि बॉट्स से कितना ट्रैफिक आता है। पहला विचार 'बॉट' शब्द के लिए लॉग की खोज करना है। तो आपको कुछ बॉट्स मिलेंगे: Googlebot, Bingbot और कई अन्य। लेकिन यहां bot बॉट ’एक शब्द नहीं है, बल्कि इसका एक हिस्सा है। यदि हम सूचकांक में 'बॉट' की खोज करते हैं, तो हमें 'Googlebot' शब्द के साथ संदेश नहीं मिलेंगे। यदि आप सूचकांक में प्रत्येक शब्द की जांच करते हैं और फिर पाए गए कीवर्ड के लिए सूचकांक को स्कैन करते हैं, तो खोज बहुत धीमी हो जाएगी। नतीजतन, लॉग के साथ काम करने के लिए कुछ कार्यक्रम एक शब्द के हिस्सों में खोज करने की अनुमति नहीं देते हैं (या सबसे अच्छा) कम प्रदर्शन के साथ विशेष सिंटैक्स का उपयोग करने की अनुमति देते हैं। हम इससे बचना चाहते हैं।

एक अन्य समस्या विराम चिह्न है। 50.168.29.7 से सभी अनुरोधों को खोजना चाहते हैं? डिबगिंग लॉग के बारे में क्या [error] ? सूचकांक आमतौर पर विराम चिह्न छोड़ते हैं।

अंत में, इंजीनियरों को शक्तिशाली उपकरण पसंद हैं, और कभी-कभी एक समस्या को केवल एक नियमित अभिव्यक्ति के साथ हल किया जा सकता है। कीवर्ड इंडेक्स इसके लिए बहुत उपयुक्त नहीं है।

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

कीवर्ड इंडेक्स बहुत अधिक स्थान लेते हैं, और लॉग प्रबंधन प्रणाली में भंडारण मुख्य लागत आइटम है।

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

जानवर बल काम करता है अगर आप एक जानवर बल समस्या है (और बहुत बल)

छोटे आंतरिक छोरों के साथ सरल कार्यों पर ब्रूट बल सबसे अच्छा काम करता है। अक्सर आप बहुत अधिक गति से काम करने के लिए आंतरिक लूप को अनुकूलित कर सकते हैं। यदि कोड जटिल है, तो इसे अनुकूलित करना अधिक कठिन है।

प्रारंभ में, हमारे खोज कोड में एक बड़ा आंतरिक लूप था। हम 4K पृष्ठों पर संदेश संग्रहीत करते हैं; प्रत्येक पृष्ठ में कुछ संदेश (UTF-8 में) और प्रत्येक संदेश के लिए मेटाडेटा हैं। मेटाडेटा एक संरचना है जिसमें मूल्य की लंबाई, आंतरिक संदेश आईडी और अन्य फ़ील्ड एन्कोडेड होते हैं। खोज लूप इस तरह दिखता है:



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

(आप पूछ सकते हैं कि हम इस प्रारूप में संदेशों को 4K पृष्ठों, पाठ और मेटाडेटा के साथ संग्रहीत करते हैं, बजाय लॉग के साथ सीधे काम करने के। आंतरिक स्केलर इंजन एक वितरित डेटाबेस की तुलना में अधिक क्यों दिखता है, इसके कई कारण हैं। फ़ाइल सिस्टम पाठ खोज अक्सर लॉग पार्सिंग के बाद खेतों में DBMS शैली फिल्टर के साथ संयुक्त है हम एक ही समय में कई हजारों लॉग खोज सकते हैं, और सरल पाठ फ़ाइलें हमारे लेनदेन, प्रतिकृति, वितरित नियंत्रण के लिए उपयुक्त नहीं हैं annymi)।

प्रारंभ में, ऐसा लगता था कि इस तरह के कोड जानवर बल विधि के तहत अनुकूलन के लिए बहुत उपयुक्त नहीं थे। String.indexOf() में "वास्तविक नौकरी" सीपीयू प्रोफाइल पर भी हावी नहीं हुई। यही है, केवल इस पद्धति का अनुकूलन एक महत्वपूर्ण प्रभाव नहीं लाएगा।

ऐसा हुआ कि हम प्रत्येक पृष्ठ की शुरुआत में मेटाडेटा संग्रहीत करते हैं, और UTF-8 में सभी संदेशों का पाठ दूसरे छोर पर पैक किया जाता है। इसका लाभ उठाते हुए, हमने एक ही बार में पूरे पृष्ठ पर खोज लूप को फिर से लिखा है:



यह संस्करण सीधे raw byte[] पर काम करता है raw byte[] पूरे 4K पेज पर एक बार में सभी संदेशों को देखता है और खोजता है।

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

हमारी वास्तविक खोज एल्गोरिथ्म लियोनिद वोल्निट्स्की के महान विचार पर आधारित है। यह प्रत्येक चरण में खोज स्ट्रिंग की लंबाई के बारे में स्किप करने के साथ बॉयर-मूर एल्गोरिथ्म के समान है। मुख्य अंतर यह है कि यह झूठे मैचों को कम करने के लिए एक बार में दो बाइट्स की जांच करता है।

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

बल लगाओ

हमने चर्चा की कि लॉग खोजों को "मोटे तौर पर" लागू किया जा सकता है, लेकिन हमारे पास कितनी "शक्ति" है? बहुत कुछ।

1 कोर : जब सही तरीके से उपयोग किया जाता है, तो आधुनिक प्रोसेसर का एक कोर अपने आप में काफी शक्तिशाली होता है।

8 कोर : हम वर्तमान में Amazon hi1.4xlarge और i2.4xlarge SSD सर्वर पर काम कर रहे हैं, जिनमें से प्रत्येक में 8 कोर (16 धागे) हैं। जैसा कि ऊपर उल्लेख किया गया है, आमतौर पर ये गुठली पृष्ठभूमि संचालन के साथ व्यस्त होती हैं। जब उपयोगकर्ता एक खोज करता है, तो पृष्ठभूमि के संचालन को रोक दिया जाता है, खोज के लिए सभी 8 कोर को मुक्त करता है। खोज आम तौर पर एक दूसरे विभाजन में पूरी होती है, जिसके बाद पृष्ठभूमि का काम फिर से शुरू होता है (नियंत्रक कार्यक्रम यह सुनिश्चित करता है कि खोज क्वेरी का एक बैराज महत्वपूर्ण पृष्ठभूमि के काम में हस्तक्षेप नहीं करेगा)।

16 कोर : विश्वसनीयता के लिए, हम सर्वर को मास्टर / दास समूहों में व्यवस्थित करते हैं। प्रत्येक मास्टर में एक SSD सर्वर और एक EBS अधीनस्थ होता है। यदि मुख्य सर्वर क्रैश हो जाता है, तो SSD पर सर्वर तुरंत अपनी जगह ले लेता है। लगभग हर समय, मास्टर और गुलाम ठीक काम करते हैं, इसलिए प्रत्येक डेटा ब्लॉक दो अलग-अलग सर्वरों पर खोजा जा सकता है (दास ईबीएस सर्वर में एक कमजोर प्रोसेसर है, इसलिए हम इस पर विचार नहीं करते हैं)। हम उनके बीच कार्य को विभाजित करते हैं, ताकि हमारे पास कुल 16 कोर उपलब्ध हों।

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

सादगी विश्वसनीयता प्रदान करती है

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

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

दूसरी ओर, किसी भी क्वेरी के लिए ब्रूट फोर्स सर्च कम या ज्यादा उसी गति से किया जाता है। लंबे शब्दों की खोज बेहतर है, लेकिन यहां तक ​​कि एकल चरित्र की खोज काफी तेज है।

ब्रूट फोर्स विधि की सादगी का मतलब है कि इसकी उत्पादकता सैद्धांतिक अधिकतम के करीब है। अप्रत्याशित डिस्क अधिभार, लॉक संघर्ष, पॉइंटर चेज़ और विफलताओं के हजारों अन्य कारणों के लिए कम विकल्प हैं। मैंने पिछले सप्ताह स्केलेयर उपयोगकर्ताओं द्वारा हमारे व्यस्ततम सर्वर पर किए गए अनुरोधों को देखा। 14,000 अनुरोध थे। उनमें से आठ ने एक से अधिक सेकंड लिए; 111 मिलीसेकंड के भीतर 99% ने प्रदर्शन किया (यदि आपने लॉग विश्लेषण उपकरण का उपयोग नहीं किया है, तो मेरा विश्वास करें: यह तेज़ है )।

सेवा का उपयोग करने की सुविधा के लिए स्थिर, विश्वसनीय प्रदर्शन महत्वपूर्ण है। यदि यह समय-समय पर धीमा हो जाता है, तो उपयोगकर्ता इसे अविश्वसनीय समझेंगे और इसका उपयोग करने के लिए अनिच्छुक हैं।

लॉग इन एक्शन

यहाँ एक छोटा सा एनीमेशन है जो स्केलियर को कार्रवाई में खोज दिखाता है। हमारे पास एक डेमो खाता है जहां हम हर घटना को हर सार्वजनिक गितुब भंडार में आयात करते हैं। इस डेमो में, मैं सप्ताह के लिए डेटा का अध्ययन करता हूं: लगभग 600 एमबी कच्चे लॉग।

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

निष्कर्ष में

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

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

जानवर बल का उपयोग करते हुए, हमने लॉग के एक सेट पर एक त्वरित, विश्वसनीय, लचीली खोज को लागू किया। हमें उम्मीद है कि ये विचार आपकी परियोजनाओं के लिए उपयोगी होंगे।

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