लॉगिंग के बारे में बात करते हैं

यह पोस्ट नैट फिंच द्वारा शुरू किए गए गो फोरम विषय से प्रेरित है। यह पोस्ट गो पर केंद्रित है, लेकिन यदि आप इससे आगे जाते हैं, तो मुझे लगता है कि यहां प्रस्तुत विचार व्यापक रूप से लागू हैं।

प्यार क्यों नहीं है?

गो में लॉग पैकेज में लॉग्स के लिए कोई स्तर नहीं है; आप मैन्युअल रूप से DEBUG, INFO, WARN और ERROR जोड़ सकते हैं और अपने आप को उपसर्ग कर सकते हैं। इसके अलावा, गो में लकड़हारा प्रकार चयनित संकुल के लिए अलग से इन स्तरों को सक्षम या अक्षम करने की क्षमता नहीं रखता है। तुलना के लिए, आइए तृतीय-पक्ष डेवलपर्स के कुछ प्रतिस्थापन देखें।



Google glog के स्तर हैं:

• जानकारी
• चेतावनी
• त्रुटि
• घातक (कार्यक्रम को समाप्त करता है)

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

• निशान
• डिबग
• जानकारी
• चेतावनी
• त्रुटि
• गंभीर

लॉगगो के पास व्यक्तिगत पैकेजों के लिए लॉग के विवरण के स्तर को व्यक्तिगत रूप से सेट करने की क्षमता भी है।

अन्य भाषाओं में लॉगिंग के लिए अन्य पुस्तकालयों के प्रभाव में स्पष्ट रूप से बनाए गए दो उदाहरण यहां दिए गए हैं।

वास्तव में, उनके मूल का पता लगाया जा सकता है वापस (3), संभवतः पहले भी। और मुझे लगता है कि वे गलत हैं।

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

मेरा तर्क है कि सफल लॉग पैकेज को बहुत कम सुविधाओं की आवश्यकता होती है और निश्चित रूप से, कम स्तर।

चेतावनी के बारे में बात करते हैं (चेतावनी)

सबसे सरल से शुरू करते हैं। किसी को चेतावनी लॉग स्तर (चेतावनी) की आवश्यकता नहीं है।

कोई भी चेतावनी नहीं पढ़ता है, क्योंकि परिभाषा के अनुसार कुछ भी बुरा नहीं हुआ है। हो सकता है कि भविष्य में कुछ गलत हो सकता है, लेकिन यह किसी और की तरह लगता है, मेरी समस्या नहीं।

इसके अलावा, यदि आप किसी प्रकार के बहु-स्तरीय लॉगिंग का उपयोग करते हैं, तो आपको चेतावनी स्तर सेट करने की आवश्यकता क्यों है? आप INFO या ERROR के स्तर को निर्धारित करेंगे। चेतावनी स्तर सेट करने का अर्थ है कि आप शायद चेतावनी स्तर पर त्रुटियों की रिपोर्ट कर रहे हैं।

चेतावनी स्तर को छोड़ दें - यह या तो एक सूचना संदेश है, या एक त्रुटि है।

आइए घातक त्रुटि के स्तर के बारे में बात करते हैं

FATAL स्तर वास्तव में संदेश को लॉग करता है, और फिर os.Exit (1) कहता है। सिद्धांत रूप में, इसका मतलब है:

• अन्य दिनचर्या (goroutines) में आस्थगित अभिव्यक्तियों को निष्पादित नहीं किया जाता है;
• बफ़र्स फ्लश नहीं होते हैं;
• अस्थायी फ़ाइलों और निर्देशिकाओं को हटाया नहीं जाता है।

संक्षेप में, log.Fatal कम क्रिया है, लेकिन शब्दार्थ घबराहट के बराबर है।

यह आमतौर पर स्वीकार किया जाता है कि पुस्तकालयों को घबराहट 1 का उपयोग नहीं करना चाहिए, लेकिन अगर लॉग.फ़ाल 2 को कॉल करने का एक ही प्रभाव है, तो इसे भी अक्षम किया जाना चाहिए।

यह धारणा कि लॉगर में शटडाउन हैंडलर्स को पंजीकृत करके इस सफाई समस्या को हल किया जा सकता है, उपयोग किए गए लॉगर और प्रत्येक जगह के बीच एक करीबी संबंध प्रदान करता है जहां सफाई संचालन होता है। यह हितों के पृथक्करण का भी उल्लंघन करता है।

संदेशों को FATAL स्तर के साथ रिकॉर्ड न करें, इसके बजाय कॉलर को एक त्रुटि वापस करना पसंद करते हैं। यदि त्रुटि main.main तक पहुँचती है, तो प्रोग्राम को बंद करने से पहले किसी भी क्लीनअप को करने के लिए यह सही जगह है।

त्रुटि के बारे में बात करते हैं (ERROR स्तर)

त्रुटि हैंडलिंग और लॉगिंग निकटता से संबंधित हैं, इसलिए, पहली नज़र में, त्रुटि स्तर लॉगिंग (ERROR) को आसानी से उचित ठहराया जाना चाहिए। मैं सहमत नहीं हूं।

Go में, यदि कोई फ़ंक्शन या मेथड कॉल करने पर कोई त्रुटि मान देता है, तो आपके पास वास्तव में दो विकल्प हैं:

• त्रुटि को संभालें।
• इसके कॉलर पर त्रुटि लौटाएं। आप खूबसूरती से गिफ्ट रैपिंग (लपेट) में गलती कर सकते हैं, लेकिन इस चर्चा के लिए यह महत्वपूर्ण नहीं है।

यदि आप लॉग में इसे लिखकर त्रुटि को संसाधित करने का निर्णय लेते हैं, तो परिभाषा के अनुसार यह अब कोई त्रुटि नहीं है - आपने इसे संसाधित किया है। त्रुटि को पंजीकृत करने का कार्य स्वयं त्रुटि का प्रसंस्करण है; इसलिए, इसे लॉग के लिए त्रुटि के रूप में लिखना उचित नहीं है।

मुझे इस कोड के टुकड़े के साथ मनाइए:

err := somethingHard() if err != nil { log.Error("oops, something was too hard", err) return err // what is this, Java ? } 

आपको कभी भी त्रुटि स्तर पर कुछ भी पंजीकृत नहीं करना चाहिए क्योंकि आपको या तो त्रुटि को संभालना चाहिए या इसे कॉलर को पास करना होगा।

आपको स्पष्ट रूप से समझने की आवश्यकता है, मैं यह नहीं कह रहा हूं कि आपको उस लॉग को नहीं लिखना चाहिए जो एक राज्य परिवर्तन हुआ है:

 if err := planA(); err != nil { log.Infof("could't open the foo file, continuing with plan b: %v", err) planB() } 

लेकिन वास्तव में, log.Info और log.Error का एक ही लक्ष्य है।

मैं नहीं कहता "त्रुटियों को पंजीकृत न करें"! इसके बजाय, मैं सवाल पूछता हूं, लॉगिंग के लिए सबसे छोटा संभव एपीआई क्या है? और जब त्रुटियों की बात आती है, तो मेरा मानना ​​है कि ERROR स्तर पर दर्ज की गई अधिकांश चीजें केवल इसलिए की गईं क्योंकि वे त्रुटि से संबंधित हैं। वास्तव में, वे सिर्फ जानकारीपूर्ण हैं, इसलिए हम अपने एपीआई से त्रुटि-स्तर लॉगिंग (ERROR) को हटा सकते हैं।

क्या बचा है?

हमने चेतावनी को छोड़ दिया, तर्क दिया कि त्रुटि स्तर (ERROR) पर कुछ भी लॉग नहीं किया जाना चाहिए, और दिखाया कि केवल शीर्ष-स्तरीय एप्लिकेशन में कुछ प्रकार का लॉग होना चाहिए। घातक व्यवहार। क्या बचा है?

मेरा मानना ​​है कि केवल दो चीजें हैं जिन्हें आपको लॉग इन करना चाहिए:

• जब वे किसी कार्यक्रम को विकसित या डिबग करते हैं, तो डेवलपर्स को परवाह होती है;
• आपके प्रोग्राम का उपयोग करते समय उपयोगकर्ता जिन चीजों की परवाह करते हैं।

जाहिर है, ये क्रमशः डिबगिंग स्तर (DEBUG) और सूचनात्मक (INFO) हैं।

log.Info को बस इस लाइन को लॉग आउटपुट में लिखना चाहिए। इसे अक्षम करना संभव नहीं होना चाहिए, क्योंकि उपयोगकर्ता को केवल यह बताना चाहिए कि उसके लिए क्या उपयोगी है। यदि कोई त्रुटि उत्पन्न होती है जिसे संसाधित नहीं किया जा सकता है, तो यह main.main में दिखाई देना चाहिए जहां प्रोग्राम से बाहर निकलता है। अंतिम लॉग संदेश से पहले FATAL उपसर्ग सम्मिलित करने या सीधे os.Stderr को fmt.Fprintf का उपयोग करने के लिए लिखने की मामूली असुविधा लॉग के साथ पैकेज का विस्तार करने के लिए पर्याप्त कारण नहीं है। घातक विधि।

log.Debug, यह एक पूरी तरह से अलग मामला है। एक डेवलपर या समर्थन इंजीनियर को कार्यक्रम को नियंत्रित करने के लिए इसकी आवश्यकता होती है। विकास के दौरान, ट्रेस स्तर या डीबग 2 का सहारा लिए बिना डिबग एक्सप्रेशन कई होने चाहिए (आप जानते हैं कि आप कौन हैं)। लॉगिंग पैकेज को पैकेज में वांछित पैकेजों के लिए या शायद संकीर्ण दायरे में भी, डिबग एक्सप्रेशंस को सक्षम या अक्षम करने के लिए दानेदार नियंत्रण का समर्थन करना चाहिए।

निष्कर्ष

यदि यह एक ट्विटर पोल था, तो मैं आपको बीच में चुनने के लिए कहूंगा

• लॉगिंग महत्वपूर्ण है
• लॉगिंग कठिन है

लेकिन तथ्य यह है कि लॉगिंग दोनों है। इस समस्या का हल नष्ट होना और निर्दयता से अनावश्यक विकर्षण को कम करना है।

आपको क्या लगता है? क्या यह काम करने के लिए पर्याप्त नहीं है, या यह सिर्फ असाधारण है?

नोट

कुछ पुस्तकालय आंतरिक नियंत्रण प्रवाह तंत्र के रूप में घबराहट / उबर का उपयोग कर सकते हैं, लेकिन मुख्य मंत्र यह है कि वे इन नियंत्रण प्रवाह संचालन को पैकेज सीमा से बाहर रिसाव की अनुमति न दें।

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

लेखक के बारे में

इस लेख के लेखक डेव चेनी , गो के लिए कई लोकप्रिय पैकेजों के लेखक हैं, उदाहरण के लिए github.com/pkg/errors और github.com/davecheney/httpstat । आप लेखक के अधिकार और अनुभव का स्वयं मूल्यांकन कर सकते हैं।

अनुवादक से

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

प्लस प्रस्तुति प्रतिबिंब क्या हमें एक नए लकड़हारे की आवश्यकता है और यह क्या होना चाहिए? क्रिस हाइन्स से।

डेव के गो-लॉग विचारों के कई कार्यान्वयन और ERROR स्तर के मुद्दे पर थोड़ा ऑफ-टॉपिक और अधिक विस्तृत लॉगर पैकेज हैं।