Feature request: Reusing previous logger instance when already instantiated

[RobinGroundfog]

Use case

As far as I can tell, calling new Logger() instantiates a new logger, which means we can't access previously appended keys across the code.

Solution/User Experience

It would be great if a new instance that uses the same service name - env var or explicit parameter - would reuse a previous Logger instance, as it's the case for the Python Powertools

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.

[dreamorosi]

Hi @RobinGroundfog, thank you for taking the time to open an issue in this repo.

You are right, at the moment all the core utilities including Logger are not singletons and creating a new instance does create an instance that is completely separated by the original one.

This is a topic that has come up in the past and that has been discussed (#777) and tested (#767) but ultimately discarded.

The usage that we would like to promote, at least until new information/use cases come up, is to create a module where you instantiate your Powertools utilities like src/powertools.ts which you can then use throughout your project:

import { Logger } from '@aws-lambda-powertools/logger';
import { Metrics } from '@aws-lambda-powertools/metrics';
import { Tracer } from '@aws-lambda-powertools/tracer';

const awsLambdaPowertoolsVersion = '1.8.0';

const defaultValues = {
  awsAccountId: process.env.AWS_ACCOUNT_ID || 'N/A',
  environment:  process.env.ENVIRONMENT || 'N/A'
};

const logger = new Logger({
  persistentLogAttributes: {
    ...defaultValues,
    logger: {
      name: '@aws-lambda-powertools/logger',
      version: awsLambdaPowertoolsVersion,
    }
  },
});

const metrics = new Metrics({
  defaultDimensions: defaultValues
});

const tracer = new Tracer();

export {
  logger,
  metrics,
  tracer,
};

For Logger specifically, you can then import the logger elsewhere and optionally create children that override some of the settings:

// src/index.ts
import { logger } from './powertools';

export const handler = async () => {
  logger.debug('...');
};

or src/my-other-module.ts:

import type { Logger } from '@aws-lambda-powertools/logger;
import { logger } from './powertools';

export class MyUtility {
  private logger = Logger;

  public constructor() {
    this.logger = logger.createChild({ logLevel: 'CRITICAL' });
  } 
};

Using this type of pattern removes any kind of ambiguity around module import order which might cause confusion as detailed here, and still allows you to reuse the same instance throughout your code.

We have already updated our examples to use this pattern but we haven't yet gotten around creating a dedicated section that explains this in the docs. This effort is tracked in #777 and we'll try to address it as soon as possible.

I'm going to close this issue as duplicate of #777, if you'd like to bring additional information and/or use cases around this topic please feel free to do so in that issue so we can keep track of all points of view in a single place.

[github-actions]

⚠️ COMMENT VISIBILITY WARNING ⚠️

Comments on closed issues 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.