🌜 ✴️ 👩🏻‍🏭 NodeJS लॉगिंग सही किया 🎱 🚭 👏🏻

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

NodeJS में प्रत्येक अनुरोध के लिए एक ट्रेस आईडी होना भी एक समस्या क्यों है?

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

पुराने दिनों में वापस (v0.11.11) हमारे पास addAsyncListener था जिसने हमें अतुल्यकालिक घटनाओं को ट्रैक करने की अनुमति दी। इसके आधार पर फॉरेस्ट नॉरवेल ने निरंतर स्थानीय भंडारण उर्फ सीएलएस का कार्यान्वयन किया। हम इस तथ्य के कारण सीएलएस के उस कार्यान्वयन को कवर नहीं करने जा रहे हैं कि हम, डेवलपर्स के रूप में, पहले से ही v0.12 में उस एपीआई से छीन लिए गए थे।

NodeJS 8 तक हमारे पास NodeJS 'async इवेंट प्रोसेसिंग तक हुक करने का कोई आधिकारिक तरीका नहीं था। और अंत में NodeJS 8 ने हमें async_hooks के माध्यम से खोई हुई शक्ति प्रदान की (यदि आप async_hooks की बेहतर समझ प्राप्त करना चाहते हैं तो इस लेख पर एक नज़र डालें)। यह हमें CLS - cls-hooked के आधुनिक async_hooks- आधारित कार्यान्वयन में लाता है।

सीएलएस अवलोकन

सीएलएस कैसे काम करता है इसका एक सरलीकृत प्रवाह है:

चलिए इसे चरण-दर-चरण तोड़ते हैं:

कहते हैं, हमारे पास एक विशिष्ट वेब सर्वर है। पहले हमें एक CLS नाम स्थान बनाना होगा। एक बार हमारे आवेदन के पूरे जीवनकाल के लिए।
दूसरा हमें प्रत्येक अनुरोध के लिए एक नया सीएलएस संदर्भ बनाने के लिए एक मिडलवेयर को कॉन्फ़िगर करना होगा। सादगी के लिए मान लें कि यह मिडलवेयर सिर्फ एक कॉलबैक है जिसे एक नया अनुरोध प्राप्त करने के लिए कहा जाता है।
इसलिए जब कोई नया अनुरोध आता है तो हम उस कॉलबैक फ़ंक्शन को कॉल करते हैं।
उस फ़ंक्शन के भीतर हम एक नया सीएलएस संदर्भ बनाते हैं (इनमें से एक तरीका रन एपीआई कॉल का उपयोग करना है)।
इस बिंदु पर सीएलएस नए संदर्भ को वर्तमान निष्पादन आईडी द्वारा संदर्भों के मानचित्र में रखता है।
प्रत्येक सीएलएस नामस्थान में active संपत्ति है। इस स्तर पर सीएलएस संदर्भ के लिए active होता है।
संदर्भ के अंदर हम एक अतुल्यकालिक संसाधन के लिए एक कॉल करते हैं, कहते हैं, हम डेटाबेस से कुछ डेटा का अनुरोध करते हैं। हम कॉल के लिए एक कॉलबैक पास करते हैं, जो डेटाबेस के अनुरोध के पूरा होने के बाद चलने वाला है।
init async हुक को नए एसिंक्रोनस ऑपरेशन के लिए निकाल दिया जाता है। यह वर्तमान संदर्भ को async आईडी द्वारा संदर्भों के मानचित्र में जोड़ता है (इसे नए अतुल्यकालिक ऑपरेशन का एक पहचानकर्ता मानें)।
जैसा कि हमारे पहले कॉलबैक के अंदर कोई और तर्क नहीं है, यह हमारे पहले अतुल्यकालिक ऑपरेशन को प्रभावी ढंग से समाप्त करता है।
Async हुक के बाद पहली कॉलबैक के लिए निकाल दिया जाता है। यह नाम स्थान पर सक्रिय संदर्भ को undefined (यह हमेशा सच नहीं होता है क्योंकि हमारे पास कई नेस्टेड संदर्भ हो सकते हैं, लेकिन सबसे सरल मामले के लिए यह सच है)।
नष्ट हुक पहले ऑपरेशन के लिए निकाल दिया जाता है। यह संदर्भ के नक्शे को इसकी async आईडी से हटाता है (यह हमारी पहली कॉलबैक की वर्तमान निष्पादन आईडी के समान है)।
डेटाबेस के लिए अनुरोध समाप्त हो गया है और हमारा दूसरा कॉलबैक ट्रिगर होने वाला है।
इस बिंदु पर पहले async हुक खेलने में आता है। इसकी वर्तमान निष्पादन आईडी दूसरे ऑपरेशन (डेटाबेस अनुरोध) की समान आईडी है। यह नामस्थान की active संपत्ति को उसके वर्तमान निष्पादन आईडी द्वारा प्राप्त संदर्भ में सेट करता active । यह वह संदर्भ है जो हमने पहले बनाया था।
अब हम अपना दूसरा कॉलबैक चलाते हैं। अंदर कुछ व्यावसायिक तर्क चलाएं। उस फ़ंक्शन के भीतर हम सीएलएस से कुंजी द्वारा किसी भी मूल्य को प्राप्त कर सकते हैं और यह हमारे द्वारा बनाए गए संदर्भ में कुंजी द्वारा जो कुछ भी पाता है उसे वापस करने जा रहा है।
यह मानते हुए कि यह हमारे फ़ंक्शन रिटर्न के अनुरोध के प्रसंस्करण का अंत है।
Async हुक के बाद दूसरी कॉलबैक के लिए निकाल दिया जाता है। यह नाम स्थान पर सक्रिय संदर्भ को undefined ।
destroy हुक दूसरे अतुल्यकालिक ऑपरेशन के लिए निकाल दिया जाता है। यह हमारे संदर्भ को इसकी async आईडी द्वारा संदर्भों के मानचित्र से हटा देता है और इसे बिल्कुल खाली छोड़ देता है।
जैसा कि हम अब संदर्भ वस्तु पर कोई संदर्भ नहीं रखते हैं क्योंकि हमारा कचरा कलेक्टर इससे जुड़ी मेमोरी को मुक्त करता है।

यह हुड के नीचे क्या चल रहा है, इसका एक सरलीकृत संस्करण है, फिर भी इसमें सभी प्रमुख कदम शामिल हैं। यदि आप गहरी खुदाई करना चाहते हैं, तो आप स्रोत कोड पर एक नज़र डाल सकते हैं। यह 500 लाइनों से कम है।

ट्रेस आईडी बनाना

इसलिए एक बार जब हम सीएलएस की समग्र समझ प्राप्त कर लेते हैं तो आइए सोचते हैं कि हम इसे अपने अच्छे के लिए कैसे उपयोग कर सकते हैं। एक चीज जो हम कर सकते हैं वह एक मिडलवेयर बनाना है जो एक संदर्भ में प्रत्येक अनुरोध को लपेटता है, एक यादृच्छिक पहचानकर्ता उत्पन्न करता है और इसे सीएलएस में प्रमुख traceID द्वारा डालता है। बाद में, हमारे एक gazillion नियंत्रकों और सेवाओं के अंदर हम CLS से उस पहचानकर्ता को प्राप्त कर सकते हैं।

एक्सप्रेस के लिए यह मिडलवेयर इस तरह दिख सकता है:

 const cls = require('cls-hooked') const uuidv4 = require('uuid/v4') const clsNamespace = cls.createNamespace('app') const clsMiddleware = (req, res, next) => { // req and res are event emitters. We want to access CLS context inside of their event callbacks clsNamespace.bind(req) clsNamespace.bind(res) const traceID = uuidv4() clsNamespace.run(() => { clsNamespace.set('traceID', traceID) next() }) }

फिर हमारे कंट्रोलर में हमें इस तरह से ट्रेस आईडी प्राप्त हो सकती है:

 const controller = (req, res, next) => { const traceID = clsNamespace.get('traceID') }

जब तक हम इसे अपने लॉग में नहीं जोड़ते, इस ट्रेस आईडी का इतना उपयोग नहीं होता है।

आइए इसे हमारी जीत में जोड़ें।

 const { createLogger, format, transports } = require('winston') const addTraceId = printf((info) => { let message = info.message const traceID = clsNamespace.get('taceID') if (traceID) { message = `[TraceID: ${traceID}]: ${message}` } return message }) const logger = createLogger({ format: addTraceId, transports: [new transports.Console()], })

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

प्रॉक्सी और सीएलएस का संयोजन

प्रॉक्सी एक ऐसी वस्तु है जो हमारी मूल वस्तु को लपेटती है जिससे हम कुछ स्थितियों में इसके व्यवहार को खत्म कर सकते हैं। इन स्थितियों की सूची (उन्हें वास्तव में जाल कहा जाता है) सीमित है और आप यहां पूरे सेट पर एक नज़र डाल सकते हैं , लेकिन हम केवल जाल पाने में रुचि रखते हैं । यह हमें संपत्ति तक पहुँचने में अवरोधन करने की क्षमता प्रदान करता है। इसका मतलब है कि अगर हमारे पास कोई ऑब्जेक्ट const a = { prop: 1 } और इसे प्रॉक्सी में रैप करें, get ट्रैप के साथ हम कुछ भी वापस कर सकते हैं जो हम a.prop लिए चाहते हैं।

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

इस परिदृश्य में हमारा प्रॉक्सी इस तरह दिख सकता है:

 const pino = require('pino') const logger = pino() const loggerCls = new Proxy(logger, { get(target, property, receiver) { // Fallback to our original logger if there is no child logger in CLS target = clsNamespace.get('loggerCls') || target return Reflect.get(target, property, receiver) }, })

हमारा मिडलवेयर कुछ इस तरह से बदल जाएगा:

 const cls = require('cls-hooked') const uuidv4 = require('uuid/v4') const clsMiddleware = (req, res, next) => { // req and res are event emitters. We want to access CLS context inside of their event callbacks clsNamespace.bind(req) clsNamespace.bind(res) const traceID = uuidv4() const loggerWithTraceId = logger.child({ traceID }) clsNamespace.run(() => { clsNamespace.set('loggerCls', loggerWithTraceId) next() }) }

और हम इस तरह लकड़हारे का उपयोग कर सकते हैं:

 const controller = (req, res, next) => { loggerCls.info('Long live rocknroll!') // Logs something like // {"level":30,"time":1551385666046,"msg":"Long live rocknroll!","pid":25,"hostname":"eb6a6c70f5c4","traceID":"9ba393f0-ec8c-4396-8092-b7e4b6f375b5","v":1} }

सीएलएस-Proxify

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

उम्मीद है, आपने अपनी परियोजना के लिए कुछ उपयोगी पाया है। अपनी प्रतिक्रिया मुझसे संवाद करने के लिए स्वतंत्र महसूस करें! मैं निश्चित रूप से किसी भी आलोचना और सवालों की सराहना करता हूं।

NodeJS लॉगिंग सही किया

NodeJS में प्रत्येक अनुरोध के लिए एक ट्रेस आईडी होना भी एक समस्या क्यों है?

सीएलएस अवलोकन

ट्रेस आईडी बनाना

प्रॉक्सी और सीएलएस का संयोजन

सीएलएस-Proxify

More articles: