Refactor calls to debug messages in all services#632
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR refactors calls to debug messages across API and Admin handlers, replacing dynamic backend settings retrieval with static boolean flags. Key changes include:
- Removing dependency on settings by replacing h.Settings.DebugHTTP(...) with fixed true/false values.
- Cleaning up unused imports related to the settings package.
- Standardizing the debug flag usage across services (osctrl-api, osctrl-admin, and osctrl-tls).
Reviewed Changes
Copilot reviewed 25 out of 25 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| cmd/api/handlers/*.go | Replaced dynamic debug flag call with static booleans. |
| cmd/admin/handlers/*.go | Updated all debug calls to use fixed values and removed settings imports. |
|
@zhuoyuan-liu please take a look, thanks! |
zhuoyuan-liu
left a comment
There was a problem hiding this comment.
Good job! I left a small comment. However, I do have some suggestions if you're interested in further modernizing osctrl.
-
Reducing Global Variables and Direct Dependencies
Relying too much on global variables and direct dependencies can make the code messy and hard to manage. It can lead to unexpected bugs, tricky testing, and parts of the code depending on each other in ways that aren’t obvious. Using dependency injection helps by making it clear what each part of the code needs, making testing easier, and allowing components to be reused more easily. -
Separating Handler Responsibilities
When handlers handle too much—like HTTP requests, business logic, and database work—it leads to messy and repetitive code. Splitting things into layers, where handlers only deal with HTTP, services handle logic, and repositories manage data, makes the code easier to test, reuse, and maintain. It also keeps errors and responses consistent across the application.
pkg/utils/http-utils.go
Outdated
| log.Debug().Msg(DebugHTTP(r, debugCheck, showBody)) | ||
| } | ||
| func DebugHTTPDump(r *http.Request, showBody bool) { | ||
| log.Debug().Msg(DebugHTTP(r, showBody)) |
There was a problem hiding this comment.
In this case, the whole DebugHTTP function will be executed. This can lead to unnecessary overhead. To avoid this overhead, you should conditionally check the log level before executing the operations:
if log.Debug().Enabled() {
// something
}There was a problem hiding this comment.
Just pushed these changes, let me know what you think! And if you have more examples of how to implement the two points mentioned above, feel free to point them out, I am always happy to improve osctrl!
There was a problem hiding this comment.
I would suggest putting the check in this function to make the code more readable.
func DebugHTTPDump(r *http.Request, showBody bool) {
if log.Debug().Enabled() {
log.Debug().Msg(DebugHTTP(r, showBody))
}
}
pkg/utils/http-utils.go
Outdated
| log.Debug().Msg(DebugHTTP(r, debugCheck, showBody)) | ||
| } | ||
| func DebugHTTPDump(r *http.Request, showBody bool) { | ||
| log.Debug().Msg(DebugHTTP(r, showBody)) |
There was a problem hiding this comment.
I would suggest putting the check in this function to make the code more readable.
func DebugHTTPDump(r *http.Request, showBody bool) {
if log.Debug().Enabled() {
log.Debug().Msg(DebugHTTP(r, showBody))
}
}| } | ||
| debug += fmt.Sprintf("%s\n", "---------------- end") | ||
| debug = fmt.Sprintf("%s\n", "---------------- request") | ||
| requestDump, err := httputil.DumpRequest(r, showBody) |
There was a problem hiding this comment.
I just realized that it logs everything from the request, which seems excessive and comes with several drawbacks:
- Log Volume – It generates a large number of logs, making search and analysis more difficult.
- Security Concerns – Some headers may contain sensitive information that should not be logged.
- Formatting – I'm unsure how this would look when integrated with
zerolog. Do you have an example?
In production, these logs might add too much noise, making it harder to diagnose issues when something goes wrong. I’d love to hear more about how you use these logs and whether there are ways to refine them.
There was a problem hiding this comment.
This is a good point, I believe this was a function I used a lot in the early stages of the osctrl development, but now it would make more sense to:
- Have the ability to only dump HTTP traffic for certain nodes and not every received request.
- Format the output to follow
zerologoutput, so it will be easier to utilize, even log to a different log file.
Does it make sense to remove it completely?
There was a problem hiding this comment.
If these logs have been rarely used recently, I’d suggest removing them. In our use case, osctrl handles 100+ requests per second, and these logs would likely add unnecessary pressure.
I understand they might be useful in certain cases, especially during development. If we need to keep them, we could use a feature flag to control logging, enabling it only in the development environment. So, it would not be mixed with other debug log messages.
E.g. --enable-http-dump=true
There was a problem hiding this comment.
I just added a new commit with three new flags in all services:
--enable-http-debug--http-debug-file--http-debug-show-body
So if needed, this must be enabled with a flag, which will reduce the risk of logs taking up too much space. And the logs will go to a different file and not stdout.
Let me know what you think! Thanks!
zhuoyuan-liu
left a comment
There was a problem hiding this comment.
LGTM. However, I believe that as osctrl matures, we will eventually remove these debug logs since they reduce code readability and provide limited value.
cmd/api/handlers/handlers.go
Outdated
|
|
||
| func WithDebugHTTP(logger *zerolog.Logger, cfg *config.DebugHTTPConfiguration) HandlersOption { | ||
| return func(h *HandlersApi) { | ||
| h.DebugHTTP = logger |
There was a problem hiding this comment.
It could be a good example of "Reducing Global Variables and Direct Dependencies". Instead of relying on the global log variable/package, you can assign the logger to your main server(strcut).
cmd/tls/main.go
Outdated
| // If enabled, prepare debug HTTP logger | ||
| if debugHTTP.Enabled { | ||
| // Open or create the debug HTTP log file (append mode) | ||
| debugFile, err := os.OpenFile( |
There was a problem hiding this comment.
Do you have any idea about the log file truncate or rotation? If it is deployed in k8s cluster or docker, you may need extra tools/steps for handling these log files. Since we would never enable them in Prod, it should be fine.
There was a problem hiding this comment.
I can probably do something like https://github.com/jmpsec/osctrl/blob/main/pkg/logging/file.go to handle logs rotation. But for now, since this should be enabled only in dev, and it will require the flag and service restart, there should not be any mistake and it ends up turned on. I will send a PR next to cleanup all the DebugHTTP in osctrl-admin and settings. Thanks!
osctrl-tls,osctrl-adminandosctrl-apito all calls of debug messages to avoid getting the setting value from the backend.--enable-http-debug--http-debug-file--http-debug-show-body