[Q] How to log JSON to console and get cloudwatch logs pick up correct metadata?

[tuananh]

This is more like a question of how pino does it.

winston.info('Hello again distributed logs', { app: 'test', sid: 1 })

pino.info('Hello again distributed logs', { app: 'test', sid: 1 })

Output:

{"app":"test","sid":1,"level":"info","message":"Hello again distributed logs","timestamp":"2017-02-16T03:34:06.186Z"}
{"pid":4269,"hostname":"Macchiato.local","level":30,"time":1487216046197,"msg":"Hello again distributed logs {\"app\":\"test\",\"sid\":1}","v":1}

I have fluentd daemon to pickup container stdout and ship it to cloudwatch.

In the example above, cloudwatchlogs can detect the metadata correctly from pino and I will be able to query the log like this

{$.app = "test"}

However, winston console is not working like that and everything got push to log attribute.

Does anyone know how to fix this. I'm using winston console with json: true and stringify: true

Ref: winstonjs/winston#985

[davidmarkclements]

you're saying that query works with pino but not winston...

At a guess I'd say cloudwatch is parsing the msg field and then running the query agains the object found in the msg field?

At any rate - typically we recommend using pino style transports https://github.com/pinojs/pino/blob/master/docs/transports.md but the pino-cloudwatch transport is still to do (volunteers welcome :D -- see #33)

Can't help with winston settings I'm not familiar, maybe ask the Winston authors?

[tuananh]

@davidmarkclements

hi, yes it works with pino.

my setup is like this: i use pino to print to console and has fluentd ship the logs to cloudwatch (batch ship, retry, etc..)

however, for another project at work, we use winston and cloudwatch doesn't pick up the metadata correctly so i was wondering what pino does differently.

I tried asking in winstonjs project but no answer just yet so I thought i might try it here.

[jsumners]

My answer is: migrate to Pino at work. The deadness of the Winston project is one of the factors that drove me to look for alternatives. For example, look at the long idle time on their PR number 835 and the lack of work on the associated issue.

[tuananh]

@jsumners i guess it' the sensible thing to do. Thanks

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.