लॉगिंग: क्या, कैसे, कहाँ और किसके साथ?

CodeGym समुदाय में सभी को नमस्कार! आज बात करते हैं लॉगिंग की:

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

यह सामग्री व्यापक दर्शकों के लिए अभिप्रेत है। यह जावा को जानने वाले किसी भी व्यक्ति के लिए स्पष्ट होगा, साथ ही वे लोग जो पहले से ही काम कर रहे हैं लेकिन केवल खोज की है logger.info("log something"); चलो चलते हैं!

आपको लॉगिंग की आवश्यकता क्यों है?

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

जावा में लॉगिंग के लिए उपकरण

जावा में प्रसिद्ध लॉगिंग समाधानों में, हम निम्नलिखित पर प्रकाश डाल सकते हैं:

• लॉग4ज
• जूल - java.util.log
• जेसीएल - जकार्ता कॉमन्स लॉगिंग
• लॉगबैक
• SLF4J - जावा के लिए सरल लॉगिंग मुखौटा

System.err.println

शुरुआत में, System.err.println था (कंसोल पर लॉग प्रविष्टियाँ प्रदर्शित करना)। आज भी, डिबगिंग करते समय इस तकनीक का उपयोग जल्दी से लॉग करने के लिए किया जाता है। बेशक, यहां चर्चा करने के लिए कोई सेटिंग नहीं है, इसलिए बस इस तरीके को याद रखें और हम आगे बढ़ेंगे।

लॉग4ज

यह एक संपूर्ण समाधान है जिसे डेवलपर्स ने आवश्यकता से बनाया है। नतीजा वास्तव में एक दिलचस्प उपकरण है जिसका आप उपयोग कर सकते हैं। विभिन्न परिस्थितियों के कारण, यह समाधान JDK में समाप्त नहीं हुआ, एक ऐसा तथ्य जिसने पूरे समुदाय को बहुत परेशान किया। Log4j में कॉन्फ़िगरेशन विकल्प हैं जो आपको पैकेज में लॉगिंग को सक्षम करने देते हैं और इसे सबपैकेज com.example.typeमें बंद कर देते हैं । com.example.type.genericइससे कोड को जल्दी से बाहर करना संभव हो जाता है जिसे लॉग करने की आवश्यकता नहीं होती है। यहां यह ध्यान रखना महत्वपूर्ण है कि Log4j के दो संस्करण हैं: 1.2.x और 2.xx, और वे एक दूसरे के साथ असंगत हैं । Log4j ने एपेंडर की अवधारणाओं को जोड़ा(लॉग लिखने के लिए प्रयुक्त एक उपकरण) और लेआउट (लॉग स्वरूपण)। यह आपको केवल वही लॉग करने देता है जिसकी आपको आवश्यकता है और इसे लॉग इन करें कि आपको इसकी आवश्यकता कैसे है। हम थोड़ी देर बाद एपेंडर के बारे में और बात करेंगे।

जूल - java.util.log

इस समाधान का एक प्रमुख लाभ यह है कि JUL JDK (जावा डेवलपमेंट किट) में शामिल है। दुर्भाग्य से, जब इसे विकसित किया गया था, तो इसके रचनाकारों ने इसे लोकप्रिय Log4j उपयोगिता पर आधारित नहीं किया, बल्कि IBM के एक समाधान के आधार पर बनाया। उस निर्णय के परिणाम हुए हैं। वास्तविकता यह है कि अब कोई भी JUL का प्रयोग नहीं करता है। JUL में लॉग स्तर लॉगबैक, Log4j और Slf4j के स्तर से भिन्न होते हैं। इससे उनके लिए एक दूसरे को समझना कठिन हो जाता है। लकड़हारा बनाना कमोबेश समान है। ऐसा करने के लिए, आपको एक आयात करने की आवश्यकता है:

java.util.logging.Logger log = java.util.logging.Logger.getLogger(LoggingJul.class.getName());

कक्षा का नाम पास हो गया है, इसलिए हम जानते हैं कि हमारी लॉगिंग कहाँ से आएगी। जावा 8 से शुरू करके, आप पास कर सकते हैं Supplier<String>। यह हमें पढ़ने और एक लाइन बनाने में मदद करता है जब हमें वास्तव में इसकी आवश्यकता होती है, हर बार नहीं, जैसा कि पहले होता था। केवल Java 8 की रिलीज़ के साथ ही डेवलपर्स ने अंततः महत्वपूर्ण समस्याओं को हल किया और JUL को वास्तव में प्रयोग करने योग्य बनाया। अर्थात्, एक Supplier<String> msgSupplierपैरामीटर के साथ तरीके, जैसा कि नीचे दिखाया गया है:

public void info(Supplier<String> msgSupplier) {
   log(Level.INFO, msgSupplier);
}

जेसीएल - जकार्ता कॉमन्स लॉगिंग

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

लॉगबैक

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

• बेहतर प्रदर्शन
• Slf4j के लिए मूल समर्थन जोड़ा गया
• विस्तारित फ़िल्टरिंग विकल्प

डिफ़ॉल्ट रूप से, लॉगबैक को किसी कॉन्फ़िगरेशन की आवश्यकता नहीं होती है, और सभी घटनाओं को DEBUG स्तर और उच्चतर पर रिकॉर्ड करता है। यदि आपको कुछ अनुकूलन की आवश्यकता है, तो आप इसे XML कॉन्फ़िगरेशन के माध्यम से प्राप्त कर सकते हैं:

<configuration> 
    <appender name="FILE" class="ch.qos.logback.core.FileAppender"> 
        <file>app.log</file> 
        <encoder> 
            <pattern>%d{HH:mm:ss,SSS} %-5p [%c] - %m%n</pattern> 
        </encoder> 
    </appender> 
    <logger name="org.hibernate.SQL" level="DEBUG" /> 
    <logger name="org.hibernate.type.descriptor.sql" level="TRACE" /> 
    <root level="info"> 
        <appender-ref ref="FILE" /> 
    </root> 
</configuration>

SLF4J - जावा के लिए सरल लॉगिंग मुखौटा

2006 में कभी-कभी, Log4j के संस्थापक पिताओं में से एक ने परियोजना छोड़ दी और Slf4j (जावा के लिए सरल लॉगिंग मुखौटा), Log4j, JUL, सामान्य-लॉगिंग और लॉगबैक के लिए एक आवरण बनाया। जैसा कि आप देख सकते हैं, हम एक रैपर के ऊपर एक रैपर बनाने के मुद्दे पर आगे बढ़ चुके हैं... इस मामले में, इसे दो भागों में विभाजित किया गया है: एक एपीआई जो एप्लिकेशन में उपयोग किया जाता है, और एक कार्यान्वयन जो अलग से जोड़ा जाता है प्रत्येक प्रकार के लॉगिंग के लिए निर्भरताएँ। उदाहरण के लिए, slf4j-log4j12.jarऔर slf4j-jdk14.jar। आपको सही कार्यान्वयन को जोड़ने की आवश्यकता है और वह यह है: आपकी पूरी परियोजना इसका उपयोग करेगी। Slf4j सभी नवीनतम विशेषताओं का समर्थन करता है, जैसे लॉगिंग के लिए स्ट्रिंग्स को स्वरूपित करना। पहले ऐसी दिक्कत होती थी। मान लीजिए कि हम इस तरह एक लॉग प्रविष्टि बनाते हैं:

log.debug("User " + user + " connected from " + request.getRemoteAddr());

कॉन्टेनेशन ऑपरेटर के कारण, userऑब्जेक्ट चुपचाप एक स्ट्रिंग बन जाता है धन्यवाद user.toString()। इसमें समय लगता है और सिस्टम धीमा हो जाता है। और अगर हम एप्लिकेशन को डीबग कर रहे हैं तो यह ठीक हो सकता है। यदि इस वर्ग के लिए लॉग स्तर INFO या उच्चतर है, तो हमें समस्याएँ आनी शुरू हो जाती हैं। दूसरे शब्दों में, हमें यह लॉग प्रविष्टि (INFO या उच्चतर के लिए) नहीं लिखनी चाहिए, और हमें स्ट्रिंग संयोजन का उपयोग नहीं करना चाहिए। सिद्धांत रूप में, लॉगिंग लाइब्रेरी को ही इसे संबोधित करना चाहिए। जैसा कि होता है, यह Log4j के पहले संस्करण में सबसे बड़ी समस्या साबित हुई। इसने एक अच्छा समाधान नहीं दिया, बल्कि ऐसा कुछ करने का सुझाव दिया:

if (log.isDebugEnabled()) {
    log.debug("User " + user + " connected from " + request.getRemoteAddr());
}

अर्थात्, लॉगिंग के लिए कोड की एक पंक्ति के बजाय, उन्होंने 3 लिखने का सुझाव दिया! लॉगिंग को कोड परिवर्तनों को कम करना चाहिए, और तीन पंक्तियां उस सामान्य दृष्टिकोण का स्पष्ट रूप से उल्लंघन करती हैं। Slf4j में JDK और API के साथ कोई संगतता समस्या नहीं थी, इसलिए एक अच्छा समाधान तुरंत सामने आया:

log.debug("User {} connected from {}", user, request.getRemoteAddr());

जहां {}विधि को दिए गए तर्कों के लिए प्लेसहोल्डर्स को दर्शाता है। अर्थात्, पहला {}इससे मेल खाता है user, और दूसरा {}उससे मेल खाता है request.getRemoteAddr()। इसे इस तरह से करने से, हम केवल तभी स्ट्रिंग संयोजन करेंगे जब लॉग स्तर के लिए हमें लॉग प्रविष्टि लिखने की आवश्यकता हो। उसके बाद, Sjf4j की लोकप्रियता तेजी से बढ़ने लगी। वर्तमान में यह सबसे अच्छा उपाय है। तदनुसार, आइए slf4j-log4j12बाइंडिंग का उपयोग करके लॉगिंग पर एक नज़र डालें।

लॉग इन करने की क्या जरूरत है

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

1. आवेदन का प्रारंभ/समाप्ति। हमें यह जानने की जरूरत है कि क्या वास्तव में आवेदन अपेक्षित रूप से शुरू और समाप्त हुआ।
2. सुरक्षा समस्याएं। यहां किसी के पासवर्ड का अनुमान लगाने के प्रयासों को लॉग करना अच्छा होगा, उदाहरण जब व्यवस्थापक साइन इन करते हैं, आदि।
3. कुछ आवेदन राज्यों । उदाहरण के लिए, व्यापार प्रक्रिया में एक राज्य से दूसरे राज्य में संक्रमण।
4. संबंधित लॉग स्तर के साथ कुछ डिबग जानकारी ।
5. कुछ SQL स्क्रिप्ट। जब यह आवश्यक हो तो वास्तविक दुनिया के मामले होते हैं। लेकिन फिर से, लॉग स्तरों को कुशलतापूर्वक समायोजित करके, आप उत्कृष्ट परिणाम प्राप्त कर सकते हैं।
6. चीजें ठीक से काम कर रही हैं यह सत्यापित करते समय रनिंग थ्रेड्स को लॉग किया जा सकता है।

लॉगिंग में लोकप्रिय त्रुटियां

यहाँ कई बारीकियाँ हैं, लेकिन हम कुछ सामान्य गलतियों का विशेष उल्लेख करेंगे:

1. अत्यधिक लॉगिंग। आपको हर उस कदम को लॉग इन नहीं करना चाहिए जो सैद्धांतिक रूप से महत्वपूर्ण हो सकता है। यहाँ अंगूठे का एक अच्छा नियम है: लॉग लोड के 10% से अधिक नहीं होना चाहिए। अन्यथा, प्रदर्शन संबंधी समस्याएं होंगी।
2. सभी डेटा को एक फ़ाइल में लॉग करना। किसी बिंदु पर, यह लॉग को पढ़ने/लिखने में बहुत मुश्किल बना देगा, इस तथ्य का जिक्र न करें कि कुछ सिस्टमों में फ़ाइल आकार पर सीमाएं हैं।
3. गलत लॉग स्तरों का उपयोग करना। प्रत्येक लॉग स्तर की स्पष्ट सीमाएँ हैं, और उनका सम्मान किया जाना चाहिए। यदि कोई सीमा स्पष्ट नहीं है, तो आप किस स्तर का उपयोग करने के बारे में एक समझौते पर आ सकते हैं।

लॉग स्तर

लॉग स्तर क्या हैं? किसी तरह लॉग प्रविष्टियों का एक पदानुक्रम बनाने के लिए, कुछ परंपराएं और परिसीमन आवश्यक हैं। यही कारण है कि लॉग स्तर पेश किए गए थे। आवेदन में स्तर निर्धारित किया गया है। यदि कोई प्रविष्टि एक निर्दिष्ट स्तर से नीचे है, तो उसे लॉग नहीं किया जाता है। उदाहरण के लिए, हमारे पास लॉग हैं जिनका उपयोग हम एप्लिकेशन को डीबग करते समय करते हैं। सामान्य ऑपरेशन के दौरान (जब एप्लिकेशन अपने इच्छित उद्देश्य के लिए उपयोग किया जाता है), ऐसे लॉग की आवश्यकता नहीं होती है। इसलिए, डीबगिंग के लिए लॉग स्तर अधिक है। आइए Log4j का उपयोग करके लॉग स्तरों को देखें। JUL के अलावा, अन्य समाधान समान लॉग स्तरों का उपयोग करते हैं। यहाँ वे घटते क्रम में हैं:

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

INFO लॉग स्तर में एप्लिकेशन में कहीं सक्षम है, तो INFO से FATAL तक, हर स्तर की प्रविष्टियाँ लॉग की जाएँगी। यदि FATAL लॉग स्तर सेट है, तो केवल उस स्तर की लॉग प्रविष्टियाँ लिखी जाएँगी।

लॉगिंग और लॉग भेजना: Appender

आइए विचार करें कि यह सब कैसे काम करता है जब हम Log4j का उपयोग करते हैं, जो लॉग लिखने / भेजने के लिए पर्याप्त अवसर प्रदान करता है:

• फ़ाइल में लिखने के लिए -DailyRollingFileAppender
• कंसोल में जानकारी लिखने के लिए —ConsoleAppender
• डेटाबेस में लॉग लिखने के लिए —JDBCAppender
• टीसीपी/आईपी पर लॉग भेजने का प्रबंधन करने के लिए —TelnetAppender
• यह सुनिश्चित करने के लिए कि लॉगिंग प्रदर्शन को नकारात्मक रूप से प्रभावित नहीं करती है —AsyncAppender

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

लॉगिंग नोड्स

प्रदर्शन उद्देश्यों के लिए, हम Log4j से कार्यान्वयन के साथ Slf4j इंटरफ़ेस का उपयोग करेंगे। लकड़हारा बनाना बहुत सरल है: नाम की एक कक्षा में MainDemo, जो कुछ लॉगिंग करेगी, हमें निम्नलिखित जोड़ने की आवश्यकता है:

org.slf4j.Logger logger = org.slf4j.LoggerFactory.getLogger(MainDemo.class);

यह हमारे लिए एक लकड़हारा बनाएगा। लॉग प्रविष्टि करने के लिए, कई उपलब्ध विधियाँ हैं जिनके नाम दर्शाते हैं कि किस लॉग स्तर का उपयोग किया जाएगा। उदाहरण के लिए:

logger.trace("Method 1 started with argument={}", argument);
logger.debug("Database updated with script = {}", script);
logger.info("Application has started on port = {}", port);
logger.warn("Log4j didn't find the log4j.properties file. Please fix this.");
logger.error("Connection refused to host = {}", host);

यद्यपि हम कक्षा उत्तीर्ण कर रहे हैं, अंतिम नाम पैकेज सहित वर्ग का पूरा नाम है। ऐसा इसलिए किया जाता है ताकि बाद में आप लॉगिंग को नोड्स में विभाजित कर सकें और प्रत्येक नोड के लिए लॉगिंग स्तर और एपेंडर को कॉन्फ़िगर कर सकें। उदाहरण के लिए, लकड़हारा com.github.romankh3.logginglecture.MainDemoवर्ग में बनाया गया था। नाम लॉगिंग नोड्स का पदानुक्रम बनाने का आधार प्रदान करता है। मुख्य नोड शीर्ष-स्तरीय रूटलॉगर है । यह वह नोड है जो संपूर्ण एप्लिकेशन के लिए सभी लॉग प्रविष्टियां प्राप्त करता है। शेष नोड्स को नीचे दिखाए अनुसार चित्रित किया जा सकता है: परिशिष्ट विशिष्ट लॉगिंग नोड्स के लिए कॉन्फ़िगर किए गए हैं। अब हम log4j.properties फ़ाइल को देखने जा रहे हैं ताकि उन्हें कैसे कॉन्फ़िगर किया जाए इसका एक उदाहरण देखें।

Log4j.properties फ़ाइल के लिए चरण-दर-चरण मार्गदर्शिका

हम एक-एक करके सब कुछ सेट करेंगे और देखेंगे कि क्या संभव है:

log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender

यह पंक्ति कहती है कि हम CONSOLE एपेंडर को पंजीकृत कर रहे हैं, जो org.apache.log4j.ConsoleAppender कार्यान्वयन का उपयोग करता है। यह एपेंडर कंसोल को जानकारी लिखता है। अगला, हम एक और परिशिष्ट पंजीकृत करते हैं। यह एक फाइल को लिखेगा:

log4j.appender.FILE=org.apache.log4j.RollingFileAppender

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

log4j.rootLogger=डीबग, कंसोल, फ़ाइल

• log4j.rootLogger का अर्थ है कि हम रूट नोड को कॉन्फ़िगर कर रहे हैं, जिसमें सभी लॉग प्रविष्टियां हैं
• बराबर चिह्न के बाद पहला शब्द लिखने के लिए न्यूनतम लॉग स्तर इंगित करता है (हमारे मामले में, यह DEBUG है)
• अल्पविराम के बाद, हम सभी परिशिष्टों का उपयोग करने का संकेत देते हैं।

अधिक विशिष्ट लॉगिंग नोड को कॉन्फ़िगर करने के लिए, आप इस तरह की प्रविष्टि का उपयोग करेंगे:

log4j.logger.com.github.romankh3.logginglecture=TRACE, OWN, CONSOLE

जहाँ log4j.logger.एक विशिष्ट नोड को संदर्भित करने के लिए उपयोग किया जाता है। हमारे मामले में, com.github.romankh3.logginglecture. अब CONSOLE एपेंडर को कॉन्फ़िगर करने के बारे में बात करते हैं:

# CONSOLE appender customization
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.threshold=DEBUG
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=[%-5p] : %c:%L : %m%n

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

# File appender customization
log4j.appender.FILE=org.apache.log4j.RollingFileAppender
log4j.appender.FILE.File=./target/logging/logging.log
log4j.appender.FILE.MaxFileSize=1MB
log4j.appender.FILE.threshold=DEBUG
log4j.appender.FILE.MaxBackupIndex=2
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.ConversionPattern=[ %-5p] - %c:%L - %m%n

आप उस विशिष्ट फ़ाइल को कॉन्फ़िगर कर सकते हैं जिसमें लॉग प्रविष्टियाँ लिखी जाएँगी, जैसा कि इस पंक्ति से देखा जा सकता है:

log4j.appender.FILE.File=./target/logging/logging.log

प्रविष्टि logging.logफ़ाइल में लिखी गई है। फ़ाइल आकार के साथ समस्याओं से बचने के लिए, आप अधिकतम कॉन्फ़िगर कर सकते हैं, जो इस मामले में 1MB है। MaxBackupIndexइंगित करता है कि ऐसी कितनी लॉग फ़ाइलें होंगी। अगर हमें इससे ज्यादा फाइल्स बनाने की जरूरत पड़ी तो पहली फाइल डिलीट हो जाएगी। एक वास्तविक उदाहरण देखने के लिए जहाँ लॉगिंग कॉन्फ़िगर की गई है, आप GitHub पर सार्वजनिक रिपॉजिटरी में जा सकते हैं।

हमने जो चर्चा की है उसे सुदृढ़ करें

हमने जो कुछ भी वर्णित किया है, उसे स्वयं करने का प्रयास करें:

• ऊपर दिए गए उदाहरण के समान अपना खुद का प्रोजेक्ट बनाएं।
• यदि आप मावेन का उपयोग करना जानते हैं, तो इसका उपयोग करें। यदि नहीं, तो इस ट्यूटोरियल को पढ़ें, जिसमें बताया गया है कि लाइब्रेरी को कैसे कनेक्ट करना है।

सारांश

1. हमने जावा में मौजूद लॉगिंग समाधानों के बारे में बात की।
2. लगभग सभी प्रसिद्ध लॉगिंग लाइब्रेरी एक व्यक्ति द्वारा लिखी गई थीं: डी
3. हमने सीखा कि क्या लॉग किया जाना चाहिए और क्या नहीं।
4. हमने लॉग स्तरों का पता लगाया।
5. हमें लॉगिंग नोड्स से परिचित कराया गया था।
6. हमने देखा कि परिशिष्ट क्या है और इसके लिए क्या है।
7. हमने चरण दर चरण एक log4j.proterties फ़ाइल बनाई।

अतिरिक्त सामग्री

1. CodeGym: लकड़हारा पाठ
2. साप्ताहिक गीकली: जावा लॉगिंग। हैलो वर्ल्ड
3. कोडिंग हॉरर: लॉगिंग के साथ समस्या
4. YouTube: जावा लॉगिंग हेल को समझना - मूल बातें। जावा लॉगिंग नर्क और इससे कैसे बचा जाए
5. Log4j: एपेंडर
6. Log4j: लेआउट

मेरा अन्य लेख भी देखें:

• IntelliJ IDEA में डिबगिंग: एक शुरुआती गाइड