Winston: لا يزال Winston 3.0.0 يوقف التسجيل في حالة الإجهاد العالي. يجعلها غير قابلة للاستخدام بالنسبة لنا.

سيؤدي استخدام while (true) في هذا المثال إلى تجويع حلقة الحدث ومنع تشغيل التعليمات البرمجية غير المتزامنة (الكتابة إلى ملف السجل الخاص بك). يمكن أن تبدو النسخة المعدلة من هذا والتي تكون أكثر ملاءمة للعقد كما يلي:

const winston = require('winston');

const myFormat = winston.format.printf(info => {
    return `${info.timestamp} ${info.level}: ${info.message}`;
});
const logger = winston.createLogger({
    level: 'info',
    format: winston.format.timestamp(),
    transports: [
        new winston.transports.File({filename: 'logs/combined.log'}),
        new winston.transports.Console({format: winston.format.combine(winston.format.timestamp(), myFormat), level: 'debug'})
    ]
});

function main() {
  let random_string = Math.random().toString(36).substring(7);
  logger.info(random_string);  // This one stops after a while (this call executes asynchronous code)
  console.log(random_string);  // while this one continues to function properly (I believe this is a synchronous function in node)
  setImmediate(main);
}

main();

mempf صحيح ، إذا قمت بحظر حلقة الحدث مثل while (true) ، فسيتم تعليق أي كود عقدة غير متزامن (غير خاص بـ winston) في النهاية. هل ^ مثاله أعلاه يعمل بشكل جيد بالنسبة لك؟

mempf لدينا نفس المشكلة داخل مشروعنا. نحن نستخدم "عنق الزجاجة" لمنع المشكلة. في حالتنا ، نقوم أحيانًا بتسجيل مجموعة من الإدخالات دفعة واحدة وأغلق Winston في الماضي. نحن نستخدم عنق الزجاجة في "انتظار" استدعاءات وظيفة السجل. هذا حل مشكلتنا. تبدو خدمة LoggerService الخاصة بنا على هذا النحو (نص مكتوب):

import * as winston from 'winston';
import * as bottleneck from 'bottleneck';

const { printf, combine, colorize } = winston.format;

const logLevels = {
  levels: {
    error: 0,
    warn: 1,
    info: 2,
    http: 3,
    sql: 4,
    debug: 5
  },
  colors: {
    error: 'red',
    warn: 'yellow',
    info: 'green',
    http: 'blue',
    sql: 'blue',
    debug: 'gray'
  }
};
winston.addColors(logLevels);

export const jsonFormatter = (logEntry: any) => {
  const base = { timestamp: new Date() };
  const json = Object.assign(base, logEntry);
  const today = new Date();
  const day = today.toISOString().split('T')[0];
  const hours = today.getUTCHours();
  const minutes = today.getUTCMinutes();
  logEntry['message'] = `[${day} ${hours}:${minutes} UTC]: ${json.message}`;
  return logEntry;
};

/**
 * Logger Service. Handles logging with winston. Service handles logging time intervals with bottleneck.
 * Bottleneck, because winston will hang up under heavy load.
 */
export const LoggerService = {
  /** "Bottleneck" Limiter for Logger */
  bottleneck: new bottleneck.default({
    maxConcurrent: 1,
    minTime: 5
  }),
  /** Winston logger. See https://github.com/winstonjs/winston#creating-your-own-logger for more details  */
  logger: winston.createLogger({
    level: 'info',
    format: combine(
      colorize(),
      winston.format(jsonFormatter)(),
      printf((info: any) => `${info.level}: ${info.message}`)
    ),
    transports: [
      new winston.transports.File({ filename: 'error.log', level: 'error' }),
      new winston.transports.File({ filename: 'combined.log' })
    ],
    exceptionHandlers: [
      new winston.transports.File({ filename: 'exceptions.log' })
    ]
  }),
  /** Returns winston logger */
  getLogger() {
    return LoggerService.logger;
  },
  /**
   * Logs an event with winston
   * <strong i="7">@param</strong> param0.level Log level. e.g. warn, info, error
   * <strong i="8">@param</strong> param0.message Log message
   */
  log({ level, message } : {level: string, message: string }) {
    LoggerService.bottleneck.schedule({}, () => {
      return Promise.resolve(LoggerService.getLogger().log({ level, message }));
    });
  }
};

LoggerService.logger.add(new winston.transports.Console({
  format: winston.format.simple()
}));

لدينا نفس المشكلة ، توقف winston عن الإخراج بعد تلقي الكثير من المدخلات. لست على دراية كافية بالعقدة لتنفيذ المثال أعلاه في مشروعي. لذلك فإن أي مساعدة سيكون موضع تقدير.

هذا هو رمزنا:

'use strict'

const appRoot = require('app-root-path')
const winston = require('winston')
const { Papertrail } = require('winston-papertrail')
const moment = require('moment')
const serializerr = require('serializerr')


const format = winston.format.combine(
  winston.format.colorize({message: true, levels: true}),
  winston.format.timestamp(),
  winston.format.align(),
  winston.format.simple(),
  winston.format.printf((info) => {
    let { timestamp, level, message, error, data } = info
    if (error && error instanceof Error) {
      let serializedError = serializerr(error)
      if (serializedError) message += `\t${JSON.stringify(serializedError)}`
    } else if (error && typeof error === 'object') {
      message += `\t${JSON.stringify(error)}`
    } else if (error) {
      message += `\t${error}`
    }

    if (data && typeof data === 'object') {
      message += `\t${JSON.stringify(data)}`
    } else if (data) {
      message += ` ${data}`
    }
    const ts = moment.utc(timestamp).format('YYYY-MM-DD HH:mm:ss Z')

    return `${ts} [${level}]: ${message}`
  })
)

// Create the Papertrail Transport
const papertrail = new Papertrail({
  host: 'logs4.papertrailapp.com',
  port: 12910,
  hostname: process.env.PAPERTRAIL_HOSTNAME,
  handleExceptions: true,
  json: true,
  format: format,
  levels: {
    critical: 0,
    error: 1,
    warn: 2,
    info: 3,
    debug: 4
  },
})

// Like with the Logger error, just output error to
// stderr if there's an error with writing to Papertrail.
papertrail.on('error', (error) => {
  console.error('Error logging to Papertrail', {error})
})


const options = {
  file: {
    level: 'info',
    filename: `${appRoot}/logs/app.log`,
    handleExceptions: true,
    exitOnError: false,
    json: true,
    maxsize: 5242880, // 5MB file chunks
    maxFiles: 5,
    format: format
  },
  output: {
    level: 'debug',
    handleExceptions: true,
    json: false,
    align: true,
    exitOnError: false,
    format: format,
    levels: {
      critical: 0,
      error: 1,
      warn: 2,
      info: 3,
      debug: 4
    },
    colors: {
      critical: 'red bold',
      error: 'red italic',
      warn: 'yellow bold',
      info: 'green',
      debug: 'blue'
    }
  }
}

// Set transports
let transports = []

if (process.env.NODE_ENV !== 'local') {
  transports = [
    new winston.transports.File({ filename: `${appRoot}/logs/app.log`, level: 'error' }),
    papertrail
  ]
} else {
  transports = [
    new winston.transports.Console(options.output)
  ]
}

// Create Winston Logger instance.
const logger = winston.createLogger({
  level: 'info',
  levels: options.output.levels,
  transports: transports
})

winston.addColors(options.output.colors)

// If there is an error with the Winston logger,
// don't try to use the logger, just output to stderr.
logger.on('error', (error) => {
  console.error(error)
})


logger.streamError = {
  write (message) {
      logger.info(`Express Request Error: ${message}`)
  }
}

module.exports = logger

عندما نحاول تسجيل أي شيء ، فإنه يتسبب في تأخير عدة ثوانٍ وهو أمر غير مقبول. أي أفكار؟

إنه أمر مثير للاهتمام ، لأنه حتى إذا أزلنا جميع وسائل النقل ، فإن هذا لا يزال يسبب ارتفاعًا كبيرًا في وحدة المعالجة المركزية (90٪ مقابل 4٪) ويبطئ الكود بشكل كبير (أقل من ثانية لتشغيل طريقة مقابل أكثر من 10).

أواجه نفس السلوك وأعتقد أنه ليس من المنطقي الالتفاف حوله.
لا ينبغي أن يكون المسجل ، إذا كان سيؤخذ على محمل الجد ، مصدر قفل النظام. أستطيع أن أرى أنه عندما ينتقل النظام إلى التحميل الزائد ، فإن قائمة انتظار الحدث كذلك. لكنها عادة ما تتعافى. ونستون في حالتي لا. يمنع النظام حتى بعد زوال الحمولة.
قد يكون هذا بسبب تدفق المخازن المؤقتة ولا يوجد شيء يمكنك القيام به ضد ذلك ، باستثناء انتظار حدث التصريف وإفلات جميع السجلات التي تصل في هذه الأثناء. ربما عدهم ثم قم بتسجيل خطأ فادح مفاده أنه تم إسقاط 200 سجل بسبب الازدحام.
إذا لم يستطع Winston التعامل مع هذا ، فلا يمكنك استخدامه في الأنظمة الهامة.

kollerebbe - شكرًا لك على

بالنسبة لي ، هذا يحل المشكلة ، مما يعني أنه يمكنني إغلاق هذه المشكلة. لدي شعور بأن المزيد من الأشخاص هنا لديهم نفس المشكلة بالرغم من ذلك.

لمthe أشخاص آخرين في هنا (samothx،tonestrikegnorbsl) يا رفاق أيضا محاولة رمز عنق الزجاجة؟ إذا لم يكن كذلك ، فجربه وانشره هنا إذا كان ذلك يحل مشاكلك .. أم لا

لم نجرب رمز عنق الزجاجة. استند الكثير من مشكلاتنا حول حجم السجلات. إذا كان سجل معين يحتوي على JSON كبير ، فسيقوم Winston برفع وحدة المعالجة المركزية الخاصة بنا إلى 90٪ +. ومع ذلك ، إذا قمنا بتشديد JSON قبل تمريرها إلى Winston ، فإننا لا نرى مثل هذا الارتفاع الهائل. إذا واجهتنا مشكلات أخرى ، فسنراجع رمز عنق الزجاجة أعلاه.

كذلك هنا...
لقد جربت عنق الزجاجة دون حل المشكلة.
إذا قمت بتسجيل الدخول إلى متغير الفهرس for-loop ، بعد تسجيل 14 إدخالًا باستخدام توقف winston ، يستمر console.log.

@ kramer65 هل تعرف ما الذي أدى إلى خفض مثيل العقدة؟ استخدام الذاكرة؟ وحدة المعالجة المركزية؟

نحن نواجه تسربًا في الذاكرة مع Winston 3.0.0. للأسف لا يمكننا إعادة إنتاجه. يحدث ذلك بين الحين والآخر (انظر # 1445). لذلك لا يمكننا بسهولة اختبار ما إذا كان عنق الزجاجة سيساعدنا. سيكون رائعًا إذا تمكن بعضكم من تأكيد أنه يساعد في تسريب الذاكرة أيضًا. شكرا!

رؤية نفس المشكلة في تطبيقنا. لا يمكن التكاثر حتى الآن ولكن ترى أن الذاكرة تتصاعد وتذهب وحدة المعالجة المركزية إلى الحد الأقصى في الوقت الذي تتوقف فيه عن التسجيل.

mherger - واجهنا ارتفاعًا في وحدة المعالجة المركزية (~ 100٪) وعندما ارتفعت وحدة المعالجة المركزية ، سترتفع الذاكرة أيضًا. إذا تم تخفيض وحدة المعالجة المركزية في وقت ما إلى أقل من 100٪ (بسبب طلبات تسجيل أقل مؤقتة) ، فسيستخدم Winston وقت التنفس هذا لتخزين جميع السجلات من قائمة الانتظار وستنخفض الذاكرة أيضًا إلى المستوى العادي. إذا ارتفعت وحدة المعالجة المركزية لفترة طويلة جدًا ، فسترتفع الذاكرة حتى تصل إلى 100٪ ثم ستتوقف العقدة بسبب خطأ في الذاكرة.

لقد تم حلها من قبل Bottleneck لأن التسجيل لن يتداخل مع التشغيل العادي للبرنامج. كان لهذا تأثير أنه في حالة وحدة المعالجة المركزية عالية ، ستتم كتابة السجلات بطريقة بعد بدئها. اختبرت ذلك من خلال كتابة اللحظة التي بدأ فيها السجل وكذلك لحظة كتابة السجل. في بعض النقاط ، رأيت تأخيرًا لمدة نصف ساعة بين لحظة بدء السجل ووقت كتابته. نظرًا لأن سجلاتنا تُستخدم عادةً للتحليل في وقت لاحق ، فهذا لا يمثل مشكلة بالنسبة لنا.

لقد قررنا إعادة كتابة تطبيقنا بالكامل في golang ، لأننا ببساطة نحتاج إلى أداء أعلى.

آمل أن يساعدك هذا في العثور على المشكلة في طلبك. اسمحوا لي أن أعرف إذا كان بإمكاني تقديم المزيد من المساعدة.

ملاحظة أخرى قد تكون ذات صلة: يتوقف تسجيل الدخول في العمليات طويلة الأمد في النهاية

نحن نستخدم وينستون مع Express-winston. تعمل بعض الخدمات لأيام دون إعادة التشغيل ، ونحن الآن نلاحظ أنه لم يعد هناك أي سجلات بعد حوالي 4-5 أيام أو نحو ذلك حتى بدون تحميل كبير.

لا تزال هذه مشكلة مع 3.1.0. يمكنني إعادة إنتاجه بنشاط باستخدام مقعد أباتشي بعد محاولة كتابة 10 رسائل سجل فقط إلى ملف.

مرحباً بالجميع ، أواجه مشكلة مماثلة. يمكن لأي شخص المساعدة إذا كان هناك أي حل بديل أو هل هناك أي إصلاح معطى لهذا في 3.2.0

ما زلت أواجه هذه المشكلة مع 3.2.1 # 1624

نفس المشكلة بالنسبة لي ... Winston 3.2.1 و node 10.15.1

نفس المشكلة مع Winston 3.2.1 ، العقدة 8.16

أي تحديثات على هذا؟

@ avik - لذا أوصي بالتبديل إلى pino (https://github.com/pinojs/pino) - لم نعد نواجه هذه المشكلة بعد الترحيل.

حدث تطبيقي أمس أيضًا مع 3.2.1. اضطررت إلى إعادة تشغيل الخادم الخاص بي لاستعادة السجلات.

مواجهة المشكلة بفاعلية ، يرجى اقتراح الحلول.

يبدو أنه إذا تسبب النقل في حدوث خطأ (أي أنه ينقل خطأ إلى وظيفة رد الاتصال "السجل") ، فسيتم إزالته من المسجل!

const winston = require("winston")
describe("transports issue", () => {
    let logger
    let errorMessage
    let counter
    let maxCounter
    let transport
    let logMock
    let logError
    beforeEach(() => {
        counter = 0
        maxCounter = 1
        jest.clearAllMocks()
        logError = undefined

        logger = winston.createLogger({
            level: "info",
            transports: [transport]
            // transports: [loggingWinston]
        })
        logger.on("error", error => {
            logError = error
        })
    })
    beforeAll(() => {
        errorMessage = "Error logging!"
        logMock = jest.fn((info, next) => {
            if (counter === maxCounter) {
                next(new Error(errorMessage))
            } else {
                counter = counter + 1
            }
            next()
        })
        transport = Object.assign(new winston.transports.Console(), {
            log: logMock
        })
    })

    describe("only log once", () => {
        beforeEach(() => {
            logger.info("log once")
        })

        test("pipes is transport", () => {
            expect(logger.transports).toEqual([transport])
        })

        test("error didn't", () => {
            expect(logError).toBeUndefined()
        })
    })

    describe("log twice", () => {
        beforeEach(() => {
            logger.info("log twice 1")
            logger.info("log twice 2") // this returns an error for the transport
        })

        //  THIS TEST FAILS
        test("pipes is transport", () => {
            expect(logger.transports).toEqual([transport]) //empty array received
        })

        test("error occured", () => {
            expect(logError).toHaveProperty("message", errorMessage)
        })
    })
})

أعتقد أنني وجدت حلاً وهو أبسط بكثير مما قد تعتقد. اتضح أن "readable-stream" تلقائيًا "unpipe" هو الدفق القابل للكتابة على أي خطأ في النقل.

الحل:

const winston = require("winston")
const transport = newErrorProneTransport() // FileTransport is only one, there are many
const logger = winston.createLogger({
    level: "info",
    transports: [transport]
})
logger.on("error", error => {
    //if your JS version doesn't have "includes(transport)", use another method like `.some(t => t===transport)`
    if (!logger.transports.includes(transport)) {
        logger.add(transport)
    }
})

ها هو الاختبار يمر الآن بشكل صحيح

const winston = require("winston")
describe("transports issue", () => {
    const mainError = "Error logging!"
    const otherError = "Other error"
    let logger
    let errorMessage
    let counter
    let maxCounter
    let logError
    let transport
    const newTransport = () =>
        Object.assign(new winston.transports.Console(), {
            log: (info, next) => {
                if (counter === maxCounter) {
                    next(new Error(errorMessage))
                } else {
                    if (logError !== undefined) {
                        errorMessage = otherError
                    }
                    counter = counter + 1
                    next()
                }
            }
        })
    beforeEach(() => {
        errorMessage = mainError
        counter = 0
        maxCounter = 1
        logError = undefined
        transport = newTransport()
        logger = winston.createLogger({
            level: "info",
            transports: [transport]
        })
        logger.on("error", error => {
            if (!logger.transports.includes(transport)) {
                logger.add(transport)
                counter = 0
            }
            logError = error
        })
    })

    describe("only log once", () => {
        beforeEach(() => {
            logger.info("log once")
        })

        test("pipes is transport", () => {
            expect(logger.transports).toEqual([transport])
        })

        test("error didn't", () => {
            expect(logError).toBeUndefined()
        })
    })

    describe("log twice", () => {
        beforeEach(() => {
            logger.info("log twice 1")
            logger.info("log twice 2") // this raises the `mainError` for the transport
        })

        test("pipes is transport", () => {
            expect(logger.transports).toEqual([transport])
        })

        test("error occurred", () => {
            expect(logError).toHaveProperty("message", mainError)
        })
    })

    describe("log thrice", () => {
        beforeEach(() => {
            logger.info("log thrice 1")
            logger.info("log thrice 2") // this raises the `mainError` for the transport
            logger.info("log thrice 3") 
        })

        test("pipes is transport", () => {
            expect(logger.transports).toEqual([transport])
        })

        test("error occurred", () => {
            expect(logError).toHaveProperty("message", mainError)
        })
    })

    describe("log four times", () => {
        beforeEach(() => {
            logger.info("log four times 1")
            logger.info("log four times 2") // this raises the `mainError` for the transport
            logger.info("log four times 3")
            logger.info("log four times 4") // this raises the `otherError` for the transport
        })

        test("pipes is transport", () => {
            expect(logger.transports).toEqual([transport])
        })

        test("other error occurred", () => {
            expect(logError).toHaveProperty("message", otherError)
        })
    })
})

yinzara هل يمكنك عمل

لست متأكدًا بنسبة 100٪ أن هذا شيء يمثل مجرد إصلاح للعلاقات العامة إلا إذا كنت تريد تسميته "تغيير عاجل". في الوقت الحالي ، إذا تم إلقاء خطأ في النقل أثناء عملية التسجيل ولم تقم بإضافة مستمع "خطأ" إلى السجل ، فستحصل على "رفض الوعد الذي لم تتم معالجته". إذا قمت "بإصلاح" هذا ، فلن تتلقى أي تحذير أو خطأ من أي نوع عندما يلقي النقل خطأ (لن تحصل حتى على رسالة سجل أو وحدة تحكم حول هذا الموضوع) ولكن على الأقل سيستمر نظام السجل في العمل. إذا كنت قد أضفت مستمعًا للأخطاء إلى السجل ، فستظل تحصل على نفس السلوك ولكن من غير المحتمل أن يقوم أي شخص بذلك لأنه لم يتم اقتراحه في الملف التمهيدي.

ربما يتم إضافة متغير تكوين إلى خيارات المسجل الذي يقول "autoHandleTransportErrors" الذي يتم تعيينه على خطأ الآن (أو ربما يكون صحيحًا مع التوثيق حول التغيير المعطل)؟

افكار من قبل الاخرين؟

سنتان هما أنه إذا توقف المسجل عن التسجيل ، فلدينا مشكلة يجب إصلاحها. هل يمكننا إعادة إضافة النقل ثم تسجيل أننا واجهنا خطأ للتو؟ ربما شيء مثل:

logger.on("error", error => {
    //if your JS version doesn't have "includes(transport)", use another method like `.some(t => t===transport)`
    if (!logger.transports.includes(transport)) {
        logger.add(transport)
        logger.log("error", error)
    }
})

نعم ، لكن هذا مجرد إصدار آخر من تغيير عاجل (أي أنه يغير وظائف المكتبة الحالية) وأعتقد أن الآخرين سيرغبون في ذلك كخيار تكوين.

بالإضافة إلى ذلك ، قد يكون لديك العديد من وسائل النقل حيث قد ترغب في الاحتفاظ بالوظيفة الأصلية لإزالة النقل عند حدوث خطأ (لست متأكدًا تمامًا من سبب ذلك ، ولكنه سيكون تغييرًا عن الوظيفة الحالية).

ربما هذا "الإصلاح" لهذا هو توفير هذا الخيار وإما أن يكون افتراضيًا على صحيح في الوقت الحالي ، أو إصدار إصدار ثانوي مثل 3.3 مع تعطيل هذا الخيار و 4.0 مع تمكين الخيار؟ آراء من الآخرين؟ "التغيير العاجل" هو في الحقيقة مجرد تغيير في السلوك غير الموثق ، لذا سأشعر بالرضا عن جعله صحيحًا وإجراء تغيير طفيف في المراجعة.

في الواقع ، يبدو أنني قد أكون قادرًا على "إصلاح" هذا فقط عن طريق إضافة معالجة أثناء باعث حدث الخطأ. سيستمر في إخراج تحذير "رفض الوعد غير المعالج" إذا لم تقم بإرفاق مستمع "خطأ" بالمسجل (كما هو الحال الآن) ولكنه على الأقل لن يزيل النقل. العمل على العلاقات العامة الآن.

yinzara - هل تم إصلاح هذا بعد؟ قد أواجه المشكلة أيضًا ولكني لست متأكدًا

حتى أنني أضفت الشيء .on(error) لتسجيل الخطأ إذا كان موجودًا ، لكن لا شيء يظهر ...
إنه يتوقف فقط عن التسجيل ، يستمر console.log العمل على الرغم من أنني أعرف أن الكود الخاص بي قد تم الوصول إليه ...

هل جربت المقتطف الصغير من التعليمات البرمجية في العلاقات العامة المشار إليها؟

أي مقتطف؟ أضفت خطافًا مع

logger.on('error', (error) => {
    // stuff
    console.log('BlaBlaBla');
)

لكن لم يتم استدعاؤها!

https://github.com/yinzara/winston/commit/cec22d58f2fbe3bc089c7804a1dc99d645f5bc3d#diff -fa17001829435e6f871f6db7e13d84c3

قم بتغيير إصدار التبعية الخاص بك لـ Winston إلى:
yinzara/winston#cec22d58f2fbe3bc089c7804a1dc99d645f5bc3d

سأتحقق مما إذا كان هذا يصلح لي!

هذا الإصدار لم يصلح لي - لذلك ربما يكون شيئًا آخر لا أراه ...

لم نجرب رمز عنق الزجاجة. استند الكثير من مشكلاتنا حول حجم السجلات. إذا كان سجل معين يحتوي على JSON كبير ، فسيقوم Winston برفع وحدة المعالجة المركزية الخاصة بنا إلى 90٪ +. ومع ذلك ، إذا قمنا بتشديد JSON قبل تمريرها إلى Winston ، فإننا لا نرى مثل هذا الارتفاع الهائل. إذا واجهتنا مشكلات أخرى ، فسنراجع رمز عنق الزجاجة أعلاه.

لقد رأيت بعض الأمثلة التي تضبط الرسالة قبل إرسالها ، فهل هناك أي تعليمات في أي مكان حول القيام بهذا أو هذا الشيء الذي اكتشفه الناس للتو بالطريقة الصعبة؟

يا شباب. كنت أبحث عن حلول ومن المنطقي أن أواجه هذا النوع من المشكلات.
لقد رأيت أنه تم دمج العلاقات العامة من yinzara بنجاح كما ترون هنا

https://github.com/winstonjs/winston/blame/3d07a80a52f5c1df0f3a7823d7c08a350a30ac58/lib/winston/logger.js#L627

قبل 4 أشهر تمت الموافقة على PR ، ولكن تبين أنه تم نشر أي إصدار NPM مع هذا التحديث ، اتضح أن هذا الرمز غير مباشر.

تم تحرير الحزمة package.json كمثال آخر مرة 11f5ea2 on Aug 15, 2019

سأحاول اليوم الإصلاح المذكور هنا ، حول إعادة إدخال النقل onError ولكن أعتقد أنه يمكن نشر هذا حتى يتمكن الجميع من عمل سجلاتهم كما هو متوقع.

لا تزال تواجه هذه المشكلة. يمكن لأي شخص أن يساعد؟

أي تحديثات على هذا؟

أنا أستخدم 3.3.3 وما زلت أرى المشكلة. لا يتم عرض سجلات الإنتاج الخاصة بي. هل هناك من يعمل عليها؟

aniketkalamkar ليس حقا. في عام 2020 ، يعد pino بالتأكيد خيارًا أفضل بكثير كمسجل ، وليس لديه هذه المشكلة.

هل يتم التحقيق في هذه المشكلة؟ يستمر هذا في الحدوث كثيرًا عندما يذهب فيضان مفاجئ من جذوع الأشجار إلى وينستون.
لقد جربت كل ما ورد أعلاه حول العمل ، لا شيء يساعد.
التحول إلى مسجل آخر ليس شيئًا يمكنني القيام به بسهولة.

نفس القضية التي أثرتها منذ 1.5 عام. لا أعتقد أن هناك من يبحث في الأمر. قد يكون لدى الناس بعض المهام الأخرى ذات الأولوية في متناول اليد.
لذا فقط لتوفير وقتك ، يرجى البدء في التفكير في ترحيل المسجل CajunDust

لقد هاجرت إلى PinoJS وهو خيار أفضل بكثير. آسف على المشرفين ، لا أرغب في إنشاء هذا النوع من المنشورات ، لكنني استثمرت وقتًا طويلاً في محاولة إنجاز هذا العمل وكان لدي العديد من المشكلات ، ولهذا السبب أذكر مطوري البرامج الآخرين.