Winston: process.exit（0）を呼び出すと、ファイルへのログ記録が失敗します

ノードでは、console。*メソッドが非同期を書き込んでおり、ファイルトランスポートは非​​同期です。 ノードがデータを書き込む前に、プロセスを閉じています。

2013年3月25日月曜日19：45、YuriZapuchlakは次のように書いています。

winstonがファイルにログを記録するように構成されていて、コードでprocess.exit（0）を呼び出すと、winstonがログファイルを作成してログメッセージをファイルに追加することはありません。
完璧な世界では、winstonはこのエッジケースを問題なく処理してファイルに書き込みますが、手動でファイルにフラッシュを強制するためにロガーインスタンスでflushを呼び出すことができれば問題ありません。
現時点では手動で「フラッシュ」する方法があるかもしれませんが、それは文書化されておらず、実際にログになる方法でロガーインスタンスまたはその内部ストリームを手動で閉じる/終了/破棄する運がありませんでしたファイルに書き出されています。
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）; // 2つのログはコンソールに書き出されますが、winston.logファイルには書き出されません/

—
このメールに直接返信するか、GitHub（https://github.com/flatiron/winston/issues/228）で表示してください。

うーん。 その場合、ノードプロセスを強制終了する必要があるが、強制終了する直前に情報をログに記録する必要がある場合は、process.exit（）を十分に長い期間でsetTimeout（）内に配置することで、確実に実行できる唯一の方法です。そのウィンストンは実際にログファイルにメッセージを書き込みますか？

わかりやすくするために、 console.logとその友達は同期しています。

@yzapuchlak私は実際にテストしていませんが、それも私が行っていることです。

@yzapuchlak setTimeoutは_おそらく_問題なく機能しますが、代わりにオプションのコールバックパラメータを使用するのが賢明だと思います。

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好奇心が

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

同じ問題が発生しているため、プロセスを終了してログファイルに記録する必要があります。 メッセージが書き込まれた後にのみプロセスを終了するために使用できるコールバックオプションがあると便利です。 または多分それはすでに存在していますか？

Winston0.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);
  }
});

上記のように、コールバック関数を単独で使用するだけでは、ファイルに正しくフラッシュするのに_十分ではありません_。 これは私にはバグのように感じます。

私は実際にfinishイベントをリッスンしていることに注意してください：winstonのflushまたはclosedイベントを使用するのではなく、 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!');

NodeJSv4.1.2およびwinston1.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();
});

理想的には、 loggerInstanceでcloseメソッドを呼び出すことができればいいのですが、それがclose呼び出しを終了するとすぐに、 closedイベントを発行するためです。基になるトランスポートのcloseメソッドは、実際に閉じた後ではなく、機能しません。 基になるトランスポートを完全に閉じずにロガーを閉じることができるのはバグのようです。

@Kegsayを使用すると、ステップとログがファイルに書き込まれます。

また、 @ Kegsayのステップを使用して成功しました...自分の関数にラップされています。

バージョン2.2.0この問題が発生します。

これはまだ実装されていませんか？ 3歳以上。 プロセス出口を使いたくない。

これは問題ではないことを理解していますが、ファイルへのすべての書き込みを終了し、開いているものをすべて閉じて、プロセスを明示的に呼び出さなくてもプロセスが自動的に終了できるようにする関数が確実に必要です。 実動システムでそのようなものを使用するのはとても難しいです。

npm installwinston-log-and-exit

これには本当にウィンストン側の解決策が必要だと反響します。 それが同期ファイルトランスポートを提供するのか、Winstonを「安全に」閉じるためのシャットダウンフックを提供するのかに関わらず、私は本当に気にしません。どちらも私にとって満足のいく解決策です。 しかし、何もないと、ログを書き込んでから終了し、実際に書き込まれることが保証されます。

同期トランスポートの場合、IOが完了するまでコードの実行がブロックされるため、パフォーマンスが制限されます。 非同期書き込みをブロッキング書き込みに変換する方法はありません。つまり、ログに非同期書き込みを行うと、NodeJSがそれに近づくまで待つ必要があり、その間に他のJSコードが実行される可能性があります。

一方、promiseは同期的にキャンセルでき、タイムアウトは同期的にクリアでき、ファイルとデータベースの接続は同期的に閉じることができるため、キャンセル/クリア/する必要があるものを追跡することで、より良い（よりパフォーマンスの高い）ソリューションが得られる可能性があります。 winston.log_and_exit()を呼び出す例外ハンドラー、またはwinston.log_and_exit()へのオプションのコールバックでそれらを閉じて閉じます。

確かに、Winstonがエラーが発生した場合に閉じる必要のあるすべてのものを追跡しておけばいいのですが、そのようなタスクマネージャーはそれ自体でおそらく便利であり、おそらく別のフレームワークに値します（を参照）。カーリーの法則）。

ここでは、パフォーマンスがどのように影響するかわかりません。 プロセスは間もなく終了します。winstonは最終ログ行で簿記を行うだけでよく、その間IMOを問題なくブロックできます。

この問題がどれほど古いか、そしてそれに対する回避策があるという事実を考えると、私はウィンストンでこれに対処する人をすぐに正確に差し控えているわけではありません。

あなたと私は目的を超えて話している（書いている）ようです。 最終的なメッセージをファイルに同期的に書き込むことに関心があるようですが、私の懸念は、エラーの直前に非同期に書き込まれたログがファイルに書き込まれるようにすることでした。

エラーの直前に発生したメッセージをファイルに同期的に書き込むには、すべてのメッセージを同期的に書き込む必要があり、それがパフォーマンスの問題です。

他の人は、エラーの後、最後のログがファイルに書き込まれる前に、他のJSコードの実行を停止することを懸念しています。

すべての人のニーズを満たす可能性のあるオプションは、非同期で書き込み、ファイルへの書き込み（フラッシュ）としてまだ確認されていないメッセージのバッファーを保持するカスタムトランスポートを作成することです。これは、エラー時に同期的にファイルに書き込まれる可能性があります（メッセージが重複するリスクがあります） 、NodeJSがすでにファイルへの書き込みを終了したが、フラッシュされたイベントがまだ処理されていない場合...）。

コールバックを返すか呼び出す前に、すべてがフラッシュされるまで待機するシャットダウンフックを呼び出すことは実際には困難ですか？ これにより、ほぼすべてのユースケースが解決されます。

しかし、同期ログを気にしない理由である私のユースケースについても説明します。 テスト。 テストの実行に1〜2秒長くかかるかどうかは関係ありません。 ログが決定論的でないかどうかは気になります。ノードがシャットダウンを決定する正確な速さに応じて、ログが書き出される場合と書き出されない場合があるためです。 それは悪いです。 非同期がデフォルトであるべきだということに心から同意します。 特にノード自体の内部のような問題に照らして、それが唯一のオプションであるべきだということに同意しません。

@mscharleyこれはlog4js.shutdown関数があります。 コールバックを呼び出す前に、すべてのアペンダー（winstonはそれらをトランスポートと呼んでいます）が書き込みを終了したことを確認するのを待ちます。 私のユーザーにとってはうまくいくようです。 シャットダウン呼び出しに応答できるようにアペンダーを作成する必要があるという点で、アペンダーからのサポートが必要です。

ちなみに、私は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シャットダウンする前に物事をきれいに閉じることを処理するライブラリを持つというあなたの考えは良いものだと思いますが、それでもすべてをディスクにフラッシュするのを待つ方法を提供するという責任をウィンストンから移すことはありません（つまり、それ自体を閉じるメカニズムを提供します）、それをそのようなライブラリと組み合わせて、さまざまなライブラリの閉じるメソッドを集約することができます。

このチケットは少なくともドキュメントを変更して、現在サポートされているように見えないようにすることはできますか？リポジトリですると、サポートさREADME 。 これは、サポートされていない機能またはバグのように思われ、回避策はあまり口に合わないものです。

これはいつ修正されますか？ これは3年前から存在しており、非常に重要です。

少なくとも、実際に機能するロガーにコールバックを入れましょう。

おそらく、すべての人のための一般的なshutdown()関数を新機能として作成したと思いますが、この機能は非常に重要です。

はい、これは非常に重要な問題です。

このための+1

率直に言って、 shutdown(callback)追加することは適切だと思いますが、トランスポートが積極的にサポートする必要があるという警告があります。 個々のトランスポートは、基礎となる出力メカニズムに関する「情報エキスパート」です。 彼らはそれがどのようにきれいにシャットダウンするべきかについてのほとんどの情報を持っています。

winstonコアが行うこと、そして最も確実にユーザーランドで行うことはすべて、リークするトランスポートの実装の詳細を必要とします。

したがって、 winstonは作業を行う必要はありません...しかし、実際には作業を完了する方法を提供する必要があります。 そうすれば、私たちは皆、トランスポートの作者と協力して手間のかかる作業を行うことができます。

以下のポイントを説明するためのいくつかの擬似コード。

`` `js
シャットダウン（コールバック）{
var transportCount = transports.length
var finish = 0;
//トランスポートごとに
if（transport.shutdown）{
transport.shutdown（function（）{
//終了数を増やします。
//すべて終了したら、元のコールバックを呼び出します。
}）;
} そうしないと {
//トランスポートは（まだ）それをサポートしていません。
//終了したカウンターをインクリメントします
}
}

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 = [new winston.transports.File（{filename： '/ log / app.log'}）]

global.log = winston.createLogger（{transports：[logTransport]}）

//指定されたリターンコードで終了するヘルパー。ただし、ロガーが終了した後のみ
//これは解決されないPromiseを返すため、実行が停止します
log.exit =（exit = 5）=> {
新しい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もこの問題を解決します

非常に特定のユースケースのみ。 プロセスが終了しないAWSLambdaではwinston-log-and-exitを使用できませんでしたが、実行間でフリーズするため、ログは失われます。 また、どのメッセージが私の最後のメッセージであるかを知っていることを前提としていますが、成功した実行パスでは常にそうであるとは限りません。

@mscharley上記のawaitソリューションはユースケースで機能しますか？ おそらくlog.exit()代わりに、より良いAPIはawait log.finish()で、すべてのトランスポートが書き込みを完了するまで待ってから、何でもできます（ process.exitを呼び出し、lamda done呼び出します）

これは、ウィンストンの内部を除いて、基本的にこの問題で私たちが推進してきたことです。 なぜこれがプラグインになるのでしょうか？ もっと頻繁に出てくるはずの何かのようです。 私たちがやっていることは特別なことではないと思いますが、すべてのプロジェクトでこの壁にぶつかりました。そのため、最終的にウィンストンから離れました。 特にプロセスの最後（エラーが発生する可能性が最も高い場所）でログを失うことは、少なくとも危険であるように思われます。

log4js-nodeは、すべてのトランスポートをフラッシュし、 process.exit()などのコールバックを受け取るシャットダウンメソッドを実装しました。 このようなものをウィンストンに追加できますか？

log4js-ノードそれはその後です

更新はありますか？ 問題は非常に現実的です。

どのロギングシステムでも、微積分は次のとおりです。

• どうしてもログが必要で、応答時間が遅くなるという代償を払っても構わないと思っている場合は、同期ロガーを使用してください
• 自分でprocess.exit()呼び出す場合は、バッファリングされたメッセージがクリアされるまで待ちます。 winstonの場合、 winston-log-and-exitパッケージがこれを行います。
• 他のコードがprocess.exit()を呼び出していて、プラットフォームにon-exitフックがある場合は、そのフックを使用して、バッファリングされたメッセージがクリアされるまで待ちます。 winston-log-and-exitもそれを助けることができます。
• 出口フックのないAWSLambdaのようなプラットフォームを使用している場合は、データを失うリスクとプラットフォームのメリットを交換していることになります。

ちなみに、@ begin-ここでも、 log_and_exit()メソッドはlog-4jsのshutdown()メソッドと基本的に同じですが、提供されたログメッセージがログに記録されるという追加の保証があります。

@jdthorpeしかし、 winston-log-and-exitはwinston3では簡単に機能しません

@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いいえ、壊れています：＃1629＃1504！

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これに対する解決策を見つけることができましたか？ 最近Winston3.xにアップグレードしましたが、2.xに戻るか、ここで解決策のない別のロガーを見つける必要がある場合があります。

@ matttowerssonos 、IIRC、これらの問題はすべてWinston @ 2に関連してい

ところで、 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イベントはイベントループが終了した後にのみ発生するため、問題ではありません。その時点でハンドラーがバインドされます。 イベントハンドラーが最初にバインドされるコードを書くと、それがより明確になると思います。

@cjbarth
ああ、どのようにイベントハンドラーを何かにバインドしますか？
それは：

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

@stephanoparaskevaはい。 これは、関数をバインドするための正しい構文です。

{
  this.process.disconnect();
}

オブジェクトprocessLoggerによって発行されたfinishイベントに。

それは私のために働きます： https ：

process.exitを呼び出さずに、代わりに適切なシャットダウンを実行する場合は、すべての接続を閉じ、イベントループがドレインされるのを待つことで、まったく問題はありません。

@deedfが何を指しているのかをよりよく理解するには、 https ： //stackoverflow.com/a/37592669を参照してください。 このアドバイスに従って、私にとってもこの問題を軽減しました。

フィニッシュイベントが何年も経ってもまだ出てこないという事実は、現時点では恥ずかしいことです。 これは、ロガーを切り替えて、すべてのカスタムトランスポートを書き直さなければならないのは面倒です。

ウィンストンがこれをまだ解決していないのかわかりません。 コードの最初のロガーのみがLogstashにログに記録されるという問題があります（winston-elasticsearchも使用）。 logger.end（）を使用すると、すべてがログに記録されますが、プログラムの終了が早すぎます。 上記のすべてのソリューションを使用してみましたが、実際には機能しませんでした。
私は本当に無力です

ウィンストンがこれをまだ解決していないのかわかりません。 コードの最初のロガーのみが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をリッスンしてすべてのトランスポートにログを記録し、アプリケーションを終了するためです。 この問題を解決するためのより良い方法はありますか？

私はしばらくウィンストンを使用していませんが、とにかくそれはログに記録されませんか？ そうでない場合は、ログに記録した後にエラーを再スローしませんか？

この「問題」が「解決」されていないのは、何もないので、人々がどうやって理解できないのかわかりません。 exit（）を呼び出さずに適切なコードを書くだけで、問題ありません。

exit（）を使用したと言ったのはどこでしたか？

あなたの読書と理解の能力がこのバグが何であるかを理解するのに十分であると仮定して申し訳ありません。 タイトルをもう一度確認してください。

8年間開かれている問題に遭遇し、適切な支援をまったく提供しない場合、あなたはとても忙しいに違いありません。

少なくとも、資格のあるガキのように泣き言を言うことなく、自分の問題を解決することができます。