Description
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
anderror
- 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.