vestal iris
Hey folks,
I'm currently using the default Logger in my production environment, and going through logs in the terminal when issues arise is becoming a bit cumbersome. I've heard about ELK Stack for more effective logging. Can anyone share some guidance on better practices for handling logs in a production setup? What tools or approaches do you recommend to streamline the process and make troubleshooting more efficient?
remote lintel
Use nestjs-pino. It's one of the best performing library and can produce JSON-structured logs. With regards to log aggregation, I typically rely on the log aggregation services provided by the hosting platform (if using one of the big platforms - AWS, GCP, etc.) That said, you could use Better Stack Logs (https://betterstack.com/logs) or ELK or Loki from Grafana.
My advice would be to not overdo and overthink it. Keep it simple. Write logs to stdout when using Docker and let the log aggregation service do the rest. Make sure logs are JSON-structured and that whatever service you use allows you to filters logs by the properties in JSON documents.
vestal iris
@remote lintel right now i'm just write logs to stdout using the default Nest JS logger & console.log here and there. i'm running most of the production apps using pm2. i've never used a log aggregator. cause i'm doing on B2B products, each app is running on totally different servers and services. reading logs from pm2 is a tedious job.
nestjs-pino looks good, i'll give that a try. logging to a file and rotating the file seems like a good approach if i'm not using an aggregator. i could keep logs for 1 day in 1 file. easier for me to check, ig.
remote lintel
I recommend you avoid using console.log because it's synchronous and a single console.log will halve the performance of your server. I benchmarked it at one point, see the screenshot.
umbral hemlock
I recommend you avoid using console.log because it's synchronous and a single co...
Hey, interested to know what metrics I'm looking at. Is it saying adding a console log knocks the amount it can process from 16k to 11 k
And holy crap we really need to shift to fastify
remote lintel
Yes, exactly @umbral hemlock ! Console.log is synchronous and a blocking call.
umbral hemlock
Yes, exactly <@337913002512744448> ! Console.log is synchronous and a blocking c...
I honestly in all my years never gave it a glancing thought that it could have such an impact . Looks like you can teach on old dog new tricks 😆
remote lintel
Keep in mind this is a synthetic benchmark, the app did not do anything useful and in the real world, network and DB requests will become your main bottleneck so unless your API only does some computations without hitting external services, you're likely to see much worse performance. Depends on the implementation but still staggering difference. The main point of the benchmark was to show the impact of a single console.log. All the tools from https://twitter.com/matteocollina are performance focused - Fastify, Mercurius, etc.