👨🏾‍🍳 🗺️ 🗳️ हम लंबरजैक + लॉगस्टैश + एलेस्टिक्स खोज + रैबिटएमक्यू का उपयोग करके लॉग एकत्र करते हैं और उनका विश्लेषण करते हैं 👸🏼 📍 💽

शुभ दोपहर

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

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

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

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

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

हमारे लक्ष्य एप्लिकेशन जिनके साथ हम लॉग एकत्र करते हैं:
1. जावा (जेटी / मूल) में दानव
2. Node.js पर दानव
3. गतिशील रूप से लॉन्च किए गए जावा एप्लिकेशन (उदाहरण के लिए, क्लस्टर नोड्स)

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

1. अच्छा बहुस्तरीय संदेश समर्थन।
2. विभिन्न संदेश स्वरूपों को संभालने की क्षमता।
3. डेटा स्रोतों का आसान विन्यास।

कॉन्फ़िगरेशन भाग में गहराई से जाने के बिना, मैं घटकों के बारे में बात करूंगा और वे सर्किट में क्यों मौजूद हैं।
सामान्य तौर पर, हमारी लॉग संग्रह योजना इस प्रकार है:

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

एजेंटों

रूपलॉग एक तैयार-निर्मित लॉगिंग डेमॉन है और प्रतीत होता है कि यह सब कुछ कर सकता है, लेकिन बिंदु हमेशा विवरण में होता है।

फायदे:
1. तेज।
2. फ़ाइलों को ट्रैक करने में सक्षम।
3. एन्क्रिप्ट करने के लिए ~~खुदाई~~ करने के लिए ~~खुदाई~~ करने और नहीं एन्क्रिप्ट करने में सक्षम।
4. पहले से ही सिस्टम में है।

नुकसान:
1. मल्टीलाइन संदेश भेजने का तरीका नहीं जानता (बहु-संदेश प्राप्त करने के लिए सर्वर पर सभी प्रयास पूरी तरह से व्यर्थ थे)।
2. मुखौटा द्वारा फ़ाइलों को ट्रैक करना नहीं जानता है।
3. खराब फ़ाइल ट्रंकेशन संभालती है।

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

लंबरजैक (अब लॉगस्टैश-फारवर्डर के रूप में जाना जाता है) लॉग भेजने के लिए एक प्रायोगिक डेमॉन है।

फायदे:
1. तेज।
2. मिनिमलिस्टिक (यूनिक्स-वे)।
3. मास्क का उपयोग करने में सक्षम।
4. न्यूनतम संसाधनों (गो में लिखे गए) का उपभोग करता है।

नुकसान:
1. प्रायोगिक।
2. यह स्वतंत्र रूप से बहुस्तरीय संदेशों का समर्थन नहीं करता है।

लॉगस्टैश (केवल एक एजेंट के रूप में)

फायदे:
1. हर जगह लॉग इकट्ठा करने के लिए एक ही सॉफ्टवेयर।
2. पर्याप्त उत्पादक।
3. वह सब जानता है जिसकी हमें जरूरत है।

नुकसान:
1. सभी सर्वर पर जावा।
2. उच्च स्मृति आवश्यकताएं, अन्य सेवाओं के संचालन को संभावित रूप से प्रभावित कर सकती हैं।
3. कॉन्फ़िगर करना मुश्किल।

एजेंट का चयन

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

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

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

Logstash

सबसे पहले, हमने पहले rsyslog के साथ मल्टीलाइन संदेशों को संसाधित करने की कोशिश की, फिर लंबरजैक से।
पहले तो हमने बड़े नियमित भावों की कोशिश की जो Google GitHub Gist पर देता है, लेकिन अंत में हम इस निष्कर्ष पर पहुंचे कि सबसे अच्छा विकल्प - वह सब कुछ जो हमारे टाइमस्टैम्प के अंतर्गत नहीं आता है, पिछले संदेश का हिस्सा माना जाता है। इसके अलावा, लंबरजैक ने सेवा से संदेशों को संशोधित नहीं किया।

परिणाम एक ऐसा सरल पैटर्न है:

filter { multiline { pattern => "(^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2})" negate => true what => "previous" } }

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

हमने लोड को दो प्रकार के उदाहरणों पर वितरित करने का निर्णय लिया, और सामान्य तौर पर विफल नहीं हुए।

पहले प्रकार के उदाहरण (1) केवल टीसीपी कनेक्शनों को सुनता है और कच्ची फाइलों को बचाता है (यह उन पर फ़िल्टर डिबग करने के लिए सुविधाजनक है), बहुस्तरीय संदेशों को चमकता है और उन्हें बस में भेजता है। यह पूरी तरह से अपने कार्य के साथ मुकाबला करता है, 100% दो कोर के लोडिंग के लिए अग्रणी है (हमारी चोटी प्रति सेकंड 2500-3000 संदेश है)।

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

पहले प्रकार के उदाहरण को उतारने के कारण यह तथ्य सामने आया कि संपूर्ण रूप से निगरानी करने वाला सर्वर कम से कम संसाधनों का उपभोग करता है और इसके साथ ही प्रति यूनिट समय पर काफी बड़ी संख्या में संदेशों का सामना करने में सक्षम है। फ़िल्टरिंग इंस्टेंस (दूसरे प्रकार के) संसाधनों में सीमित हो सकते हैं और आप वास्तव में उनके प्रदर्शन की परवाह नहीं कर सकते हैं।

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

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

बहुत विस्तृत लॉग के साथ समस्याएं थीं, उदाहरण के लिए, Node.js लकड़हारा ब्यान , आउटपुट पर यह 30-40 (!) तक था, स्वाभाविक रूप से इंटरफ़ेस में यह भयानक लग रहा था। यहाँ हमने तर्क दिया है:
1) अनावश्यक क्षेत्रों को हटा दिया;
2) मानव-पठनीय रूप में संदेशों की प्राथमिकता को कम करें।

Elasticsearch

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

इंटरफ़ेस

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

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

संक्षिप्त सारांश

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

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

परिणाम

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

अद्यतन

लॉगस्टैश श्रोता

 input { lumberjack { charset => "CP1252" port => 9999 ssl_certificate => "/etc/ssl/changeme.crt" ssl_key => "/etc/ssl/changeme.key" } } filter { multiline { pattern => "(^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2})|(^\d+\))|(^{\")" negate => true what => "previous" } } output { file { path => "/logs/raw/%{host}/%{+YYYY-MM-dd}.log" } rabbitmq { durable => true exchange => "logstash-exchange" exchange_type => "direct" host => "127.0.0.1" key => "logstash-routing-key" password => "changeme" persistent => true user => "logstash" vhost => "logstash" } }

लॉगस्टैश फिल्टर

 input { rabbitmq { auto_delete => false charset => "CP1252" durable => true exchange => "logstash-exchange" exclusive => false host => "127.0.0.1" key => "logstash-routing-key" password => "changeme" prefetch_count => 4 queue => "logstash-indexer" type => "logstash-indexer-input" user => "logstash" vhost => "logstash" } } filter { #ugly hack date { match => ["@timestamp", "ISO8601"] } mutate { gsub => ['host', '.example.com', ''] } #just in case 2 types of applications if [type] == "custom" { grok { match => ["message", "(?m)(?<date>\d{4}-\d{2}-\d{2}) (?<time>\d{2}:\d{2}(?::\d{2}(?:\.\d+)?)?) \[%{LOGLEVEL:level}\s?\] - (?<mxf_raw_message>.*)"] } grok { match => ["message", "(?m)(?<mxf_datetime>\d{4}-\d{2}-\d{2} \d{2}:\d{2}(?::\d{2}(?:\.\d+)?)?) "] } mutate { replace => ["mxf_datetime", "%{date}T%{time}Z" ] } date { match => ["mxf_datetime", "ISO8601"] target => "mxf_timestamp" } mutate { remove_field => ["mxf_datetime"] } grep { match => [ "message", "\|" ] add_tag => "have_id" drop => false } if "have_id" in [tags] { grok { match => ["message", "\[@%{HOSTNAME:mxf_host} %{GREEDYDATA:mxf_thread} (?<mxf_class>[az]{1}[.]{1}[az]{1}[.]{1}[a-zA-Z]{1}.*):%{NUMBER:mxf_classline}\|(?<mxf_id>.*):%{NUMBER:mxf_linenum}\]$"] } #ugly hack for correct mapping mutate { convert => [ "mxf_linenum", "integer" ] } } else { grok { match => ["message", "\[@%{HOSTNAME:mxf_host} %{GREEDYDATA:mxf_thread} (?<mxf_class>[az]{1}[.]{1}[az]{1}[.]{1}[a-zA-Z]{1}.*):%{NUMBER:mxf_classline}\]$"] } } grok { match => ["message", "(?m).*\] - (?<mxf_message>.*)\[@.*"] } grok { match => ["file", "\/opt\/apps\/%{GREEDYDATA:mxf_version}\/logs\/%{GREEDYDATA:mxf_account}\/%{WORD:mxf_logfilename}.log$"] } mutate { gsub => ["mxf_aiid","\|",""] } } if [type] == "nodejs" { json { source => "message" } mutate { rename => ["msg","mxf_message"] } mutate { rename => ["args.0.code","mxf_response_code"] } mutate { rename => ["data.service","mxf_service"] } mutate { rename => ["data.method","mxf_method"] } mutate { rename => ["t","mxf_request_time"] } mutate { rename => ["pid","mxf_pid"] } mutate { rename => ["err.name","mxf_errname"] } mutate { rename => ["err.stack","mxf_stacktrace"]} mutate { rename => ["err.message", "mxf_errmsg"] } mutate { remove_field => ["0", "1", "2", "args", "http", "hostname", "msg", "v", "data", "err","t", "pid","io"] } if [level] == 60 { mutate { replace => ["level","FATAL"] } } if [level] == 50 { mutate { replace => ["level","ERROR"] } } if [level] == 40 { mutate { replace => ["level","WARN"] } } if [level] == 30 { mutate { replace => ["level","INFO"] } } if [level] == 20 { mutate { replace => ["level","DEBUG"] } } if [level] == 10 { mutate { replace => ["level","TRACE"] } } } } output { elasticsearch_http { host => "127.0.0.1" } }

किबना विन्यास

हम लंबरजैक + लॉगस्टैश + एलेस्टिक्स खोज + रैबिटएमक्यू का उपयोग करके लॉग एकत्र करते हैं और उनका विश्लेषण करते हैं