-
Notifications
You must be signed in to change notification settings - Fork 14
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
logs: simplify the bpfman-agent logs #336
base: main
Are you sure you want to change the base?
Conversation
As part of a security review which required extend logging behaviour, investigated improving the logs. Moved the logs from using context, which prints a lot if useless info, to just using regular logs. Signed-off-by: Billy McFall <[email protected]>
Here is the current logs, from a KIND cluster at boot, and running Original Logs
After Change
|
6c3cbc3
to
5f754a4
Compare
I'm still struggling with
Recently was reviewing an OpenShift cluster logs, which had a lot more pods than my KIND cluster, and the logs were just filled with these type logs. However, if something does change, we need to know. |
5f754a4
to
5a16ecb
Compare
Is it possible to tell that we were called because of a pod change, and then make the log debug if it is? If something does change, though, we'd like to know, so it would be good if there's some trace of it when things are changing. |
Should we also make the "*Controller found no * Programs" log debug in all cases? |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #336 +/- ##
==========================================
- Coverage 27.64% 27.60% -0.04%
==========================================
Files 87 87
Lines 7499 7495 -4
==========================================
- Hits 2073 2069 -4
Misses 5226 5226
Partials 200 200
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Not that I could find. I found a couple of discussions on the topic, but the answer was always that you shouldn't care why you were called, just reconcile to the desired state. |
I found a way to determine if
|
r.Logger = log.FromContext(ctx) | ||
r.Logger = ctrl.Log.WithName("tc") | ||
|
||
r.Logger.Info("bpfman-operator enter: TC", "Name", req.NamespacedName) |
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.
Should we have this log for all program types?
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.
Looks good other than one question.
@@ -73,7 +72,7 @@ func (r *BpfmanConfigReconciler) SetupWithManager(mgr ctrl.Manager) error { | |||
} | |||
|
|||
func (r *BpfmanConfigReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) { | |||
r.Logger = log.FromContext(ctx) | |||
r.Logger = ctrl.Log.WithName("configMap") |
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.
all reconciller object has Logger
type ReconcilerCommon struct {
client.Client
Scheme *runtime.Scheme
Logger logr.Logger
}
so we just need to initialize in the operator and agent main and use it here and all places below ?
As part of a security review which required extend logging behavior, investigated improving the logs. Moved the logs from using context, which prints a lot if useless info, to just using regular logs. Also changed the logging default from debug to info, and changed the level of some of the existing logs.