Next.js: Feature request: make logging possible on custom server

[Janpot]

Feature request

Is your feature request related to a problem? Please describe.

Using custom server interferes with other logging in my app.

Describe the solution you'd like

A way to silence next and an interface to tap into ready, recompile, error events.

const app = next({ dev: true, quiet: true })
app.on('ready', myLogger.info);
app.on('recompile', myLogger.trace);
app.on('error', err => myLogger.error('something went wrong', { err }));

const handle = app.getRequestHandler()
// ...

[Janpot]

@timneutkens I would like to find a way to integrate the logging of the request handler into my logging/monitoring infrastructure. I guess it would need some refactoring on next side to be able to hook into this. I don't mind trying to cook up a PR for this if this is something you'd like to add. Right now I see two directions this can be implemented:

1. provide a logger instance in the style of things like pino. If you want to overwrite logging, you can just pass your own.
2. "silence" next with a verbose: false flag or stdout: null (or another stream) or something. And add events that report on the different stages of the app compiling, compiled, error,...

What are your thoughts on this?

[ravinggenius]

Is there any interest in this? I have a custom server, and I'd really like to unify my log output. I'm personally fine with either approach. Passing in a custom logger sounds easier for Next users (developers), though adding a silent option and emitting logging events would be more flexible.

@timneutkens, @rauchg Thoughts? If bandwidth is an issue I can probably get something working in my spare time over the next few weeks.

[bensaufley]

More than this, I'm using pino-http for my logging and it attaches a bunch of metadata to every log entry; error logging would be _much_ more useful if I were able to get that information on errors. A simple error handler would be better than nothing, but I'd prefer something even more granular.

It seems to me that Next.js is intercepting these errors so neither Sentry.io (which we use for error reporting) nor our server-level try/catch receive the error to handle or log it. This is really inconvenient. It seems like the ideal solution would be just _not_ to catch these errors in a custom server (maybe a flag… catch (e) { if (process.env.NEXT_HANDLE_ERRORS === 'false') throw e; }) and let my top-level server catch them and handle them.

[adamhathcock]

Allowing some way to attach a customizable logger to Next's logging would be great for me.

I log JSON to stdout for Docker and use Next as a custom server.

[oswaldoacauan]

Did anyone found a workaround? We are trying to integrate Rollbar and Datadog and this would be great.

[ravinggenius]

My "workaround" is to just filter out non-JSON lines. Using roarr:

npm run start | npx roarr filter --context 0 --exclude-orphans '{ "context.logLevel": { gt: 10 } }' | npx roarr pretty-print

My solution for pino is similar, but I had to use jq to filter offending lines.

[Ianfeather]

Just want to bump this issue. Not being able to have structured logs emit from next is a real limitation. Would love to see an api like:

const app = next({ dev: true, logger: myLogger })

and happy to work on this if you'd be willing

[shakedlokits]

Bumping it again, this is important, would be happy if it would exist.

[MaxmaxmaximusGitHub]

Сustomizing log system is a fundamental thing that should be exists from the start, plus all of the above

[MaxmaxmaximusGitHub]

Сustomizing log system is a fundamental thing that should be exists from the start. Bump.

[kraiovsky]

+1 this would be good improvement

in the meantime, how do you guys log response body with your pino or pino-http solutions?

[ravinggenius]

I added an Express middleware to log each request. pino-http makes this easy.

This works because each route hits the server, whether rendering on the server (HTML) or client (JSON).

[bensaufley]

That doesn't handle this problem though, because as soon as inside your Express handler you _hand off_ the request to next, pino has no jurisdiction and everything gets outputted to stdout or stderr again. You can log the initial request but as soon as you call handle or whatever, logging is taken out of your hands.

[kraiovsky]

I ended up creating a custom serializer for next req/res: file
a higher-order function that takes that logger, and wraps around API handler: file
example of usage: file

project repo

if there is some interest, I could convert it into a package that would take other loggers and more middlewares to run.

[daviduzumeri]

+1 to this being sorely missed; we've got stdout logging to DataDog with structured logs for all of our other services and now it's just constantly interspersed with Next.js's line logging being noise.