-
Notifications
You must be signed in to change notification settings - Fork 981
application failover klog structured logging #6566
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
base: master
Are you sure you want to change the base?
application failover klog structured logging #6566
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
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.
Summary of Changes
Hello @SujoyDutta, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request begins the process of adopting structured logging within the application failover controllers. The core change involves updating existing klog
statements to use structured logging functions, aiming to make log data more consistent, parsable, and easier to analyze for debugging and monitoring purposes.
Highlights
- Structured Logging Adoption: Initiated the migration of
klog
calls from traditional printf-style formatting (klog.Errorf
,klog.Infof
) to structured logging equivalents (klog.ErrorS
,klog.InfoS
). - Improved Log Parsability: Enhanced log messages by converting variable arguments into explicit key-value pairs, which significantly improves machine readability and programmatic analysis of logs.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command>
or @gemini-code-assist <command>
. Below is a summary of the supported commands.
Feature | Command | Description |
---|---|---|
Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/
folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
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.
Code Review
This pull request migrates logging calls to use klog's structured logging capabilities across the application failover controllers. The changes correctly adopt the InfoS
and ErrorS
functions. My feedback focuses on improving the consistency and clarity of log keys in crb_application_failover_controller.go
to make them more descriptive and align better with structured logging best practices.
@@ -59,7 +59,7 @@ type CRBApplicationFailoverController struct { | |||
// The Controller will requeue the Request to be processed again if an error is non-nil or | |||
// Result.Requeue is true, otherwise upon completion it will remove the work from the queue. | |||
func (c *CRBApplicationFailoverController) Reconcile(ctx context.Context, req controllerruntime.Request) (controllerruntime.Result, error) { | |||
klog.V(4).Infof("Reconciling ClusterResourceBinding %s.", req.Name) | |||
klog.V(4).InfoS("Reconciling ClusterResourceBinding", "name", req.Name) |
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.
For consistency and clarity in structured logging, it's better to use a more specific key for the resource name. The corresponding controller for ResourceBinding
uses resourceBinding
as a key. Here, clusterResourceBinding
would be a more descriptive key than name
.
klog.V(4).InfoS("Reconciling ClusterResourceBinding", "name", req.Name) | |
klog.V(4).InfoS("Reconciling ClusterResourceBinding", "clusterResourceBinding", req.Name) |
@@ -132,7 +132,7 @@ func (c *CRBApplicationFailoverController) syncBinding(ctx context.Context, bind | |||
|
|||
err := c.evictBinding(binding, needEvictClusters) | |||
if err != nil { | |||
klog.Errorf("Failed to evict binding(%s), err: %v.", binding.Name, err) | |||
klog.ErrorS(err, "Failed to evict binding", "binding", binding.Name) |
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.
The key binding
is a bit generic and could be ambiguous. A more descriptive key like clusterResourceBinding
would improve log clarity and consistency with other parts of the codebase.
klog.ErrorS(err, "Failed to evict binding", "binding", binding.Name) | |
klog.ErrorS(err, "Failed to evict binding", "clusterResourceBinding", binding.Name) |
@@ -153,7 +153,9 @@ func (c *CRBApplicationFailoverController) evictBinding(binding *workv1alpha2.Cl | |||
for _, cluster := range clusters { | |||
taskOpts, err := buildTaskOptions(binding.Spec.Failover.Application, binding.Status.AggregatedStatus, cluster, CRBApplicationFailoverControllerName, clustersBeforeFailover) | |||
if err != nil { | |||
klog.Errorf("failed to build TaskOptions for ClusterResourceBinding(%s) under Cluster(%s): %v", binding.Name, cluster, err) | |||
klog.ErrorS(err, "Failed to build TaskOptions for ClusterResourceBinding under Cluster", | |||
"binding", binding.Name, |
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.
@@ -225,7 +227,7 @@ func (c *CRBApplicationFailoverController) clusterResourceBindingFilter(crb *wor | |||
resourceKey, err := helper.ConstructClusterWideKey(crb.Spec.Resource) | |||
if err != nil { | |||
// Never reach | |||
klog.Errorf("Failed to construct clusterWideKey from clusterResourceBinding(%s)", crb.Name) | |||
klog.ErrorS(err, "Failed to construct clusterWideKey from clusterResourceBinding", "binding", crb.Name) |
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.
The key binding
is a bit generic. A more descriptive key like clusterResourceBinding
would improve log clarity and consistency.
klog.ErrorS(err, "Failed to construct clusterWideKey from clusterResourceBinding", "binding", crb.Name) | |
klog.ErrorS(err, "Failed to construct clusterWideKey from clusterResourceBinding", "clusterResourceBinding", crb.Name) |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #6566 +/- ##
==========================================
- Coverage 45.36% 45.34% -0.03%
==========================================
Files 687 687
Lines 56358 56389 +31
==========================================
Hits 25568 25568
- Misses 29194 29225 +31
Partials 1596 1596
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
22f77ff
to
e16fa60
Compare
/assign |
@SujoyDutta , thanks for this contribution! Generally looks good. Please update to use the keys |
Thanks @jabellard updated, please take a look and lmk if i missed anything . Thanks ! |
/lgtm /cc @RainbowMango for another look. |
@SujoyDutta , Also, please make sure to squash your commits after making change to make sure the PR is ready to get merged. |
In addition, it is recommended to add your email to GitHub Emails, otherwise, GitHub can't recognize you and count your contributions. PS: It is exactly the reason why GitHub still recognizes you as the |
Signed-off-by: sdutta133 <[email protected]> fix lint issues fix cicd Signed-off-by: sdutta133 <[email protected]> consistent naming Signed-off-by: sdutta133 <[email protected]>
79ce9de
to
3bd480e
Compare
New changes are detected. LGTM label has been removed. |
Generally looks good to me. /cc @RainbowMango for another look. |
What type of PR is this?
structured logging support. More details are highlighted in
#6440 and
#6230
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?: