pino-debug

[davidmarkclements]

pino-debug

[jsumners]

I like the options object route. But I do understand the desire to replicate as much as possible the debug methodology. I would be happy if the options object accepted a useEnv: true property so that it is clear to the reader where to look for the rest of the configuration. And any other properties supplied, trace, info, etc. could override the settings in the environment.

[jsumners]

I have used debug once or twice because it seemed to be "the way things are done." But I'm not really a fan. In my opinion the reasoning behind debug is that the library using it shouldn't have its own logger because it is meant to be included in a larger application (which would have its own logger). I think in such cases that if logging is to be done then it should:

1. require abstract-logging
2. log all development, aka debug, logs to .trace()
3. log error messages to .error()
4. log error stack traces to .debug()
5. tell the user of the library that they can supply an abstract-logging compatible logger to get messages, e.g. pino

Items 3 and 4 are optional; I just like to do it that way.

That being said, I'm not opposed to pino-debug existing.

[mcollina]

I'm not fond of the idea of pino-debug. We should probably do something new for development. Recently I'm doing tap test.js | pino to get some good looking output.

We can easily draw some parallelism between debug ENV filters and pino child loggers. We might just need a way to control those using ENV.

[marwanhilmi]

Perhaps another interesting idea is to at least capture debug logs. Many libraries are using debug internally, so it would be great if we could setup Pino to capture those logs and route to a single location.

[davidmarkclements]

@marwanhilmi you've just opened up a whole new way to think about this

require pino-debug in your entry point, if NODE_ENV is production, all debug logs are enabled but go through pino (also, we could allow a mapper, so each name space could be mapped to a log (info, error, debug etc) type if desired.

This would really create a logging firehose because all you deps logs (and core too if we want) would be turned on

[mcollina]

Let me want to address two problems:

a. intercept the debug content of dependencies we have no control with
b. easy migration from debug of apps from debug to pino

IMHO, we should do the first.
If NODE_ENV=production and if NODE_DEBUG=express:*, all express related content ends up in the debug (or trace?) debug layer. Enabling everything is a little bit scary, because we might loose some flexibility that debug gives us.

[davidmarkclements]

i think 1 too - what if we actually do

$ PINO_TRACE=fs,net,http PINO_DEBUG=express:* PINO_INFO=myApp:* node app.js

[jsumners]

I really don't like relying on environment variables. They are an external state that make it difficult to figure out what is wrong when their presence is missing or they are set incorrectly.

[mcollina]

I absolutely agree with you @jsumners. This is a way to get some data out from debug. I'm not even sure it's a good idea.

[davidmarkclements]

the value here for a production set up is fine grain control over debug output that's in the same logging format, with minimum overhead.

The other way is an options object

require('pino-debug')({
  trace: 'fs, http, net',
  debug: 'express:*',
  info: 'myApp:*'
})

[davidmarkclements]

PoC - https://github.com/pinojs/pino-debug
Note the benchmarks: https://github.com/pinojs/pino-debug#benchmarks

Only thing left is to get feedback and write unit tests /cc @jsumners @mcollina

[davidmarkclements]

also try out the example folder (express app with pino-debug)

[mcollina]

Preloaders are awesome. Go ahead and release that, add something to the README over here as well. Good job Dave!

[jsumners]

Very crafty. I'm quite impressed.

Seeing how you're applying runbench to more things, I suppose it really should be made into its own module. Let's discuss it and figure out what it would really need to be complete.

[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.