Hey everyone! I’m working on a Golang backend for my project and I’m not sure about the best way to handle logging. I’ve got slog for logging and chi for routing, but I’m wondering if I’m doing it right.
Right now, I’ve got the chi logger middleware turned on, but I’m thinking maybe it’s not that useful in production. It seems like it might just be adding unnecessary stuff to the logs.
I’ve got a couple of questions:
- Is it worth keeping the router logging, or should I turn it off for production?
- Where should I be putting logs in my code? Just in the handlers and services, or should I add them in the storage layer too?
I’m pretty new to this, so any tips or suggestions would be super helpful! If you know any good articles or resources about logging in Go, I’d love to check those out too.
Thanks in advance for any help!
hey there! have you considered using a logging library like zerolog? it’s super awesome for structured logging and really easy to use. i’m curious, what kind of info are you trying to capture in your logs? maybe we could brainstorm some ideas for what to log where. btw, have you thought about adding tracing to your app? it can be a game-changer for debugging!
As someone who’s worked on several Golang backend projects, I can share my experience with logging practices. In production, I typically disable router logging as it can generate excessive noise without providing much value. Instead, I focus on strategic logging in key areas of the application.
I recommend placing logs in handlers for capturing important request/response details, in services for tracking business logic flow, and in the storage layer for database operations or performance metrics. This approach provides a comprehensive view of your application’s behavior without overwhelming your logs.
For structured logging in Go, I’ve found zap and zerolog to be excellent alternatives to slog, offering better performance and flexibility. Remember to use log levels appropriately - reserve ERROR for actual errors, use INFO for significant events, and DEBUG for detailed troubleshooting information.
Lastly, consider implementing a correlation ID system to trace requests across different parts of your application. This can be invaluable when debugging issues in a distributed system.
yo, i’ve been there! for production, i usually ditch the router logging. it’s just noise, ya know? focus on logging in handlers and services. that’s where the real juice is. maybe add some in storage if you’re doing complex db stuff. oh, and check out logrus - it’s pretty sweet for golang logging. keep it simple, dude!