Feature request: support `POWERTOOLS_LOG_LEVEL` environmental variable

[nateiler]

Use case

We were transitioning some lambdas from logging with Pino to Powertools and encountered a conflict when setting the LOG_LEVEL constant.

When setting the LOG_LEVEL constant to 'WARN', Pino would throw an error as it would expect warn.

Solution/User Experience

I'm proposing POWERTOOLS_LOG_LEVEL is added. It aligns w/ the other environment naming conventions yet allows for specific targeting for AWS Powertools without any side effects.

The current LOG_LEVEL would remain, but POWERTOOLS_LOG_LEVEL would take precedence if present.

Alternative solutions

No response

Acknowledgment

• This feature request meets Lambda Powertools Tenets
• Should this be considered in other Lambda Powertools languages? i.e. Python, Java, and .NET

Future readers

Please react with 👍 and your use case to help us understand customer demand.

[shdq]

Hi @nateiler 👋

Thank you for using Powertools Logger and opening this issue. It is safe to use lowercase values for log levels, look at the type definition and method responsible for log level setup. So you can set LOG_LEVEL constant to warn to satisfy pino, it will work with Logger correctly. Maybe we should clarify that in the docs.

For the proposal part, we should wait for the response from maintainers and thumbs-ups from the users.

Have a nice day!

[nateiler]

Ah, I should have dug a little deeper into the code.

Thanks for pointing that out!

[dreamorosi]

Hi @nateiler, thank you for opening the issue.

As @shdq also pointed out (thx!), you can now use both uppercase & lowercase versions of all log levels. This is a new feature that was launched in 1.6.0 last week. Prior to that only the uppercase version was allowed.

With this in mind, I would like to put the feature request temporarily on hold with the goal to understand if there's demand for this type of change.

I do see your point about consistency, and after looking at the Powertools toolkit in other versions I found out that Python uses the same as us (LOG_LEVEL), while Java and .NET use the proposed POWERTOOLS_LOG_LEVEL. I'd like to also take this discussion with the other teams and understand if there's a potential to converge on one or the other.

Personally, while I see the argument about consistency and scoping, I think LOG_LEVEL is a standard enough variable name for this purpose, as proven by the fact that other libraries use it too, so I'd be inclined to keep it for the time being.
However, like I said, if the feature request gathers enough momentum, and if we decide to converge with the other libraries I'd be happy to move to the POWERTOOLS_ prefixed version. I don't think we should support both, nor implement a resolution/priority logic for this, so if that happens it'll have to be considered a breaking change.

In the meanwhile, as a stop gap solution until an agreement has been reached, people who want to use non standard variable names can still do so, and then handle in their code the translation (although it's not the most elegant/ergonomic):

const logLevel = process.env.MY_CUSTOM_LOG_LEVEL_VARIABLE || 'INFO';
const logger = new Logger({ logLevel });