मैंने कभी भी ऐसे प्रोग्राम नहीं लिखे हैं जो लॉगिंग का महत्वपूर्ण उपयोग करते हैं। सबसे अधिक मैंने किया है जब अपवाद होता है तो स्टैक निशान को पकड़ना है।
मैं सोच रहा था, अन्य लोग कितना लॉग इन करते हैं? क्या यह निर्भर करता है कि आप किस तरह का आवेदन लिख रहे हैं? क्या आपको लॉग वास्तव में मददगार लगते हैं?
जवाबों:
काम के लिए मैंने बड़े पैमाने पर एम्बेडेड अनुप्रयोगों को किया है, एक अमूल्य उपकरण में लॉगिंग। कोड की लाइन को इंगित करने के लिए कम से कम त्रुटियों को पर्याप्त जानकारी के साथ लॉग इन करना होगा। अगले, आवेदन भर में प्रमुख समारोह अंक होगा। एडमिन जैसी चीजों ने मशीन को एक्सेस किया। हम एक ऐसी प्रणाली का उपयोग करते हैं जो हमें अधिक वर्बोज़ लॉगिंग को सक्षम करने की अनुमति देती है। यह आमतौर पर डेवलपर विशिष्ट है। यह सुविधा के परीक्षण के दौरान डेवलपर की सहायता के लिए इस्तेमाल किया जा सकता है या ग्राहक की समस्या के निदान में सहायता के लिए हो सकता है।
मैंने व्यक्तिगत रूप से मेरे द्वारा विकसित किए गए सभी एप्लिकेशन में लॉगिंग का उपयोग किया है। इसने हमेशा एक अनुप्रयोग के प्रवाह की बेहतर समझ पैदा की है। खासकर तब जब ग्राहक के हाथ में हो। वे कभी नहीं (शायद ही कभी) अपने उपयोग के मामलों को उन लोगों तक सीमित करते हैं, जिनके खिलाफ आप परीक्षण करते हैं।
मुझे नहीं लगता कि यह आवेदन के प्रकार पर निर्भर करता है: लॉगिंग सभी (गैर-तुच्छ) अनुप्रयोगों में उपयोगी है । निश्चित रूप से, मुझे लगता है, यह दूसरों की तुलना में कुछ अनुप्रयोगों में अधिक उपयोगी हो सकता है, लेकिन मुझे नहीं लगता कि यह कभी भी बेकार है ।
विशेष रूप से, एक त्रुटि के मामले में, एक स्टैक ट्रेस आपको प्रोग्राम की स्थिति को विफलता के सटीक बिंदु पर बताएगा , लेकिन आपको त्रुटि के ठीक पहले राज्य के बारे में बहुत कम सुराग मिला है । समस्या को ट्रैक करने में यह जानकारी बहुत उपयोगी हो सकती है, और लॉगिंग उस में एक उपयोगी जानकारी प्रदान कर सकता है। मुझे लगता है कि ऐसा कुछ है जो सभी लेकिन कार्यक्रमों के सबसे तुच्छ लाभ उठा सकता है।
लॉगिंग का एक और उपयोग, जो सभी कार्यक्रमों के लिए उपयोगी नहीं हो सकता है, सांख्यिकी विश्लेषण में है। उदाहरण के लिए, आपका वेब सर्वर आमतौर पर आने वाले प्रत्येक अनुरोध को लॉग करता है, और फिर कई उपकरण हैं जो उन लॉग का विश्लेषण कर सकते हैं और आपके व्यस्ततम समय के ग्राफ, सबसे लोकप्रिय पेज और इतने पर उत्पादन कर सकते हैं। आप क्षमता नियोजन करने के लिए उस डेटा का उपयोग कर सकते हैं ("क्या मुझे एक बड़े सर्वर की आवश्यकता है?") और इसी तरह।
लॉगिंग करने के दो कारण हैं:
डायग्नोस्टिक लॉगिंग पर पहले ही दूसरों द्वारा चर्चा की जा चुकी है और मैं इस बात को अधिक विस्तार नहीं दूंगा। मैं सिर्फ इतना कहूंगा कि अगर आपको लॉग फेल होता है तो आपको दृढ़ता से सोचना चाहिए कि क्या होता है? क्या आप ऐप के माध्यम से एक अपवाद को फेंकने या इसे दूसरे तरीके से प्रबंधित करने के लिए पर्याप्त देखभाल करते हैं? यह एक "यह निर्भर करता है" लेकिन सूचना स्तर के संदेशों को लॉग करना संभवत: छोड़ दिया जाना चाहिए।
ऑडिट लॉगिंग एक व्यावसायिक आवश्यकता है। ऑडिट लॉगिंग सिस्टम में महत्वपूर्ण घटनाओं को कैप्चर करता है और वे हैं जो प्रबंधन और कानूनी ईगल में रुचि रखते हैं। यह चीजें हैं जो किसी चीज़ पर हस्ताक्षर किए हैं, किसने संपादन किया है, आदि। सिस्टम के समस्या निवारण के लिए एक sysadmin या डेवलपर के रूप में, आप शायद हैं। केवल हल्के से इनमें रुचि रखते हैं। हालाँकि, कई मामलों में इस तरह की लॉगिंग पूरी तरह से लेन-देन का हिस्सा है और यदि इसे पूरा नहीं किया जा सकता है तो इसे पूरे लेनदेन में विफल होना चाहिए।
दो अलग-अलग के बारे में सोचना मेरे लिए न केवल इसलिए उपयोगी है क्योंकि एक "वैकल्पिक" है और दूसरा अनिवार्य है, लेकिन क्योंकि आवश्यकताओं के आधार पर, मुझे वास्तव में उन्हें अलग से लागू करने की आवश्यकता हो सकती है। यह एक मामला (कभी-कभी) हो सकता है कि वे दोनों फल हैं, लेकिन एक सेब है और दूसरा संतरे। आमतौर पर, एक एकल लॉगिंग फ्रेमवर्क हालांकि दोनों को संभाल सकता है।
अधिकांश सर्वर कार्यों में लॉगिंग महत्वपूर्ण है, क्योंकि आमतौर पर चीजें होने पर व्यवस्थापक नहीं होता है, इसलिए उसे बाद में तथ्य की जांच करनी होगी।
लेकिन, Google के एक व्यक्ति ने मुझे एक बार कहा था कि उनके सर्वर प्रक्रिया लॉगिंग नहीं करते हैं; इसके बजाय, वे 'साधनित' हैं; इसका मतलब यह है कि हर प्रक्रिया में हुक या पोर्ट होते हैं (उन्होंने यांत्रिकी को निर्दिष्ट नहीं किया है) जहां अन्य प्रक्रिया पैरामीटर, और आंकड़ों के लिए पूछ सकते हैं। यह उन मॉनिटरिंग प्रक्रियाओं की है जो बहुत सारी चीजों को लॉग में संग्रहीत करता है, लाभ यह है कि उन्हें जो जानकारी मिलती है वह "एक फ़ाइल खोलें", "यह लिखें", "प्राप्त करें"; उन्हें "45,453 फाइलें खुली", "सेवा एक्स के 653 ग्राहक", "क्वेरी के लिए 344ms औसत प्रतिक्रिया" जैसी चीजें मिलती हैं।
निश्चित रूप से एक अलग दृष्टिकोण है, और एक कि मैं अपने सिस्टम को ध्यान में रखता हूं, भले ही वे छोटे आकार के कुछ आदेश हों।
मैं एक winforms N-Tiered एप्लिकेशन से आया हूं जो सब कुछ लॉग करता है।
यह बहुत उपयोगी नहीं था।
निश्चित रूप से, अपवाद छोड़ना महान है; लेकिन जब आप सिर्फ देव टीम के अपवाद को ईमेल कर सकते हैं तो उन्हें ग्राहक की मशीन में क्यों लॉग इन करें?
लॉगिंग जानकारी आसानी से एक लत में बदल जाती है जिसका मूल्य शायद ही कभी उचित होता है। हर स्थिति के लिए जहां आप गंभीर रूप से लॉग इन कर सकते हैं, लक्षित जानकारी एकत्र करना और उसे भेजने के लिए बेहतर है जहां आपको जाने की आवश्यकता है।
अपवाद जानकारी पर कब्जा करना एक आवश्यक है क्योंकि यह कुछ हद तक बहुत सहायक हो सकता है। लेकिन कभी-कभी अपवाद जानकारी पर्याप्त नहीं होती है, खासकर यदि एप्लिकेशन उपयोगकर्ता / ग्राहक उचित जानकारी के साथ त्रुटि की रिपोर्ट नहीं कर सकते हैं।
क्या केवल लॉगिंग त्रुटि सूचना को सीमित करने के लिए सीमित है?
मेरे मामले में (वेब एप्लिकेशन), मैं हमेशा लॉग इन करता हूं कि कौन से पेज पर गए हैं, कब, क्या क्लिक करते हैं, कहां आईपी और ब्राउजर, आदि। यहां तक कि मैं प्रत्येक पेज विजिट के लिए कुल लोड समय भी लॉग इन करता हूं, ताकि मुझे पता चल सके कि कौन से पेज धीमे हैं और अनुकूलन की आवश्यकता है। इसलिए मैं कह सकता हूं कि मैं जितना संभव हो उतना लॉग इन करता हूं।
पहले, मुझे नहीं पता था कि यह कितना महत्वपूर्ण होगा। लेकिन स्पष्ट रूप से यह कई चीजों में बहुत उपयोगी है (डिबगिंग के अलावा):
मुझे लगता है, अगर हम इसमें आँकड़ा बनाने की कोशिश करते हैं, तो लॉगिंग अधिक महत्वपूर्ण हो सकती है।
मैं एक कंपनी में डेवलपर हूं, जिसके उत्पाद विदेशों में तैनात हैं। जब एक समर्थन टीम समस्या की परिभाषा के बारे में पूछती है, तो निदान के लिए मेरा एकमात्र उपकरण मेरी लॉग फाइलें और ग्राहक के डेटाबेस की एक प्रति है। डेटाबेस और मेरे विकास के वातावरण का उपयोग करते हुए, मेरे पास गलत मामले को पुन: पेश करने का अवसर है, क्योंकि मैं अपने मॉड्यूल और संबंधित कार्यों के लिए आने वाले डेटा को लॉग करता हूं। यदि मैं एकत्रित किए गए डेटा की मदद से त्रुटि को पुन: उत्पन्न कर सकता हूं, तो मैं इसे डीबगिंग के साथ ठीक कर सकता हूं। अगर मेरे पास कोई लॉग फाइल नहीं थी, तो मुझे ग्राहक या सपोर्ट टीम के विवरण पर निर्भर रहना होगा कि किस स्थिति में क्या होता है (जिसमें भ्रामक होने का एक बड़ा मौका है)।
दूसरे, लॉगिंग मुझे तैनात जगह पर मेरे मॉड्यूल की बाधाओं का पता लगाने का मौका देती है, क्योंकि मैं कुछ कार्यों की तारीख और समय लॉग करता हूं और फिर मैं देख सकता हूं कि किस कार्रवाई में कितना समय लगता है।
इसके अलावा, मान लीजिए कि हमारे समाधान में 6 मॉड्यूल हैं और मैं डेटाबेस लॉगआउट के बारे में अपनी लॉग फ़ाइलों में त्रुटि लॉग देख रहा हूं। यदि इन त्रुटियों को 5 अन्य मॉड्यूल में भी लॉग इन किया जाता है, तो संभावना है कि यह SQL सर्वर से संबंधित समस्या बड़ी हो जाती है। यदि यह केवल मेरे मॉड्यूल में लॉग इन किया जाता है, तो मेरी क्वेरी छोटी होने की संभावना अधिक हो जाती है। मुझे लगता है कि इस प्रकार की चीजें उपयोगी संकेतक हैं।
अपनी लॉग फ़ाइलों में मुझे किस प्रकार का डेटा दिखाई देता है, यह लॉग स्तर के कॉन्फ़िगरेशन पर निर्भर करता है। यदि यह एक नया उत्पाद है, तो हम जितना संभव हो उतना डेटा एकत्र करने के लिए लॉग स्तर "सभी" पर सेट करते हैं। लेकिन जब हम उत्पाद में सुधार करते हैं, तो हम केवल त्रुटि को लॉग करने के लिए "त्रुटि" पर लॉग स्तर को रखना पसंद कर सकते हैं, लेकिन सूचना के स्तर को लॉग करने के लिए नहीं, आदि ...
लॉगिंग उन सूचनाओं के लिए उपयोगी है जिन्हें आप अन्य कार्यक्रमों द्वारा प्राप्त नहीं कर सकते हैं:
नोट: आप कम से कम दो लॉग फाइल चाहते हैं।
INFO एक हमेशा चालू रहता है। जरूरत पड़ने पर DEBUG एक चालू है।
लॉगिंग कोड लिखें जो यह अनुमान लगाता है कि आपको एक दिन ऐसी स्थिति में डिबग करना पड़ सकता है जहां आपके पास सभी लॉग फ़ाइल है, और इसे सही करने से फ़ायर होने और प्रचारित होने के बीच अंतर हो सकता है।
अतिरिक्त मील के लिए, सभी फ़ंक्शन कॉल के साथ जावा में किसी भी स्टैक ट्रेस के लिए अपने पैरामीटर जोड़ें
public void sendEmail(String sender, String recipient) {
try {
...
} catch (Exception e) {
throw new RuntimeException("sendEmail(sender="+sender+", recipient="+recipient+")");
}
यह दृष्टिकोण अनिवार्य रूप से पैरामीटर मान के साथ आपके कॉल स्टैक को बढ़ाता है, और आपको स्टैक ट्रेस के साथ स्थिति का विश्लेषण करने और लॉग फ़ाइलों को देखने की अनुमति नहीं दे सकता है।
मैं यह भी सलाह दूंगा कि सभी गैर-तुच्छ ऐप मल्टी-लेवल लॉगिंग को रोजगार देते हैं।
दूसरों ने जिन कारणों के लिए कहा है, यह आवेदन के साथ समस्याओं को हल करने के लिए एक अमूल्य उपकरण है।
कुछ मामलों में, लॉगिंग आवश्यक है, उदाहरण के लिए वित्तीय अनुप्रयोगों और अन्य डोमेन में जो गतिविधि लॉग की आवश्यकता होती है, सुरक्षा, उपयोग मैट्रिक्स और ऑडिटिंग के लिए।
यह निश्चित रूप से आपके द्वारा बनाए जा रहे सिस्टम के प्रकार पर निर्भर करता है।
यदि आप एक स्टैंड-अलोन डेस्कटॉप एप्लिकेशन, जैसे कि वर्ड प्रोसेसर, लिख रहे हैं, तो आपको शायद किसी लॉगिंग की आवश्यकता नहीं है।
यदि आप एक एम्बेडेड सिस्टम लिख रहे हैं, तो आप लॉगिन किए बिना नहीं रह सकते। अन्यथा, जब आपका एम्बेडेड डिवाइस जम जाता है, तो आपको पता नहीं क्यों। जब भी आपके सिस्टम में कई प्रक्रियाएं या एक-दूसरे के साथ संचार करने वाली कई भौतिक मशीनें शामिल होती हैं, तो आपको लॉगिंग की आवश्यकता होती है। फिर से, जब सिस्टम लटका होता है, तो आपको यह जानना होगा कि इसका कौन सा हिस्सा कब और क्यों मर गया। आपको यह निर्धारित करने के लिए लॉग की तुलना करने में सक्षम होने की आवश्यकता है कि क्या डेटा ने इसे एक प्रक्रिया से दूसरी प्रक्रिया में बनाया है या नहीं। एक ही टोकन के द्वारा, आपको लॉगिंग की आवश्यकता होती है जब भी आपका सिस्टम बिना अधिक प्रत्यक्ष उपयोगकर्ता सहभागिता के विस्तारित समय के लिए चलने के लिए होता है।
लॉगिंग हमेशा उपयोगी होती है। लेकिन जब लागू होने के बारे में पता है कि यह जरूरी नहीं है, जो लॉग पढ़ने के लिए जा रहा है। शायद यह किसी प्रकार का एक व्यवस्थापक है, एक अंतिम-उपयोगकर्ता, एक ग्राहक, एक समर्थन टीम, ...
इसलिए न केवल स्टैकट्रैक लॉग करें, बल्कि कुछ अतिरिक्त जानकारी भी जो गैर-डेवलपर्स द्वारा व्याख्या की जा सकती है। जब आपका एप्लिकेशन कुछ अन्य समूहों द्वारा बनाए रखा जाता है, तो यह आपके लॉग में कुछ अद्वितीय त्रुटि कोड लिखने के लिए भी सहायक होता है। यह समर्थन, स्वचालन, को कम कर सकता है ...
व्यवस्थापक दृष्टिकोण से एक और बिंदु: लॉग रोटेशन के बारे में सोचें।