इसके साथ शुरू करने के लिए, मैं दोहराता हूं कि प्रत्येक डेवलपर को इस बारे में क्या जानना चाहिए - ~~संरक्षित करने की आवश्यकता है~~ ।

मुझे लॉग इन करने की आवश्यकता क्यों है

आपने एक सर्वर एप्लिकेशन लॉन्च किया है जिसमें अपनी स्थिति प्रदर्शित करने के लिए GUI नहीं है, लेकिन मैं वास्तव में जानना चाहता हूं। सबसे सरल और सबसे स्पष्ट समाधान कुछ संदेश कहीं प्रदर्शित करना है - stdout / stderr, फ़ाइलें, syslog, कुछ अधिक विकृत। यह लॉगिंग (धन्यवाद कैप) है।

मैं उन मुख्य कार्यों को सूचीबद्ध करूँगा जिन्हें लॉगिंग का उपयोग करके हल किया जा सकता है:

व्यवहार और प्रदर्शन का विश्लेषण। यहां यह ध्यान दिया जाना चाहिए कि प्रदर्शन विश्लेषण के लिए, प्रोबिंग का उपयोग करना बेहतर है (जैसे ट्विटर ज़िपकिन कोड में नमूनों के माध्यम से डेटा प्राप्त करता है)। व्यवहार का तात्पर्य उस सब से है जो अभी हो रहा है।
समस्याओं का विश्लेषण और निदान। यहां यह स्पष्ट है कि आवेदन में 1/0 की महत्वपूर्ण स्थिति है (और ऐसा नहीं है जब ऐसा हुआ, तो आवेदन मरने वाला है), मुझे क्या करना चाहिए? यह सही है - इसे प्रतिज्ञा करना। इसके बारे में नीचे विस्तार से बताया गया है।
सभी प्रकार के बाएं हाथ के उपयोग के मामले।

कैसे लॉग इन करें

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

यही है, हम लिखते हैं कि जो कुछ हो रहा है उसे समझने के लिए आप खुद को क्या आवश्यक मानते हैं। लेकिन यह जोर दिया जाना चाहिए कि लॉगिंग एप्लिकेशन संसाधनों को खाती है - इसलिए दूर नहीं किया जाता है, मैंने एक बार आवेदन देखा, जहां लॉगिंग ने लगभग 50% प्रदर्शन किया (बेशक पीपीसी को उस तरह से करने की आवश्यकता नहीं है)।

यदि कोई त्रुटि / अपवाद होता है, आदि, तो आपको यह समझने की आवश्यकता है कि क्यों। इस क्षण में, हम लॉग में सब कुछ लिखते हैं (हाँ, बिल्कुल सब कुछ) यह समझना आवश्यक है कि ऐसा क्यों हुआ (यहां आपको बस बहुत लिखना है - शर्मीली मत बनो)।

लॉग स्तर

जाहिर है, हर संदेश समान महत्व का नहीं है। आमतौर पर, अधिकांश अनुप्रयोगों के लिए 5 लॉगिंग स्तर पर्याप्त हैं - मैं उन स्तरों के नाम का उपयोग करता हूं जिनका उपयोग मैंने slf4j के साथ किया है:

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

इसके अलावा लॉगर की एक छोटी सी तुलना होगी जो मैंने नोड में कोशिश की थी। जेएस और उनके साथ क्या गलत है, ऊपर दिया गया है।

log4js

यह पहली चीज है जिसे मैंने देखा है, इस उम्मीद में कि यह कम से कम कुछ हद तक log4j के समान होगा।

एक छोटा सा उदाहरण:

var log4js = require('log4js'); var logger = log4js.getLogger(); logger.debug("Some debug messages");

कंसोल में एक रंगीन संदेश दिखाई देगा:

 [2014-01-13 20:41:22.604] [DEBUG] [default] - Some debug messages

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

विंस्टन

यह अक्सर SO पर अनुशंसित होता है। मैं व्यक्तिगत रूप से किसी को भी इसकी सिफारिश नहीं करूंगा।
एक उदाहरण:

 var winston = require('winston'); winston.info('Hello distributed log files!');

कंसोल में क्या होगा:

 info: Hello distributed log files!

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

Bunyan

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

दूसरे परिदृश्य के लिए JSON, जो कि मेरी राय में, लॉगिंग का सबसे उचित उपयोग है, यह है कि कोड कोड में C ++ कोड में एक त्रुटि कैसे देखें। लोगों द्वारा लॉग पढ़े जाते हैं। यदि आवेदन छोटा है, तो लॉग कलेक्टर अनावश्यक है, और यदि यह दिखाई देता है, तो आपको बस इसके लिए एक हैंडलर जोड़ने की आवश्यकता है।
अगर हम कोड के संगठन के बारे में बात करते हैं, तो यह है कि लकड़हारा हैंडलर बाहर निकलता है और कहां, यह हैंडलर की जिम्मेदारी है - अर्थात्, सिद्धांत रूप में JSON आउटपुट को किसी भी लाइब्रेरी में फास्ट किया जा सकता है जो आपको अपने हैंडलर या फॉर्मेटर को लिखने की अनुमति देता है।
बनीन में एक विशेषता है - कस्टम प्रकार के लिए धारावाहिक। संदेश के साथ ऑब्जेक्ट्स का एक बंडल लकड़हारे को खिलाया जाता है और यह उन्हें क्रमबद्ध करता है। यदि आप इसे एक अलग कोण से देखते हैं:
क्रमांकन एक वस्तु का सिर्फ JSON प्रतिनिधित्व है; प्रत्येक वस्तु अपने प्रोटोटाइप में toJSON विधि निर्धारित कर सकती है और इसे JSON.stringify के साथ कहा जाएगा - यह धारावाहिक है; अब इसे कैसे निकाला जाए - बिल्कुल सभी लकड़हारे आपको एक विशेष ध्वज (उपयोग के लिए% j) के साथ वस्तुओं के जोंस प्रतिनिधित्व को प्रदर्शित करने की अनुमति देते हैं। यानी फीचर काफी हद तक स्पष्ट प्रतीत हो रहा है।

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

इंटेल

यह सबसे अच्छी लॉगिंग लाइब्रेरी है जो मैं भर में आया हूँ। कॉन्फ़िगरेशन के संदर्भ में, मुझे इसके बारे में कोई शिकायत नहीं थी। मैं उसे क्यों पसंद आया:

जैसा कि पहले ही कहा गया है, उसके पास बहुत सुविधाजनक कॉन्फ़िगरेशन है, आप एक जगह में सब कुछ कॉन्फ़िगर कर सकते हैं। लॉगर्स में हैंडलर होते हैं, हैंडलर के पास मैसेज फॉर्मेटर्स, मैसेज और लेवल के अनुसार फिल्टर होते हैं। लगभग एक परी कथा।
Slf4j के साथ आए लॉगर की पदानुक्रम, उदाहरण के लिए, इसे दी गई है, हालांकि, केवल इस परिवाद में इसे सामान्य रूप से लागू किया गया था। लकड़हारा पदानुक्रम क्या है:
प्रत्येक लकड़हारे के पास माता-पिता होते हैं (लकड़हारा का पूरा नाम सभी माता-पिता के बिंदु के माध्यम से बताकर सेट किया जाता है), माता-पिता के कॉन्फ़िगरेशन को सेट करते हुए, आप विकल्प सेट कर सकते हैं ताकि सभी बच्चे इसे स्वचालित रूप से प्राप्त करें (लॉग प्रसार)। यही है, उदाहरण के लिए, मैं कई पैरेंट लॉगर बना सकता हूं, उनके लिए हैंडलर सेट कर सकता हूं (जैसे कि ERROR और WARN स्तरों को ईमेल भेजें) और सभी बच्चे उनका उपयोग करेंगे, लेकिन इसके अलावा, अगर मुझे किसी प्रकार के लॉग ट्री को म्यूट करने की आवश्यकता है, तो मैं सिर्फ इसके लिए कॉन्फ़िगरेशन का विशेषज्ञ हूं इसका पूरा रास्ता। और यह सब एक जगह और एक बार में।
मानक कंसोल का बहुत ही उचित प्रतिस्थापन। वर्तमान वर्किंग डायरेक्टरी के सापेक्ष पथों की अनुमति है, जो आपको कंसोल.लॉग आउटपुट को आसानी से कॉन्फ़िगर करने और लकड़हारा बन्स प्राप्त करने की अनुमति देता है।

एक छोटे से उपयोग के बाद (मैंने देखा कि इस परियोजना में दूसरों की तरह थोड़ा ध्यान दिया जाता है), मैंने आउटपुट मिलीसेकंड, आउटपुट स्वरूपित त्रुटि आउटपुट के लिए समर्थन को जोड़ने के लिए कई पुल अनुरोध किए, लेकिन लेखक और 4-5 के साथ एक छोटी बातचीत के बाद पुल अनुरोध, यह स्पष्ट हो गया कि लेखक अपने तरीके से जाना चाहता है और मैंने उस परियोजना को जोड़ दिया जिसे मैंने सपने में देखा था।
कोड में खुदाई, मैंने देखा कि लेखक ने बेंचमार्क के लिए कोड को अनुकूलित किया। मैं ऐसी चीजों पर अपनी राय बेहतर तरीके से खुद पर छोड़ता हूं।
मैंने खुद को लीवर में बदल दिया, जिससे हैंडलर्स अछूते नहीं रहे:

मैंने बेंचमार्क के लिए इस तरह की सभी अनुकूलन को बाहर फेंक दिया - ऐसी चीजें लिखने के लिए जो खुद का सम्मान नहीं करते हैं।
इंटेल में संदेशों का प्रारूप: आपको रिकॉर्ड ऑब्जेक्ट के फ़ील्ड के प्रकार को इंगित करने की आवश्यकता है (जैसे '[% (दिनांक) s]% (नाम) s ::% (संदेश) s', लेकिन इन फ़ील्ड्स के प्रकार ज्ञात हैं - तो क्यों उन्हें निर्दिष्ट करने की आवश्यकता है। इसके बजाय, मैंने लॉगबैक से संदेश प्रारूप लिया।
लॉगिंग के दौरान तर्कों को प्रारूपित करने के लिए, हम अपने स्वयं के अनुरूप उपयोग करते हैं। अपनी स्वयं की कुंजियों के साथ। इसका उपयोग कंसोल को बदलने के दौरान भी किया जाता है, अर्थात यदि कोई तृतीय-पक्ष पुस्तकालय कुछ लिखता है, तो हमें वह नहीं मिलेगा जो हम कंसोल में उम्मीद करते हैं। स्वाभाविक रूप से इसे use.format द्वारा बदल दिया गया था
कुछ रूपरेखा के बाद, यह स्पष्ट हो गया कि हर समय संदेशों को प्रारूपित करने में लगता है। चूंकि प्रारूप आमतौर पर एक बार सेट किया जाता है, इसलिए इसे अनुकूलित करना उचित है, जो कि किया गया था, नए फ़ंक्शन का उपयोग करते हुए, प्रारूप एक बार एकत्र किया जाता है, और हर कॉल के साथ नहीं।

अभी भी कुछ छोटी चीजें हैं, लेकिन यह किसी तरह का पीआर होगा, और तुलना नहीं।
मतभेदों की कुछ गूढ़ता दिखाने के लिए - गति का एक छोटा माप ( बेंचमार्क कोड , सभी संस्करण नवीनतम हैं)। बस logger.info प्रिंट करें (संदेश के साथ):

 $ node benchmark/logging.js console.info x 1,471,685 ops/sec ±0.79% (95 runs sampled) rufus.info x 200,641 ops/sec ±1.04% (84 runs sampled) winston.info x 65,567 ops/sec ±0.80% (96 runs sampled) intel.info x 56,117 ops/sec ±1.51% (92 runs sampled) bunyan.info x 86,970 ops/sec ±1.71% (81 runs sampled) log4js.info x 45,351 ops/sec ±3.25% (79 runs sampled) Fastest is console.info

इस संदेश प्रारूप के साथ '[% date]% लकड़हारा ::% संदेश', जो हमेशा अपेक्षा के अनुरूप है। आइए अनुकूलन की पूरी शक्ति को महसूस करने के लिए इसे बुद्धि में एक मानक संदेश के साथ बदलने का प्रयास करें:

 $ node benchmark/logging.js console.info x 1,569,375 ops/sec ±0.66% (95 runs sampled) rufus.info x 199,138 ops/sec ±0.81% (97 runs sampled) winston.info x 66,864 ops/sec ±0.84% (91 runs sampled) intel.info x 173,483 ops/sec ±5.64% (59 runs sampled) bunyan.info x 86,357 ops/sec ±1.02% (94 runs sampled) log4js.info x 49,978 ops/sec ±2.29% (81 runs sampled) Fastest is console.info

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

Node.js में लॉग इन करने के बारे में