Winston: process.exit (0) 호출시 파일에 로깅이 실패합니다.

노드에서 console. * 메소드는 비동기를 작성하고 파일 전송은 비동기입니다. 노드가 데이터를 쓰기 전에 프로세스를 닫습니다.

2013 년 3 월 25 일 월요일 19:45에 Yuri Zapuchlak은 다음과 같이 썼습니다.

파일에 기록하도록 winston을 구성하고 코드에서 process.exit (0)을 호출하면 winston은 로그 파일을 만들고 파일에 로그 메시지를 추가하지 않습니다.
완벽한 세상에서 winston은이 엣지 케이스를 기꺼이 처리하고 파일에 쓸 수 있지만, 수동으로 파일에 플러시를 강제하기 위해 로거 인스턴스에서 플러시를 호출 할 수도 있습니다.
현재 수동으로 '플러시'할 수있는 방법이있을 수 있지만 문서화되지 않았으며 실제로 로그를 생성하는 방식으로 로거 인스턴스 또는 내부 스트림을 수동으로 닫거나 종료 / 파괴하는 데 운이 없었습니다. 파일에 기록되고 있습니다 ..
var winston = require ( 'winston'); var logger = new (winston.Logger) ({transports : [new (winston.transports.Console) (), new (winston.transports.File) ({filename : 'winston.log'})]}); logger.info ( '정보 기록됨'); logger.error ( '오류 기록됨'); process.exit (0); // 두 로그는 콘솔에 기록되지만 winston.log 파일에는 기록되지 않습니다.

—
이 이메일에 직접 회신하거나 GitHub (https://github.com/flatiron/winston/issues/228)에서 확인하세요.

흠. 이 경우 노드 프로세스를 죽여야하지만 죽이기 직전에 정보를 기록해야하는 경우, 충분히 긴 시간을 가진 setTimeout () 안에 process.exit ()를 넣어야합니다. winston이 실제로 로그 파일에 메시지를 씁니까?

명확성을 위해 console.log 및 친구 는 동기식 입니다.

@yzapuchlak 나는 실제로 테스트하지 않았지만 그게 나도하는 일입니다.

@yzapuchlak setTimeout은 문제없이 _probably_ 작동하지만, 대신 선택적 콜백 매개 변수를 사용하는 것이 현명하다고 생각합니다.

2000 또는 5000의 setTimeout은 간단한 테스트 스크립트에서 작동하지만 실제 코드에서 사용하려고 할 때는 작동하지 않습니다. 따라서 잠재적 인 수정이 얼마나 신뢰할 수 있는지 모르겠습니다. 선택적 콜백 프런트에 운이 없으면 나중에 그 문제를 파헤칠 것입니다.

@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 Curious, 버전 0.6.2입니까?

└─┬ [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected]

지금 같은 문제가 발생하면 프로세스를 종료하고 로그 파일에 메모를 작성해야합니다. 메시지가 작성된 후에 만 ​​프로세스를 종료하는 데 사용할 수있는 콜백 옵션이 있으면 좋을 것입니다. 아니면 이미 존재합니까?

Winston 0.7.2에서 동일한 문제가 발생합니다.
성공하지 않고 setTimeout 및 콜백 해결 방법을 테스트했습니다.

이것은 # 288 및 log4js-node 문제 (https://github.com/nomiddlename/log4js-node/issues/148)와 동일한 문제입니다. 문제는 process.exit 콜백이 완료되면 이벤트 루프가 실행되지 않는다는 것입니다. 따라서 보류중인 비동기 호출 (예 : 파일 쓰기)이 실행될 기회를 얻지 못합니다. 누군가가 나를 틀렸다는 것을 증명하고 해결책을 제시 할 수 있다면 매우 기쁠 것입니다.

해결책을 찾을 수 있다면이 문제를 해결하는 데 시간을 할애하겠습니다. 주요 문제는 WritableStreams가 process.exit () 또는 처리되지 않은 예외에 대한 플러시를 보장하지 않는다는 것입니다. 대체 솔루션을 조사 했습니까? WritableStream이 소모 될 때까지 로그를 메모리에 캐시 할 수있는 것 같습니다. 그런 다음 process.exit 또는 포착되지 않은 예외가 발생하면 드레인되지 않은 로그를 동 기적으로 작성할 수 있습니다. 이로 인해 중복 로그가 생성 될 수 있지만 적어도 로그 손실은 방지됩니다. 이견있는 사람?

https://github.com/nomiddlename/log4js-node/issues/148 관련

# 288과 관련이 있습니다.

여기에 업데이트가 있습니까? ~ 0.9.0 여전히 실패

예, 이전에 @yzapuchlak에서 언급 한 setTimeout () 해킹을 사용하고 있습니다.

어쨌든 나는 이것을 윈스턴의 버그로 보지 않는다. 때 당신에게 process.exit 당신이 아직 완전히 처리에서 실행중인 모든 것을 죽일하기로 결정을 한 코드에서. 여전히 실행중인 HTTP 요청이있는 경우 이러한 요청이 응답 될 것이라고 가정하지 않는데, 로그 메시지가 로그에 끝날 것이라고 가정하는 이유는 무엇입니까? 이것은 노드가 작동하는 방식입니다. 콜백 또는 setTimeout 접근 방식을 사용한 경우 setTimeout이 완료되거나 콜백이 호출되기 직전에 애플리케이션이 다른 행을 기록하는 것을 방해하는 것은 없습니다.

이 문제를 해결하는 유일한 방법은 동기 로깅을 사용하는 것이지만 요청을 처리 할 때 비동기 시스템을 간단한 로그 문으로 사용하는 모든 목적을 무력화합니다.

그래서 내가 제안하는 것은이 문제를 해결하지 않고 닫는 것입니다. 로그 메시지를 놓치지 않으려면 process.exit를 호출하기 전에 애플리케이션을 올바르게 정리하고 종료했는지 확인하십시오.

편집 또한 모든 setTimeout 해킹은 결함이 있으며 모든 데이터가 운영 체제에 기록되는 데 걸리는 시간과 디스크 또는 SSD가 처리하는 속도를 알지 못하므로 문제를 해결하지 마십시오. 여기서 유일하게 적절한 해결책은 스트림의 drain 이벤트를 듣고 프로세스를 종료하는 것입니다. 그러나 응용 프로그램이 계속 로깅하는 경우 오랜 기간 동안 호출되지 않을 수도 있습니다. 종료하기 전에 응용 프로그램을 제대로 종료하지 않았기 때문에 이것은 또 다른 해킹 일뿐입니다.

문제는 현재 로그가 플러시 될 때까지 (콜백 / 약속 / 무엇이든) 기다릴 방법이 없다는 것입니다. 또한 동기화 로깅을 강제하면 process.on('exit') 로그를 추가 할 수 있습니다.

응용 프로그램의 수명 동안 비동기 로깅을 사용하고 process.exit 동안 동기화 로깅을 사용하려면 쓰기를 동기화하는 사용자 지정 파일 구현으로 새 winston 인스턴스를 만들어야합니다. 그리고 언제 플러시되는지 알고 싶다면 스트림의 드레인 이벤트를 수신해야합니다.

고마워요!

그만한 가치를 위해 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);
  }
});

위에서 언급했듯이 콜백 함수 만 사용하는 것만으로는 파일에 올바르게 플러시되도록 _ 충분하지 않습니다 _. 이것은 나에게 버그처럼 느껴집니다.

winston의 flush 또는 closed 이벤트를 사용하는 대신 실제로 finish 이벤트를 수신하고 있습니다. https://nodejs.org/api/stream.html#stream_event_finish 그것도 올바르게 기록하기에는 불충분하기 때문입니다 : /

이걸로 해봐. 제 경우에는 꽤 잘 작동합니다. process.exit 직접 호출하는 대신 로그를 플러시 한 후 로거가 process.exit 호출하도록합니다.

logger.js :

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 및 winston 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을 '안전하게'종료하기 위해 종료 후크를 제공하든 상관 없지만 나에게 만족스러운 솔루션이 될 것입니다. 그러나 아무것도 가지지 않으면 로그를 작성하고 종료하고 실제로 기록 될 것이라는 확신을 가질 수 없습니다.

동기 전송의 경우 IO가 완료 될 때까지 코드 실행이 차단되어 성능이 제한됩니다. 비동기 쓰기를 차단 쓰기로 변환하는 방법은 없습니다. 즉, 일단 로그에 비동기 쓰기를하면 NodeJS가 접근 할 때까지 기다려야하며 그동안 다른 JS 코드가 실행될 수 있습니다.

반면에 프라 미스는 동기식으로 취소 할 수 있고, 시간 초과는 동기식으로 지울 수 있으며, 파일 및 데이터베이스 연결은 동기식으로 닫을 수 있으므로 더 나은 (더 나은 성능) 솔루션은 취소 / 지워야하는 항목을 추적하는 것입니다. winston.log_and_exit() 를 호출하는 예외 처리기 또는 winston.log_and_exit() 대한 선택적 콜백에서 닫고 닫습니다.

물론 Winston이 오류 발생시 닫아야하는 모든 사항을 추적하면 좋을 것입니다. 그러나 그러한 작업 관리자는 그 자체로 유용한 것일 수 있으며 별도의 프레임 워크를 사용할 가치가있을 것입니다. Curley의 법칙).

여기서 성능이 어떤 영향을 미치는지 모르겠습니다. 프로세스가 종료 될 예정입니다. winston은 IMO를 행복하게 차단할 수있는 최종 로그 라인에 대한 부기 만 수행하면됩니다.

이 문제가 얼마나 오래되었고 이에 대한 해결 방법이 있다는 사실을 감안할 때 언제라도 winston에서이 문제를 해결하는 사람을 정확히지지하지는 않습니다.

당신과 내가 목적을두고 이야기 (쓰기)하는 것처럼 들립니다. 파일에 최종 메시지를 동기식으로 작성하는 데 관심이있는 것처럼 들리지만 제 관심사는 오류 직전에 비동기식으로 작성된 로그가 파일에 작성되도록하는 것이 었습니다.

오류 직전에 발생한 파일에 메시지를 동 기적으로 기록하려면 모든 메시지가 동 기적으로 기록되어야하며 이것이 성능 문제입니다.

다른 사람들은 오류가 발생한 후 마지막 로그가 파일에 기록되기 전에 다른 JS 코드가 실행되지 않도록하는 것에 대해 우려했습니다.

모든 사람의 요구를 만족시킬 수있는 옵션은 비동기 적으로 쓰는 사용자 지정 전송 을 작성하는 것이며, 아직 파일에 기록 (플러시) 된 것으로 확인되지 않은 메시지의 버퍼를 유지하는 것입니다. , NodeJS가 이미 파일 쓰기를 완료했지만 플러시 된 이벤트가 아직 처리되지 않은 경우 ...).

반환 및 / 또는 콜백을 호출하기 전에 모든 것이 플러시 될 때까지 기다리는 종료 후크를 호출에 제공하는 것이 실제로 어렵습니까? 이것은 거의 모든 사용 사례를 해결할 것입니다.

그러나 동기 로그에 관심이없는 이유 인 사용 사례에 대해서도 설명하겠습니다. 테스트. 테스트를 실행하는 데 1 ~ 2 초가 더 걸리는지 상관 없습니다. 로그가 결정적이지 않은지 여부는 노드가 종료하기로 결정하는 속도에 따라 기록 될 수도 있고 기록되지 않을 수도 있기 때문입니다. 그것은 나쁘다 . 비동기가 기본값이어야한다는 점에 진심으로 동의합니다. 특히 내부 노드 자체와 같은 문제를 고려할 때 이것이 유일한 옵션이어야한다는 데 동의하지 않습니다.

@mscharley 이것이 log4js.shutdown 함수가 있습니다. 콜백을 호출하기 전에 모든 어 펜더 (winston이 트랜스 포트라고 부름)가 작성을 완료했는지 확인하기 위해 기다릴 것입니다. 내 사용자에게 잘 작동하는 것 같습니다. 종료 호출에 응답 할 수 있도록 작성해야한다는 점에서 어 펜더의 지원이 필요합니다.

저는 log4js를 홍보하거나 윈스턴보다 낫다고 말하지 않습니다. 다만이 접근 방식이 효과가있을 수 있다고 지적합니다. 최선의 방법이 아닐 수도 있습니다.

이것은 winston.log_and_exit() 는 일에 관한 것입니다. log4js.shutdown() 는 쓰기 가능한 스트림 ( appenders.filter(a => a.shutdown).forEach(a => a.shutdown(complete)); )을 기반으로하는 추가의 경우 writable.end(complete) 에 종속되며 여전히 비동기식 종료입니다.

@mscharley 의 의견과 관련하여 장점은 fileSync appender가 있다는 것입니다. shutdown() 를 사용하여 노드가 파일에 기록 될 때 전체 로그를 작성할 필요가 없습니다. 프로세스가 종료됩니다 ...

예, fileSync 전송을 사용하면 순 성능이 저하 되더라도 일부 상황에서 유용 할 수 있습니다.

@jdthorpe 종료하기 전에 깨끗하게 닫는 라이브러리를 갖는 것에 대한 귀하의 아이디어는 좋은 것이라고 생각하지만 여전히 모든 것을 디스크에 플러시 할 때까지 기다리는 방법을 제공하기 위해 winston에서 책임을 옮기지는 않습니다 (즉, 자체를 닫는 메커니즘 제공) 그런 다음 이러한 라이브러리와 결합하여 다양한 라이브러리에 대한 close 메서드를 집계 할 수 있습니다.

이 티켓은 최소한 문서를 변경하여 현재 지원되지 않는 것처럼 보이게 할 수 있습니까? 리포지토리에서 seriously 를 검색 할 때 지원한다고 주장하는 이 문제를 디버깅하는 데 30 분을 보냈습니다. README 이것은 지원되지 않는 기능이나 버그처럼 보이며 해결 방법은 실제로 너무 맛있지 않습니다.

이 문제는 언제 해결됩니까? 이것은 지금까지 3 년 동안 존재했으며 매우 중요합니다.

적어도 실제로 작동하는 로거에 콜백을 넣어 보겠습니다.

모든 사람을위한 일반 shutdown() 함수를 새로운 기능으로 작성했을 수 있으며이 기능은 매우 중요합니다.

예 이것은 매우, 매우 중요한 문제입니다.

이것에 대한 +1

솔직히 shutdown(callback) 것이 적절 해 보이지만 운송 수단이이를 적극적으로 지원해야한다는 경고가 있습니다. 개별 전송은 기본 출력 메커니즘에 대한 "정보 전문가"입니다. 그들은 그것이 어떻게 완전히 종료되어야하는지에 대한 가장 많은 정보를 가지고 있습니다.

winston 코어가 수행하는 모든 작업, 그리고 가장 확실하게 사용자 영역에서 수행하는 모든 작업에는 유출 할 전송의 구현 세부 정보가 필요합니다.

따라서 winston 가 작업 을 수행 할 필요는 없지만

아래 요점을 설명하는 몇 가지 의사 코드입니다.

```js
shutdown (callback) {
var transportCount = transports.length
var finished = 0;
// 각 전송에 대해
if (transport.shutdown) {
transport.shutdown (function () {
// 완료 횟수를 늘립니다.
// 모두 완료되면 원래 콜백을 호출합니다.
});
} else {
// 전송은 (아직) 지원하지 않습니다.
// 완료된 카운터 증가
}
}

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))
  })
}

```js
const logTransports = [새 winston.transports.File ({파일 이름 : '/log/app.log'})]

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

// 주어진 반환 코드로 종료하는 도우미이지만 로거가 완료된 후에 만
// 해결되지 않는 Promise를 반환하므로 실행이 중지됩니다.
log.exit = (exit = 5) => {
return new Promise (() => {
Promise.all (
logTransports.map (transport => new Promise (resolve => transport.on ( 'finished', resolve)))
) .then (() => process.exit (exit))
})
}

</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
}

기록이 깨지는 것은 아니지만 winston-log-and-exit 도이 문제를 해결합니다.

매우 구체적인 사용 사례에만 해당됩니다. 프로세스가 종료되지 않는 AWS Lambda에서는 winston-log-and-exit을 사용할 수 없었지만 실행 사이에 동결되므로 로그가 여전히 손실됩니다. 또한 성공적인 실행 경로에서 항상 그렇지는 않은 마지막 메시지가 어떤 메시지인지 알고 있다고 가정합니다.

@mscharley 위의 await 솔루션이 사용 사례에 적합합니까? 아마도 log.exit() 대신에 더 나은 API는 await log.finish() 가 될 것입니다. 이것은 모든 트랜스 포트가 쓰기를 마칠 때까지 기다렸다가 무엇이든 할 수있게합니다 ( process.exit 호출, 람다 호출 done 콜백 등)

그것은 기본적으로 우리가 윈스턴 내부를 제외하고는 이번 호에서 추진해온 것입니다. 이것이 플러그인 인 이유는 무엇입니까? 더 자주 등장해야 할 것 같습니다. 나는 우리가하는 일이 특별한 일이 아니라고 생각하지만 우리는 모든 프로젝트에서이 벽을 쳤습니다. 그래서 우리는 결국 Winston에서 멀어졌습니다. 특히 오류가 발생할 가능성이 가장 높은 프로세스 끝에서 로그를 잃는 것은 적어도 위험 해 보입니다.

log4js-node는 모든 전송을 플러시하고 process.exit() 와 같은 콜백을받는 종료 메서드 를 구현했습니다. winston에 이와 같은 것을 추가 할 수 있습니까?

log4js-node는 다음과 같습니다.

업데이트가 있습니까? 문제는 매우 실제적입니다.

모든 로깅 시스템의 경우 미적분은 다음과 같습니다.

• 로그가 반드시 있어야하고 느린 응답 시간에 대한 비용을 지불 할 의향이있는 경우 동기식 로거를 사용하십시오.
• process.exit() 직접 호출하는 경우 버퍼링 된 메시지가 지워질 때까지 기다리십시오. winston의 경우 winston-log-and-exit 패키지가이 작업을 수행합니다.
• 다른 코드가 process.exit() 호출하고 플랫폼에 on-exit 후크가있는 경우 해당 후크를 사용하고 버퍼링 된 메시지가 지워질 때까지 기다리십시오. winston-log-and-exit 도 도움이 될 수 있습니다.
• on-exit 후크가없는 AWS Lambda와 같은 플랫폼을 사용하는 경우 데이터 손실 위험에 대해 플랫폼의 이점을 거래하는 것입니다.

부수적으로 @ begin-again log_and_exit() 메서드는 기본적으로 log-4js의 shutdown() 메서드와 동일하며 제공된 로그 메시지가 기록된다는 추가 보장이 있습니다.

@jdthorpe 하지만 winston-log-and-exit 은 winston 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)
})

@ redhat-raptor. 대부분 의 경우 작동하지만 항상 작동한다고 보장 할 수는 없습니다. nextTick ()이 호출 될 때 버퍼가 지워졌지만 로거가 의존하는 연결에 따라 쉽게 메시지가 손실 될 수

이 코드는 나를 위해 일했습니다.

            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-written-in-winston

@danielweck 아니요, 고장

6 년, 즉 _important_로 표시된 버그의 경우 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 이것에 대한 해결책을 찾을 수 있었습니까? 최근에 Winston 3.x로 업그레이드했지만 2.x로 돌아가거나 여기에서 솔루션이없는 다른 로거를 찾아야 할 수 있습니다.

@matttowerssonos , IIRC, 이러한 문제는 모두 Winston @ 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 실수가 아니라면 processLogger.end() 호출하지 않기 때문에 finish 이벤트가 processLogger 하지 않습니다. 이를 호출하면 Winston이 로깅을 완료하면 finish 이벤트가 발생합니다.

또한 사용하는 것이 process.disconnect() 대신 process.exit() 드레인 대기열을 수 있습니다. 대기열이 비워지면 자동으로 종료됩니다.

@stephanoparaskeva 실수가 아니라면 processLogger.end() 호출하지 않기 때문에 finish 이벤트가 processLogger 하지 않습니다. 이를 호출하면 Winston이 로깅을 완료하면 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 이벤트는 처리기가 바인딩되는 시간에 이벤트 루프가 전환 된 후에 만 ​​발생해야하므로 중요하지 않습니다. 이벤트 처리기가 먼저 바인딩되는 코드를 작성하면 더 명확하게 작성한다고 생각합니다.

뿡뿡
오, 이벤트 핸들러를 어떻게 바인딩합니까?
그럴까요?

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

@stephanoparaskeva 네. 이것이 함수 바인딩을위한 올바른 구문입니다.

{
  this.process.disconnect();
}

processLogger 개체에 의해 생성 된 finish 이벤트에.

나를 위해 작동합니다 : https://stackoverflow.com/a/59260151

process.exit를 호출하지 않고 대신 모든 연결을 닫고 이벤트 루프가 배수 될 때까지 기다림으로써 적절한 종료를 수행하면 전혀 문제가 없습니다.

@deedf 가 무엇을 하려면 https://stackoverflow.com/a/37592669 를 참조하십시오. 이 조언에 따라 저도이 문제를 완화했습니다.

종료 이벤트가 몇 년이 지난 후에도 여전히 발생하지 않는다는 사실은이 시점에서 당황 스럽습니다. 로거를 전환하고 모든 사용자 지정 전송을 다시 작성해야하는 것은 고통 스러울 것입니다.

나는 이것이 winston에 의해 아직 해결되지 않은 방법을 이해하지 못합니다. 내 코드의 첫 번째 로거 만 Logstash에 기록되는 문제가 있습니다 (winston-elasticsearch도 사용). logger.end ()를 사용하면 모든 것이 기록되지만 프로그램이 너무 일찍 종료됩니다. 위의 모든 솔루션을 사용해 보았지만 실제로 작동하지 않았습니다.
난 정말 무력 해

나는 이것이 winston에 의해 아직 해결되지 않은 방법을 이해하지 못합니다. 내 코드의 첫 번째 로거 만 Logstash에 기록되는 문제가 있습니다 (winston-elasticsearch도 사용). logger.end ()를 사용하면 모든 것이 기록되지만 프로그램이 너무 일찍 종료됩니다. 위의 모든 솔루션을 사용해 보았지만 실제로 작동하지 않았습니다.
난 정말 무력 해

이거 해봤 어?

나는 사람들이이 "문제"가 "해결"되지 않았 음을 이해하지 못하는 이유를 이해하지 못한다. exit ()를 호출하지 않고 적절한 코드를 작성하면 괜찮습니다.

나는 사람들이이 "문제"가 "해결"되지 않았 음을 이해하지 못하는 이유를 이해하지 못한다. exit ()를 호출하지 않고 적절한 코드를 작성하면 괜찮습니다.

그래서이 문제에 대한 해결책은 process.exit ()를 호출하지 않는 것입니다.

나는 사람들이이 "문제"가 "해결"되지 않았 음을 이해하지 못하는 이유를 이해하지 못한다. exit ()를 호출하지 않고 적절한 코드를 작성하면 괜찮습니다.

그래서이 문제에 대한 해결책은 process.exit ()를 호출하지 않는 것입니다.

예, nodejs에서는 항상 나쁜 생각입니다. https://stackoverflow.com/a/37592669를 참조

나는 사람들이이 "문제"가 "해결"되지 않았 음을 이해하지 못하는 이유를 이해하지 못한다. exit ()를 호출하지 않고 적절한 코드를 작성하면 괜찮습니다.

그래서이 문제에 대한 해결책은 process.exit ()를 호출하지 않는 것입니다.

예, nodejs에서는 항상 나쁜 생각입니다. https://stackoverflow.com/a/37592669를 참조

개인적으로 process.exit를 사용하는 이유는 uncaughtException 및 unhandledRejection을 듣고 모든 전송에 기록한 다음 응용 프로그램을 종료하기 때문입니다. 이 문제를 해결하는 더 좋은 방법이 있습니까?

나는 사람들이이 "문제"가 "해결"되지 않았 음을 이해하지 못하는 이유를 이해하지 못한다. exit ()를 호출하지 않고 적절한 코드를 작성하면 괜찮습니다.

내가 exit ()를 사용했다고 어디에서 보았습니까?

나는 사람들이이 "문제"가 "해결"되지 않았 음을 이해하지 못하는 이유를 이해하지 못한다. exit ()를 호출하지 않고 적절한 코드를 작성하면 괜찮습니다.

내가 exit ()를 사용했다고 어디에서 보았습니까?

당신의 읽기와 이해 능력이이 버그가 무엇인지 이해하기에 충분하다고 생각해서 죄송합니다. 제목을 다시 확인하십시오.

나는 사람들이이 "문제"가 "해결"되지 않았 음을 이해하지 못하는 이유를 이해하지 못한다. exit ()를 호출하지 않고 적절한 코드를 작성하면 괜찮습니다.

내가 exit ()를 사용했다고 어디에서 보았습니까?

당신의 읽기와 이해 능력이이 버그가 무엇인지 이해하기에 충분하다고 생각해서 죄송합니다. 제목을 다시 확인하십시오.

8 년 동안 열려 있고 적절한 도움을 전혀 제공하지 않는 문제에 직면하면 너무 바빠야합니다.

나는 사람들이이 "문제"가 "해결"되지 않았 음을 이해하지 못하는 이유를 이해하지 못한다. exit ()를 호출하지 않고 적절한 코드를 작성하면 괜찮습니다.

그래서이 문제에 대한 해결책은 process.exit ()를 호출하지 않는 것입니다.

예, nodejs에서는 항상 나쁜 생각입니다. https://stackoverflow.com/a/37592669를 참조

개인적으로 process.exit를 사용하는 이유는 uncaughtException 및 unhandledRejection을 듣고 모든 전송에 기록한 다음 응용 프로그램을 종료하기 때문입니다. 이 문제를 해결하는 더 좋은 방법이 있습니까?

나는 한동안 winston을 사용하지 않았지만 어쨌든 기록하지 않습니까? 그렇지 않은 경우 로깅 후 오류가 다시 발생하지 않습니까?

나는 사람들이이 "문제"가 "해결"되지 않았 음을 이해하지 못하는 이유를 이해하지 못한다. exit ()를 호출하지 않고 적절한 코드를 작성하면 괜찮습니다.

내가 exit ()를 사용했다고 어디에서 보았습니까?

당신의 읽기와 이해 능력이이 버그가 무엇인지 이해하기에 충분하다고 생각해서 죄송합니다. 제목을 다시 확인하십시오.

8 년 동안 열려 있고 적절한 도움을 전혀 제공하지 않는 문제에 직면하면 너무 바빠야합니다.

적어도 나는 자격을 갖춘 녀석처럼 징징 대지 않고 내 문제를 해결할 수 있습니다.