Sending JSON is broken

[wyqydsyq]

Setting the json option to true results in my log never actually reaching loggly, no error gets thrown and the Winston transport isn't emitting it's error event either, so it causes logging to silently fail.

This issue can be worked-around by not specifying json: true in the options, and manually JSON.stringifying the log body e.g:

Instead of:

function loggerFactory() {
  const logglyTransport = new (require('winston-loggly-bulk')).Loggly({
    subdomain: process.env.LOGGLY_SUBDOMAIN,
    token: process.env.LOGGLY_TOKEN,
    tags: tags || [],
    json: true,
  })

  const winston = new (require('winston')).Logger({
    transports: [logglyTransport],
  })

  return function(fields: Fields) {
    winston.log(fields.level, fields)
  }
}

Use:

function loggerFactory() {
  const logglyTransport = new (require('winston-loggly-bulk')).Loggly({
    subdomain: process.env.LOGGLY_SUBDOMAIN,
    token: process.env.LOGGLY_TOKEN,
    tags: tags || [],
  })

  const winston = new (require('winston')).Logger({
    transports: [logglyTransport],
  })

  return function(fields: Fields) {
    winston.log(fields.level, JSON.stringify(fields))
  }
}

[Shwetajain148]

Hi @wyqydsyq, Please give me some time to finish my ongoing issues. I'll try to reproduce once I get some time.

Thanks for reporting.

[elfilip]

I can't reproduce this. Json option works for me fine.

[monbrey]

I've encountered the same issue - it seems that JSON cannot be sent if no message string is provided.
Example

winston.info("Message")
// logs { json: { level: "info", message: "Message", timestamp: <time> } } to Loggly
winston.info("Message", { prop: "value" } )
// logs { json: { level: "info", message: "Message", prop: "value", timestamp: <time> } } to Loggly
winston.info({ prop: "value" })
// logs { json: { level: "info", timestamp: <time> } } to Loggly

If JSON is the only parameter, it seems to be ignored

[wyqydsyq]

Ah that makes sense as to why some couldn't reproduce, I think in my case I didn't specify a message property in the JSON object while I assume most people would.

Seems there's some kind of internal check/processing happening on body.message in the log handler for this transport (or somewhere along it's call stack) and the transport is silently dropping the log event if it is unable to find/extract a value from that property instead of just submitting the log event without it as would be expected.

[monbrey]

Working on this today, I’ve found that Loggly also has a “feature” which drops fields from the parser if their type had changed (eg from string to object) which might also be causing the issue

[alestrunda]

works in version 3