Winston: प्रक्रिया को कॉल करते समय फ़ाइल में लॉगिंग विफल हो जाती है। बाहर निकलें (0)

नोड में कंसोल। * विधियाँ async लिख रही हैं, फ़ाइल परिवहन async है। नोड के पास डेटा लिखने से पहले आप प्रक्रिया को बंद कर रहे हैं।

सोमवार २५ मार्च २०१३ को १९:४५ बजे यूरी ज़ापुचलक ने लिखा:

जब आपने विंस्टन को किसी फ़ाइल में लॉग इन करने के लिए कॉन्फ़िगर किया है और आप अपने कोड में process.exit(0) को कॉल करते हैं, तो विंस्टन कभी भी लॉग फ़ाइल बनाने और लॉग संदेशों को फ़ाइल में जोड़ने के लिए समाप्त नहीं होता है।
एक आदर्श दुनिया में, विंस्टन खुशी से इस किनारे के मामले को संभाल लेगा और फ़ाइल को लिख देगा, लेकिन फ़ाइल में फ्लश को मैन्युअल रूप से मजबूर करने के लिए मैं लॉगर इंस्टेंस पर फ्लश को कॉल करने में सक्षम होने के साथ भी ठीक रहूंगा।
इस समय मैन्युअल रूप से 'फ्लश' करने का कोई तरीका हो सकता है, लेकिन यह दस्तावेज नहीं है और न ही मुझे लॉगर इंस्टेंस या इसकी आंतरिक धाराओं को अब तक बंद/समाप्त/नष्ट करने के लिए मैन्युअल रूप से कोई भाग्य है जो वास्तव में लॉग में परिणाम देता है एक फ़ाइल में लिखा जा रहा है ..
वर विंस्टन = आवश्यकता ('विंस्टन'); वर लकड़हारा = नया (विंस्टन। लकड़हारा) ({ परिवहन: [नया (winston.transports.Console) (), नया (winston.transports.File) ({फ़ाइल नाम: 'winston.log'})]}); logger.info ('जानकारी लॉग की गई'); लकड़हारा। त्रुटि ('त्रुटि लॉग की गई'); प्रक्रिया। बाहर निकलें (0); // दो लॉग कंसोल के लिए लिखे जाते हैं, लेकिन विंस्टन के लिए नहीं। लॉग फ़ाइल/

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub (https://github.com/flatiron/winston/issues/228) पर देखें।

हम्म। उस स्थिति में, यदि किसी को नोड प्रक्रिया को मारना है, लेकिन उसे मारने से ठीक पहले जानकारी लॉग करने की आवश्यकता है, तो प्रक्रिया को डाल रहा है। एक सेटटाइमआउट () के अंदर पर्याप्त बड़ी समय अवधि के साथ केवल एक चीज यह सुनिश्चित करने के लिए कर सकती है कि विंस्टन वास्तव में लॉग फ़ाइल को संदेश लिखता है?

केवल स्पष्टता के लिए, console.log और मित्र समकालिक हैं ।

@yzapuchlak मैंने वास्तव में परीक्षण नहीं किया है, लेकिन मैं भी यही करता हूं।

@yzapuchlak setTimeout बिना किसी समस्या के _probably_ काम करेगा, लेकिन मुझे लगता है कि इसके बजाय वैकल्पिक कॉलबैक परम का उपयोग करना बुद्धिमानी होगी।

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

@dtex मैंने अभी वैकल्पिक कॉलबैक (जैसा कि निम्नलिखित उदाहरण कोड में देखा गया है) का उपयोग करने का प्रयास किया है, लेकिन इसके परिणामस्वरूप फ़ाइल में लॉग लिखे जा रहे हैं। फ़ाइल वास्तव में इस मामले में बनाई जाती है लेकिन इसमें कोई लॉग नहीं लिखा जाता है।

var winston = require('winston');
var logger = new (winston.Logger)({
  transports: [
    new (winston.transports.Console)(),
    new (winston.transports.File)({ filename: 'winston.log' })
  ]
});

logger.info('winston - info logged');
logger.error('winston - error logged');

logger.info('winston - exiting now', { seriously: true }, function(err, level, msg, meta) {
  console.log('console - CALLING PROCESS EXIT');
  process.exit(0);
});

logger.warn('winston - I probably should only appear in console, not the log file?');

@yzaouchiak जिज्ञासु, क्या वह संस्करण 0.6.2 है?

विंस्टन@0.6.2
├── [email protected]
रंग@0.6.0-1
├── चक्र@१.०.२
आंखें@0.1.8
├── [email protected]
[email protected]
└── स्टैक-ट्रेस@0.0.6

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

मुझे विंस्टन 0.7.2 के साथ एक ही समस्या है।
मैंने बिना किसी सफलता के सेटटाइमआउट और कॉलबैक वर्कअराउंड का परीक्षण किया।

यह वही समस्या है जो #288 और log4js-node समस्या (https://github.com/nomiddlename/log4js-node/issues/148) के समान है। मुझे लगता है कि समस्या यह है कि प्रक्रिया के बाद ईवेंट लूप नहीं चलता है। कॉलबैक समाप्त हो गया है - इसलिए किसी भी लंबित एसिंक कॉल (जैसे फ़ाइल लिखता है) को चलाने का मौका नहीं मिलता है। मुझे बहुत खुशी होगी अगर कोई मुझे गलत साबित कर सकता है, और एक सुधार के साथ आ सकता है।

अगर हम कोई समाधान निकाल सकते हैं तो मैं इसे ठीक करने के लिए समय देने को तैयार हूं। मुख्य मुद्दा यह प्रतीत होता है कि WritableStreams process.exit() या अनचाहे अपवाद पर फ्लशिंग की गारंटी नहीं देता है। क्या किसी वैकल्पिक समाधान की जांच की गई है? ऐसा लगता है कि हम लॉग को मेमोरी में कैश कर सकते हैं जब तक कि राइटेबलस्ट्रीम ड्रेन न हो जाए। फिर यदि कोई process.exit या न आया हुआ अपवाद होता है, तो हम ऐसे किसी भी लॉग को सिंक्रोनाइज़ कर सकते हैं जिसे ड्रेन नहीं किया गया है। यह डुप्लिकेट लॉग उत्पन्न कर सकता है, लेकिन कम से कम लॉगलॉस को रोकेगा। कोई विचार?

https://github.com/nomiddlename/log4js-node/issues/148 . से संबंधित

#288 से संबंधित।

यहां कोई अपडेट? अभी भी मेरे लिए ~ 0.9.0 साथ असफल

हाँ, मैं अभी भी पहले @yzapuchlak द्वारा उल्लिखित

मैं वास्तव में इसे वैसे भी विंस्टन की बग के रूप में नहीं देखता। जब आप अपने कोड में process.exit करते हैं तो

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

तो मैं जो सुझाव दे रहा हूं वह इस मुद्दे को अभ्यस्त फिक्स के साथ बंद कर रहा है। यदि आप किसी लॉग संदेश को मिस नहीं करना चाहते हैं, तो सुनिश्चित करें कि आपने process.exit को कॉल करने से पहले अपने एप्लिकेशन को सही ढंग से साफ और बंद कर दिया है।

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

बात यह है कि लॉग को फ़्लश करने के लिए वर्तमान में प्रतीक्षा करने का कोई तरीका नहीं है (कॉलबैक/वादा/जो कुछ भी)। सिंक लॉगिंग को मजबूर करने से process.on('exit') में लॉग जोड़ना संभव हो जाएगा

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

मैं कोशिश करूँगा, धन्यवाद!

इसके लायक क्या है, आप लगभग setTimeout के उपयोग को प्राप्त कर सकते हैं लेकिन आपको अंतर्निहित _stream को हथियाने की आवश्यकता है:

// log then exit(1)
logger.error("The thing to log", function(err) {
  var numFlushes = 0;
  var numFlushed = 0;
  Object.keys(logger.transports).forEach(function(k) {
    if (logger.transports[k]._stream) {
      numFlushes += 1;
      logger.transports[k]._stream.once("finish", function() {
        numFlushed += 1;
        if (numFlushes === numFlushed) {
          process.exit(1);
        }
      });
      logger.transports[k]._stream.end();
    }
  });
  if (numFlushes === 0) {
    process.exit(1);
  }
});

जैसा कि ऊपर उल्लेख किया गया है, केवल कॉलबैक फ़ंक्शन का उपयोग _not पर्याप्त_ है ताकि इसे फ़ाइल में सही ढंग से फ़्लश किया जा सके। यह मेरे लिए एक बग की तरह लगता है।

ध्यान दें कि मैं वास्तव में finish घटना के लिए सुन रहा हूँ: https://nodejs.org/api/stream.html#stream_event_finish बजाय विंस्टन के flush या closed घटना का उपयोग करने के क्योंकि वह भी इसे सही ढंग से लॉग इन करने के लिए अपर्याप्त है: /

इसको आजमाओ। यह मेरे मामले में बहुत अच्छा काम करता है। process.exit सीधे कॉल करने के बजाय हम लॉग को फ्लश करने के बाद लॉगर को process.exit पर कॉल करने देते हैं।

लकड़हारा.जेएस:

var winston = require('winston');

winston.loggers.add('my-logger', {
    console: {
        level: 'debug',
        colorize: true,
        timestamp: true,
        handleExceptions: true
    },
    file: {
        level: 'info',
        colorize: false,
        timestamp: true,
        filename: 'file.log',
        handleExceptions: true
    }
});

var logger = winston.loggers.get('my-logger');


/* ******* *
 * EXPORTS
 * ******* */

exports.exitAfterFlush = function(code) {
    logger.transports.file.on('flush', function() {
        process.exit(code);
    });
};

exports.info = function() {
    logger.info.apply(this, arguments);
};

exports.warn = function() {
    logger.info.apply(this, arguments);
};

exports.error = function() {
    logger.info.apply(this, arguments);
};

आपके कोड में:

var logger = require('./logger.js');
logger.exitAfterFlush(0);
logger.info('Done!');

NodeJS v4.1.2 और विंस्टन 1.1.0 . पर परीक्षण किया गया

मैं @ da-mkay के समान कुछ उपयोग कर रहा हूं।

function closeAllLoggersAndDisconnect() {
    "use strict";

    let openCount = 0;

    Object.keys(loggerInstance.transports).forEach((key) => {

        let transportInstance = loggerInstance.transports[key];

        if (typeof transportInstance.close === "function") {
            transportInstance.close();
            openCount++;
        }

        transportInstance.on("closed", () => {
            openCount--;
        });

        setInterval(() => {
            if (openCount === 0) {
                if (process.connected) {
                    process.disconnect();
                }
            }
        }, 100);
    });
}

आपके कोड में:

winston.error("Error Occured", err, () => {
    closeAllLoggersAndDisconnect();
});

आदर्श रूप से यह अच्छा होगा यदि मैं close विधि को loggerInstance पर कॉल कर सकता हूं, लेकिन चूंकि यह closed घटना को उत्सर्जित करता है जैसे ही यह close कॉल करना समाप्त करता है

@Kegsay का उपयोग

सफलता के साथ @Kegsay के कदमों का भी उपयोग

अभी भी यह समस्या संस्करण 2.2.0 ।

क्या यह अभी भी लागू नहीं हुआ है? 3 साल से अधिक पुराना। मैं प्रक्रिया से बाहर निकलने का उपयोग नहीं करना चाहता।

मैं समझता हूं कि यह कोई मुद्दा नहीं है, लेकिन फाइलों को सभी लिखने और किसी भी खुली सामग्री को बंद करने के लिए निश्चित रूप से एक फ़ंक्शन होना चाहिए ताकि प्रक्रिया स्पष्ट रूप से कॉल किए बिना स्वयं से बाहर निकल सके। उत्पादन प्रणालियों में ऐसी चीजों का उपयोग करना इतना कठिन है।

npm विंस्टन-लॉग-एंड-एक्जिट स्थापित करें

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

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

दूसरी ओर, वादों को समकालिक रूप से रद्द किया जा सकता है, टाइमआउट को सिंक्रोनाइज़ किया जा सकता है, फ़ाइल और डेटाबेस कनेक्शन को सिंक्रोनाइज़ किया जा सकता है, इसलिए एक बेहतर (अधिक प्रदर्शन करने वाला) समाधान हो सकता है कि उन चीज़ों पर नज़र रखी जाए जिन्हें रद्द करने/साफ़ करने की आवश्यकता है/ बंद करें और उन्हें अपवाद हैंडलर में बंद करें जो कॉल करता है winston.log_and_exit() , या वैकल्पिक कॉलबैक winston.log_and_exit() ।

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

मैं नहीं देखता कि यहां प्रदर्शन का कोई प्रभाव कैसे पड़ता है। प्रक्रिया समाप्त होने वाली है, विंस्टन को केवल अंतिम लॉग लाइनों पर बहीखाता पद्धति करने की आवश्यकता है, जिसके दौरान यह आईएमओ को खुशी से ब्लॉक कर सकता है।

यह देखते हुए कि यह मुद्दा कितना पुराना है, और तथ्य यह है कि इसके लिए एक समाधान है, मैं विंस्टन में इसे जल्द ही संबोधित करने वाले किसी भी व्यक्ति के लिए बिल्कुल सही नहीं हूं।

ऐसा लगता है कि आप और मैं अलग-अलग उद्देश्यों से बात कर रहे हैं (लिख रहे हैं)। ऐसा लगता है कि आप फ़ाइल में अंतिम संदेशों को समकालिक रूप से लिखने में रुचि रखते हैं, जबकि मेरी चिंता यह सुनिश्चित कर रही थी कि जो लॉग फ़ाइल में त्रुटि लिखे जाने से ठीक पहले अतुल्यकालिक रूप से लिखे गए थे।

फ़ाइल में संदेशों को लिखने के लिए जो त्रुटि के ठीक पहले समकालिक रूप से हुआ था, यह आवश्यक होगा कि सभी संदेश समकालिक रूप से लिखे जाएं, और यह प्रदर्शन समस्या है।

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

एक विकल्प जो हर किसी की जरूरतों को पूरा कर सकता है वह है एक कस्टम ट्रांसपोर्ट लिखना जो एसिंक्रोनस रूप से लिखता है, और संदेशों का एक बफर रखता है जो अभी तक लिखित (फ्लश) के रूप में पुष्टि नहीं की गई है, जिसे त्रुटि पर सिंक्रोनाइज़ करने के लिए लिखा जा सकता है (डुप्लिकेट संदेशों के जोखिम पर , इस मामले में कि NodeJS ने पहले ही फ़ाइल में लिखना समाप्त कर दिया है, लेकिन फ़्लश की गई घटना को अभी तक संसाधित नहीं किया गया है ...)

क्या कॉल करने के लिए शटडाउन हुक प्रदान करना वास्तव में मुश्किल है जो लौटने और/या कॉलबैक कॉल करने से पहले सबकुछ फ़्लश होने तक प्रतीक्षा करेगा? यह हर उपयोग के मामले को काफी हद तक हल करेगा।

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

@mscharley इस प्रकार log4js यह करता है - एक log4js.shutdown फ़ंक्शन है जिसे आप कॉलबैक प्रदान कर सकते हैं। यह सुनिश्चित करने के लिए प्रतीक्षा करेगा कि सभी एपेंडर्स (विंस्टन उन्हें ट्रांसपोर्ट कहते हैं, मुझे लगता है) ने कॉलबैक को कॉल करने से पहले लिखना समाप्त कर दिया है। ऐसा लगता है कि मेरे उपयोगकर्ताओं के लिए ठीक काम करता है। इसमें परिशिष्टों के समर्थन की आवश्यकता होती है, जिसमें उन्हें लिखने की आवश्यकता होती है ताकि वे शटडाउन कॉल का जवाब दे सकें।

मैं log4js को बढ़ावा देने की कोशिश नहीं कर रहा हूं या कह रहा हूं कि यह विंस्टन से बेहतर है, वैसे - बस यह इंगित करना कि यह दृष्टिकोण काम कर सकता है। यह सबसे अच्छा तरीका नहीं हो सकता है।

यह इस बारे में है कि winston.log_and_exit() क्या करता है। ध्यान दें कि log4js.shutdown() लिखने योग्य धाराओं के आधार पर परिशिष्टों के मामले में writable.end(complete) पर निर्भर करता है, ( appenders.filter(a => a.shutdown).forEach(a => a.shutdown(complete)); ) जो अभी भी एक एसिंक्रोनस शटडाउन है।

मुझे लगता है कि @mscharley की टिप्पणी के संबंध में, लाभ यह है कि एक fileSync एपेंडर है, जिसके लिए shutdown() के उपयोग की आवश्यकता नहीं है ताकि फ़ाइल में पूर्ण लॉग लिखे जा सकें जब नोड प्रक्रिया बंद...

हां, कुछ स्थितियों में fileSync परिवहन उपयोगी होगा, भले ही यह शुद्ध प्रदर्शन में कमी हो।

@jdthorpe मुझे लगता है कि एक पुस्तकालय रखने के बारे में आपका विचार जो बंद करने से पहले चीजों को साफ-

क्या यह टिकट कम से कम दस्तावेज़ों को बदल सकता है, इसलिए ऐसा नहीं लगता है कि यह वर्तमान में समर्थित है, मैंने इस मुद्दे को डीबग करने में अभी 30 मिनट बिताए हैं, जब आप रेपो में seriously खोजते हैं तो इसका समर्थन किया जाता है, यह केवल समर्थित है README । ऐसा लगता है कि या तो एक असमर्थित सुविधा या बग की तरह लगता है और कामकाज वास्तव में बहुत स्वादिष्ट नहीं हैं।

इसे कब ठीक किया जाएगा? यह अब 3 साल से अस्तित्व में है और यह बहुत महत्वपूर्ण है।

कम से कम हम उस लॉगर में कॉलबैक डालते हैं जो वास्तव में काम करता है।

मैं कहूंगा कि शायद एक नई सुविधा के रूप में सभी के लिए एक सामान्य shutdown() फ़ंक्शन लिखा है, और यह सुविधा बहुत महत्वपूर्ण है।

हाँ यह एक बहुत ही महत्वपूर्ण मुद्दा है imo

इसके लिए +1

सच कहूं, तो मुझे लगता है कि shutdown(callback) जोड़ना उचित लगता है, लेकिन उस चेतावनी के साथ जो ट्रांसपोर्ट को सक्रिय रूप से इसका समर्थन करने की आवश्यकता है। व्यक्तिगत परिवहन अपने अंतर्निहित आउटपुट तंत्र के बारे में "सूचना विशेषज्ञ" हैं; उनके पास सबसे अधिक जानकारी है कि इसे कैसे सफाई से बंद करना चाहिए।

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

तो winston को कार्य करने की आवश्यकता नहीं होनी चाहिए ... लेकिन इसे वास्तव में कार्य को पूरा करने के लिए एक रास्ता प्रदान करने की आवश्यकता है। तब हम सभी भारी भारोत्तोलन करने के लिए परिवहन लेखकों के साथ काम कर सकते हैं।

नीचे दिए गए बिंदु को स्पष्ट करने के लिए कुछ छद्म कोड।

```जेएस
शटडाउन (कॉलबैक) {
वर परिवहन गणना = परिवहन.लंबाई
वर समाप्त = 0;
// प्रत्येक परिवहन के लिए
अगर (परिवहन.शटडाउन) {
परिवहन। शटडाउन (फ़ंक्शन () {
// समाप्त गिनती बढ़ाएँ।
// यदि सब कुछ समाप्त हो गया है, तो मूल कॉलबैक को कॉल करें।
});
} अन्य {
// परिवहन (अभी तक) इसका समर्थन नहीं करता है।
// वेतन वृद्धि समाप्त काउंटर
}
}

https://github.com/ortexx/winston-callback

इसे v3.x में निश्चित देखना पसंद करेंगे।

यहाँ मेरा समाधान है (एक ऐसा वातावरण मानता है जो async / await )

const logTransport = new winston.transports.File({filename: '/log/app.log'})

global.log = winston.createLogger({transports: [logTransport]})

// helper to exit with a given return code, but only after the logger is finished
// this will return a Promise that will never resolve, thus halting execution
log.exit = (exit = 5) => {
  return new Promise(() => {
    logTransport.on('finished', () => process.exit(exit))
  })
}

```जेएस
कॉन्स्ट लॉगट्रांसपोर्ट्स = [नया विंस्टन.ट्रांसपोर्ट्स.फाइल ({फ़ाइल नाम: '/log/app.log'})]

Global.log = विंस्टन.क्रिएटलॉगर ({परिवहन: [लॉगट्रांसपोर्ट]})

// किसी दिए गए रिटर्न कोड के साथ बाहर निकलने के लिए सहायक, लेकिन लकड़हारा समाप्त होने के बाद ही
// यह एक वादा वापस करेगा जो कभी हल नहीं होगा, इस प्रकार निष्पादन को रोक देगा
log.exit = (निकास = 5) => {
नया वादा वापस करें (() => {
वादा.सब(
logTransports.map (परिवहन => नया वादा (संकल्प => परिवहन। पर ('समाप्त', संकल्प)))
)। तब (() => प्रक्रिया। बाहर निकलें (बाहर निकलें))
})
}

</details>
<br>
Then, call with `await` like:

```js
try {
  something()
} catch(e) {   
  //do something with the error
  await log.exit(5) // <--- nothing will happen past this line as the promise will never resolve!
  // <--- process will have exited before it reaches here
  trySomethingElse() // <--- this will never be called, and control wont return to the calling code
}

टूटा हुआ रिकॉर्ड नहीं होना चाहिए, लेकिन विंस्टन-लॉग-एंड-एग्जिट भी इस मुद्दे को हल करता है

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

@mscharley क्या उपरोक्त await समाधान आपके उपयोग के मामले में काम करेगा? शायद log.exit() बजाय एक बेहतर एपीआई await log.finish() होगा जो तब तक इंतजार करेगा जब तक कि सभी ट्रांसपोर्ट्स ने लिखना समाप्त नहीं कर दिया और फिर आपको जो कुछ भी करने दें ( process.exit कॉल करें, लैमडा को कॉल करें done कॉलबैक, आदि)

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

log4js-node ने सभी ट्रांसपोर्टों को फ्लश करने के साथ process.exit() जैसे कॉलबैक लेता है। क्या विंस्टन में ऐसा कुछ जोड़ा जा सकता है?

log4js-नोड यह तब है

कोई अपडेट्स? समस्या बहुत वास्तविक है।

किसी भी लॉगिंग सिस्टम के लिए, कैलकुलस है:

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

संयोग से, @ शुरुआत-फिर से यह log_and_exit() विधि अनिवार्य रूप से log-4js की shutdown() विधि के समान है, अतिरिक्त गारंटी के साथ कि प्रदान किया गया लॉग संदेश लॉग किया जाएगा।

@jdthorpe लेकिन winston-log-and-exit विंस्टन 3 पर आसानी से काम नहीं करेगा

@VRuzhentsov ओह, यह एक समस्या है। उन्हें वास्तव में इसके बारे में कुछ करना चाहिए।

@jdthorpe ने इसे ठीक किया

const transport = new Transport();
const logger = createLogger({
  transports: [
    transport 
  ]
})

logger.finish = (exitCode) => {
  transport.on('finish', () => process.exit(exitCode));
  transport.close();
};

const shutDown = (exitCode) => {
  logger.info('Shutting down');
  logger.finish(exitCode);
};

shutDown(1);

निम्नलिखित मेरे लिए काम करता है:

logger.info('winston - info logged');
logger.error('winston - error logged');
process.nextTick(() => {
    process.exit(0)
})

@ रेडहाट-रैप्टर। यह ज्यादातर समय काम करेगा, लेकिन हर समय काम करने की गारंटी नहीं है। ऐसा होता है कि अगली टिक () को कॉल किए जाने तक आपके बफर साफ़ हो गए थे, लेकिन आपके लॉगर्स जिन कनेक्शनों पर भरोसा करते हैं, उनके आधार पर यह आसानी से खोए हुए संदेशों का परिणाम हो सकता है ...

यह कोड मेरे लिए काम किया:

            logger.error(`No value specified for ${value} variable! Node will exit now...`);
            logger._flush(() => {
                process.exit(1);
            })

क्या यह मूल रूप से v3 में समर्थित नहीं है?

https://github.com/winstonjs/winston/blob/master/README.md#awaiting -logs-to-be-write-in-winston

@danielweck नहीं, यह टूटा हुआ है: #1629 #1504!

6 साल, यह सही है, _महत्वपूर्ण_ के रूप में चिह्नित बग के लिए 6 साल। यह सीमा रेखा प्रभावशाली है।

मैं एक waitForWinston() वादे का उपयोग करता हूं:

const winston = require('winston');

const fileTransport = new winston.transports.File({ name: 'file', filename: FILE_PATH });
const consoleTransport = new winston.transports.Console({ name: 'console', stderrLevels: ['error'] });
const transports = [
    fileTransport,
    consoleTransport
];
winston.configure({
    level: 'verbose',
    transports,
    format: winston.format.cli()
});
winston.log('info', 'TEST MSG');
try {
    await waitForWinston();
} catch (err) {
    console.log(err);
}
process.exit(0);

const waitForWinston = async () => {
    return new Promise(async (resolve, _reject) => {
        for (const transport of transports) {
            try {
                await closeWinstonTransportAndWaitForFinish(transport);
            } catch (err) {
                console.log(err);
            }
        }
        resolve();
    });
};

const closeWinstonTransportAndWaitForFinish = async (transport) => {
    if (!transport.close) {
        // e.g. transport.name === 'console'
        return Promise.resolve();
    }
    // e.g. transport.name === 'file'

    return new Promise(async (resolve, _reject) => {
        transport._doneFinish = false;
        function done() {
            if (transport._doneFinish) {
                return; // avoid resolving twice, for example timeout after successful 'finish' event
            }
            transport._doneFinish = true;
            resolve();
        }
        setTimeout(() => { // TODO: use a cancellable setInterval instead
            done();
        }, 5000); // just in case the 'finish' event never occurs
        const finished = () => {
            done();
        };

/* Update: `stream.end()` does not flush pending writes, so this solution is inadequate.  For some reason, in recent tests `transport.close();` + `transport.once('finish', ...);` works just fine ... not sure why this works now though! (it used to fail!) */

/*
        if (transport._stream) {
            transport._stream.once('finish', finished);
            transport._stream.end();
        }
*/
            transport.once('finish', finished);
            transport.close();
    });  
};

अद्यतन: stream.end() लंबित लेखन फ्लश नहीं करता है, इसलिए यह समाधान अपर्याप्त है। किसी कारण से, हाल के परीक्षणों में transport.close(); + transport.once('finish', ...); ठीक काम करता है ... सुनिश्चित नहीं है कि यह अब क्यों काम करता है! (यह असफल होता था!)

उपरोक्त मेरे कार्य समाधान में, कुंजी का उपयोग करना है:
transport._stream.once('finish', finished); transport._stream.end();
की बजाय:
transport.once('finish', finished); transport.close();
(अतिरिक्त टाइमआउट रणनीति मेरे उपयोग-मामले के लिए विशिष्ट है, और शायद सामान्य मामले में वैकल्पिक/अनावश्यक है)

आसान तरीका:

logger.error(`No value specified for ${missing_vars.join(',')} variable! Node will exit now...`, () => {
            process.exit(1);
        });

@danielweck क्या आप कभी इसका समाधान ढूंढ पाए? हमने हाल ही में विंस्टन 3.x में अपग्रेड किया है लेकिन 2.x पर वापस जाना पड़ सकता है या यहां समाधान के बिना एक अलग लॉगर ढूंढना पड़ सकता है।

@matttowerssonos , IIRC, ये सभी समस्याएं विंस्टन @ 2 से संबंधित हैं

BTW, मुझे Winston@3 पर खोए हुए लॉग के साथ कोई समस्या नहीं दिखाई दे रही है, इसलिए हो सकता है कि आप अपने कॉन्फ़िगरेशन को अपने नए अंक में शामिल करना चाहें।

@cjbarth यह काम नहीं करता है:

  process.on(type as any, (err: ErrorExtended) => {
    const processLogger: Logger = loggers.get('processLogger');

    processLogger.error(errorFormatter(err, type));

    processLogger.on('finish', function () {
      processLogger.end();
      console.log('never reaches here');
      process.exit(1);
    });
  });

processExit('uncaughtException');
// log and exit for unhandledRejection events.
processExit('unhandledRejection');

@stephanoparaskeva अगर मैं गलत नहीं हूं, तो finish ईवेंट को कभी भी processLogger पर सक्रिय नहीं किया जाएगा क्योंकि आप कभी भी processLogger.end() कॉल नहीं करते हैं। यदि आप इसे कॉल करते हैं, तो, जब विंस्टन लॉगिंग पूरी कर लेता है, तो finish ईवेंट सक्रिय हो जाना चाहिए।

मैं भी प्रयोग करेंगे process.disconnect() के बजाय process.exit() , जो नाली के लिए कतार अनुमति देता है। कतार समाप्त होने पर यह स्वचालित रूप से बाहर निकल जाएगा।

@stephanoparaskeva अगर मैं गलत नहीं हूं, तो finish ईवेंट को कभी भी processLogger पर सक्रिय नहीं किया जाएगा क्योंकि आप कभी भी processLogger.end() कॉल नहीं करते हैं। यदि आप इसे कॉल करते हैं, तो, जब विंस्टन लॉगिंग पूरी कर लेता है, तो finish ईवेंट सक्रिय हो जाना चाहिए।

मैं भी प्रयोग करेंगे process.disconnect() के बजाय process.exit() , जो नाली के लिए कतार अनुमति देता है। कतार समाप्त होने पर यह स्वचालित रूप से बाहर निकल जाएगा।

गोचा, तो ऐसा कुछ?

process.on(type as any, (err: ErrorExtended) => {
  const processLogger: Logger = loggers.get('processLogger');

  processLogger.error(errorFormatter(err, type));
  processLogger.end()

  processLogger.on('finish', function () {
    process.disconnect();
  });
});

// log and exit for uncaughtException events.
processExit('uncaughtException');
// log and exit for unhandledRejection events.
processExit('unhandledRejection');

@stephanoparaskeva जो बेहतर दिखता है।

मैं आम तौर पर processLogger.end() कॉल करने से पहले ईवेंट हैंडलर को बाध्य करता हूं, लेकिन इससे कोई फर्क नहीं पड़ता क्योंकि finish ईवेंट केवल ईवेंट लूप चालू होने के बाद ही आग लगनी चाहिए, उस समय तक हैंडलर बाध्य होगा। मुझे लगता है कि उस कोड को लिखना जहां ईवेंट हैंडलर पहले बाध्य है, इसे स्पष्ट करता है।

@cjbarth
ओह, आप इवेंट हैंडलर को किसी चीज़ से कैसे बांधते हैं?
क्या यह होगा:

processLogger.on('finish', () => {
    this.process.disconnect();
  });

@stephanoparaskeva हाँ। फ़ंक्शन को बाइंड करने के लिए यह सही सिंटैक्स है

{
  this.process.disconnect();
}

वस्तु processLogger द्वारा उत्सर्जित finish घटना के लिए।

यह मेरे लिए काम करता है: https://stackoverflow.com/a/59260151

यदि आप process.exit को कॉल नहीं करते हैं, लेकिन सभी कनेक्शनों को बंद करके और इवेंट लूप के समाप्त होने की प्रतीक्षा करके, इसके बजाय एक उचित शटडाउन करते हैं, तो कोई समस्या नहीं है।

इसे बेहतर ढंग से समझने के लिए https://stackoverflow.com/a/37592669 देखें: @deedf किस बात का जिक्र कर रहा है। इस सलाह के बाद, मेरे लिए भी इस समस्या को कम कर दिया।

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

मुझे नहीं पता कि इसे अभी तक विंस्टन द्वारा कैसे हल नहीं किया गया है। मुझे एक समस्या है कि मेरे कोड में केवल पहला लॉगर लॉगस्टैश में लॉग हो जाता है (विंस्टन-इलास्टिक्स खोज का उपयोग करके)। अगर मैं logger.end() का उपयोग करता हूं तो सब कुछ लॉग हो जाता है, लेकिन प्रोग्राम बहुत जल्दी निकल जाता है। उपरोक्त सभी समाधानों का उपयोग करने का प्रयास किया, और कोई भी वास्तव में काम नहीं किया।
मैं वास्तव में असहाय हूँ

मुझे नहीं पता कि इसे अभी तक विंस्टन द्वारा कैसे हल नहीं किया गया है। मुझे एक समस्या है कि मेरे कोड में केवल पहला लॉगर लॉगस्टैश में लॉग हो जाता है (विंस्टन-इलास्टिक्स खोज का उपयोग करके)। अगर मैं logger.end() का उपयोग करता हूं तो सब कुछ लॉग हो जाता है, लेकिन प्रोग्राम बहुत जल्दी निकल जाता है। उपरोक्त सभी समाधानों का उपयोग करने का प्रयास किया, और कोई भी वास्तव में काम नहीं किया।
मैं वास्तव में असहाय हूँ

क्या आपने यह कोशिश की?

मुझे नहीं पता कि लोगों को यह कैसे नहीं मिलता है कि यह "समस्या" "हल" नहीं हुई है क्योंकि कोई भी नहीं है। बाहर निकलें() को कॉल न करके बस उचित कोड लिखें और आप ठीक हो जाएंगे।

मुझे नहीं पता कि लोगों को यह कैसे नहीं मिलता है कि यह "समस्या" "हल" नहीं हुई है क्योंकि कोई भी नहीं है। बाहर निकलें() को कॉल न करके बस उचित कोड लिखें और आप ठीक हो जाएंगे।

तो इस समस्या का हमारा समाधान process.exit() को कॉल नहीं करना है?

मुझे नहीं पता कि लोगों को यह कैसे नहीं मिलता है कि यह "समस्या" "हल" नहीं हुई है क्योंकि कोई भी नहीं है। बाहर निकलें() को कॉल न करके बस उचित कोड लिखें और आप ठीक हो जाएंगे।

तो इस समस्या का हमारा समाधान process.exit() को कॉल नहीं करना है?

हां, नोडज में यह हमेशा एक बुरा विचार है, देखें https://stackoverflow.com/a/37592669

मुझे नहीं पता कि लोगों को यह कैसे नहीं मिलता है कि यह "समस्या" "हल" नहीं हुई है क्योंकि कोई भी नहीं है। बाहर निकलें() को कॉल न करके बस उचित कोड लिखें और आप ठीक हो जाएंगे।

तो इस समस्या का हमारा समाधान process.exit() को कॉल नहीं करना है?

हां, नोडज में यह हमेशा एक बुरा विचार है, देखें https://stackoverflow.com/a/37592669

खैर इसका कारण यह है कि मैं व्यक्तिगत रूप से process.exit का उपयोग कर रहा हूं क्योंकि मैं अपने सभी ट्रांसपोर्टों में लॉग इन करने के लिए uncaughtException और unhandledRejection सुन रहा हूं, फिर आवेदन छोड़ दें। क्या इस मुद्दे को पूरा करने का कोई बेहतर तरीका है?

मुझे नहीं पता कि लोगों को यह कैसे नहीं मिलता है कि यह "समस्या" "हल" नहीं हुई है क्योंकि कोई भी नहीं है। बाहर निकलें() को कॉल न करके बस उचित कोड लिखें और आप ठीक हो जाएंगे।

आपने कहाँ देखा मैंने कहा कि मैंने निकास () का उपयोग किया है?

मुझे नहीं पता कि लोगों को यह कैसे नहीं मिलता है कि यह "समस्या" "हल" नहीं हुई है क्योंकि कोई भी नहीं है। बाहर निकलें() को कॉल न करके बस उचित कोड लिखें और आप ठीक हो जाएंगे।

आपने कहाँ देखा मैंने कहा कि मैंने निकास () का उपयोग किया है?

यह मानने के लिए खेद है कि आपकी पढ़ने और समझने की क्षमता यह समझने के लिए पर्याप्त है कि यह बग किस बारे में है। शीर्षक फिर से जांचें।

मुझे नहीं पता कि लोगों को यह कैसे नहीं मिलता है कि यह "समस्या" "हल" नहीं हुई है क्योंकि कोई भी नहीं है। बाहर निकलें() को कॉल न करके बस उचित कोड लिखें और आप ठीक हो जाएंगे।

आपने कहाँ देखा मैंने कहा कि मैंने निकास () का उपयोग किया है?

यह मानने के लिए खेद है कि आपकी पढ़ने और समझने की क्षमता यह समझने के लिए पर्याप्त है कि यह बग किस बारे में है। शीर्षक फिर से जांचें।

यदि आप किसी ऐसे मुद्दे पर आते हैं जो 8 वर्षों से खुला है और कोई उचित सहायता नहीं देता है, तो आपको बहुत व्यस्त होना चाहिए।

मुझे नहीं पता कि लोगों को यह कैसे नहीं मिलता है कि यह "समस्या" "हल" नहीं हुई है क्योंकि कोई भी नहीं है। बाहर निकलें() को कॉल न करके बस उचित कोड लिखें और आप ठीक हो जाएंगे।

तो इस समस्या का हमारा समाधान process.exit() को कॉल नहीं करना है?

हां, नोडज में यह हमेशा एक बुरा विचार है, देखें https://stackoverflow.com/a/37592669

खैर इसका कारण यह है कि मैं व्यक्तिगत रूप से process.exit का उपयोग कर रहा हूं क्योंकि मैं अपने सभी ट्रांसपोर्टों में लॉग इन करने के लिए uncaughtException और unhandledRejection सुन रहा हूं, फिर आवेदन छोड़ दें। क्या इस मुद्दे को पूरा करने का कोई बेहतर तरीका है?

मैंने थोड़ी देर में विंस्टन का उपयोग नहीं किया है, लेकिन क्या यह वैसे भी लॉग नहीं करेगा? यदि नहीं, तो लॉगिंग करने के बाद त्रुटि को फिर से नहीं फेंकेगा?

मुझे नहीं पता कि लोगों को यह कैसे नहीं मिलता है कि यह "समस्या" "हल" नहीं हुई है क्योंकि कोई भी नहीं है। बाहर निकलें() को कॉल न करके बस उचित कोड लिखें और आप ठीक हो जाएंगे।

आपने कहाँ देखा मैंने कहा कि मैंने निकास () का उपयोग किया है?

यह मानने के लिए खेद है कि आपकी पढ़ने और समझने की क्षमता यह समझने के लिए पर्याप्त है कि यह बग किस बारे में है। शीर्षक फिर से जांचें।

यदि आप किसी ऐसे मुद्दे पर आते हैं जो 8 वर्षों से खुला है और कोई उचित सहायता नहीं देता है, तो आपको बहुत व्यस्त होना चाहिए।

कम से कम मैं एक हकदार बव्वा की तरह रोए बिना अपने मुद्दों को हल कर सकता हूं।