Skip to content

Support log levels other than info and debug #4061

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

Open
nikki-quant opened this issue Feb 18, 2025 · 2 comments
Open

Support log levels other than info and debug #4061

nikki-quant opened this issue Feb 18, 2025 · 2 comments
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature.

Comments

@nikki-quant
Copy link

Describe the feature you are requesting

Log entries for the load balancer controller are in JSON format and one of the fields is level which contains a severity level. There is a --log-level parameter supported as a runtime argument for the tool. However, that log level argument currently only supports setting either info or debug levels and not warn or error.

A bug was raised about this in 2021: #1820

As far as I can see, the logging remains the same in version v2.11.0 - info level messages are printed to stdout when passing --log-level=warn.

That previous issue describes the situation as follows:

the log-level flag currently can have only two values - info or debug. If anything else is specified, the debug level gets set on the logger. That is why you see debug logs when you specify level of error [...]

[...] due to the limitations of the current logging packages, we won't be able to safely support multiple log levels (other than info and debug) in the short term.

Four years later, I came across this ticket and wanted to ask whether there's plans to change this behavior on the roadmap.

Motivation

Being able to configure verbosity for third party applications like the Load Balancer Controller helps users keep log aggregation costs and query times down.

Describe the proposed solution you'd like

  • Configurable log levels to include warn and error
  • Documentation to clear supported log levels clearly

Describe alternatives you've considered

Currently if needed, my team filters out info level messages in our log aggregation tool. However, that either ends up very verbose (if we want a granular approach with per-chart log filtering) or very blunt (dropping those log levels for all applications, when we may want to collect more granular information from one application than another).

Contribution Intention (Optional)

-[ ] Yes, I am willing to contribute a PR to implement this feature
-[x] No, I cannot work on a PR at this time

I would be happy to help investigate options for this, but I don't have any background in go, so I would not be able to commit to implementing this myself.

@shraddhabang shraddhabang added the kind/feature Categorizes issue or PR as related to a new feature. label Feb 19, 2025
@shraddhabang
Copy link
Collaborator

@nikki-quant Thank you for raising this. I agree enhanced log level configuration (including warn/error) is important for efficient log management. We can definitely take this as feature request. Any community contribution would be welcome for this. :)

@shraddhabang shraddhabang added the good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. label Feb 19, 2025
@maeshinshin
Copy link

@shraddhabang Hi, I would like to work on this issue. May I assign this issue to myself?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

3 participants