Closed ryanfitzer closed 2 years ago
Its worth clarifying that this is only for server-side logs - for intercepting console.log
(and similar methods) where ever you're running your server. Browser/client side logging is an orthogonal problem, that's solved through application functionality, using tools like New Relic or Sentry.
I suspect you could add a custom transport to pino
to send logs to an endpoint, but its an anti-pattern in your architecture. Your application should be unconcerned with where its logs go, beyond emitting logs as soon as they happen, in an ingestible format (for example, JSON), tostdout
. From here, your infrastructure, orchestrator, or application host should be responsible for handling your logs.
If you want your logs to go to another service, you'd handle this within your infrastructure - for example, using fluentd
for ingestion into ElasticSearch and Kibana, or CloudWatch on AWS. The suggestion in the Pino transports docs is piping your application's stdout
to another process.
I'm going to close this, as options for getting this working and recommendations for good practice have been provided.
I'm new to logging and the complexities of doing so in Next.js makes things even more difficult, so thanks for your effort on this module.
Can you give me an idea as to how to configure
next-logger
to send server-side/browser logs to an endpoint? Would this be done using the@beta
version and passing a transport to thepino
instance that is supplied to the config's exported function?