Skip to content
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

feat(server): cmd flag to disable colored logs #18478

Merged
merged 10 commits into from
Nov 19, 2023
Merged

Conversation

robert-zaremba
Copy link
Collaborator

@robert-zaremba robert-zaremba commented Nov 15, 2023

Description

Ref: #13699

Colored logs should be optional. Enforcing colored logs will make the log capture ugly and non dev friendly.
Common use case is to stream logs to a logging service (eg Google logs). With colored logs, this will contain all color codes, making the log browsing very unfriendly.

This PR adds a new global flag: log_colored. By default it's false (so this PR changes the default behavior), meaning that logs are not colored by default. When set, just by adding --log_colored the behavior will be as "now". This setting is more system friendly.

Note, I was thinking to use more traditional name scheme with - for connecting words (so log-colored instead of log_colored), but other log related flags are using _ (eg: log_level).


Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

  • included the correct type prefix in the PR title
  • added ! to the type prefix if API or client breaking change
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • followed the guidelines for building modules
  • included the necessary unit and integration tests
  • added a changelog entry to CHANGELOG.md
  • included comments for documenting Go code
  • updated the relevant documentation or specification
  • reviewed "Files changed" and left comments if necessary
  • run make lint and make test
  • confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

  • confirmed the correct type prefix in the PR title
  • confirmed ! in the type prefix if API or client breaking change
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic
  • reviewed API design and naming
  • reviewed documentation is accurate
  • reviewed tests and test coverage
  • manually tested (if applicable)

Summary by CodeRabbit

  • New Features

    • Introduced a new command-line flag to enable or disable colored logs, enhancing user control over log output preferences.
  • Refactor

    • Consolidated log options to simplify the logging setup process.
  • Documentation

    • Updated CHANGELOG.md to reflect the new flag for controlling log colorization.

@robert-zaremba robert-zaremba added C:CLI C:log C:server/v2 Issues related to server/v2 labels Nov 15, 2023
@robert-zaremba robert-zaremba requested a review from a team as a code owner November 15, 2023 17:52
Copy link
Contributor

coderabbitai bot commented Nov 15, 2023

It seems that the existing content is still valid, so I'll repeat it verbatim in my response:

Walkthrough

The changes involve the introduction of a new feature for controlling log colorization across various files in a codebase. A flag has been added to toggle colored logging, which is then utilized in the logger creation function to set the appropriate logging options. This update is consistent across client and server components, enhancing user control over log output aesthetics.

Changes

File Path Change Summary
client/flags/flags.go Introduced new flags (FlagColorLogs, FlagLogColored, FlagLogNotColored, FlagLogNoColor) for controlling log colorization.
server/cmd/execute.go Added persistent flags (FlagColorLogs, LogColored, LogNotColored) to the root command for colored log toggling.
server/util.go Updated CreateSDKLogger function to include a color option based on the new log colorization flags and adjusted trace logging options.
CHANGELOG.md Documented the addition of new command-line flags for disabling colored logs in the server.

Poem

In the code where the logs do bloom, 🌼
A rabbit hopped in, avoiding the gloom. 🐇
With flags in hand and colors to spare,
It tweaked the hues with utmost care. 🎨


Tips

Chat with CodeRabbit Bot (@coderabbitai)

  • If you reply to a review comment from CodeRabbit, the bot will automatically respond.
  • To engage with CodeRabbit bot directly around the specific lines of code in the PR, mention @coderabbitai in your review comment
  • Note: Review comments are made on code diffs or files, not on the PR overview.
  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Commands (invoked as PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai help to get help.

Note: For conversation with the bot, please use the review comments on code diffs or files.

CodeRabbit Configration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • The JSON schema for the configuration file is available here.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json

@github-prbot github-prbot requested review from a team, facundomedica and likhita-809 and removed request for a team November 15, 2023 17:52
@github-actions github-actions bot removed the C:log label Nov 15, 2023

This comment has been minimized.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Status

Actionable comments generated: 1

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between e64f3bc and debb6ab.
Files selected for processing (3)
  • client/flags/flags.go (1 hunks)
  • server/cmd/execute.go (1 hunks)
  • server/util.go (2 hunks)
Files skipped from review due to trivial changes (2)
  • client/flags/flags.go
  • server/cmd/execute.go
Additional comments: 1
server/util.go (1)
  • 197-200: The addition of the log level option is correctly implemented and the removal of the duplicate log.TraceOption from the previous version is a good cleanup. The code now correctly sets the log level based on the FlagLogLevel value from the context.

server/util.go Outdated Show resolved Hide resolved
@robert-zaremba
Copy link
Collaborator Author

I'm adding a backport to v0.47. We had that functionality in our v0.46 fork, and would like to have that option in v0.47, otherwise our logging service will be less friendly.

@robert-zaremba robert-zaremba added the backport/v0.47.x PR scheduled for inclusion in the v0.47's next stable release label Nov 15, 2023
@julienrbrt
Copy link
Member

We should keep it on by default imho. Only v0.46 didn't had it on.

@julienrbrt julienrbrt added the backport/v0.50.x PR scheduled for inclusion in the v0.50's next stable release label Nov 15, 2023
client/flags/flags.go Outdated Show resolved Hide resolved
server/util.go Outdated Show resolved Hide resolved
@@ -28,6 +28,7 @@ func Execute(rootCmd *cobra.Command, envPrefix, defaultHome string) error {
rootCmd.PersistentFlags().String(flags.FlagLogLevel, zerolog.InfoLevel.String(), "The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:<level>,<key>:<level>')")
// NOTE: The default logger is only checking for the "json" value, any other value will default to plain text.
rootCmd.PersistentFlags().String(flags.FlagLogFormat, "plain", "The logging format (json|plain)")
rootCmd.PersistentFlags().Bool(flags.FlagColorLogs, false, "Enable colored logs")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
rootCmd.PersistentFlags().Bool(flags.FlagColorLogs, false, "Enable colored logs")
rootCmd.PersistentFlags().Bool(flags.FlagColorLogs, true, "Enable colored logs")

Or switch the flag name to disable color

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?

Copy link
Member

@julienrbrt julienrbrt Nov 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because it should stay enabled by default. It was on in v0.45, v0.47 and v0.50. v0.46 was an exception because the logger was reverted to comet logger.

Additionally the PR mentions a flag to disable the logger, so I don't expect a behavior change here (turning off the coloring by default).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Normally non colored logs are the default in software. I would consider default=colored setting as a "soft bug".
But if everyone wants to keep colored by default, then fair enough. Will wait for one more comment.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I understand and agree that logs should be clean, we should focus on majority usage and expectations plus keeping expectations as they are. Please read about Hyrum's law https://www.hyrumslaw.com/
I am with @julienrbrt that we shouldn't just be turning off long standing behavior. Most users expect the colored lines to help them find out what's tripping or interesting events.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough. So maybe last question - do we want to conduct a quick survey with other projects before we finalize the decision about the default.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think, inverting the change later on is a much easier process and it'll allow you to get your commit in as we collect data. Essentially I'd say, let's get it to the current defaults, meantime when running your node, turn off coloring, then put out a survey asking folks about the problem and give it time so you get sufficient data and once ready, just flipping an opposite will be a trivial commit :-)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no other comment, and both of you prefer to keep the "current" defaults => I will do the update.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've renamed the flag to FlagLogNotColored. Boolean flags should be false by default.

@tac0turtle
Copy link
Member

We can't guarantee flags will stay the same in server v2. I'd propose we have an app.toml variable for which logger is used, json, default(colored), noncolored. This way the config will feed into things already in use. Secondly apps can pass their own custom logger if needed

@robert-zaremba
Copy link
Collaborator Author

I'd propose we have an app.toml variable for which logger is used

Isn't viper already doing that?

If not, I would say that this should be done be a separte PR. The scope of this PR is to follow what is currently in the upstream.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between debb6ab and 5570800.
Files selected for processing (4)
  • CHANGELOG.md (1 hunks)
  • client/flags/flags.go (1 hunks)
  • server/cmd/execute.go (1 hunks)
  • server/util.go (2 hunks)
Files not reviewed due to errors (1)
  • server/util.go (Error: Server error. Please try again later.)
Files skipped from review due to trivial changes (3)
  • CHANGELOG.md
  • client/flags/flags.go
  • server/cmd/execute.go

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between 5570800 and 5fbe2f2.
Files selected for processing (2)
  • CHANGELOG.md (1 hunks)
  • server/util.go (2 hunks)
Files not reviewed due to errors (1)
  • server/util.go (Error: Server error. Please try again later.)
Files skipped from review due to trivial changes (1)
  • CHANGELOG.md

Copy link
Collaborator

@odeke-em odeke-em left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this change @robert-zaremba! I just made a comment about keeping the original behavior instead of unexpectedly turning it off for your use case: majority of the users were used to colored logs.

server/cmd/execute.go Outdated Show resolved Hide resolved
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Status

Actionable comments generated: 1

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between 5fbe2f2 and 17020cc.
Files selected for processing (3)
  • client/flags/flags.go (1 hunks)
  • server/cmd/execute.go (1 hunks)
  • server/util.go (2 hunks)
Files skipped from review due to trivial changes (2)
  • client/flags/flags.go
  • server/cmd/execute.go
Additional comments: 1
server/util.go (1)
  • 198-201: The logger level is correctly set based on the parsed log level string. This is a good use of the zerolog package's level parsing capabilities.

server/util.go Outdated Show resolved Hide resolved
@julienrbrt
Copy link
Member

julienrbrt commented Nov 17, 2023

I dont think this is needed. You can set an environment variable to turn it off: NO_COLOR=true or set a custom logger for your node. I believe if you log in json there will not be any color?

Wow TIL. That is true (https://github.com/rs/zerolog/blob/bb14b8b9de1133342fce9aff0158b354ec72f08c/console.go#L323-L333), this PR isn't needed then indeed.

@robert-zaremba
Copy link
Collaborator Author

this PR isn't needed then indeed.

Good to know about the zerolog env variable. However, it's not documented in SDK, and I bet 99% are not aware about it.
CLI is always better, because it's self documented and clear.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between 17020cc and 7809c4c.
Files selected for processing (1)
  • client/flags/flags.go (1 hunks)
Files skipped from review due to trivial changes (1)
  • client/flags/flags.go

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between 7809c4c and ff6d836.
Files selected for processing (1)
  • server/util.go (2 hunks)
Additional comments: 2
server/util.go (2)
  • 173-179: The changes here correctly implement the new feature to control log colorization based on the log_colored flag. The use of !ctx.Viper.GetBool(flags.FlagLogNoColor) is appropriate to toggle the color option. However, ensure that the FlagLogNoColor constant is correctly defined and corresponds to the log_colored flag mentioned in the summary. Also, verify that the default value of this flag is indeed false as intended.

  • 198-201: The removal of the redundant log.TraceOption and consolidation with the existing options is a good simplification. Ensure that the FlagTrace constant is correctly defined and used throughout the codebase.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between ff6d836 and 04e9d94.
Files selected for processing (1)
  • server/cmd/execute.go (1 hunks)
Files skipped from review due to trivial changes (1)
  • server/cmd/execute.go

Copy link
Member

@julienrbrt julienrbrt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

Copy link
Collaborator

@odeke-em odeke-em left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you for the inversion @robert-zaremba! However, after @tac0turtle's discovery of the environment variable toggle, should we perhaps document or proceed otherwise with this PR? I personally vote to proceed with this PR as it won't be an implementation detail but even more keeps the code highly configurable just by our start time flags.

@julienrbrt
Copy link
Member

+1 to have this explicit.

@julienrbrt julienrbrt added this pull request to the merge queue Nov 19, 2023
Merged via the queue into main with commit 8c7e694 Nov 19, 2023
61 of 62 checks passed
@julienrbrt julienrbrt deleted the robert/color-logs branch November 19, 2023 14:51
mergify bot pushed a commit that referenced this pull request Nov 19, 2023
(cherry picked from commit 8c7e694)

# Conflicts:
#	CHANGELOG.md
julienrbrt added a commit that referenced this pull request Nov 19, 2023
)

Co-authored-by: Robert Zaremba <robert@zaremba.ch>
Co-authored-by: Julien Robert <julien@rbrt.fr>
julienrbrt added a commit that referenced this pull request Nov 19, 2023
)

Co-authored-by: Julien Robert <julien@rbrt.fr>
@robert-zaremba
Copy link
Collaborator Author

@odeke-em documenting zerolog dependency is not part of this PR, and CLI thankfully is self explanatory.
I agree that we should document zerolog though.

@faddat faddat mentioned this pull request Mar 20, 2024
12 tasks
emidev98 pushed a commit to terra-money/cosmos-sdk that referenced this pull request Mar 21, 2024
@faddat faddat mentioned this pull request Nov 8, 2024
12 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport/v0.47.x PR scheduled for inclusion in the v0.47's next stable release backport/v0.50.x PR scheduled for inclusion in the v0.50's next stable release C:CLI C:server/v2 Issues related to server/v2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants