वास्तविक समय लॉग विश्लेषण

आधुनिक निगरानी प्रणाली "बॉक्स से बाहर" आपको एकल सिस्टम नोड के लगभग सभी संकेतकों को ट्रैक करने की अनुमति देती है, लेकिन कई महत्वपूर्ण कमियां हैं।

• एक नोड के बारे में सब कुछ जानते हुए भी, उन्हें सिस्टम के संचालन के बारे में कोई विचार नहीं है - पूरे बॉक्स को प्रबंधन देने की कोशिश करें "फिलहाल हमारे सामने 1200RPS हैं, 90% पृष्ठ 300ms में दिए गए हैं, 650% में 95%, सिस्टम की त्रुटियां और टाइमआउट 10 प्रति सेकंड ”(कट के नीचे की तस्वीर देखें)
• सिस्टम नोड्स में से एक के सिस्टम संकेतक से परे जाने का मतलब यह नहीं है कि यह अलार्म के लायक है - शायद नोड बढ़े हुए लोड के तहत आया है, या डेवलपर्स ने एल्गोरिथ्म को बदल दिया है
• व्यक्तिगत नोड्स की निगरानी के भाग के रूप में, सेवा के क्रमिक क्षरण को ट्रैक करना लगभग असंभव है - एक नियम के रूप में, यह तभी काम करता है जब "कुछ भी नहीं" पहले से ही काम करता है
• बाह्य सेवाओं के प्रदर्शन में गिरावट को सिद्धांत रूप में मॉनिटर नहीं किया जाता है (क्या आपको कभी सीडीएन द्वारा प्रतिबंधित किया गया है?)

हमारी साइट की प्रारंभिक साइट पर, 1,000,000 से अधिक अद्वितीय आगंतुक हैं, प्रति दिन फ्रंट-एंड के लिए 100,000 100,000 http अनुरोध, और समर्थन के मामले में एक वजनदार, परियोजनाओं का चिड़ियाघर। कीवर्ड का एक सेट - नग्नेक्स, अपाचे, php (दो भिन्नताएं), ओरेकल। एक आवधिक आवधिकता के साथ, परिस्थितियां उत्पन्न होती हैं कि "सब कुछ हमारे लिए काम करता है" जिम्मेदारी के व्यक्तिगत क्षेत्रों में या, जो असामान्य नहीं है, "आपके लिए कुछ भी काम नहीं करता है"। जिम्मेदारी की सीमाओं पर टिकटों का निरंतर हस्तांतरण होता है।
हमने पहिया को फिर से शुरू करने के लिए शुरू नहीं किया और बैकएंड की प्रतिक्रिया को ट्रैक करने के साथ उपयोगकर्ता की प्रतिक्रिया के समय और शुद्धता की निगरानी करने का निर्णय लिया, साथ ही उनमें से कौन से एक विशिष्ट अनुरोध को संसाधित करने में शामिल थे। ठीक है, प्लस हमारे वॉल्यूम - बहुत बड़े नहीं हैं, लेकिन प्रस्तुति के दौरान कुछ रेक का प्रदर्शन किया जा सकता है।


आखिर में हमें क्या मिला।

1. स्रोत डेटा की तैयारी।

यदि सिस्टम में एक से अधिक नोड हैं, तो पूरे सिस्टम के माध्यम से सामने से शुरू होने वाले एक अनुरोध को ट्रैक करने का तरीका अच्छा होगा। यदि दर्जनों नोड्स हैं, तो क्लाइंट आईपी अब मदद नहीं करेगा। यदि आधार नीचे है, तो डीबीए कभी-कभी टांका लगाने वाले लोहे और "जिसका अनुरोध ???" वाक्यांश के साथ चलेगा। ठीक है, संयुक्त मानक में बैकएंड के लिए प्रसंस्करण समय के बारे में कोई जानकारी नहीं होती है, अपस्ट्रीम द्वारा चयनित कैश में मारा जाता है, जिस समय उपयोगकर्ता को डेटा भेजा गया था। मानक नगनेक्स मॉड्यूल में लगभग वह सब कुछ होता है जिसकी हमें आवश्यकता होती है। हमने हेडहंटर से केवल एक मॉड्यूल जोड़ा
github.com/hhru/nginx_requestid , nginx पर प्रत्येक अनुरोध के लिए एक अद्वितीय पहचानकर्ता असाइन करना और आपको इसे लॉग में लिखने की अनुमति देता है, और हेडर में भी इसे ऊपर और नीचे अग्रेषित करता है। हमारे nginx लॉग का अंतिम प्रारूप निम्नानुसार है।



डरावना? यह अधिक मजेदार है कि अपस्ट्रीम प्रकार के क्षेत्रों में निम्नलिखित चीजें हो सकती हैं "upstream_1: upstream_2", इस अनुरोध को संसाधित करने वाले सभी बैकेंड के लिए। Request_id को पहले ही वर्णित किया जा चुका है, अंतिम दो uid_got, uid_set ngx_http_userid मॉड्यूल हैं, जो आपको सिस्टम कुकीज़ स्थापित करके एक विशिष्ट उपयोगकर्ता को ट्रैक करने की अनुमति देता है। पार्सिंग अनुभाग में एक विभाजक के रूप में चार रिक्त स्थान का उपयोग क्यों किया जाता है। अपाचे या php-fpm स्तर पर, यह अनुरोध करता है कि ऊपर से लॉग में आए request_id को लिखें, और यदि अनुरोध बैलेंसर को अपस्ट्रीम के रूप में निर्दिष्ट किया गया है, तो होस्ट नाम दें। आवेदन स्तर पर, त्रुटि संदेशों में request_id को इंगित करने के लिए एक नियम स्थापित करना सार्थक है। एक छोटे से नोट में वर्णित ओरेकल सत्र के लिए डेटा का अनुरोध करने के तरीकों में से एक। इसका लाभ यह है कि आपको डेवलपर्स को अपने साधनों के साथ ऐसा करने के लिए कहने की आवश्यकता नहीं है और इस बात की गारंटी है कि आपके पास एक बार में सभी परियोजनाओं पर डेटा होगा। यह प्रत्येक अनुरोध के लिए और परियोजना / साइट के लिए औसतन बाह्य संसाधनों (आधार, एपीआई सेवाएं, सिस्टम कॉल) की विलंबता को ट्रैक करने के लिए पिनबा या xhprof की दिशा में देखने के लिए भी समझ में आता है। इस क्षेत्र में हमारा निरंतर समाधान सर्दियों के करीब तैयार होगा।

आगे चर्चा वर्तमान में हमारे सिस्टम में सबसे अधिक जानकारीपूर्ण और स्वैच्छिक के रूप में नग्नेक्स लॉग का उपयोग करके लॉग का विश्लेषण करने के हमारे प्रयास के लिए समर्पित है।

2. एक ही केंद्र में लॉग का संग्रह।

लॉग एकत्रीकरण में वास्तविक मानक डीएसएल के विभिन्न कांटे और वंशज हैं। यूडीपी का उपयोग कनेक्शन समर्थन और वितरण आश्वासन के रूप में ओवरहेड से बचने के लिए परिवहन के रूप में किया जाता है। आप सामान्य मोड में कुछ प्रतिशत संदेश खो सकते हैं, और अधिक वैश्विक नुकसान आपके बुनियादी ढांचे की वैश्विक समस्याओं के साथ पहले से ही जुड़े होंगे, जिसके बारे में आप अन्य स्रोतों से सीखेंगे। आप hh.ru के संचालन निदेशक की रिपोर्ट "SOA पर स्विच करने का अनुभव" www.slideshare.net/kuchinskaya/sivko की रिपोर्ट से संदेशों की एक बड़ी धारा में नुकसान के बारे में अधिक जान सकते हैं, यह एक ही स्थान पर लॉग एकत्र करने के कई विकल्पों पर चर्चा करता है। Udp डिलीवरी के अलावा, यह भविष्य के लिए सिंगल फाइल स्टोरेज में लॉग इकट्ठा करने के लिए समझ में आता है।

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

2.5 पार्सिंग लॉग।

हमारे मामले में, पार्सर पर्ल में लिखा गया है, डेटा MongoDB 2.2.0 में संग्रहीत है। एल्गोरिथ्म अपमान करने के लिए सरल है - फ़ाइल में अंतिम संसाधित स्थिति को याद रखें, वर्तमान आकार की तुलना करें, यदि डेल्टा कट-ऑफ से अधिक है - हम इसे फ़ाइल पार्सिंग में भेजते हैं, पार्सिंग में हम रिकॉर्ड की शुद्धता की जांच करते हैं (क्या हमें रिकॉर्डिंग बफ़रिंग के बारे में सब कुछ याद है?)। एक रेक से

• अगर बहुत सारी फाइलें हैं - हर बार फाइल खोलने के बजाय, स्टोर डिस्क्रिप्टर को स्टोर करें, तो इतना समय नहीं है, लेकिन स्टोरेज अधिक सुखद हो जाएगा
• reg हमारे प्रारूप में प्रति सेकंड 700 लाइनों को संसाधित करता है, एक मानक विभाजक प्रारूप पर स्विच करने और विभाजन के साथ नियमित रूप से बदलने के बाद, गति प्रति सेकंड 10-20 हजार लाइनों तक बढ़ गई। यहां संख्याएं आंतरिक मान्यताओं से बेहतर हैं
• यदि पुनरावृत्ति का समय दो या तीन सेकंड से कम है - थोड़ी नींद लें, तो भंडारण और भी अधिक सुखद हो जाएगा कि यह हर सेकंड सैकड़ों फाइलों के आंकड़ों के लिए नहीं खींचा जाता है
• बैच_इन्टर बेस को अच्छा बनाएगा, लेकिन मोंगो में एक इन्सर्ट कॉल पर 16MB की सीमा होती है (4MB से 2.2)

Udp डेटा भेजकर इन सभी आकर्षण से बचा जा सकता है।

3. कंप्यूटिंग एनालिटिक्स और खोज के लिए अस्थायी भंडारण।

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

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

मानगो के गैर-धार्मिक लाभों में से

• कैप्ड कलेक्शन - रेकॉर्ड्स का फि ल्म कलेक्शन, हमारे मामले में अभी भी पर्याप्त 3GB कलेक्शन है, जिसकी फाइलें रैमडिस्क पर हैं
• एकत्रीकरण ढांचा - संस्करण 2.2 से एक नई सुविधा, 50-200 के लिए प्रति सेकंड 1.200-10.000 हमारे कार्य समूहों के लिए
• ttl संग्रह - संग्रह जहां आप रिकॉर्ड के जीवनकाल को निर्दिष्ट कर सकते हैं (मेमेचे में समाप्ति का एनालॉग), इमो कुछ हद तक कच्चा है
• एक धारा में गति लिखें - प्रति सेकंड 5-6 हजार रिकॉर्ड, कई रिकॉर्डिंग धाराओं द्वारा बढ़ाया जा सकता है

जेली

• संस्करण 2.2.0-rc0 के एकत्रीकरण $ परियोजना में, $ एड ऑपरेटर को स्ट्रिंग्स पास करना संभव था, इस प्रकार कई क्षेत्रों की एक समूह कुंजी बनाते हुए, संस्करण 2.2.0-rc1 में उच्चतर होता है और ऐसी कोई संभावना नहीं होती है, और 2.3 में $ concat ऑपरेटर का वादा किया जाता है। x बिना किसी समय सीमा के। मुझे प्रत्येक रिकॉर्ड में एक समूह कुंजी लिखकर, पार्सर में उच्च स्तर के चारों ओर जाना पड़ा
• जितने अधिक इंडेक्स बनाए जाएंगे, उतनी ही धीमी गति से प्रविष्टि होगी। कम सूचकांक, कम खोज के अवसर। अब हमारे पास दो इंडेक्स हैं - सिस्टम पहचानकर्ता और रिकॉर्ड से टाइमस्टैम्प। हम परीक्षण बेंच पर अधिक खर्च नहीं कर सकते।
• कैप्ड कलेक्शन बिल्ट-इन माध्यमों से फेरबदल नहीं है, यह आवेदन स्तर पर किया जाना चाहिए।

दूसरे रेक के बावजूद, अनुरोधों की संख्या, बैकएंड लोड, लास्ट-मिनट ट्रैफिक की शीर्ष -50 आईपी का पता लगाने के लिए अपेक्षाकृत जटिल अनुरोध 800-1200ms के लिए गणना की जाती है। हमारे मामले में, लोहे का एक टुकड़ा रिकॉर्डिंग डेटा के लिए कार्य करता है और उन्हें (मास्टर) बाहर करने के लिए मजबूर करता है, दूसरा एक प्रतिकृति है ताकि एनालिटिक्स गणना रिकॉर्डिंग को धीमा न करें।

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

टारनटूल के संभावित लाभों में से

• स्मृति आधारित डेटाबेस
• संग्रहीत कार्यविधियों के लिए भाषा निर्मित
• मास्को में रूसी और उच्च इत्र पार्टियों में लेखक की उपलब्धता

4. इकाइयों, प्रतिशत ...

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

my $res3=$slave->logs2->run_command( { aggregate=>'lines', pipeline=>[ {'$match'=>{'tstamp'=>{'$lt'=>$i,'$gte'=>$i-1}}}, {'$project'=>{ 'gf'=>1, 'upstream_time'=>1 ,'resp_time'=>1 ,'size'=>1 } }, {'$group'=>{'_id'=>'$gf',total=>{'$sum'=>1},traffic=>{'$sum'=>'$size'},'times'=>{'$push'=>'$upstream_time'},'response'=>{'$push'=>'$resp_time'}}} ] } ); 

जहां gf क्षेत्र है

 $inf{gf}=join(' ',($inf{upstream},$inf{code},$inf{host},$inf{backend},$inf{frontend},$inf{cache_status},$inf{content_type},$inf{url},$inf{upstream_code})); 

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

प्रमुख गणना की आवश्यकता यह है कि समय अंतराल की गणना समय और निगरानी प्रणालियों में लोड करना इस अंतराल से कम होना चाहिए।

हमारे पास इस समय 100-200ms प्रति सेकंड के अंतराल का क्रम है। दूसरा अंतराल सबसे गंभीर परिस्थितियों में सब कुछ में तोड़ने के लिए निर्माता के विधानसभा के चरण में चुना जाता है। वास्तविक परिस्थितियों में, 5/10/30/60-सेकंड औसत जीवन के लिए अधिक अधिकार हैं।

5. क्या हमने गणना की और आगे क्या?

सबसे पहले, डेटा किसी भी तरह अच्छी तरह से प्रदर्शित किया जाना चाहिए। पिछले चरणों को डीबग करने के चरण में, उच्चचर लाइब्रेरी का उपयोग किया गया था, डेटा को MongoDB से लिया गया था, जहां उन्हें बिंदु 4 से स्क्रिप्ट द्वारा जोड़ा गया था।

• अंतिम उपयोगकर्ता द्वारा प्रति पृष्ठ ग्राफ़ के सेट के मनमाने ढंग से गठन के मुद्दों को हल नहीं करता है
• सिद्धांत में निगरानी कार्यों के लिए अनुकूलित नहीं (सीमा मूल्यों का कोई ट्रैकिंग नहीं, एसएलए द्वारा सेवा उपलब्धता की गणना, आदि।)
• एक वाह प्रभाव प्रदान किया

भविष्य में, निगरानी प्रणाली के लिए महत्वपूर्ण इच्छाएं तैयार की गईं, जहां हम डेटा अपलोड करेंगे

• आपके मैट्रिक्स को शुरू करने की क्षमता
• उन्हें बाहर से डाउनलोड करें (एपीआई / सॉफ्टवेयर डाउनलोड करने के लिए)

इतना नहीं, zabbix, जिसे शीर्षक स्क्रीन पर दिखाया गया है, पूरी तरह से हमारे अनुकूल है। यहाँ, मानगो के साथ, यह सब व्यक्तिगत प्राथमिकताओं और विशिष्ट स्थिति पर निर्भर करता है। उनके मैट्रिक्स को zabbix trapper प्रकार के साथ शुरू किया जाता है, और डेटा को mybql बेस के रूप में zabbix_sender उपयोगिता द्वारा बैच मोड में लोड किया जाता है। सैकड़ों मान डाउनलोड करने में 1-2ms लगते हैं।

6. सारांश

किए गए काम के बाद, जो पृष्ठभूमि में एक महीने के बारे में था, हमें मिला

• 90 सेकंड की देरी के साथ चयनित मैट्रिक्स पर अप-टू-डेट जानकारी (बफ़र्स के माध्यम से रिकॉर्डिंग समय की गारंटी, पार्सिंग, मोंगो में रिकॉर्डिंग, दास के लिए प्रतिकृति, गणना)
• सभी सिस्टम नोड्स में उपयोगकर्ता अनुरोध प्रसंस्करण को ट्रैक करने की क्षमता (ngx_request_id)
• निम्नतम स्तर पर समझ - db, ऊपर से भरी हुई है (सत्र की जानकारी के अंदर होस्ट, request_uri, request_id को अग्रेषित करना)
• परियोजनाओं के लिए पूर्ण-पाठ खोज सेवा उपयोग आँकड़े
• प्रदान की गई सेवा के परिप्रेक्ष्य से साइट पर एक नज़र - कई परियोजनाओं द्वारा सामग्री का उत्पादन और वितरण
• बीकन मैट्रिक्स व्यक्तिगत परियोजनाओं और एक पूरे के रूप में साइट के लिए विशिष्ट है
• मार्गदर्शन के लिए सुंदर चित्र
• सबसे संभव विशलिस्ट के कार्यान्वयन के लिए मंच (वर्तमान चरण में शून्य बिंदु होना चाहिए)

विकास के पथ पर

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

यदि अधिक विस्तार से विषय में डुबकी लगाने की इच्छा है - पिछले वर्ष के हैंगआउट में, निगरानी और प्रोफाइलिंग का विषय बार-बार उठाया गया है, अगर टिप्पणियों में ऐसे प्रकाशनों के लिंक हैं - तो मुझे केवल खुशी होगी।

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