Support log levels other than info and debug

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: https://github.com/kubernetes-sigs/aws-load-balancer-controller/issues/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.