Preserve logLevel for children of logger unless explicitly overridden.

[codyfrisch]

Right now, if I .createChild({serviceName: "FancyService"}) the logLevel resets to default because it is not specified. I would think that when I create the first parent, if I set the logLevel to "DEBUG" that would persist to children unless explicitly overwritten with a different value.

This way when I create an initial child after invocation, and getting the user profile (which includes a log level), this user loglevel will persist to any further children created where the service name may change.

Another concept is the ability to tell injectLambdaContext a key in the clientContext to check for loglevel. such as context.clientContext.logLevel as a string (I think?). Or even event.requestContext.authorizer.lambda.logLevel. This way the authorizer (or client invoking the lambda) can set the loglevel.

Any other strategies are welcome of course :)

[saragerion]

Thanks for sharing this ideas to improve the utility! Curious to hear what others think about it.

[shdq]

Right now, if I .createChild({serviceName: "FancyService"}) the logLevel resets to default because it is not specified. I would think that when I create the first parent, if I set the logLevel to "DEBUG" that would persist to children unless explicitly overwritten with a different value.

This way when I create an initial child after invocation, and getting the user profile (which includes a log level), this user loglevel will persist to any further children created where the service name may change.

Hello @codyfrisch

A child logger should have exactly the same parent's attributes, except attributes specified during the creation of a child, they will be overwritten. After that, parents and children live separate lives and can't influence each other.

For the first part of your question, this PR merged and fixed that. I think it is going to be available in the next release. But better ask @dreamorosi.

Another concept is the ability to tell injectLambdaContext a key in the clientContext to check for loglevel. such as context.clientContext.logLevel as a string (I think?). Or even event.requestContext.authorizer.lambda.logLevel. This way the authorizer (or client invoking the lambda) can set the loglevel.

Any other strategies are welcome of course :)

For the second part, I think you should describe it in detail and request a feature in the issues.

Thank you for using Lambda PowerTools!

[shdq]

I'm sorry for suggesting creating a feature request. I thought that issues are a good place to discuss the idea. Anyway, let's hear the details from @codyfrisch.

[codyfrisch]

In regard to why the client/caller (really the caller) should control the log level, is in production we need to restrict heavily what data gets into the logs under normal circumstances. Even for errors. The ability to log additional data on a per-customer basis is the motivation. I know there are many possible ways to tackle this though.

It sounds like the loggers loglevel can only be set when being instantiated, which is a limiting factor.

[dreamorosi]

I see what you mean and see the value in a multi tenant application. Logger & Powertools aside, I'm just not a fan of having a field in the context responsible of deciding the logging of a function. I could see however the function having logic that based on the tenant applies one logging level or another.

Anyway, incidentally, we have already a feature request that was opened a few days ago about this very topic (changing log level at runtime): #1265 - at the moment we are trying to gather use cases from customers so it'd be great if you could cross-link this discussion there

[codyfrisch]

Thanks for the heads up on that feature request.

As far as the logic that decides what logging to apply, that's actually happening in the lambda authorizer function on API Gateway and being put into the authorizer return context. So its not coming from an unknown source in my case, I'd just be determining what logging is needed where upfront then that carries through the various services in the rest of the chain.

[dreamorosi]

Okay, apologies for making assumptions, doing it in the authorizer makes sense.

Could I politely ask you to please add a +1 (thumbs up) to the issue I've linked? This will help us gather/measure interest in the feature.