-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add capability to set loglevel to trace during runtime #1171
Add capability to set loglevel to trace during runtime #1171
Conversation
7abb780
to
d4f4d81
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be fantastic if we could move the common logic of changing the log level into SDK. then it can be reused in different components much easier.
You mean something like adding a function that encapsulates all this signal thing to the sdk, and just calling a single function from the cmds? It sounds awesome, I feared that I would have to copy paste the current pr to every cmd, but this makes it a lot easier, I'll look around. |
main.go
Outdated
func handleLogChangeSignal(ctx context.Context, ch chan os.Signal, logLevel logrus.Level) { | ||
OUT: | ||
for { | ||
select { | ||
case <-ctx.Done(): | ||
break OUT | ||
case sig := <-ch: | ||
switch sig { | ||
case syscall.SIGUSR1: | ||
log.FromContext(ctx).Infof("Setting log level to %s", logrus.TraceLevel.String()) | ||
logrus.SetLevel(logrus.TraceLevel) | ||
case syscall.SIGUSR2: | ||
log.FromContext(ctx).Infof("Setting log level to %s", logLevel.String()) | ||
logrus.SetLevel(logLevel) | ||
} | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I wonder, does it make sense to run the pprof server in case of enabling trace level via signals?
cc @szvincze
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@denis-tingaikin: Since the TRACE log level could have influence on the different profiles, like CPU and memory, I would not tie the log level and profiling together but keep them separately configurable. If someone needs both activated then configure them one by one.
d4f4d81
to
a71ced1
Compare
Put the implementation here, not sure whether the log directory, or the logrus subdirectory would be preferred, but this way, I could just use function from the log module directly which was convenient. |
1a5faf0
to
94bfc9b
Compare
logruslogger.SetupLevelChangeOnSignal(ctx, map[os.Signal]logrus.Level{ | ||
syscall.SIGUSR1: logrus.TraceLevel, | ||
syscall.SIGUSR2: level, | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tihnk we can ignore it if current lelvel is trace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure, I don't think its worth adding an extra 'if' statement to check against the config. It shouldn't matter that much the worst case would be having a few extra lines of log stating that the current level is trace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think adding a new 'if branch' is lesser evil than having extra goroutine and subscription on the signals.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay, you convinced me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I agree that it would be better to not add a new if branch; probably we could add a check on signal map size in the 'SetupLevelChangeOnSignal' and say if size is less than 2, then do nothing. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:'D how about we add it to the function in the sdk instead? :'D
run golangci-lint Running [/home/runner/golangci-lint-1.53.3-linux-amd64/golangci-lint run --out-format=github-actions --timeout 3m --verbose] in [] ... Error: cyclomatic complexity 16 of func
main is high (> 15) (gocyclo)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I agree that it would be better to not add a new if branch; probably we could add a check on signal map size in the 'SetupLevelChangeOnSignal' and say if size is less than 2, then do nothing. Thoughts?
Yeah sounds good
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean yeah in addition to checking if the original level is not trace, in addition to that it is a correct opinion to check the map's size too yeah.
94bfc9b
to
bc6cb95
Compare
Signed-off-by: Arpad Kiss <[email protected]>
bc6cb95
to
e65b67e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…d-forwarder-vpp@main PR link: networkservicemesh/cmd-forwarder-vpp#1171 Commit: d876631 Author: Arpad Kiss Date: 2024-10-08 02:35:18 +0200 Message: - Add capability to set loglevel to trace during runtime (#1171) Signed-off-by: NSMBot <[email protected]>
…d-forwarder-vpp@main (#12369) PR link: networkservicemesh/cmd-forwarder-vpp#1171 Commit: d876631 Author: Arpad Kiss Date: 2024-10-08 02:35:18 +0200 Message: - Add capability to set loglevel to trace during runtime (#1171) Signed-off-by: NSMBot <[email protected]> Co-authored-by: NSMBot <[email protected]>
networkservicemesh/deployments-k8s#12296