लॉग की जरूरत नहीं है?

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

Yandex.Verticals में बड़ी समस्याओं में से एक लॉग था - प्रति दिन 18 टीबी और प्रति सेकंड 250,000 लॉग, सब कुछ फाइलों में लिखा है। लॉग विषम हैं क्योंकि कई भाषाएं हैं: स्काला, जावा, पायथन, गो। फिर वे फ्लुएंट बिट द्वारा एकत्र किए जाते हैं, काफ्का में लिखते हैं, हैंडलर एक लोहे की मशीन पर काम करते हैं, काफ्का से इकट्ठा होते हैं और डिस्क पर सब कुछ लिखते हैं। इसके अलावा, यह लॉग का दूसरा संस्करण है।



नतीजतन, एक लंबी खोज समस्या पैदा होती है। ये लॉग grep का उपयोग करके खोजा जाता है। कुछ सेवाओं पर, grep घंटों तक पहुंच सकता है। यदि आपको उत्पादन में समस्या है, तो आप घंटों तक अपने लॉग की तलाश में नहीं रहेंगे। समस्या को हल करने के लिए, यैंडेक्स ने खोज के लिए अपनी लॉग डिलीवरी बाइक लिखने का फैसला किया। इसके बारे में क्या आया, यह अलेक्सई डैनिलोव ( डेनवगे ) को बताएगा - यैंडेक्स.वार्टिकल में इंफ्रास्ट्रक्चर टीम के डेवलपर। Auto.ru और Yandex.Real Estate परियोजनाओं का विकास, लेखन और समर्थन करता है।

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

नोट। लेख RIT ++ 2019 DevOps Conf पर एलेक्सी डेनिलोव की रिपोर्ट "लॉग्स की आवश्यकता नहीं है" का एक विस्तारित संस्करण है, जिसे स्टाइलिस्टिक रूप से संशोधित किया गया है और नई सामग्री के साथ पूरक है। आप हमारे YouTube चैनल के लिंक पर अलेक्सी के भाषण की वीडियो रिकॉर्डिंग पा सकते हैं।

Yandex.Vertical टीम में 300 लोग हैं, जिनमें से लगभग 100 डेवलपर हैं। विकास में, हम अधिकांश कंपनियों से अलग नहीं हैं जो अपने स्वयं के उत्पाद समाधान बनाते हैं। माइक्रोसिस्टर्स, हर कोई डॉकर में रहता है, PHP में एक मोनोलिथ एक अंधेरे कोने में धूल इकट्ठा कर रहा है, जिसे हैशिकॉर्प नोमैड के माध्यम से तैनात किया गया है और हम भाषाओं का एक चिड़ियाघर रखते हैं: स्काला, जावा, गो, नोड.जेएस, पायथन।

Yandex.Verticals में बड़ी बुनियादी सुविधाओं की समस्याओं में से एक आवेदन लॉग है। जब हमने गंभीरता से इस समस्या से संपर्क किया, तो हमने उनके संग्रह और प्रसंस्करण के तीसरे संस्करण का उपयोग किया। सरलीकृत, यह इस तरह काम किया:

• फ़ाइलों को लिखे गए अनुप्रयोग;
  
• धाराप्रवाह बिट फ़ाइलों को पढ़ा और उन्हें कफका फ़ाइलबीट के लिए लाइन द्वारा भेजा;
  
• एक समर्पित लोहे की मशीन पर एक एप्लिकेशन था जो काफ्का विषय को पढ़ता था और डिस्क पर फाइलों को लिखा था।
  

गर्म मौसम में, हमारे पास प्रति दिन 18 टीबी लॉग या प्रति सेकंड 250,000 लाइनें थीं। यह एक बहुत बड़ी राशि है, जो इस डेटा के साथ काम को जटिल बनाती है। इसका विश्लेषण करने का एकमात्र तरीका grep है, क्योंकि सब कुछ फाइलों में संग्रहीत है। बड़े अनुप्रयोगों के लिए, विश्लेषण में घंटों लग सकते हैं। उत्पादन में समस्याओं के लिए, आपके पास यह समय नहीं है।

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

इस स्थिति में, हमने लॉग एकत्र करने और विश्लेषण करने के लिए अपनी स्वयं की प्रणाली को लागू करने का निर्णय लिया।

बाइक

नोट: यदि अगली बाइक दिलचस्प नहीं है, तो तुरंत "टंकण" अनुभाग पर आगे बढ़ें।

प्रारूप

हम कई पीएल का उपयोग करते हैं और माइक्रोसर्विस को प्यार करते हैं। लॉग के साथ काम करने के लिए, हमने समान रूप से अपने स्वयं के JSON प्रारूप का गठन किया। यह लॉग के साथ आगे के काम के लिए अधिकांश जरूरतों को कवर करता है।


सभी संभावित क्षेत्रों के साथ लॉग का एक उदाहरण।

डॉकर लॉग ड्राइवर

लॉग को इकट्ठा करने के लिए, हमने अपना खुद का डॉक लॉग ड्राइवर लिखा - गो ऑन ए एप्लिकेशन। यह एक विशेष तरीके से इकट्ठा किया जाता है, जिसे डॉकटर कमांड द्वारा वितरित किया जाता है, रजिस्ट्री में संग्रहीत किया जाता है, और डॉकर को चलाने वाले एकल उदाहरण में चलता है।

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

समस्याओं

मैं डॉक लॉग ड्राइवर के संस्करण को अपडेट करने की समस्याओं का अलग से उल्लेख करूंगा।


आंतरिक ग्राफ्टाना से स्क्रीनशॉट।

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

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

सामान्य योजना

लॉग एकत्र करने और वितरित करने के लिए एक नई प्रणाली की सामान्य योजना पर विचार करें। अन्य विवरण इतने दिलचस्प नहीं हैं।



एप्लिकेशन लेखन को JSON प्रारूप में stdout में लॉग लिखते हैं। डॉकटर कंटेनर से पाइप को सुनता है और इसे डॉकर चालक पर पुनर्निर्देशित करता है। Docker ड्राइवर पढ़ता है और पुष्कर में एसिंक्रोनसली सब कुछ फिर से पिघला देता है।

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

रिकॉर्डिंग लॉग के लिए तीन रिपॉजिटरी हैं।

• Yandex समय की लंबी अवधि में लॉग के भंडारण और विश्लेषण के लिए मैप करें । यह Hadoop का एक एनालॉग है।
  
• अंतिम दिन के दौरान लॉग को संग्रहीत करने के लिए ClickHouse ।
  
• अंतिम दिन के लिए लॉग स्टोर करने के लिए हमियो (एक प्रयोग के रूप में)।
  

लाभ

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

छोटे संस्करणों के लिए, विकल्पों पर विचार करें: हुमियो, स्प्लंक और इलास्टिक। अंतिम दो में आधिकारिक डोकर चालक हैं। यदि आप AWS में रहते हैं, तो वह Amazon CloudWatch है।

अमेज़ॅन क्लाउडवॉच

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


अमेज़ॅन क्लाउडवॉच लॉग को मैट्रिक्स और ग्राफिक्स में परिवर्तित करता है।

लॉग के साथ क्या करना है?

हमारी बाइक पर वापस - क्या यह सभी मामलों को संतुष्ट करता है? नहीं, हमारा समाधान आपको लॉग ढूंढने की अनुमति देता है, लेकिन उन्हें बहुत अधिक जानकारी और इसके प्रकार की व्यापकता की आवश्यकता होती है। लॉग का उपयोग बहुत अधिक मामलों में किया जाता है।

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

यदि आप किसी भी डेटा के एक निश्चित अराजकता या घटना लॉग के रूप में लॉग की कल्पना करते हैं, तो वे काम नहीं करेंगे।

यह जानकारी का एक बड़ा झमेला होगा जिसे संसाधित नहीं किया जा सकता है। लॉग के औपचारिककरण में एक खेल शुरू होगा: "आइए हम इन पंक्तियों को एक विशेष प्रारूप में लिखते हैं ताकि बाद में पार्स करना सुविधाजनक हो!" वह भी काम नहीं करता है। हमारा विश्वास करो, हमने कोशिश की।

टाइपिंग

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

बस मामले में

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

// validate customer func Validate(customer Customer) { // ??? log.debug(“Validate customer %v”, customer) … log.Error(“Customer not valid %v. Reason: %s”, ...) …. } 

लॉग ऐसी टिप्पणियां नहीं हैं जिन्हें हटाया जा सकता है। यह उस कोड का हिस्सा है जिसे संशोधित करना, बनाए रखना और यहां तक ​​कि अधिक हटाना भी अधिक कठिन है।

सर्वोत्तम स्थिति में, ऐसा लॉग डीबग या ट्रेस में बदल सकता है। इस प्रकार से कोड को क्लट किया जाता है । रैश लॉगिंग के कारण, मैं इसमें उपयोगकर्ताओं के व्यक्तिगत डेटा, पासवर्ड और कुकीज़ प्राप्त कर सकता हूं।

सही तरीका यह है कि उन्हें फेंक दो और उन्हें भूल जाओ । लेकिन फिर हम एक नई समस्या का सामना कर रहे हैं। कैसे एक त्रुटि के साथ स्थिति को पार्स करने के लिए?

घातक / महत्वपूर्ण त्रुटि

शुरू करने के लिए, हम केवल महत्वपूर्ण त्रुटियों पर विचार करते हैं। ये ऐसी त्रुटियां हैं जिनके कारण उपयोगकर्ता और डेवलपर पीड़ित हैं। पहला - जब वे ऑपरेशन पूरा नहीं कर सकते। दूसरा - जब आपको हाथ से सुधार करने की आवश्यकता होती है।

लॉग फिट क्यों नहीं होते?

कोई त्वरित प्रतिक्रिया नहीं । यदि विकास टीम समर्थन या ट्विटर के माध्यम से उपयोगकर्ताओं से त्रुटि के बारे में जानती है, तो यह कुछ बदलने का समय है।

कोई संदर्भ नहीं है । त्रुटि लॉग की एक अलग लाइन बेकार है। हमें बिट द्वारा संदर्भ बिट एकत्र करना होगा। फिर भी, यह पर्याप्त नहीं हो सकता है, क्योंकि यह प्रक्रिया का संदर्भ है, त्रुटि नहीं।

कोई बड़ी तस्वीर नहीं है । सवालों के जवाब नहीं:

• कितनी बार ऐसी त्रुटि होती है;
  
• यह सेवा की शेष प्रतिकृतियों पर हुआ;
  
• क्या यह पहले था?
  

इन समस्याओं को ठीक करने के लिए, उपयुक्त उपकरण का उपयोग करें, उदाहरण के लिए, संतरी ।io । यह आपको अनुकूलन संबंधी alerting rule साथ प्रतिनिधि, पूर्ण (प्रासंगिक) त्रुटि जानकारी के साथ काम करने की अनुमति देता है। संतरी वेबसाइट संतरी का उपयोग करने से लॉग में अंतर का वर्णन करता है।

क्रिटिकल एरर नहीं

हमने घातक और महत्वपूर्ण त्रुटियों को फेंक दिया और अब वे संतरी में लिखे गए हैं। लेकिन आंतरिक त्रुटियां थीं - तीसरे पक्ष की सेवाओं से विभिन्न पुस्तकालय या उत्तर।

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

यदि ऐसी त्रुटियां कार्य करने के लिए महत्वपूर्ण नहीं हैं और वे उपयोगकर्ता को एक दुर्लभ पुनरावृत्ति के साथ प्रभावित नहीं करती हैं, तो ये त्रुटियां बिल्कुल भी नहीं हैं। यह सेवा का ह्रास है, हालांकि उपयोगकर्ता की प्रतिक्रिया 50 एमएस बाद में आई। इस प्रकार का लॉग चेतावनी को संदर्भित करता है - चेतावनी।

चेतावनी

अलर्ट एक सेवा की गिरावट के बारे में जानकारी है।

यहां हम वही समस्याएं देखेंगे जो महत्वपूर्ण त्रुटियों में निहित हैं, लेकिन आरक्षण के साथ। एक व्यक्तिगत घटना की प्रतिक्रिया महत्वपूर्ण नहीं है - समय के साथ उनकी मात्रा महत्वपूर्ण है।

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

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

हमें लॉग को चिन्हित करने की आवश्यकता नहीं है, लेकिन गिरावट मेट्रिक्स।

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

उदाहरण।

सशर्त user_service में तीन घटनाएं हुईं। वे सेवा के संचालन को प्रभावित करते हैं: डेटाबेस के लिए एक लंबा अनुरोध, बार-बार service_b सेवा एपीआई तक पहुंच और कैश में कोई उपयोगकर्ता अधिकार नहीं मिला। चार्ट और अलर्ट सेवा के डेवलपर्स के लिए महत्वपूर्ण होंगे, संदर्भ के लिए धन्यवाद।

ट्रेसिंग

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

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

आप तीन स्रोतों से ट्रेसिंग एकत्र कर सकते हैं।

• यदि आप साझा किए गए बैलेन्सर का उपयोग करते हैं, तो उनसे लॉग को पार्स करें और उन्हें जैगर को भेजें।
  
• स्वयं सेवाएं , यदि वे सेवा डिस्कवरी के माध्यम से पते प्राप्त करते हैं और सीधे जाते हैं। इस मामले में, सेवाओं से ट्रेस सीधे जेगर को भेजा जाता है।
  
• स्मार्ट सेवा जाल । वह जानता है कि एक ट्रेस कैसे इकट्ठा करना और भेजना है, उदाहरण के लिए, इस्तियो।
  

प्रारंभिक जानकारी

यह जानकारी API सेवा कॉल, Cron लॉन्च, डेटाबेस क्वेरी या अन्य सेवाओं के लिए कॉल के बारे में है।

 { "_message": "Request: ...; request_id: ...,... ", "_level": "INFO", "_time": "2019-03-08T12:04:05.000+07:00", "_context": "ryawvcHandler", "_tread": "785534" } 

यह जानकारी "बस मामले में" ब्लॉक की है, लेकिन यह अलग है क्योंकि यह अधिक सामान्य है। त्रुटि को पार्स करने के लिए यह जानकारी आवश्यक है और आप इसे फेंक सकते हैं ।

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

निष्पादन का समय

यह जानकारी विधियों, एपीआई, डेटाबेस प्रश्नों या अन्य सेवाओं के निष्पादन के समय के बारे में है।

 { "_message": "Get customer 12ms", "_level": "INFO", "_time": "2019-03-08T12:04:05.000+07:00", "_context": "ryawvcCustomerRepository", "_tread": "785534" } 

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

व्यवसाय की जानकारी

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

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

यह इस उम्मीद में लॉग की पूरी धारा को पार्स करने के लिए काम नहीं करेगा कि डेटा अभिसरण करेगा।

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

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

प्रदर्शन

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

टाइपिंग का परिणाम है

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

समस्या प्रौद्योगिकी में नहीं है, लेकिन एक संज्ञानात्मक जाल में है जब हम भरोसा करते हैं कि हमारे सिस्टम की स्थिति के विश्वसनीय प्रतिनिधित्व के साधन के रूप में लॉग होता है। ऐसा नहीं है, लॉग अराजक घटनाओं का एक सेट है।

एक अपवाद है - डिबग-लॉग, जिसका उपयोग दुर्लभ मामलों में किया जा सकता है।

डिबग लॉग

डिबग-लॉग की विस्तृत जानकारी होनी चाहिए। उन्हें नकल नहीं करनी चाहिए जो पहले से ही हमारे द्वारा वर्णित प्रणालियों में भेजा जा रहा है। विशेष मामलों को पार्स करने के लिए यह प्रकार मौजूद है। उदाहरण के लिए, उत्पादन के दौरान एक समझदार बग उत्पन्न होता है, और पल में यह मैट्रिक्स द्वारा स्पष्ट नहीं होता है कि क्या हो रहा है।

सेवा को पुनरारंभ किए बिना, हॉट-डिबग-लॉग ऑन करें । चूंकि हम कई सेवाओं के बारे में बात कर रहे हैं, उनमें से कई नहीं होंगे। परिष्कृत बुनियादी ढांचे की जरूरत नहीं है। जटिल "तैयारी" के बिना पर्याप्त ईएलके स्टैक। यह भी सभी आवश्यक संदर्भ के साथ संतरी के लिए एक चेतावनी जोड़ने के लिए समझ में आता है।

डिबग लॉग का उपयोग विकास के लिए किया जा सकता है । लेकिन वे पूरी तरह से डिबगिंग द्वारा बदल दिए गए हैं।

संक्षेप में देना

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

कच्चे लॉग बेकार हैं, लेकिन उन्हें उपयोगी मीट्रिक में बदल दिया जा सकता है।

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

त्रुटियों में त्रुटि का संदर्भ होना चाहिए।

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

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

नवंबर में हाईलाड ++ 2019 में एक DevOps सेक्शन होगा - AWS में लोड पर 13 रिपोर्ट, लमोडा में एक निगरानी प्रणाली, मॉडल डिलीवरी के लिए कन्वेयर, कुबेरनेट्स के बिना जीवन, और बहुत कुछ। अलग पृष्ठ " रिपोर्ट " पर विषयों और सार की पूरी सूची देखें। और हम वसंत में DevOpsConf में मिलेंगे - समाचार पत्र के लिए साइन अप करें, हमें बताएं कि जब हम तिथियां और स्थान निर्धारित करते हैं।