Feature request: Log warning message if Advanced Logging Controls log level is less verbose than Logger level

[tknisch]

Use case

If I use the Logger for example at Debug level and the Advanced Logging Controls are set to Info I will not get the log messages printed.
It would be nice, the a warning message could be printed if this constellation is given.

Solution/User Experience

Print a warning message (configurable) if log messages would be suppressed by Advanced Logging Controls.

Alternative solutions

Acknowledgment

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

Future readers

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

[boring-cyborg]

Thanks for opening your first issue here! We'll come back to you as soon as we can.
In the meantime, check out the #typescript channel on our Powertools for AWS Lambda Discord: Invite link

[dreamorosi]

Hi @tknisch, thank you for opening this issue.

As we discussed on Discord, I think this is something we missed and should address.

We already have a way to detect whether Advanced Logging Controls is enabled and its level, so I think with some light refactoring we should be able to check that value and emit a warning if the log level is less verbose and log buffering is enabled.

We should also add a callout to the docs as additional measure.

Thank you for bringing this up!

[dreamorosi]

I've added the help-wanted label, so if anyone is interested in contributing please leave a comment and I'll assign the issue to you.

In terms of implementation, I think we should add some logic around here and call this.getEnvVarsService().getAwsLogLevel();. If the value of that variable is less verbose than the log buffering threshold, then we should call this.warnOnce() and let the customer know.

[ConnorKirk]

I can take a look

[dreamorosi]

Thank you @ConnorKirk - let me know if you need any help.

Ideally I'd like to include the change in the next release (~22/04), if plans change on your side let me know and we'll take over.

[leandrodamascena]

Hi, @dreamorosi. @anafalcao is working on this implementation in Python, just to make sure the idea of ​​the implementation here is clear.

We already issue a warning if the Powertools LogLevel is more verbose than ALC and this works as expected. But now we need to issue a new warning when the customer flushes the buffer so that the customer knows that the flush_buffer will have no effect.

If the idea is to enable based on the buffer level log I think we need to review this. I think it makes more sense when flushing, since that is where the data loss will occur.

WDYT?

[dreamorosi]

Imo we should just log a warning when you initialize the logger and these conditions happen:

• you enable log buffering
• the ALC log level is less verbose than log buffering

So for example if you set ALC to INFO (like this customer did) and enable buffering by default, you'd immediately get a warning telling you that you'll 100% lose data with this config, since whatever is buffered is automatically lost.

If we logged the warning upon flushing, you would never find out until you've lost the data.

It we log on init, you've got a chance to fix before the data is actually lost.

This is in line with the other init warning we emit when you set ALC less verbose than your log level. Since ALC is an env config, it makes sense to warn the customer as soon as we detect it.

[tknisch]

If we log on init, you've got a chance to fix before the data is actually lost.

From a customer perspective I would prefer this also.

If, for example I test my code on lower stages where the ALC is set to DEBUG I will not run into the problem.
Then I deploy to production where the ALC is set to INFO or above.
When the warning will be printed in error case first, we will miss logs.
But when it will be printed at initiation we will see this

[dreamorosi]

Had a quick chat with @leandrodamascena offline and he brought forward a good point.

The TL;DR; is that we should emit a warning once, both:

• when instantiating a new Logger instance
• when flushing the log buffer

The first one covers early detection, but the second one covers the actual moment of the data loss.

If we emitted the warning only during init, there's a non-zero chance that the warning could go unnoticed if the buffer is flushed at a much later point.

Because of this, we'll emit a warning in both cases.

Thank you @leandrodamascena.

[leandrodamascena]

Hey @anafalcao, please check this issue.

[anafalcao]

Thanks guys! It makes sense. I'll submit a PR this week for Python based on that.

[github-actions]

⚠️ COMMENT VISIBILITY WARNING ⚠️

This issue is now closed. Please be mindful that future comments are hard for our team to see.

If you need more assistance, please either tag a team member or open a new issue that references this one.

If you wish to keep having a conversation with other community members under this issue feel free to do so.