Winston: लॉगिंग विधियां अब कॉलबैक नहीं लेती हैं, कुछ वातावरणों में विश्वसनीय रूप से इसका उपयोग नहीं कर सकती हैं (एडब्ल्यूएस लैम्ब्डा)

हम एक अलग समाधान का उपयोग कर रहे हैं।

इसे कोई मुद्दा नहीं बनाते हैं। इसे लाने के लिए धन्यवाद।

संपादित करें: यह काम नहीं करता

=============
मुझे यकीन नहीं है कि यह सबसे अच्छा तरीका है, और न ही यह सभी मामलों में काम करता है, लेकिन अभी तक हम निम्नलिखित करके इसे संभाल रहे हैं:

मैंने एक wait-for-logger.js फ़ंक्शन इस प्रकार बनाया है:

function waitForLogger(logger) {
  return new Promise((resolve) => {
    logger.on('close', resolve);
    logger.close();
  });
}

module.exports = waitForLogger;

हमारे हैंडलर के अंत में, हम लौटने से पहले फ़ंक्शन आउटपुट की प्रतीक्षा करते हैं:

const logger = require('./logger');
const waitForLogger = require('./wait-for-logger');

async function handler(event, context) {
  // your functionality
  logger.log('info', 'This should make it through all the transports');
  // ...

  await waitForLogger(logger);
}

हम nodejs8.10 लैम्ब्डा रनटाइम का उपयोग कर रहे हैं - यदि आप पुराने रनटाइम का उपयोग कर रहे हैं, तो आप शायद निम्न की तरह कुछ कर सकते हैं:

function handler(event, context, callback) {
  // your functionality
  logger.log('info', 'This should make it through all the transports');
  // ...

   waitForLogger(logger).then(() => callback(null));
}

धन्यवाद @dpraul। हमारा एक ट्रांसपोर्ट बाहरी सेवा में लॉग इन करता है, और इसमें कुछ अतिरिक्त एमएस लग सकते हैं। क्या logger.close() पूरा होने की प्रतीक्षा करेगा?

@natesilva ने इस बारे में कुछ और सोचा

1. winston@3 में Logger और Transport दोनों Node.js स्ट्रीम हैं ।
2. लिखने योग्य स्ट्रीम एक .end विधि और एक 'finish' घटना को उजागर करती हैं।

इसलिए सिद्धांत रूप में यह _चाहिए_ काम करता है, लेकिन मैंने अभी तक इसका परीक्षण नहीं किया है:

const winston = require('winston');
const logger = winston.createLogger({
  transports: [
    new winston.transports.Console()
  ]
});

process.on('exit', function () {
  console.log('Your process is exiting');
});

logger.on('finish', function () {
  console.log('Your logger is done logging');
});

logger.log('info', 'Hello, this is a raw logging event',   { 'foo': 'bar' });
logger.log('info', 'Hello, this is a raw logging event 2', { 'foo': 'bar' });

logger.end();

सत्यापित:

{"foo":"bar","level":"info","message":"Hello, this is a raw logging event"}
{"foo":"bar","level":"info","message":"Hello, this is a raw logging event 2"}
Your logger is done logging
Your process is exiting

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

यदि आपके पास @natesilva समय है तो आप winston का उपयोग करके एंड-टू-एंड AWS लैम्ब्डा उदाहरण में योगदान कर सकते हैं, तो यह बहुत अच्छा होगा।

हम बोलते समय इसकी समीक्षा कर रहे हैं, और मेरा मानना ​​है कि मैंने काम करने के लिए इनमें से किसी भी तरीके को सत्यापित नहीं किया है। मैं शीघ्र ही एक पूर्ण परीक्षण-मामला यहाँ साझा करने का प्रयास करूँगा।

const winston = require('winston');

class CustomTransport extends winston.Transport {
  log({ message }, cb) {
    setTimeout(() => {
      console.log(`custom logger says: ${message}`);
      cb(null);
    }, 3000);
  }
}

const logger = winston.createLogger({
  transports: [
    new winston.transports.Console(),
    new CustomTransport(),
  ],
});

logger.on('finish', () => {
  console.log('done!');
});
logger.log('info', 'here is some content');
logger.end();

अपेक्षित उत्पादन:

{"level":"info","message":"here is some content"}
custom logger says: here is some content
done!

वास्तविक आउटपुट:

{"level":"info","message":"here is some content"}
done!
custom logger says: here is some content

सभी परिवहन समाप्त होने से पहले finish घटना फायरिंग हो रही है। अंत में .on('close', fn) और .close() ईवेंट का उपयोग करते समय वही व्यवहार होता है।

क्षमा करें, मैंने अपनी टिप्पणी हटा दी। इन स्ट्रीम इवेंट के बारे में मेरी समझ सीमित है, लेकिन @dpraul के उदाहरण के अनुसार, मैं देख सकता हूँ कि finish गलत समय पर कैसे सक्रिय हो सकता है।

मैं end , finish , और close घटनाओं के साथ एक ही उदाहरण से गुजरा हूं, और stream.Transform.close() और stream.Transform.end() दोनों का उपयोग कर रहा हूं - सभी के परिणाम समान होते हैं, जहां CustomerTransport से पहले ट्रिगर होने वाली घटनाओं ने इसे callback ।

Transports और Logger बीच ईवेंट कैसे पारित किए जाते हैं, इसमें कुछ समस्या हो सकती है?

भले ही, @natesilva या @indexzero , आप इस मुद्दे को फिर से खोलना चाह सकते हैं।

@dpraul जो प्रशंसनीय लगता है, लेकिन मैं यह नहीं देखता कि वह कहाँ होगा:

1. Transport में winston-transport Node.js के Writeable इंटरफ़ेस को पूरा करने के लिए _write पद्धति को लागू करता है। यह callback प्राप्त करता है
2. Console में परिवहन winston कॉल process.{stderr,stdout}.write और उसके बाद का आह्वान callback । process.stdout और process.stderr लिए Afaik लेखन समकालिक संचालन हैं इसलिए पीठ के दबाव का कोई संभावित जोखिम नहीं होना चाहिए।

स्पष्ट रूप से इस प्रवाह में कुछ छूट रहा है। कुछ Node.js लोगों के साथ चैट करने जा रहे हैं और देखें कि मैं क्या खोद सकता हूं।

मैं अभी भी नहीं जानता कि समस्या का कारण क्या है, लेकिन मुझे एक समाधान मिला जो सभी परिवहनों के समाप्त होने की प्रतीक्षा करता है!

const winston = require('winston');

class CustomTransport extends winston.Transport {
  log({ message }, cb) {
    setTimeout(() => {
      console.log(`custom logger says: ${message}`);
      cb(null);
    }, 3000);
  }
}

const logger = winston.createLogger({
  transports: [
    new winston.transports.Console(),
    new CustomTransport(),
  ],
});

async function waitForLogger(l) {
  const transportsFinished = l.transports.map(t => new Promise(resolve => t.on('finish', resolve)));
  l.end();
  return Promise.all(transportsFinished);
}

logger.log('info', 'here is some content');

waitForLogger(logger).then(() => console.log('all done!'));

आउटपुट:

{"level":"info","message":"here is some content"}
custom logger says: here is some content
all done!

ऐसा लगता है कि logger.end() ट्रांसपोर्टों के लिए ठीक से प्रचारित करता है, लेकिन सभी ट्रांसपोर्टों को निकाल देने से पहले finish घटना को सक्रिय करता है। समाधान यह है कि प्रत्येक Transport पर अपने स्वयं के finish ईवेंट को सक्रिय करने के लिए प्रतीक्षा करें और Logger पर बिल्कुल भी भरोसा न करें।

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

कुछ लोगों से सत्यापन कराने जा रहे हैं।

@mcollina @davidmarkclements & @mafintosh से कुछ इनपुट के लिए धन्यवाद, मैंने सीखा कि pipe शब्दार्थ की मेरी समझ त्रुटिपूर्ण थी।

• 'error' और 'finish' ईवेंट वापस पाइप श्रृंखला के माध्यम से प्रचारित नहीं होते हैं।
• 'error' ईवेंट के कारण पाइप नहीं खुलते हैं।

यह पता लगाने के लिए जा रहे हैं कि या तो इन घटनाओं का प्रचार कैसे करें या Logger पर एक स्पष्ट विधि का खुलासा करें जो उस तकनीक को लागू करता है जिसका आप अभी उपयोग कर रहे हैं @dpraul (शायद एंड-ऑफ-स्ट्रीम का उपयोग कर)।

@natesilva इस मुद्दे को तब तक खुला छोड़ने जा रहा है जब तक कि स्पष्ट सुधार न हो, लेकिन इस बीच आप उपरोक्त तकनीक का उपयोग करने में सक्षम होना चाहिए:

• सभी परिवहनों पर 'finish' ईवेंट सुनें
• logger.end() कॉल करें
• जब सभी 'finish' ईवेंट उत्सर्जित हो गए हैं तो आप लॉगिंग कर चुके हैं।

महत्वपूर्ण मॉड्यूल जो उपयोगी हो सकते हैं: पंप और एंड-ऑफ-स्ट्रीम।

@mcollina सैद्धांतिक रूप से एक Node.js स्ट्रीम परिप्रेक्ष्य से हमें _final को लकड़हारे पर लागू करने में सक्षम होना चाहिए ताकि finish ईवेंट को बाद में उत्सर्जित किया जा सके, है ना?

@indexzero हाँ, यह सही होगा।

कृपया मुझे बताएं, विंस्टन @ 3 में मैं संस्करण 2 की तरह कॉलबैक का उपयोग नहीं कर सकता?
(दस्तावेज़ीकरण में कोई जवाब नहीं है)

// ... some check the connection to db ... and if fail:
logger.error('message',  function() {
  process.exit(1);
});

और यदि कॉलबैक का उपयोग नहीं करते हैं तो मेरा ऐप संदेश लॉग होने की तुलना में तेज़ी से बंद हो जाता है =(

@TuxGit FYI करें इसे UPGRADE-3.0 में प्रलेखित किया गया है (देखें: पीआर कोड )

@natesilva @dpraul PR अब इसे संबोधित करने के लिए खुला है: https://github.com/winstonjs/winston/pull/1346

मुझे विश्वास है कि यह अभी भी टूटा हुआ है। हालांकि finish घटना अब सही ढंग से प्रचारित हो रही है और प्रतीक्षा की जा रही है, कम से कम File परिवहन में, अंतर्निहित WriteableStream ने अभी तक डिस्क पर अपने लेखन को फ्लश करना समाप्त नहीं किया है।

मेरा मानना ​​​​है कि PassthroughStream के बजाय इसकी finish घटना उत्सर्जित हो रही है, यही कारण है कि यह लिखने का इंतजार नहीं कर रहा है।

कोई बात नहीं - PassthruStream ठीक है, लेकिन यह finish घटना को सुनकर काम नहीं कर रहा है।

मैं पुष्टि कर सकता है कि अप करने के लिए तारों end-of-stream और उस का उपयोग कर को सुनने के लिए transport._stream वास्तव में कार्य करता है।

इस पर किसी भी अद्यतन ? मैं कोशिश कर रहा हूँ logger.on('finish', () => process.exit(0)) लेकिन यह बाहर निकलने के लिए प्रतीत नहीं होता। यह टाइमआउट समाप्त होने के बाद ही मौजूद है

कंसोल ट्रांसपोर्ट का उपयोग करते समय मुझे एक ही समस्या हो रही है (फ़ाइल को ईमानदार होने की कोशिश नहीं की है)। ऐसा लगता है कि Logger stream-readable मॉड्यूल से stream.Transform Logger बढ़ाता है और _final विधि को _stream_transform में कॉल नहीं किया जा रहा है, केवल _stream_writable । मैं वास्तव में इस पर ध्यान नहीं देना चाहता था क्योंकि यह मेरा पहली बार है कि मैं इनमें से किसी भी मॉड्यूल का उपयोग कर रहा हूं और अगर मैंने कुछ गलत समझा तो मैं क्षमा चाहता हूं।

../lib/winston $ grep -n _final *.js
logger.js:249:  _final(callback) {

.../readable-stream/lib $ grep -n _final *.js
_stream_writable.js:130:  // if _final has been called
_stream_writable.js:276:    if (typeof options.final === 'function') this._final = options.final;
_stream_writable.js:601:  stream._final(function (err) {
_stream_writable.js:613:    if (typeof stream._final === 'function') {

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

const Transport = require('winston-transport');

class YourCustomTransport extends Transport {
  log(info, callback) {
    setImmediate(() => {
      this.emit('logged', info);
    });
    if (info.level === 'error') {
      console.log('DO WHATEVER YOU WANT HERE.....', info.message);
    }
    callback();
  }
}

module.exports = YourCustomTransport;

और जिस फ़ाइल में आप winton.createLogger(...) का उपयोग करके अपना कस्टम विंस्टन लकड़हारा बनाते हैं, उसमें अपने CustomTransport को "transports" विकल्प की सरणी में config में शामिल करें।

transports: [
        new winston.transports.Console({ silent: isTestEnvironment }),
        new CustomTransport(),
      ],

हैलो, मैंने नीचे अनुशंसित कोड का उपयोग किया है, लेकिन यह प्रक्रिया को बंद करने से पहले फाइलों को लिखना समाप्त नहीं करता है। मुझे कंसोल को लिखी गई त्रुटियां दिखाई देती हैं। अगर मैं process.exit को कॉल नहीं करता, तो फ़ाइलें सही ढंग से लिखती हैं। मैं देख रहा हूं कि यह मुद्दा बंद हो गया है, लेकिन इसका समाधान हो गया है?

logger.log ('जानकारी', 'कुछ संदेश');
logger.on('finish', () => process.exit ());
लकड़हारा.अंत ();

क्या किसी के पास यह सही ढंग से काम कर रहा है? कोई विचार?

@tsaockham
मेरे पास समाधान है :)

function waitForLogger() {
    return new Promise(resolve => setTimeout(resolve, 2500));
}

समाधान खोजने के 2 घंटे के बाद मैंने इसे कार्यान्वित किया, यहां तक ​​​​कि @dpraul द्वारा प्रतीक्षा करने के लिए फ़ंक्शन भी काम नहीं किया, मैं कर चुका हूं।

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

लैम्ब्डा लैम्ब्डा एक्ज़ीक्यूशन कॉन्टेक्स्ट के तहत नोड चलाता है। प्रासंगिक जानकारी जा रही है:

लैम्ब्डा फ़ंक्शन निष्पादित होने के बाद, एडब्ल्यूएस लैम्ब्डा एक और लैम्ब्डा फ़ंक्शन आमंत्रण की प्रत्याशा में कुछ समय के लिए निष्पादन संदर्भ बनाए रखता है।

तथा

• आपके लैम्ब्डा फ़ंक्शन कोड में कोई भी घोषणा (हैंडलर कोड के बाहर, प्रोग्रामिंग मॉडल देखें) आरंभिक बनी रहती है, जब फ़ंक्शन को फिर से लागू किया जाता है तो अतिरिक्त अनुकूलन प्रदान करता है।

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

अब आइए विंस्टन की प्रतीक्षा के लिए सुझाए गए समाधान को देखें - UPGRADE-3.0.md से अनुकूलित, यह मानते हुए कि हम लैम्ब्डा में चल रहे हैं:

async function lambdaHandler(event, context) {
  const logger = winston.createLogger({
    transports: [
      new winston.transports.Console(),
      new CustomAsyncTransport(),
    ],
  });
  logger.log('info', 'some message');
  logger.on('finish', () => process.exit());
  logger.end();
}

समस्या का पता लगाएं? logger हैंडलर फ़ंक्शन के संदर्भ में logger.end() को सक्रिय करता है, लेकिन logger.on('finish') द्वारा फ़ायर किया गया फ़ंक्शन हैंडलर संदर्भ के बाहर चलता है। CustomAsyncTransport से जुड़ी कोई भी एसिंक प्रक्रिया finish घटना को फायरिंग से रोक देगी, जिससे यह संभावना है कि उस घटना के शुरू होने से पहले निष्पादन संदर्भ फ्रीज हो जाए।

इसे हल करने के लिए, lambdaHandler को हल करने से पहले लकड़हारे के बाहर निकलने की प्रतीक्षा करनी चाहिए:

async function lambdaHandler(event, context) {
  const logger = winston.createLogger({
    transports: [
      new winston.transports.Console(),
      new CustomAsyncTransport(),
    ],
  });
  const loggerFinished = new Promise(resolve => logger.on('finish', resolve));
  logger.log('info', 'some message');
  logger.end();
  await loggerFinished;
}

चूँकि lambdaHandler तब तक बाहर नहीं निकलता जब तक logger finish ईवेंट को सक्रिय नहीं कर देता, हमारे CustomAsyncTransport को हमारे लैम्ब्डा हैंडलर से पहले बंद कर देना चाहिए, उन प्रक्रियाओं को फ़्रीज़ होने से बचाना (यह मानकर finish ईवेंट @indexzero द्वारा सही ढंग से कार्यान्वित किया गया है)।

इसे मेरे द्वारा पहले साझा किए गए कोड के समान कुछ के लिए सामान्यीकृत किया जा सकता है:

async function waitForLogger(logger) {
  const loggerDone = new Promise(resolve => logger.on('finish', resolve));
  // alternatively, use end-of-stream https://www.npmjs.com/package/end-of-stream
  // although I haven't tested this
  // const loggerDone = new Promise(resolve => eos(logger, resolve));
  logger.end();
  return loggerDone;
}

async function lambdaHandler(event, context) {
  const logger = winston.createLogger({
    transports: [
      new winston.transports.Console(),
      new CustomAsyncTransport(),
    ],
  });
  logger.log('info', 'some message');
  await waitForLogger(logger);
}

उम्मीद है कि यह कुछ लोगों की मदद करता है।

मुझे लगता है कि यह डिफ़ॉल्ट लॉगर के लिए काम नहीं करता है?

winston.on() एक फ़ंक्शन नहीं है।

@dpraul समाधान ने मेरे लिए काम किया।

इसे थोड़ा सा अनुकूलित किया:

  async close() {
    return new Promise((resolve, reject) => {
      logger.on('close', () => {
        return resolve()
      })
      logger.on('error', err => {
        return reject(err)
      })
      logger.close()
    })
  }

बस ध्यान दें, जब आप अपना logger बनाते हैं तो उसी समय अपने त्रुटि हैंडलर को सेट करना अच्छा अभ्यास है। त्रुटियों को किसी भी समय सक्रिय किया जा सकता है - यदि आप लकड़हारे को बंद करते समय केवल उन्हें सुनते हैं, तो आप उन्हें याद करने की संभावना रखते हैं।

मैं sqlTransport मॉड्यूल के साथ mariaDB में Nodejs8 लॉगिंग के तहत विंस्टन 3 का उपयोग करना चाहता हूं। इसके लिए, मैंने डॉक्स/transports.md के अनुसार Winston3 के लिए sqlTransport को अनुकूलित किया।
विंस्टन 3 ने कार्यक्रम को अंत में लटका दिया।
मैंने इस मुद्दे से विभिन्न प्रस्तावों के साथ प्रयोग किया और निम्नलिखित निष्कर्ष पर पहुंचा:
sqlTransport मॉड्यूल में एक करीबी () विधि लागू होनी चाहिए जो मॉड्यूल (यानी क्लाइंट के अंदर) को सही ढंग से बंद कर दे।
नोट: अंत () विधि को लागू न करें! - मुझे सच में पता नहीं क्यों।
अब, logger.end() प्रोग्राम को सही ढंग से बंद करने के लिए पर्याप्त है।
Logger.close (), जो लकड़हारे को तत्काल निरस्त करने और डेटा हानि का कारण बनता है।

यदि प्रोग्राम के अंत में एक त्रुटि हैंडलर की आवश्यकता होती है तो आप इसका उपयोग कर सकते हैं

फ़ंक्शन प्रतीक्षाफॉरलॉगर (myLogger) {
कॉन्स्ट लॉगरडोन = नया वादा ((समाधान, अस्वीकार) => {
myLogger.on('finish', () => {रिटर्न रिजॉल्यूशन ()})
myLogger.on ('त्रुटि', त्रुटि => {वापसी अस्वीकार (गलती)})
})
myLogger.end ();
लकड़हारा लौटा;
}
तथा
WaitForLogger (लॉगर)। तब (() => {कंसोल। लॉग ('सब किया!')})। पकड़ें ((गलती) => {कंसोल। त्रुटि (गलती)});

मैं अभी भी यह काम नहीं कर सकता। मैं विंस्टन 3.1.0 का उपयोग कर रहा हूं और यह सुस्त परिवहन विंस्टन-स्लैक-वेबहुक-ट्रांसपोर्ट जो एक http अनुरोध करता है। यह त्रुटि प्राप्त करना शुरू किया:

Error: write after end
at writeAfterEnd (/var/task/node_modules/winston/node_modules/readable-stream/lib/_stream_writable.js:257:12)
at DerivedLogger.Writable.write (/var/task/node_modules/winston/node_modules/readable-stream/lib/_stream_writable.js:301:21)
at DerivedLogger.(anonymous function) [as error] (/var/task/node_modules/winston/lib/winston/create-logger.js:81:14)
at errorHandler (/var/task/error/error-handler.js:27:36)
at Layer.handle_error (/var/task/node_modules/express/lib/router/layer.js:71:5)
at trim_prefix (/var/task/node_modules/express/lib/router/index.js:315:13)
at /var/task/node_modules/express/lib/router/index.js:284:7
at Function.process_params (/var/task/node_modules/express/lib/router/index.js:335:12)
at Immediate.next (/var/task/node_modules/express/lib/router/index.js:275:10)
at Immediate._onImmediate (/var/task/node_modules/express/lib/router/index.js:635:15)

संपादित करें:
मैंने अब देखा है कि मुझे हैंडलर के अंदर लॉगर बनाना होगा, अगर मैं नहीं करता, तो लैम्ब्डा संदर्भ का पुन: उपयोग कर सकता है और "समाप्त" लॉगर इंस्टेंस का उपयोग करने का प्रयास कर सकता है।

मुझे @iudelsmann जैसी ही त्रुटि मिल रही है, क्या यह जांचना संभव है कि लकड़हारा पहले से बंद है या नहीं?

एडब्ल्यूएस एपीआई गेटवे के साथ, हम 1-2 संदेशों को लॉग करने में सक्षम हैं लेकिन logger.end() के बाद; यह अभी भी उसी लकड़हारे का उपयोग करने का प्रयास कर रहा है और हम प्राप्त कर रहे हैं
UnhandledPromiseRejectionWarning: Error: write after end at writeAfterEnd (/var/task/node_modules/winston/node_modules/readable-stream/lib/_stream_writable.js:257:12) at DerivedLogger.Writable.write (/var/task/node_modules/winston/node_modules/readable-stream/lib/_stream_writable.js:301:21) at DerivedLogger.log (/var/task/node_modules/winston/lib/winston/logger.js:223:12)

हम विंस्टन-सिसलॉग के साथ पेपरट्रेल लॉगिंग का उपयोग कर रहे हैं।

यहाँ कोड है।

`कॉन्स्ट विंस्टन = आवश्यकता ('विंस्टन')
आवश्यकता है ('विंस्टन-सिसलॉग')
कॉन्स्ट होस्टनाम = आवश्यकता ("ओएस")। होस्टनाम ()

स्थिरांक विकल्प = {
होस्ट: PAPERTRAIL_URL,
पोर्ट: PAPERTRAIL_PORT,
ऐप_नाम: PAPERTRAIL_LOG_CHANNEL,
लोकलहोस्ट: होस्टनाम
}

कॉन्स्ट पीटीट्रांसपोर्ट = नया विंस्टन.ट्रांसपोर्ट। सिस्लॉग (विकल्प)
कॉन्स्ट लॉगर = विंस्टन। क्रिएटलॉगर ({
परिवहन: [पीटीट्रांसपोर्ट],
प्रारूप: विंस्टन.format.combine(
विंस्टन। प्रारूप। रंग ({
सभी सच
}),
विंस्टन। प्रारूप। सरल ()
)
})`

@hdpa ऐसा शायद इसलिए है क्योंकि इसे बंद करने के बाद आपके फ़ंक्शन का पुन: उपयोग किया जाता है, हमारा वर्तमान समाधान यह है:

// logger.js
let logger;

const recreateLogger = () => {
  logger = winston.createLogger({
  ....
};

const getLogger = () => {
  if (logger && !logger.writable) {
    recreateLogger();
  }
  return logger;
}

const closeLogger = async () => {
  const loggerClosed = new Promise(resolve => logger.on('finish', resolve));
  // https://github.com/winstonjs/winston/issues/1250
  logger.end();
  return loggerClosed;
}

फिर हमारे फ़ंक्शन में हम लॉगर प्राप्त करने के लिए केवल getLogger() पर कॉल करते हैं जो बंद होने पर स्वचालित रूप से इसे फिर से खोल देता है और फ़ंक्शन के अंत में हम closeLogger() का उपयोग यह सुनिश्चित करने के लिए करते हैं कि यह क्लाउडवॉच के सभी लॉग को फ्लश करता है

उपरोक्त परिवर्तनों को लागू किया लेकिन फिर भी वही समस्या हो रही है। मैंने कंसोल में लॉगर ऑब्जेक्ट मुद्रित किया है। नीचे पहले और दूसरे अनुरोधों की प्रतिक्रिया है,

DerivedLogger { _readableState: ReadableState { objectMode: true, highWaterMark: 16, buffer: BufferList { head: null, tail: null, length: 0 }, length: 0, pipes: Syslog { _writableState: [Object], writable: true, domain: null, _events: [Object], _eventsCount: 6 

DerivedLogger { _readableState: ReadableState { objectMode: true, highWaterMark: 16, buffer: BufferList { head: null, tail: null, length: 0 }, length: 0, pipes: null, pipesCount: 0, flowing: false, ended: true, endEmitted: false, reading: false, sync: false, needReadable: 

त्रुटि: लिखने के बाद अंत में लिखें आफ्टरएंड (/var/task/node_modules/winston/node_modules/readable-stream/lib/_stream_writable.js:257:12) पर DerivedLogger.Writable.write (/var/task/node_modules/winston/node_modules) /readable-stream/lib/_stream_writable.js:301:21) DerivedLogger पर। (अनाम फ़ंक्शन) [त्रुटि के रूप में] (/var/task/node_mod)


ऐसा लगता है कि Syslog ट्रांसपोर्ट को एंड मेथड के बाद हटाया जा रहा है और यहीं पर हमें एरर मिल रहा है।

मेरी पोस्ट को भूल जाओ, ऐसा लगता है कि पहले अनुरोध पर यह काम करता है, दूसरे पर कुछ बस टाइमआउट 😕 इसे बंद करने के बजाय इसे फ्लश करने के लिए बस इंतजार करना अच्छा होगा

ओह, ऊपर की समस्या यह है कि मैं पहले से बंद लकड़हारे को बंद करने का प्रयास करता हूं ताकि वादा कभी हल न हो, यह इसे ठीक करता है

const closeLogger = async () => {
  if (logger && !logger.writable) {
    // If it's already closed don't try to close it again
    return Promise.resolve();
  }
  const loggerClosed = new Promise(resolve => logger.on('finish', resolve));
  // https://github.com/winstonjs/winston/issues/1250
  logger.end();
  return loggerClosed;
}

अंक #1081 इस धागे को संदर्भित करता है, लेकिन लकड़हारा परिवहन का उपयोग करके अनुरोध आईडी को अलग करने वाले क्लाउडवॉच लॉग का वास्तविक समाधान नहीं है। जिस तरह से मैं अनुरोध आईडी को शामिल करने में सक्षम था, वह लैम्ब्डा के context ऑब्जेक्ट का उपयोग करके नीचे दिया गया है -

createLogger({
    defaultMeta: { service: process.env.AWS_LAMBDA_FUNCTION_NAME,
                    requestID: context.awsRequestId
                   },
    transports: [
        new transports.Console({
            level: 'debug',
            format: format.combine(
                format.timestamp({
                    format: 'YYYY-MM-DD HH:mm:ss'
                  }),
                format.errors({ stack: true }),
                format.splat(),
                format.json()
            )
        })
    ]
});

हालाँकि, यह विधि काम नहीं करती है यदि आपका Logger.js आपके लैम्ब्डा हैंडलर के बाहर होता है उदाहरण के लिए लैम्ब्डा लेयर में। जाहिर है, संदर्भ आयात से सुलभ नहीं है, इसलिए यदि आपके पास अपनी लॉगर परिभाषा एक परत में शामिल है और आप इसे अपने लैम्ब्डा में आयात करते हैं तो आपको defaultMeta को logger इंजेक्ट करना होगा। हैंडलर फ़ंक्शन के अंदर

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

const logger = require('./opt/nodejs/Logger'); //import from Lambda Layer

exports.handler = async (event, context) => {
    //inject defaultMeta
    logger.log.defaultMeta =  { service: process.env.AWS_LAMBDA_FUNCTION_NAME,
                            requestID: context.awsRequestId };
    logger.log.info(`This is just an info message`);
    logger.log.error("This is an error message");
    await logger.waitForLogger(logger.log);
    return event;
};

logger.end() केवल पहले फ़ंक्शन कॉल के लिए काम करता है। दूसरी कॉल त्रुटि की ओर ले जाती है:

{
    "errorType": "Error",
    "errorMessage": "write after end",
    "code": "ERR_STREAM_WRITE_AFTER_END",
    "stack": [
        "Error: write after end",
        "    at writeAfterEnd (/var/task/node_modules/readable-stream/lib/_stream_writable.js:257:12)",
        "    at DerivedLogger.Writable.write (/var/task/node_modules/readable-stream/lib/_stream_writable.js:301:21)",
        "    at DerivedLogger.(anonymous function) [as info] (/var/task/node_modules/winston/lib/winston/create-logger.js:81:14)",
        "    at Runtime.handler (/var/task/lambda_logger.js:65:12)",
        "    at Runtime.handleOnce (/var/runtime/Runtime.js:66:25)"
    ]
}

मैं लैम्ब्डा हैंडलर के लिए डेकोरेटर के रूप में winston उपयोग करता हूं:

// lambda_logger.js
const winston = require('winston')
const WinstonCloudWatch = require('winston-cloudwatch')
const { format } = winston

async function closeLogger(logger) {
  const transportsFinished = logger.transports.map(
    t => new Promise(resolve => t.on('finish', resolve))
  )
  logger.end()
  return Promise.all(transportsFinished)
}

const decorator = (wrapped, loggerName = null) => {
  return async (event, context, callback) => {
    const LAMBDA_LOGGER_NAME =
      loggerName || `${process.env.AWS_LAMBDA_FUNCTION_NAME}-lambda-logger`

    winston.loggers.add(LAMBDA_LOGGER_NAME, {
      format: format.combine(
        format.timestamp({ format: 'DD-MM-YYYY HH:mm:ss' }),
        format.errors(),
        format.label({
          label: `${process.env.AWS_LAMBDA_FUNCTION_NAME}:${process.env.AWS_LAMBDA_FUNCTION_VERSION}`,
        }),
        format.splat(),
        format.json()
      ),
      transports: [
        new WinstonCloudWatch({
          logGroupName: process.env.AWS_LAMBDA_LOG_GROUP_NAME,
          logStreamName: process.env.AWS_LAMBDA_LOG_STREAM_NAME,
          awsRegion: process.env.AWS_REGION,
          jsonMessage: true,
          retentionInDays: 3,
        }),
      ],
      defaultMeta: { context, logger_name: LAMBDA_LOGGER_NAME },
    })
    const logger = winston.loggers.get(LAMBDA_LOGGER_NAME)

    logger.info({ env: process.env, event })
    let res

    try {
      res = await wrapped(event, {
        context,
        callback,
        loggerName: LAMBDA_LOGGER_NAME,
      })
      logger.debug('RES:', res)
    } catch (e) {
      console.error(e)
      throw e
    }

    await closeLogger(logger)

    return res
  }
}

module.exports = decorator

// handler.js
const winston = require('winston')
const loggingDecorator = require('./lambda_logger')

const hello = async (event, opts) => {
  const { loggerName } = opts
  const logger = winston.loggers.get(loggerName)

  logger.warn({ logger })

  const res = {
    statusCode: 200,
    body: JSON.stringify({
      message: 'We use Winston logger as a decorator for lambda handdler!!'
    }),
  }

  return res
}

module.exports.hello = loggingDecorator(hello)

क्या इसे ठीक करने का कोइ उपाय है?

मुझे लगता है कि इस मुद्दे को पहली प्राथमिकता में रखा जाना चाहिए।
कोड के साथ प्रक्रिया के लिए जैसे:

process.on('uncaughtException', err => {
    logger.error(err, () => {
        process.exit(1);
    });
});

यह प्रक्रिया को हमेशा के लिए लटका देगा और इनायत से पुनरारंभ करने में असमर्थ होगा।

क्या यह समस्या ठीक हो जाएगी या यह बंद ही रहेगी?

@dpraul का समाधान यहाँ (https://github.com/winstonjs/winston/issues/1250#issuecomment-452128291) ने समस्या और समाधान को बहुत अच्छी तरह समझाया। इसने मेरे लिए AWS लैम्ब्डा में काम किया।

एक नोट जो उसने पहले थ्रेड में कहा था कि मैं फिर से दोहराऊंगा। लैम्ब्डा हैंडलर की शुरुआत में आपको अपना लॉगर और ट्रांसपोर्ट ऑब्जेक्ट बनाना होगा। यदि आप उनका पुन: उपयोग करने का प्रयास करते हैं तो आपको त्रुटियां मिलेंगी क्योंकि लैम्ब्डा निष्पादन वातावरण जमे हुए होने पर परिवहन स्ट्रीम बंद हो जाएगी।

एक आसान तरीका मैं वास्तव में खुद को पसंद करता हूं:

function noop() {}

class AsyncTransport extends Transport {
  constructor(opts) {
    super(opts)
    this.callsInProgress = new Map()
    this.index = 0
  }

  async finish() {
    return Promise.all(this.callsInProgress.values())
  }

  log(info) {
    const promise = someAsyncFn(info)
    const i = this.index++
    this.callsInProgress.set(
      i,
      new Promise(resolve => {
        promise.then(resolve)
        setTimeout(resolve, 3000)
      }).then(() => {
        this.callsInProgress.delete(i)
      }),
    )
  }
}

const asyncTransport = new AsyncTransport({ level: 'info' })

const logger = createLogger({
  transports: [
    asyncTransport,
  ],
})
logger.flush= async () => asyncTransport.flush()

module.exports = logger

फिर अपने लैम्ब्डा में आप फिर से कर सकते हैं:

exports.handler = async function() {
  logger.info('I will be awaited at the end!')
  await logger.flush()
}

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

विंस्टनक्लाउडवॉच परिवहन के लिए एक पुन: प्रयोज्य फ्लश विकल्प है: kthxbye। अधिक जानकारी के लिए kthxbye खोजें।

यदि आप एक सामान्य प्रक्रिया लिखना चाहते हैं। पर ('बाहर निकलें' हैंडलर जो विंस्टन लॉगर को बंद कर देता है, तो आपको यहां क्या करना है।

// Send kthxbye to WinstonCloudWatch transports
if (logger.writable) {
  await new Promise(resolve => {
    logger.on('error', resolve).on('close', resolve).on('finish',
      () => logger.close()).end();
  });
}
// Send kthxbye to WinstonCloudWatch transports again

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

इसलिए, विंस्टन 3 में अभी भी फ्लश ऑपरेशन नहीं है जो सभी ट्रांसपोर्ट के साथ काम करता है।