असीमित लॉगिंग

Question

अभी मेरे आवेदन में, कुछ बिंदुओं पर हम लॉग फ़ाइलों में कुछ भारी सामान लॉग कर रहे हैं।

असल में केवल लॉगिंग के लिए हम उपलब्ध डेटा के JSON बना रहे हैं और फिर लॉग फ़ाइलों में लॉग इन कर रहे हैं। यह JSON प्रारूप में डेटा लॉग करने के लिए व्यावसायिक आवश्यकता है।

अब उपलब्ध डेटा से JSON बना रहा है और फिर FILE पर लॉगिंग करने में बहुत समय लगता है और मूल अनुरोध वापसी समय पर असर पड़ता है। अब विचार बैठना बेहतर है।

चीजें है कि हम पर चर्चा की है में से एक हमारे कोड में

Executors.newSingleThreadExecutor() 

का उपयोग कर और उसके बाद जो JSON और बाद में प्रवेश में डेटा के रूपांतरण करता है इसे करने के लिए कार्य प्रस्तुत करने के एक धागा पूल तैयार करना है।

क्या यह करने के लिए यह एक अच्छा तरीका है? चूंकि हम थ्रेड पूल का प्रबंधन कर रहे हैं, क्या यह कुछ मुद्दों को बनाने जा रहा है?

अगर कोई बेहतर समाधान साझा कर सकता है तो मैं सराहना करता हूं। इसके लिए लॉग 4j का उपयोग करने के लिए सोमवे। मैंने AsyncAppender का उपयोग करने की कोशिश की लेकिन किसी वांछित परिणाम को प्राप्त नहीं किया। हम ईजेबी 3, जेबॉस 5.0, लॉग 4j, जावा 6 का उपयोग कर रहे हैं।

Answer 1

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

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

Answer 2

MongoDB for logging का उपयोग कर रहा है?

1. MongoDB आवेषण एसिंक्रोनस रूप किया जा सकता है। यदि लॉगिंग धीमी थी, या उससे नीचे रुक गया तो कोई उपयोगकर्ता के अनुभव को रोकने के लिए नहीं चाहता था। मोंगो डीबी एक लॉग संग्रह में डालने के लिए क्षमता प्रदान करता है और प्रतिक्रिया कोड की प्रतीक्षा नहीं करता है। (यदि एक एक प्रतिक्रिया चाहता है, तो एक कॉल प्राप्त करें LastError() - हम इसे यहां छोड़ देंगे।)
2. पुराना लॉग डेटा स्वचालित रूप से एलआरयू आउट हो गया। कैप्ड संग्रहों का उपयोग करके, हम लॉग के लिए स्थान को पूर्ववत करते हैं, और एक बार यह पूर्ण हो जाने पर, लॉग लपेटता है और निर्दिष्ट स्थान का पुन: उपयोग करता है। अत्यधिक लॉग जानकारी के साथ डिस्क भरने का कोई जोखिम नहीं है, और लॉग आर्काइवल/ हटाने की स्क्रिप्ट लिखने की आवश्यकता नहीं है।
3. यह समस्या के लिए पर्याप्त तेज़ है। सबसे पहले, मोंगो डीबी सामान्य में बहुत तेज है, इस तरह की समस्याओं के लिए पर्याप्त तेज़ है। दूसरा, कैप्ड संग्रह का उपयोग करते समय, सम्मिलन आदेश स्वचालित रूप से संरक्षित होता है: हम को टाइमस्टैम्प पर इंडेक्स बनाने की आवश्यकता नहीं है। यह चीजों को तेज बनाता है, और यह महत्वपूर्ण है कि लॉगिंग उपयोग मामले में पढ़ने की तुलना में उच्च संख्या में लिखने की संख्या है (अधिकांश डेटाबेस समस्याओं के विपरीत)।
4. दस्तावेज़-उन्मुख/JSON लॉग जानकारी के लिए एक महान प्रारूप है। इस अर्थ में बहुत लचीला और "स्कीमालेस" हम किसी भी समय फ़ील्ड में फेंक सकते हैं।

Answer 3

Logback पर एक नज़र डालें, AsyncAppender यह पहले से ही अलग थ्रेडपूल, कतार आदि प्रदान करता है और आसानी से कॉन्फ़िगर करने योग्य है, यह लगभग वैसे ही करता है जैसा आप कर रहे हैं, लेकिन आपको पहिया को फिर से आविष्कार से बचाता है।

Answer 4

है भी log4j 2: http://logging.apache.org/log4j/2.x/manual/async.html ही कारण है कि यह इतनी तेजी से है के बारे में यह लेख पढ़ें: http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html#.UzwywI9Bow4

Answer 5

तुम भी CoralLog कोशिश एसिंक्रोनस रूप disruptor पद्धति का उपयोग कर डेटा प्रवेश करने के लिए कर सकते हैं। इस तरह आप लॉगर थ्रेड में न्यूनतम समय बिताते हैं और सभी कड़ी मेहनत को वास्तविक फ़ाइल I/O करने वाले धागे को पास किया जाता है। यह उपभोक्ता थ्रेड को गति देने और कतार विवाद को कम करने के लिए मेमोरी मैप की गई फ़ाइलें भी प्रदान करता है।

अस्वीकरण: मैं इस साझा करने के लिए