replace gin logger for requests #221
Conversation
WalkthroughThe changes introduce a custom Gin middleware for logging HTTP requests using zerolog, replacing the default Gin logger in the API server setup. The new middleware logs detailed request information, including latency and errors, at the debug level for each incoming request. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant GinRouter
participant LoggerMiddleware
participant Handler
Client->>GinRouter: Sends HTTP request
GinRouter->>LoggerMiddleware: Passes request
LoggerMiddleware->>Handler: Forwards request after logging start
Handler-->>LoggerMiddleware: Handles request, returns response
LoggerMiddleware-->>GinRouter: Logs details, passes response
GinRouter-->>Client: Sends HTTP response
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
cmd/api.go(1 hunks)internal/middleware/logger.go(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
cmd/api.go (1)
internal/middleware/logger.go (1)
Logger(11-50)
🔇 Additional comments (2)
internal/middleware/logger.go (1)
3-8: LGTM on imports and package structure.The imports are appropriate and the package structure follows Go conventions.
cmd/api.go (1)
51-51:❓ Verification inconclusive
Verify log level configuration for production compatibility.
The replacement of
gin.Logger()withmiddleware.Logger()is implemented correctly, but there's an important operational consideration: the custom middleware logs at debug level while Gin's default logger typically logs at info level.Please verify that the application's log level configuration will allow debug-level logs to be visible in production, or consider updating the custom middleware to use info level logging.
🏁 Script executed:
#!/bin/bash # Description: Check for log level configuration in the codebase # Expected: Find configuration that sets log level, verify if debug logs will be visible echo "Searching for log level configuration..." rg -i "level|loglevel|log_level" --type go -A 2 -B 2 echo -e "\nSearching for zerolog level configuration..." rg "zerolog.*level|level.*zerolog" --type go -A 2 -B 2 echo -e "\nSearching for environment variable usage for logging..." rg "LOG_LEVEL|LOGLEVEL" --type go -A 2 -B 2Length of output: 3065
Ensure HTTP logs are visible with the new middleware
The switch from
gin.Logger()to your custommiddleware.Logger()means request logs are emitted at debug level, but by default the global log level is set to WARN (seeinternal/log/logger.go). Ifconfig.Cfg.Log.Level(backed by the--log-levelflag incmd/root.goandconfigs/config.go) isn’t explicitly set todebug, those logs will be suppressed.Please verify one of the following:
- You’re configuring
log.leveltodebugin production so that HTTP access logs remain visible.- Or update
middleware.Logger()to emit at info level instead, matching Gin’s default behavior.Relevant locations:
- cmd/api.go (L51): replaced
gin.Logger()→middleware.Logger()- internal/log/logger.go: default
zerolog.WarnLevel- cmd/root.go & configs/config.go: definition and binding of
log.level
TL;DR
Replace Gin's default logger with a custom zerolog-based logger middleware.
What changed?
Logger()middleware function ininternal/middleware/logger.gothat uses zerolog for structured loggingcmd/api.goto use the custom logger middleware instead of Gin's default loggerHow to test?
Why make this change?
The custom zerolog-based logger provides more structured logging compared to Gin's default logger. This makes logs easier to parse, filter, and analyze, especially in production environments. Using zerolog consistently throughout the application also ensures a uniform logging format.
Summary by CodeRabbit
New Features
Refactor